- Solutions
-
- File Server: Ransomware Protection
- File Server: File Copy
- File Server: Audit File Access
- File Server: Storage growth reporting
- Licensing/Pricing
- Contact
Everytime a insert, update or delete happens on a database table, the activity is written to the database's Transaction Log File. And although we'll be talking specifically about Microsoft SQL Server, this is true for most database systems.
Sometimes there will be a change to the product that will require a lot of background database activity. Some recent examples:
One setting that can have a very large impact on the Transaction Log file size is the Recovery Model. This page does a good job discussing the differences:
Briefly, the SIMPLE recovery model will reuse space in the Transaction Log file, while the FULL recovery model requires the Transaction Log to be backed up before space can be reused. However, the FULL model allows point-in time recovery of the database which the SIMPLE model does not. FULL is the default setting.
When the Transaction Log becomes very large the inclination is to truncate the log file. This can't be done if the Recovery Model is FULL (unless the log is first backed up). So many people will run the following commands:
ALTER DATABASE {your database name here} SET RECOVERY SIMPLE GO DBCC SHRINKFILE ({your database name here}_log, 1) GO ALTER DATABASE {your database name here} SET RECOVERY FULL
It is also recommended to take a look at how large SQL Server will let your Transaction Log grow before (in SIMPLE Recovery Mode) it starts to re-use the log space. This can be seen in the database settings as shown below:
“[ PA Server Monitor's benefit is less] wasted labor in tracking what was unbillable - that now ADDS a LOT more BILLABLE time addressing issues we just could not get to before - making networks we manage much more stable and reliable. WE do a BETTER job for our clients and capture time we basically 'gave away' before.”
Oly G., On-Site Computer Solutions, USA