Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Ran out of log space!!! Expand / Collapse
Author
Message
Posted Sunday, February 17, 2013 1:00 AM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: 2 days ago @ 3:23 PM
Points: 554, Visits: 3,009
An archiving process that moves data from my prod db to archive an db consumed my entire log drive. Both dbs logs are on the same drive. This is a 2000/SP4 cluster active/passive.

I moved the the active cluster node over, probably a bad idea in hindsight.

Prod is in full recovery mode. Archive in simple.

Right now now archive is in recovery (slow). I attempted to take prod offline to move its log to another drive. This is in progress but taking a long time.

Suggestions welcome...
Post #1420947
Posted Sunday, February 17, 2013 1:34 AM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: 2 days ago @ 3:23 PM
Points: 554, Visits: 3,009
I managed to shrink my prod logs to create some space. The archive db is still recovering, I'll let it go.
Post #1420949
Posted Sunday, February 17, 2013 3:26 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Yesterday @ 3:18 PM
Points: 37,744, Visits: 30,025
Restarting SQL while a process is rolling back (as it would have been after running out of log space) is indeed a bad idea as the rollback then has to finish with the DB unavailable

Wait. There's little else you can do here.



Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #1420955
Posted Sunday, February 17, 2013 5:50 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Tuesday, May 21, 2013 2:30 AM
Points: 24, Visits: 143
Mrs 500

Now i am going to explain why it is taking more time to recovery database?

First Question:It’s not just the amount of transaction logs you need to consider, you also need to take into account the space the transaction log management system will “reserve” to allow for proper transaction rollback. If a transaction generates 100MB of transaction log records, the system will reserve approximately 100MB of empty space in the transaction log to guarantee it can abort the transaction and correctly roll back. It’s a safety mechanism to prevent a database becoming inconsistent. This is why you may have seen the transaction log grow, even though you think you’ve given it enough space for the largest transaction.

So please check the transaction log disk space .otherwise drop the database using master single user mode then resorte the database

Post #1420967
Posted Tuesday, February 19, 2013 8:33 AM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: 2 days ago @ 3:23 PM
Points: 554, Visits: 3,009
The archive db did recover. I then shrunk its log. I expanded the prod log to a reasonable size given it normal processing/backup schedule.

Pretty resilent system despite my somewhat misguided actions.

The vednor provided archive process (rbar) clearly needs to be run with smaller date increments.

Thanks
Post #1421677
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse