05-20-2012 09:33 AM
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.
Solved! Go to Solution.
05-20-2012 01:26 PM
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
05-20-2012 09:40 AM
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?
05-20-2012 09:46 AM
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)
05-20-2012 10:14 AM
sounds like you're running a database backup but you're not backing up and truncating the log files
05-20-2012 10:21 AM
Log Transaction backup occurs rightafter the DB backup.
Shring DB runs every Sunday Morning at 1:00AM.
I also ran ShrinbDB without success.
05-20-2012 10:22 AM
here's a really good article for you http://www.symantec.com/docs/TECH74666
follow these steps and you should be good!
05-20-2012 10:31 AM
That's the article I used to set it up initially:)
05-20-2012 10:47 AM
give this a shot:
USE EvServer01ExchMVS01_1; GO SELECT file_id, name FROM sys.database_files; GO DBCC SHRINKFILE (1, TRUNCATEONLY);
05-20-2012 11:00 AM
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 |
05-20-2012 11:46 AM
I changed the DB to Simple from Full and it dropped down, Any issues with me using Simple versus Full?
05-20-2012 12:04 PM
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.
05-20-2012 01:26 PM
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
05-20-2012 01:52 PM
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.