You are viewing limited content. For full access, please sign in.

Question

Question

Laserfiche SQL DB logs increasing rapidly

Laserfiche Administration
Updated April 3, 2017
asked on March 5, 2017

Hi

 

We have more than 5 repository in the Laserfiche server. Recently we noticed only one repository's SQL Database log started increasing rapidly, almost 100GB in a day. Hence we need to shrink the log every day.

The current size of SQL Data file size is 12GB, but it does not seems to be increasing in the SQL server.

The Laserfiche application does not seems to be having much load to create such huge logs. Do you have faced the same type of issue?

 

How we can come out of this issue?

 

Regards

Kirubaa

0 0

Replies

replied on March 6, 2017

Hi Kirubaa,

 

Do you have the transaction model set to full or simple?

 

Cheers!

2 0
replied on March 22, 2017

If you must use Full recovery mode instead of Simple, then you must back up the transaction logs as well as the database.  Or you can also manually (or scripted) shrink your transaction logs.

USE yourdb;
GO
DBCC SHRINKFILE(yourdb_log, 200);
GO

Also see Shrinking the Transaction Log

2 0
replied on March 18, 2017

Hi Chris,

It is full mode when the log is increasing.

Transaction log never grows when its in Simple model.

 

Cheers!  

0 0
View 2 previous replies
replied on March 20, 2017

Hi Krubaa,

 

Do you understand the difference between the 2? One allows for point in time recovery, but that is only applicable if you are replicating the volumes live. The other will allow backup restore time. You are probably best setting it to simple if you are running overnight backups.

 

This article is a pretty good read....

https://technet.microsoft.com/en-us/library/ms366344(v=sql.105).aspx

4 0
replied on March 22, 2017

Hi Chris,

 

Thanks for the reply!

We need to have the DB in Full recovery model, as it is supported to have mirroring on DB in Disaster recovery zone.

 

 

0 0
replied on March 22, 2017 • Show version history

Hi Kirubaa,

 

Awesome smiley, but if you aren't live replicating your Laserfiche volumes also, then there is little point to having a full recovery model. wink

 

It's also important to perform regular full backups of your SQL database to keep the full transaction logs small.

0 0
replied on April 2, 2017

Hi Chris,

 

Yes We have replicating the laserfiche repository folders completely. SQL full backup scheduled weekly basis, and log backup daily.

So it is possible to keep the log shrinking to happen after full backup, but during the problem is log is growing about 100 GBs in a day. Identifying the reason is harder.

 

Any clue!

0 0
replied on April 3, 2017

The full transaction log will log all changes in the DB to allow a point in time restore. The rate at which this grows will depend on the amount of changes happening, the more changes going on, the more it will grow and the more disk space you will need in order to track and keep a log of these changes. The simple model doesn't log quite as many changes, thus it doesn't grow anywhere near as big or as fast. Unless you are live replicating your laserfiche volumes there is little benefit to having a full transaction log type set as the DB and volumes must match excatly in order to be of any use.

If you are going to use a full transaction model type then you need to have a SQL backup/maintenance plan in place to truncate or maintain these log files which is only available in an automated way through full SQL (SQL Standard or higher). You can still run maintenance tasks in SQL express but there is no way to automate them. If you are having SQL issues, then I would certainly recommend reaching out to a local SQL/DBA resource in your local area to come and take a look with you. wink

1 0
You are not allowed to follow up in this post.

Sign in to reply to this post.

Details
Related Posts
Loading ...