As diagnostics functionality tends to be very useful most implementers when arriving at a site immediately enable all diagnostics. In case of profile option “SLA: Enable Diagnostics” this might cause more bad than good, and here is why:

First of all it’s important to understand the basic concept of SLA. When SLA creates accounting it doesn’t physically store all the data from the subledgers into the XLA tables. Instead SLA uses views to look directly at the subledger data it requires (you can see these views in the SLA Accounting Event Class Options window under the Transaction Objects tab).

But when profile option “SLA: Enable Diagnostics” is set to Yes, SLA will not only look at the subledger data through the abovementioned views, but it will also physically copy over all that data into an SLA diagnostics table (XLA_DIAG_SOURCES).

The reason why SLA does this is because you enabled SLA diagnostics so SLA expects that you will want to run the Transaction Objects Diagnostics report. But in order for this report to be able to pick up data, SLA first needs to make the data available, therefore it copies over all the subledger data to the SLA tables so afterwards the Transaction Objects Diagnostics report can print the data for you.

This copy process happens during Create Accounting so when you run Create Accounting while the profile option is set to Yes you should also notice a decrease in the Accounting Program’s performance (because all the inserts into XLA_DIAG_SOURCES are being executed).

Correct order of events when diagnosing SLA:

1. Enable profile option “SLA: Enable Diagnostics”
2. Run “Create Accounting”
3. Disable profile option “SLA: Enable Diagnostics”
4. Run “Transaction Objects Diagnostics” report
5. Run “Purge Transaction Objects Diagnostics”

Conclusion

Keep the profile option away from so-called “overenthusiastic profile option switchers”. I’ve seen a case where the profile option was set to Yes at Site level meaning every single run of Create Accounting copied all source data to the XLA scheme eventually causing the database to run out of space. Although this was in a DEV instance without security policy it still proves that this (and in fact any) profile option should be handled with care - if you don’t know it then please don’t touch it.

When you do use the profile option then use it as it was intended to be used: run Create Accounting for a very small amount of data. It really doesn’t make any sense to try and diagnose a large volume of data because you will get lost in the Transaction Objects Diagnostics’ output file.

When you’re done diagnosing do not forget to switch the profile option back to No.

As soon as you’ve run your Transaction Objects Diagnostics report you can run Purge Transaction Objects Diagnostics request. This will purge the diagnostics data from XLA_DIAG_SOURCES. You can still continue looking at the data because that’s saved in the Transaction Objects Diagnostics’ output file.