cancel
Showing results for 
Search instead for 
Did you mean: 

Transaction log error

I am receiving an error that:

Log Name:      Application
Source:        Enterprise Vault
Date:          2/17/2012 9:00:03 AM
Event ID:      41013
Task Category: Monitoring
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      EServer01.mkllp.com
Description:
The SQL database transaction log for Vault Store 'EVExchMVS01' has used 97% of its allocated space.

 

I backed up the DB and ran a shrinkDB without any success.

The DB is set to: Autogrowth. File Growth: 10%, Max File Size: 2GB, Full Backup Mode.

 

When I ran DBCC SQLPERF(logspace), it still shows 98%.

 

Database Name Log Size (MB) Log Space Used (%) Status
master 0.7421875 45.26316 0
tempdb 6.117188 60.66411 0
model 1.742188 95.06727 0
msdb 2.742188 39.03134 0
EnterpriseVaultDirectory 24.99219 65.56541 0
EnterpriseVaultMonitoring 79.99219 24.57393 0
EVServer01ExchangeGroup_1_1 90.17969 7.777441 0
EvServer01ExchMVS01_1 502.4297 97.45495 0
EVServer01JournalVS01_2 79.99219 2.299419 0

 

Why is it not shrinking?

 

I am the DBA (not really a DBA though) and I run EV.

 

 

 

 

 

1 Solution

Accepted Solutions
Accepted Solution!

To be honest, I've never

To be honest, I've never never known anyone to do Point In time restores when it comes to SQL and data consistency, especially when you have to work with fingerprint databases and other vault stores, the idea of restoring a single database is a little aimless.

Also depending on how the SQL Storage is set for the databases and such, having it simple logging causes a lot less strain on the disks and can improve throughput and what not

https://www.linkedin.com/in/alex-allen-turl-07370146

View solution in original post

12 Replies

whats the initial file size

whats the initial file size set to ? 450MB per chance?
the problem with autogrowth is that even if you do 10% and you're writing to it heavily, when you have a small file, with a small autogrowth and a lot of items being written, you're constantly performing an autogrow.

Also what backup are you using to back up the database? is it doing the truncation of the file before the shrink?


 

https://www.linkedin.com/in/alex-allen-turl-07370146

Initial Size if 503 MB Growth

Initial Size if 503 MB

Growth 10%.

Restrict: 2GB

 

I am using SQL Maintenance jobs to backup the DB.

 

Backup occurs at 12:00AM (Daily)

Shring job runs at 1:00 AM (weekly)

 

sounds like you're running a

sounds like you're running a database backup but you're not backing up and truncating the log files

Log Transaction backup occurs

Log Transaction backup occurs rightafter the DB backup.

 

Shring DB runs every Sunday Morning at 1:00AM.

 

I also ran ShrinbDB  without success.

here's a really good article

here's a really good article for you http://www.symantec.com/docs/TECH74666

follow these steps and you should be good!

That's the article I used to

That's the article I used to set it up initially:)

 

give this a shot: USE

give this a shot:

USE EvServer01ExchMVS01_1;
GO
SELECT file_id, name
FROM sys.database_files;
GO
DBCC SHRINKFILE (1, TRUNCATEONLY);

it

it returns:

 

DbId FileId CurrentSize MinimumSize UsedPages EstimatedPages
9 1 173056 12800 153544 153544

 

 

However,  DBCC SQLPERF(logspace) still shows

 

EvServer01ExchMVS01_1 502.4297 97.45495 0        

 

 

 

I changed the DB to Simple

I changed the DB to Simple from Full and it dropped down, Any issues with me using Simple versus Full?

simple mode doesnt allow for

simple mode doesnt allow for point in time recover, hense the trans logs got wiped out when you set it to simple. full mode writes all the transactions (changes) to the logs before being commited to the database. in the event you need to restore from backup, you can restore your full database from the last time you backed it up and play forward all the log files you want to get it back to a specific point in time.

Accepted Solution!

To be honest, I've never

To be honest, I've never never known anyone to do Point In time restores when it comes to SQL and data consistency, especially when you have to work with fingerprint databases and other vault stores, the idea of restoring a single database is a little aimless.

Also depending on how the SQL Storage is set for the databases and such, having it simple logging causes a lot less strain on the disks and can improve throughput and what not

https://www.linkedin.com/in/alex-allen-turl-07370146

View solution in original post

Ok, I guess I will change all

Ok, I guess I will change all my DB's to be Simple. I used Symantec Docs to set it up as Full, but if it's not feasible, it'll need to change.