Session Properties

There are some properties that you can configure for a session
Fail parent if task fails: The workflow is said to be the parent of a session. So if the session fails,
the whole workflow fails and you can see this in the monitor
Write compatible Log: by default Informatica creates log files in .bin format; we can create
them in .txt format by selecting this option in the session properties.
Bulk vs. normal load: bulk load is faster but it has some prerequisites to it like the target table
should not have any constraints or indexes defined for it. We try to use the bulk mode as much
as possible but if not possible we use the normal mode.
Save session log: we can specify the number of runs for which we need to save the session log
for. We can specify it as 5 runs or 10 runs or as many as we like but the log files take up some
space so we shouldnt save them for too many runs.
Pre-post sql: this applies to both source and target so you can run some independent SQL
queries before and after a session for example drop some index before you load a target table
and create an index after youre done loading.
Email task: email can be sent before starting a session, after completing the session or upon
session failure. You can also run a command task, OS command before running your session or
after completing the session

1. Fail Parent if Task Fails

You can find this option in the General tab of the session properties

When you check this option youre specifying that the complete workflow should fail if this session fails.
For example if there is an error in the connection string or in any other session property, the session will
fail. If the Fail parent if task fails options not checked, the task failure wont effect the workflow, it will
continue to run as normal and execute other sessions and tasks connected to it. But if this oprion is
checked, as soon as the session fails, the complete workflow halts and enters the failed state. The cause
of the error can be seen in the workflow monitor session logs.
For example in the session that we created earlier, if we alter the source tables connection, the task will
fail, causing the complete workflow to fail.

2. Write Compatible Log

This option can be found in the Properties tab in the session properties

If Write Backward Compatibility Session Log File option is checked under the Informatica session
property settings, then it will write the workflow or session logs into a text file(You can find the session
log files under server directory: \infa_shared\SessLogs)
If the Write Backward Compatibility Session Log File option is not checked, then the integration service
creates the binary log only(session log files are in binary format by default). So if you dont give Write
Backward Compatibility Session Log File then it will give a binary format of the session log file.

3. Bulk vs. Normal Load

This option can be found in the Mapping tab of the target

Bulk loading, improves the performance of a session that inserts a large amount of data to the target
database. When bulk loading, the Integration Service bypasses the database log, which speeds
performance. Without writing to the database log, however, the target database cannot perform
rollback. As a result, you may not be able to perform recovery.
In normal load the database log is not bypassed and therefore the target database can recover from an
incomplete session.
When you are using bulk load, if there are any indexes defined on the table, you have to drop them
before loading. After the data is loaded, you can enable or recreate the indexes. If you did not drop the
indexes session will fail.
Bulk load is used when you are loading large amount of data (more than 100GB). Bulk load makes the
data loading faster.

4. Save Session Log

This option can be found in the Config Object tab in the session properties

You have the option to save the session log file by either session runs or timestamp. When you set the
option as a session run, informatica saves a specific number of session log files. You can set the number
of log files to be saved in the Save Session Log for These Runs option.
This option allows you to define the number of session log files you wish to save in order to maintain the
history of log files. By default the session log files are overwritten. The maximum number of history you
can maintain is 2,147,483,647. But you shouldnt save them for many runs as the consume space.

5. Pre-Post SQL
This option can be found in the Mapping tab of both the Source and the Target.

Using these you can run some independent SQL queries before and after a session. For example we
want a speedy load process for the target table so we should use the Bulk load type but the target table
has a few indexes defined on it. The bulk load does not support tables with indexes defined on them so
this is where well use the pre and post SQLs. In the Pre-SQL well drop the index on the target table and
in the Post-SQL well recreate the index. This way the bulk load type will be used.

6. Email
The email option can be found in the Components tab in the session properties

This is a useful property of as you can notify the support team in case of any failures in the session task.
You can also send an email after the successful completion of the task.

7. Stop on Errors
This option is found in the Config Object tab of the session properties.

This property specifies the number of errors before which the session is stopped and failed. By default
the value is 0 but it is a good practice to set it to 1 as most of the sessions are run at the night when
there are not many developers around but only the support team monitoring the session runs.
For example if we have duplicate rows coming from the source which has a primary key defined on it,
the session will fail when it encounters the first duplicate row and none of the other rows will be loaded
into the target. If the value of Stop on Errors property was set to 0 then the duplicate row will be
discarded, written to the .bad file and the rest of them would be loaded to the target.

8. Commit Interval
This option is found in the Properties tab of the session properties.

In Informatica, the Commit Interval Property helps the Integration Service commit rows to targets based
on the commit interval. By default the value is set to 10,000 records, this means that Informatica
requests the database to commit the rows after the insertion of every 10,000 records. This value can be
increased if you have a large amount of data.
If the session fails for some reason then, the Integration Service rolls back to the last commit point, The
roll back depends on the commit interval configured in the session.