October 18, 2007 at 7:19 am
I am getting an error in SQL Server 2005 when I try to open or manage a databases. The ldf and mdf files exist in the data directory but I cannot detach, delete, restore the database.
The error is as follows:
Attempt to retrieve data for object failed for Server (name of server) (Microsoft.SQLServer.SMo)
Additional Information:
The database (database name) does not exist on the server. (Microsoft.SQLServer.SMo)
October 18, 2007 at 7:32 am
This is due to space constraint issue. If you open the Enterprize Manger, you can able to see the respective databases goes into (SUSPECT) mode. Please ensure that you have adequate space in your server that run's both the application as well as the databases.
If you are running out of space, then remove unwanted files so as to create the space for the databases.
Then restart the server, so as to access the databases online.
October 18, 2007 at 9:11 am
Space is not the issue as I have terrabytes of data available on my SAN. Anything else?
October 19, 2007 at 11:41 am
Sounds like you have a database but it's been detached - is that the case? If so, how did it get detached?
Paul Randal
CEO, SQLskills.com: Check out SQLskills online training!
Blog:www.SQLskills.com/blogs/paul Twitter: @PaulRandal
SQL MVP, Microsoft RD, Contributing Editor of TechNet Magazine
Author of DBCC CHECKDB/repair (and other Storage Engine) code of SQL Server 2005
November 5, 2007 at 7:38 am
I resolved the error.It was symantec. Their antivirus application was causing the problem. Once I disabled, everything worked fine. I had to uninstall the antivirus, reinstall and apply some patches.
November 7, 2007 at 1:04 am
help me
i use SQL 2000
database corruption
when attach, error at :
Error 5172: The header for file '.mdf' ....
i try recover, but not success
i need data, not structure
help me
mail me at: tuanta55@gmail.com
thanks for all
November 7, 2007 at 10:12 am
Looks like the file header for your .mdf file is corrupt. There's no way around that except to restore from your backups. Product Support will advise you of the same too.
Paul Randal
CEO, SQLskills.com: Check out SQLskills online training!
Blog:www.SQLskills.com/blogs/paul Twitter: @PaulRandal
SQL MVP, Microsoft RD, Contributing Editor of TechNet Magazine
Author of DBCC CHECKDB/repair (and other Storage Engine) code of SQL Server 2005
November 7, 2007 at 7:38 pm
u're wrong
i find a anwser, it's some "recovery tools" ,
ex: kernel for sql server, or Recovery for SQL server
which can recovery full data,
u can search by google
i have a version demo, not have crack
who have crack, please send to me, thanks
mail: tuanta55@gmail.com😎
November 8, 2007 at 6:50 pm
Sigh - no, I'm not wrong. If an MDF's file header is corrupt, it nearly always means that a lot of the rest of the database has corruptions too. No amount of recovery tools (and there isn't a single one I know of that can deal with all database structures) can get back all the data in such a case. I don't mean to sound conceited, but I wrote DBCC CHECKDB/repair for SQL Server 2005 and I've seen literally thousands of corruption incidents at customers around the world over the last ten years - so I do know what I'm talking about.
Thanks
Paul Randal
CEO, SQLskills.com: Check out SQLskills online training!
Blog:www.SQLskills.com/blogs/paul Twitter: @PaulRandal
SQL MVP, Microsoft RD, Contributing Editor of TechNet Magazine
Author of DBCC CHECKDB/repair (and other Storage Engine) code of SQL Server 2005
November 9, 2007 at 8:15 pm
i see you're manager director http://www.sqlskills.com
i don't know you're a partner of Microsoft and with you,MS SQL Server is best
but with MS SQL Server more 5 years, i see not good of MSSQL it's no backup and current data corruption same my error post,.. so is die !
unreasonable for lost data,
data is very more important than structure.
November 10, 2007 at 11:28 am
"data is very more important than structure."
Absolutely - so if you have important data then you should have a sound backup strategy and even a redundant mirror of the data. Repair is only there to fix things up in the absence of either of these two safeguards - and relying on a tool to scrape data from a damaged database/log is not a good solution for protecting your data.
Thanks
Paul Randal
CEO, SQLskills.com: Check out SQLskills online training!
Blog:www.SQLskills.com/blogs/paul Twitter: @PaulRandal
SQL MVP, Microsoft RD, Contributing Editor of TechNet Magazine
Author of DBCC CHECKDB/repair (and other Storage Engine) code of SQL Server 2005
November 12, 2007 at 1:35 am
you're a philosopher
not sql or database manager
not, not:D
November 13, 2007 at 7:27 am
No... he's dead on...
Nothing is more important than a recent backup.
A Good SQL/DB Manager knows this and does (at a minimum) a daily backup of the Database. Depending on the volume of transactions, this could even been an hourly or even every 5 minutes backup if necessary.
November 13, 2007 at 9:56 pm
yes yess, yess
i know, i see, i understood
but before to backup time on schedule, data corrupt
>hehe, what do i?:w00t:
November 14, 2007 at 9:29 am
I think the best takeaway from this is to learn from one's mistakes, chalk it up to experience, and become knowlegeable in the process of creating and storing backups, ie, how often, store offsite, overwrite backup media, etc.
I personally would find it difficult to justify hiring a DBA who has never had any experience dealing with crashes, corruptions, replication disasters, or other emergencies, simply because that person really has no experience except operational.
A good question to pose at this point would be to ask what are the considerations to take when trying to prevent database header corruption. You have in this forum the guy who wrote the darn repair tool, utilize his knowlege to increase yours !
Enough pontification, if you won't pose the question, I will -
Paul, in your experience, what have you found to be the most common causes of header corruption ? and how does one prepare for prevention of same ?
Viewing 15 posts - 1 through 15 (of 18 total)
You must be logged in to reply to this topic. Login to reply