β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.