If you need a very really large log volumn, probably you are using wrong backup strategies.
When anyone need a log > 60% data, is because it's running in ETL (data import/export). In this case, you can deactivate log.
If you are making a "fly bill sell app", then even 100% of data size could be acceptable... But remember, if your database is large, then you will be higly recomended, in this case, to maintain your log in a separate mirror than your data files (a client mine have 5 disks: 2 mirrored for LOG only, and 3 in a Strip with Parity for SO and data - and even in this case, besides Log being 50% of data, we never seen it greater than 30% full).
In case of database lost, we can backup transaction log, load last data backup and then load the transaction log - up to latest minute before crash.
Whell, we can take a day talking about strategies, sizing and backups... I think you really should look for documentation about database administration concepts (I like some written for MS SQL and the Oracle ones are really complete in this subject).
The concepts are applyable to MaxDB, besides under different names sometimes.
Best regards,
Edson Richter
Andris Spruds wrote:
Hi,
if you define a too small log size, you will have a lot of log backups,
decreasing general database performance. I have just one question left: what are the consequences if I define too large log size?
I expect this been helpful.
Thank you very much for your asnwer. Indeed, it helped me a lot.
Andris Spruds
-- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
