Impacts During And After The Shrink - The Best Practice For Transaction Logs Shrink

News Knowledge Base
#1

What can aid to advise any impacts during and after the shrink? Do we need to stop all jobs and processes in UiPath or even stop database connection? Can any best practices be shared for transaction logs shrink?

Resolution : There should not be any impact while doing shrink operation, although this should not be performed on a regular basis.

This must remain an exception only because the transaction log file grew too much. It should figure out why the log file grew so much. If its running 24/7 and it seems important, backup strategy should be planned accordingly.

  • If a single backup once a week for example is sufficient and if Point in time recovery is not required, then a switch to Simple recovery model can be recommended.
  • If the log file grows much huge when using Full recovery model, that might be because enough Transaction Log backup (i.e. every 5 to 30 min on DB with lots of transaction or less on smaller one) is not performed or some huge query is run that does moving lot of data without frequent Transaction log backup.

If Full recovery model is used, perform the below:

  1. Take a Transaction log backup (current usage should be close to 0%)
  2. Shrink to the desired size (500MB or 1GB or more than the current usage)
  3. Repeat steps 1-2. if file size does not go down enough. It may take several run on large files.

If Simple recovery model is used, perform the below:

  1. Shrink to the desired size (500MB or 1GB or more than the current usage)
  2. Repeat steps1-2. if it doesn’t go down enough. It may take several run on large files.

In the end, a file with a size around 5MB or 1GB should be manageable. Growth should be set to a similar value (500 or 1GB but not X%).