I am trying to resolve what cause the following corruption.
2011-06-29 10:47:26.42 spid5s Starting up database 'master'.
2011-06-29 10:47:26.53 spid5s Error: 9003, Severity: 20, State: 1.
2011-06-29 10:47:26.53 spid5s The log scan number (216:72:1) passed to log scan in database 'master' is not valid. This error may indicate data corruption or that the log file (.ldf) does not match the data file (.mdf). If this error occurred during replication, re-create the publication. Otherwise, restore from backup if the problem results in a failure during startup.
2011-06-29 10:47:26.53 spid5s Cannot recover the master database. SQL Server is unable to run. Restore master from a full backup, repair it, or rebuild it. For more information about how to rebuild the master database, see SQL Server Books Online.
I can find plenty of threads and information on how to recover databases when master db is corrupt. I can recover them succussfully.
HOWEVER, this is not very satisfactory for customers to have perform these operations. I have been able to examine event log files of when the corruption occurs. From there I can see server working fine then computer is shutdown, few hours later the computer is switched on and master db is corrupted.
Any help greatly appreciated
One of:
disk corruption. Run chkdsk etc with SQL Server shutdonw
someone has been playing with the MDF/LDF files
The master DB starts once when SQL Server starts up: so why did this happen? Patch? BSOD? PEBKAC? Note: the MDF/LDF files won't be locked when SQL is shutdown...
I can't recall a corrupt master, ever, unless it's one of the 3 reasons above
Related
I need make a backup of my SQL Server database. When I try, I get this error:
System.Data.SqlClient.SqlError: Read on "c:..." failed: 23(...)(Data error (cyclic redundancy error))
Now, I'm trying to run this command:
DBCC CheckDB ('MYDATABASE') WITH NO_INFOMSGS, ALL_ERRORMSGS
But I get this error
Msg 8921, Level 16, State 1, Line 18
Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.
What can I do? I just need make a backup.
I'm using Microsoft SQL Server Management Studio.
First of all, check the Service Account used for the SQL Server Instance from Services.
Ensure the service account have enough permission for read/write at the exact location for Backup in Physical Disk.
Ensure the the user (the user you using to login in SQL Instance) have enough permission to perform backup.
Final option to recover the data from the database is create another database with same tables (blank) in different machine in different SQL instance, then Export all the database to new database using Management studio (Right click on the Database > task > Export Data)
The 2 table not insert or select or delete or drop table command execute then show error below:
The error I'm receiving
Warning: Fatal error 829 occurred at Oct 10 2019 12:48PM. Note the
error and time, and contact your system administrator.
DROP TABLE [dbo].[tbl_SalesMaster_tmp]
GO
Just a quick search on Google and find a similar thread here. However, I extracted the possible solution for an easy reference.
Means there's an I/O subsystem problem. Is something called a 'hard I/O error'. SQL Server asks the OS to read a page and it says no - this means the I/O subsystem couldn't read the page in question.
The CHECKDB output means that it couldn't create the internal database snapshot that it uses to get a transactionally-consistent point-in-time view of the database. There are a number of different causes of this:
There may not be any free space on the volume(s) storing the data files for the database
The SQL service account might not have create-file permissions in the directory containing the data files for the database
If neither of these are the case, you can create your own database snapshot and run DBCC CHECKDB on that. One you have, run the following:
DBCC CHECKDB (yourdbname) WITH NO_INFOMSGS, ALL_ERRORMSGS
Whatever the results are, you're looking at either restoring from a backup, extracting data to a new database, or running repair. Each involves varying amounts of downtime and data-loss. You're also going to have to do some root-cause analysis to figure out what happened to cause the corruption in the first place.
By the way - do you have page checksums enabled? Have you looked in the SQL error log or Windows application event log for any signs of corruption or things going wrong with the I/O subsystem?
Without going into too much detail, I had a system failure which meant that SQL got shut down unexpectedly. I have managed to detach the database and remove it from the list of databases in SSMS.
I am now trying to re-attach the database from a different location, on the same NAS;
The command I am using is this;
CREATE DATABASE ArchiveManager
ON (Filename = '\\411352-web5\m$\FTP\Detroit\ArchiveManager.mdf'),
(Filename = '\\411352-web5\m$\FTP\Detroit\ArchiveManager_log.ldf')
FOR ATTACH;
Originally, the database was sat on the share j$. I have now had to move it to m$.
I get the below error why trying to attach the database;
File activation failure. The physical file name "\\192.168.200.222\j$\FTP\Detroit\ArchiveManager_log2.ldf" may be incorrect.
The log cannot be rebuilt because there were open transactions/users when the database was shutdown, no checkpoint occurred to the database, or the database was read-only. This error could occur if the transaction log file was manually deleted or lost due to a hardware or environment failure.
Msg 1813, Level 16, State 2, Line 7
Could not open new database 'ArchiveManager'. CREATE DATABASE is aborted.
Note that 192.168.200.222 resolves to 411352-web5.
I run a query in which I wanted to update more then 130 mln of records. After few hours I got an error:
The transaction log for database 'MGR' is full due to 'ACTIVE_TRANSACTION'.
now I ve got 70 MB free on my C disk drive.
I supose that the problem was with to little disc space and thats why query failed but how can I now regain the lost disc space from before query ?
Im using sql server 2008 R2
Thanks for any hints
The problem has to do with how sql logs all the changes during an active transaction. While a transaction is active, the log cannot be flushed, so if you have a huge active transaction the log keeps growing until it reaches a point where it can exceed its capacity. The amount of logging depends on many factors: the recovery mode (full recovery mode is the one that generates more logging activity). Also, you can breakdown the transaction in small chunks to enable log flushing in between. Also look into table hint TABLOCK. The lost amount of disk must possibly have gone to the log file. Check that out.
This is the situation:
Got a full backup (.bak file) of a SQL 2008 database, with partitions.
The .bak file is 100gb.
I need to restore this database on a different server, to a new database.
So, command is like this:
Restore Database [newname] FROM DISK= N'D:\mydatabase.bak' WITH FILE = 1
MOVE 'mydatabasename' TO 'C:\mydatabase.mdf'
MOVE 'Partition1' TO 'C:\`mydatabase_1.ndf'
etc..
STATS = 1
After 52 percent processed, I get this error:
Msg 3183, Level 16, State 2, Line 1
RESTORE detected an error on page (8481:555819297) in database "dbname" as read from the backup set.
Msg 3013, Level 16, State 1, Line 1
RESTORE DATABASE is terminating abnormally.
Before all default suggestions come up, this is what I have already done:
Checkdb on original database --> no errors
Restore the .bak file on my local machine --> no errors, so the backup is correct.
What can I do to troubleshoot this? How can I get to the actual problem?
Thanks for any suggestions.
I'd check the MD5 checksums of the .bak as created on the server and after it's been moved to the new home. I'll bet something small got tweaked in your copy as you moved it over; something in your process, maybe just a network hiccup, borked something or other.
Few MD5 checksum utilities here: http://www.thefreecountry.com/utilities/free-md5-sum-tools.shtml
Best of luck.
We were able to restore the backup on other servers.
After a while, we switched over to a new server.
The old one with the errors is on a test bench now.
Conclusion is that the backup file was correct, and the problem lies in a hardware problem on the server. Probably disk problemens, but when thats clear, i will post it here..
Thanks for the suggestions.
yeah for such restoration errors the problem lies in the drive from where you are trying to restore the backup,try changing the drive (e.g d to e )..it worked for me.
one can also try attaching mdf file directly.