You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Recent discussion shown that for many users the fact that long-living transaction may in some conditions uncontrollably inflate database with gigabytes of temporary blobs is unexpected if not confusing.
It does not help, that long-living read-only transaction are told in many FAQs as a valid if not recommended way to work with data (and having parallel short transactions for changing them)
In particular, even read-only requests in read-only transactions (like fetching from calculated columns or views) tend to uncontrollably write a lot of data into database file, which is counterintuitive and i think can be considered as a "gotcha" or trap for novices.
I believe that - until the implementation changes so that temp blobs would be reclaimed before transaction end, and for those versions where this would not be backported to - documentation should proactively warn users about the possibility of this counter-intuitive and damaging scenarios.
This would include:
1) documentation of read-only and/or long-alive transactions: should note that some r/o-looking operations are actually attempts to write data into the database file.
1.1) ditto for read-only database mode
2) documentation of blob concatenations and LIST function (and any other operation, potent of temp blob creation. Typecasts ? UDFs ? whatever? ): should have a notice that this requires write operations on database file and can expand that file with no limits until full-COMMIT or full-ROLLBACK executed
3) documentation of Autonomous Transactions should notice that they do not free associated resources themselves, and as such can uncontrollably increase temporary blobs amount for their parent transaction
4) documentations about monitoring and tools extracting database statistics: should include a pattern, that implies the user really stepped over those rooks.
Probably this should be formed as a separate errata-like document that would be referenced and linked to form the places outlined above.
The text was updated successfully, but these errors were encountered:
Submitted by: Arioch (arioch)
Recent discussion shown that for many users the fact that long-living transaction may in some conditions uncontrollably inflate database with gigabytes of temporary blobs is unexpected if not confusing.
It does not help, that long-living read-only transaction are told in many FAQs as a valid if not recommended way to work with data (and having parallel short transactions for changing them)
In particular, even read-only requests in read-only transactions (like fetching from calculated columns or views) tend to uncontrollably write a lot of data into database file, which is counterintuitive and i think can be considered as a "gotcha" or trap for novices.
I believe that - until the implementation changes so that temp blobs would be reclaimed before transaction end, and for those versions where this would not be backported to - documentation should proactively warn users about the possibility of this counter-intuitive and damaging scenarios.
This would include:
1) documentation of read-only and/or long-alive transactions: should note that some r/o-looking operations are actually attempts to write data into the database file.
1.1) ditto for read-only database mode
2) documentation of blob concatenations and LIST function (and any other operation, potent of temp blob creation. Typecasts ? UDFs ? whatever? ): should have a notice that this requires write operations on database file and can expand that file with no limits until full-COMMIT or full-ROLLBACK executed
3) documentation of Autonomous Transactions should notice that they do not free associated resources themselves, and as such can uncontrollably increase temporary blobs amount for their parent transaction
4) documentations about monitoring and tools extracting database statistics: should include a pattern, that implies the user really stepped over those rooks.
Probably this should be formed as a separate errata-like document that would be referenced and linked to form the places outlined above.
The text was updated successfully, but these errors were encountered: