cancel
Showing results forΒ 
Search instead forΒ 
Did you mean:Β 

Transaction log error

anon1m0us1
Level 6

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 ACCEPTED SOLUTION

Accepted Solutions

JesusWept3
Level 6
Partner Accredited Certified

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 12

JesusWept3
Level 6
Partner Accredited Certified

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

anon1m0us1
Level 6

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)

 

AndrewB
Moderator
Moderator
Partner    VIP    Accredited

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

anon1m0us1
Level 6

Log Transaction backup occurs rightafter the DB backup.

 

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

 

I also ran ShrinbDB  without success.

AndrewB
Moderator
Moderator
Partner    VIP    Accredited

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

follow these steps and you should be good!

anon1m0us1
Level 6

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

 

AndrewB
Moderator
Moderator
Partner    VIP    Accredited

give this a shot:

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

anon1m0us1
Level 6

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        

 

 

 

anon1m0us1
Level 6

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

AndrewB
Moderator
Moderator
Partner    VIP    Accredited

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.

JesusWept3
Level 6
Partner Accredited Certified

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

anon1m0us1
Level 6

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.