May 17, 2010 at 2:42 am
Dear All,
I Have server Class Machine which Crashed Few days Back, Our IT Team Reinstalled OS(Server 2003)
They Executed Some Recovery Procedure after Which I reinstalled SQL Server 2000, Now I am unable to attach My Databases on New Installed SQL. The data IS really V critical for me and I Have no Point to Loose this data. I am Pretty Sure that Data is existing in DB's (as Stellar Phoenix SQL Recovery a Software Which Demands 500$ or Even More Shows the data) . I want Some Script/ Procdure to Recover All of my DB's. I have No BackUp's Coz All DB's TOtal Size is appx 500 GB of Which i have no Place to Take Backup.
Your Kind Response will be really V Helpful for Me.
May 17, 2010 at 2:59 am
You might be having all .mdf & .ldf files..Try to attach all database to new instance..You need to recreate all users and jobs if u dont have master and msdb backup
May 17, 2010 at 3:29 am
Upon Attaching The Database it Gives Me Error : "THE FILE You Have Specified Is not Valid SQL Server Datbase File"
I Have Also Tried THe Recovery Procedure But It Takes The Database Into Suspect Mode and the Command To recreate Log file Fails
DBCC REBUILD_LOG ('SIMS', 'D:\Microsoft SQL Server\MSSQL\Data\SIMS.ldf')
May 17, 2010 at 3:49 am
muhammad.raza (5/17/2010)
Upon Attaching The Database it Gives Me Error : "THE FILE You Have Specified Is not Valid SQL Server Datbase File"
You sure it's a mdf file? If you're getting that error and it really is a SQL database file, there is no way you're going to attach it.
Can you explain exactly what you did to get to the point of trying to rebuild the log? Again, if that fails, there's usually no alternatives as it is the last resort.
The DB being 500GB is absolutely no excuse for no backups. External drives are not that expensive and I'm sure the complete loss of the entire database is going to cost a fair bit more than a couple extra drives
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
May 17, 2010 at 4:05 am
I am 200 % Sure Brother its MDF.
What I did Previously is as Follows(the full Recovery Script):
shutdown sql
move the current database file or rename it
restart sql server
create a new database of the same name and log file and location as the old
database and log file
get rid of the old database.
you may be able to right click delete it in this situation or used
sp_removedb
stop sql
rename the new databases.mdf or delete it if you don't have enough space -
do not touch the .ldf
move back in the old database .mdf file or rename it back again
restart sql server
it should come up suspect
--------------------------------
1. From a query window, set the status so that you can update the system
tables by running the following query:
use Master
go
sp_configure "allow", 1
go
reconfigure with override
go
2. Then set the status of the DB that is giving you the problem (XXXXX) into
Emergency Mode by running the following query:
update sysdatabases set status = 32768 where name = '<DBName>'
go
checkpoint
go
shutdown with nowait
go
3. Go into the data directory (MSSQL7\DATA) and rename the log file
associated
the DB in question (XXXX.ldf) to some
temporary name, such as XXXX.TMP.
4. Exit the query window.
5. Then start up SQL Server from a DOS command window by issuing:
sqlservr -c -T3608 -T4022.
6. Bring up another query window and verify that the DB is in emergency mode
by issuing:
select Name, Status from Sysdatabases where name = '<DB_Name>'
7. Verify that the status is 32768. If it is, then issue the query:
dbcc traceon(3604)
DBCC REBUILD_LOG ('SIMS', 'D:\Microsoft SQL Server\MSSQL\Data\database.ldf')<--- You will need
dbcc traceon(3604)
DBCC REBUILD_LOG ('SIMS', 'D:\Microsoft SQL Server\MSSQL\Data\SIMS_LOG.ldf')
update sysdatabases set status = 0 where name = 'SIMS'
the quotation marks
REBUILD_LOG should take less than 5 minutes even on a very large
database. It should complete with the message
DBCC execution completed
8. Take the database out of bypass recovery mode by issuing the command
update sysdatabases set status = 0 where name = '<DBName>'
9. Exit the query window and then shutdown (Ctrl-C in the DOS window) and
restart SQL server. Verify the status of the
database by running DBCC NEWALLOC and DBCC CHECKDB on the database
This Script Worked fine till point 7,
but When I execute
DBCC REBUILD_LOG ('SIMS', 'D:\Microsoft SQL Server\MSSQL\Data\SIMS_LOG.ldf')
it gives me error. I know very Well That Having no Backup is not right Excuse , but the only fact right now is that I Don’t have any backup and I have to Carry the Recovery From This very Stage.
I really Appreciate your Response and Concern on this.
May 17, 2010 at 4:31 am
If the rebuild log failed, it's game over. That's the absolute last resort and there's nothing else that can be done.
Try the data recovery tool (yes, you'll have to buy it), but don't expect that it will recover everything, it may well not recover anything at all.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
May 17, 2010 at 5:14 am
with All Due Respect Gail Shaw I Don't Agree With You I will definately Find A way n will surely Let U know. Don't Take It Personally Bro. But My Vision Says NOT to Leave Effort. 🙂
May 17, 2010 at 5:38 am
You're welcome to feel that way.
Do note that I'm not talking in ignorance here. I know a reasonable amount about corrupt databases and recovering them. I could point you to a blog post by the person who wrote DBCC CheckDB where he explains about emergency mode and what it means if the emergency mode log rebuild fails. (I could also ask him for a second opinion if you like, but he's on vacation for the next two weeks)
You may be able to extract data from the DB after setting it to emergency, even without the rebuild log succeeding. If you can, it may an option to extract what you can and recreate the database.
What error was the log rebuild giving?
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
May 17, 2010 at 5:51 am
PLEASE DO What ever you Could do to Help me in this particular Regrd. I don’t remember what exactly was the error but I will redo all the process n let you know the exact error , Your advice of Trying to Extract data from emergency mode could also help me. I will try it Surely. I will be Able to Reply you after 16 Hours Appx from Now Coz I am going home now. Till then , if you could contact the person who wrote DBCC and take a second opinion also . Thanks A lot.
May 17, 2010 at 5:56 am
muhammad.raza (5/17/2010)
PLEASE DO What ever you Could do to Help me in this particular Regrd.
Well you're not paying me, so I'm not going to spend hours or days on this, but I'll give you all the assistance I reasonably can, even though you don't appear to trust my conclusions.
Till then , if you could contact the person who wrote DBCC and take a second opinion also .
I'll ask, but as I said, he's on vacation for 2 weeks and may well decide not to reply even when he gets back.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
May 17, 2010 at 8:46 am
Gail didn't post an opinion. Her conclusion is based on fact.
Having build backup tools and log readers for a living she is 100% correct. You have gone as far as you can with native tools. You can try any of the log reader tools out there from red gate\apexsql\lumegent but I wouldn't put much stock in what was recovered ether. If the physical log is corrupt it is corrupt. Your efforts should be on migrating as much data from the suspect database into a new database and figuring out just how much data has been lost and how to reconstruct or re-enter that data.
Oh, if there is a tool that shows 100% of you data and you don't want to spend the $500.00 for it then they data isn't worth $500.00?? At this point I'd spend the money and not bat an eye. You or the business decided that backups were too expensive. You now need to decide exactly what your data is worth.
Wes
May 17, 2010 at 8:52 am
Red Gate has Log Rescue for free if you want to try it http://www.red-gate.com/products/sql_log_rescue/index.htm
May 17, 2010 at 8:52 am
Wesley Brown (5/17/2010)
If the physical log is corrupt it is corrupt.
I don't think it's the log that's corrupt (or at least not just the log). If it was only the log that was corrupt, SQL would still be able to rebuild it, or the log could be completely deleted and rebuilt. For a rebuild of the log to fail, I'm guessing (and it's a guess without error msgs) that there's some critical portion of the data file damaged as well. Likely either system tables or allocation structures.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
May 17, 2010 at 9:18 am
Well, knowing what I know about the person who wrote DBCC, I believe his advice at this point would involve updating your resume ... just in case.
Try the tool that Steve recommended. If it doesn't work, buy the other tool that can see the data.
May 17, 2010 at 9:18 am
I presume you've added the correct Service Packs and hot fixes?
What about seeing if the databases work on a newer version 2005 or 2008?
Viewing 15 posts - 1 through 15 (of 19 total)
You must be logged in to reply to this topic. Login to reply