|
|
|
Forum Newbie
Group: General Forum Members
Last Login: Thursday, May 20, 2010 1:03 AM
Points: 6,
Visits: 14
|
|
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.
|
|
|
|
|
SSCrazy
Group: General Forum Members
Last Login: Thursday, December 08, 2011 7:48 AM
Points: 2,242,
Visits: 2,885
|
|
| 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
|
|
|
|
|
Forum Newbie
Group: General Forum Members
Last Login: Thursday, May 20, 2010 1:03 AM
Points: 6,
Visits: 14
|
|
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')
|
|
|
|
|
SSC-Dedicated
Group: General Forum Members
Last Login: Today @ 12:01 PM
Points: 30,217,
Visits: 23,017
|
|
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
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
|
|
|
|
|
Forum Newbie
Group: General Forum Members
Last Login: Thursday, May 20, 2010 1:03 AM
Points: 6,
Visits: 14
|
|
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.
|
|
|
|
|
SSC-Dedicated
Group: General Forum Members
Last Login: Today @ 12:01 PM
Points: 30,217,
Visits: 23,017
|
|
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
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
|
|
|
|
|
Forum Newbie
Group: General Forum Members
Last Login: Thursday, May 20, 2010 1:03 AM
Points: 6,
Visits: 14
|
|
| 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. :)
|
|
|
|
|
SSC-Dedicated
Group: General Forum Members
Last Login: Today @ 12:01 PM
Points: 30,217,
Visits: 23,017
|
|
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
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
|
|
|
|
|
Forum Newbie
Group: General Forum Members
Last Login: Thursday, May 20, 2010 1:03 AM
Points: 6,
Visits: 14
|
|
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.
|
|
|
|
|
SSC-Dedicated
Group: General Forum Members
Last Login: Today @ 12:01 PM
Points: 30,217,
Visits: 23,017
|
|
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
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
|
|
|
|
