Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Temporary BLOBS tends to unexpectedly inflate database file [DOC89] #99

Open
firebird-automations opened this issue Jul 29, 2013 · 1 comment

Comments

@firebird-automations
Copy link

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.

@firebird-automations
Copy link
Author

Commented by: Arioch (arioch)

Discussion in russian: http://www.sql.ru/forum/516139-a/bystryy-rost-obema-bazy-interbase-firebird

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants