All,
In thinking about Yi Lu's imminent problem with the Firebird transaction number
size, I am wondering if as developers we have overlooked the "reasonableness"
of the situation (actually the lack thereof).
Reality: a simple backup / restore cycle is all that needs to be performed to
resolve the issue.
Reality: All systems require maintenance. Yi Lu described database usage of 24
x 7 x 365 is "mythical".
Reality: There are a handful of systems worldwide which have the same level of
transactions (120 trans/sec - 10 Million per day). So this is not a 99%
problem or even a 99.9% problem. This is a 99.999999% problem.
Reality: A review of the Uptime/SLA guarantees of a number of ISP or Hosted
solution providers finds values ranging between 99.9 or 99.95%.
Reality: 99.9% uptime provides for 3.65 *days* of downtime annually, 99.95%
uptime provides for 1.825 days of downtime.
Reality: Even an extreme 99.99% uptime provides for 8.76 hours of downtime.
So, I would suggest that no further changes to FB be made to increase the
transaction limit (beyond the v3 changes) and that the answer to Yi Lu should
be: arrange a maintenance period and perform a backup/restore.
Sean
------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
