arturosm
asked on
Estimating suitable log file size (MSSQL Server)
Hi Experts.
I have an application that uses MS SQL Server. The application does not uses transactions explicitly but as I understand, applications create or use default transactions. The fact is, that the log file is growing and I need to reduce it. The client is asking me to recommend a minumum log file size suitable for the application but I have no idea how to calculate such size, based on how my program works. So my question would be:
How do you calculate the espace needed for an application, regarding the log size (MS SQL Server) based on the instructions you send to the database (inserts, updates, etc)?
Note: as I don´t use explicit transactions that log information is useless for my application.
Thank you in advance.
I have an application that uses MS SQL Server. The application does not uses transactions explicitly but as I understand, applications create or use default transactions. The fact is, that the log file is growing and I need to reduce it. The client is asking me to recommend a minumum log file size suitable for the application but I have no idea how to calculate such size, based on how my program works. So my question would be:
How do you calculate the espace needed for an application, regarding the log size (MS SQL Server) based on the instructions you send to the database (inserts, updates, etc)?
Note: as I don´t use explicit transactions that log information is useless for my application.
Thank you in advance.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Your database breaks one second before the daily backup. You lost all the transactions for the last 24 hr. That is pretty much unacceptable for almost all the cases.
A simple recovery is not recommendable to a production environment unless you have a case where you update the database periodically through some import or syncing process but even then is risky.
There is no justification not to use full recovery as it is not at all a very complicated process. It can be set up through the Maintenance plan wizard in minutes.
A simple recovery is not recommendable to a production environment unless you have a case where you update the database periodically through some import or syncing process but even then is risky.
There is no justification not to use full recovery as it is not at all a very complicated process. It can be set up through the Maintenance plan wizard in minutes.
ASKER
Thank you.
ASKER
thanks for your responses. I know the client backup the database daily and the application does not uses the log data, never. For me, this log issue is just a secondary effect of using MS SQL Server. What would be the worst scenario of using simple recovery model?
Regards.