Every time I run a query, my database does not respond to an immediate second query and complains that it is in recovery mode (though it does not show anything beside the database name). This happens for about 5-10 minutes after which everything goes back to being normal.
I am expecting a major crash so I am copying the tables into a different database but anyone knows why this could happen or if there is a permanent fix?
Normally, a database is only in "Recovery" mode during startup - when SQL Server starts up the database. If your database goes into Recovery mode because of a SQL statement, you almost definitely have some sort of corruption.
This corruption can take one of many forms and can be difficult to diagnose. Before you do anything, you need to check a few things.
Make sure you have good backups of your database - copied onto a separate file system/server.
Check Windows Event Log and look for errors. If any critical errors are found, contact Microsoft.
Check SQL Server ERRORLOG and look for errors. If any critical errors are found, contact Microsoft.
Run chkdsk on all the hard drives on the server.
Run dbcc checkdb against your database. If any errors are found, you can attempt to fix the database with the REPAIR_REBUILD option. If any errors could not be fixed, contact Microsoft.
Restore a backup copy of your database onto a different server. This will confirm whether it is a problem within your database or the SQL Server/machine.
After step #4, #5, and #6, run your queries again to see if you can cause the database to go into Recovery mode. Unfortunately, corruption can occur because of an untold number of reasons, but more important than anything is the data. It will confirm whether it is a problem with your data or elsewhere. As long as you have backups that can be restored to a different SQL Server and a restored copy does not continually go into Recovery mode, you don't have to worry too much.
I always put Number 6 last because setting up a separate server with SQL Server and moving/restoring a large database can take an extensive amount of time; but if you already have a backup/test server in place, this might be a good first option. After all, it won't cause any downtime with your live server.
Finally, don't be afraid to contact Microsoft over this. Databases are often mission-critical, and Microsoft has plenty of tools at their disposal to diagnose problems just like this.
Late answer...
Does your database have autoclose set to true? When set, the DBMS has to bring the database online which may account for your symptoms
This can happen when the SQL Server Service has gone down hard in the middle of write operations and sometimes during mode during server startup. Follow the query in this link to monitor
http://errorbank.blogspot.com/2012/09/mssql-server-database-in-recovery.html
I've only had this happen when the service (or the SQL Server Service) has gone down hard in the middle of write operations. Once it came back, everything was fine.
However, if this happening often, then I would suspect a disk level failure of some sort. I would make sure the database is fully backed up and move it to another server while you run diagnostics / rebuild the problem server.
Related
I have a delicate situation wherein some records in my database are inexplicably missing. Each record has a sequential number, and the number sequence skips over entire blocks. My server program also keeps a log file of all the transactions received and posted to the database, and those missing records do appear in the log, but not in the database. The gaps of missing records coincide precisely with the dates and times of the records that show in the log.
The project, still currently under development, consists of a server program (written by me in Visual Basic 2010) running on a development computer in my office. The system retrieves data from our field personnel via their iPhones (running a specialized app also developed by me). The database is located on another server in our server room.
No one but me has access to my development server, which holds the log files, but there is one other person who has full access to the server that hosts the database: our head IT guy, who has complained that he believes he should have been the developer on this project.
It's very difficult for me to believe he would sabotage my data, but so far there is no other explanation that I can see.
Anyway, enough of my whining. What I need to know is, is there a way to determine who has done what to my database?
If you are using identity for your "sequential number", and your insert statement errors out the identity value will still be incremented even though no record has been inserted. Just another possible cause for this issue outside of "tampering".
Look at the transaction log if it hasn't been truncated yet:
How to view transaction logs in SQL Server 2008
How do I view the transaction log in SQL Server 2008?
If you want to catch the changes in real time, I suggest you consider using SqlDependency. This way, when data changes, you will be alerted immediately and can check which user is using the database at the very moment (this could also be done using code).
You can use this code sample.
Coming to think about it, you can establish the same effect using a trigger and writing ti a table active users. Of course, if you are suspecting someone is tempering with data, using SqlDependency might be a better way to go with, as the data will be stored outside of the tampered database.
You can run a trace, for example a distant profiler trace, that will get all SQL queries containing the DELETE keyword. This way, nobody will be aware that queries are traced. You can also query the default trace regularly to get the last DELETE commands: Maintaining SQL Server default trace historical events for analysis and reporting
Please advise what suits my problem better. I have a highload web app hosted on the same server where SQL server is hosted. I also have SQL Service reporting running on the same server, generating user reports.
So my server basically works on top of disk read/write speed. I'm going to get another server and install there another SQL server in order to host SSRS there. So my criteria is to get as fresh data as it possible.
I've looked a couple of solution, currently I do make backup via jobs, copy it to second server and restore it there, also via jobs. But that's not the best solution.
All replication mechanism(transaction, merge, snapshot) affect publisher database by locking it's table, what is unacceptable for me.
So I wonder is there any possibility to create a replica with read only access, that would be synced periodically not affecting main db? I would put all report load to that replica and make my primary db be used only by web app.
What solution might suit my problem? As I'm not a DBA, I'd start investigating that direction. Thanks.
Transactional Replication is typically used to off-load reporting to another server/instance and can be near real-time in a best case scenario. The benefit of Transactional Replication is you can place different indexes on the subscriber(s) to optimize reporting. You can also choose to replicate only a portion of the data if only a subset is needed for reporting.
The only time locking occurs with Transactional Replication is when you generate a snapshot. With concurrent snapshot processing, which is the default for Transactional Replication, the shared locks are only held for a short period of time, so users are able to continue working uninterrupted. Either way, this shouldn't be an issue since you'll likely be generating the snapshot during a period of low user activity anyway.
One of my servers went down and I've had to move all my databases to another server. I want to use the "attach" functionality in SQL Server 2012 (these databases are SQL Server 2005).
For some reason I am getting a NOLOCK error on most of the databases when trying to attach them:
Could not continue scan with NOLOCK due to data movement.
Could not open new database 'db'. CREATE DATABASE is aborted.
File activation failure. The physical file name "D:\db\xxxx_log.ldf" may be incorrect.
New log file 'C:\db\xxxx_log.ldf' was created.
(Microsoft SQL Server, Error: 601)
Judging by the comments above, this database is well and truly broken, there are ways to recover it, one of which is detailed here:
Re-attaching, and fixing a SUSPECT database
But the problem with this is that you can never be sure what state the data is in, it is most likely transactionally inconsistent which will most likely cause you pain later on if you continue trying to use this.
Best thing to do is if you have a backup, restore that instead.
I currently have a SQL Server 2005 set up and has been running successfully for quite a long period of time without any issues.
As of this morning our website applications have been attempting to perform udpates on various rows. However, every time an update happens the data never gets updated in the database.
Our application's code hasn't been changed in any way, and there appears to be no errors of any kind.
Is there anything in SQL Server that can prevent updates from being performed on a database? Can the size of transaction logs prevent data from being updated on a SQL Server database? Or anything at all that can cause this strange behaviour?
We had similar behaviour on one of our servers and it was due to the log file being on a hard drive that had run out of disk space - so worth checking that.
Also check that the Autogrowth limits haven't been reached:
By mistake I have updated data on production database. Is there any way to rollback those transactions.
I have executed the update statement from management studio and the script does not have in
Begin Trans/rollback/commit.
Thanks
Here is what I would do in this case:
Restore backup in separate database and compare these databases to recover rows that exist in backup?
If your database is in full recovery mode try reading transaction log to recover the remaining rows.
In order to read transaction log you can use a third party tool such as ApexSQL Log or try to do this yourself through fn_dblog function (here is an example but it’s quite complex).
Here are other posts on this topic:
Read the log file (*.LDF) in SQL Server 2008
How can I rollback an UPDATE query in SQL server 2005?
Without transaction (or indeed even with a committed transaction), there is no easy way to revert the changes made.
Transaction are mostly useful to ensure that a series of changes to the database are performed as a single unit, i.e. so that either all of these changes get performed [in the order prescribed] or that none of them get performed at all (or more precisely that the database server rolls-back whatever changes readily done would there be a problem before all changes are completed normaly).
Depending on the recovery model associated with your database, the SQL log file may be of help in one of two ways:
If you have a backup and if the log file was started right after this backup, the logfile may help "roll forward" the database to the point that preceded the unfortunate changes mentioned in the question. (aka point-in-time restore)
If no such backup is avaiable, the log file may be suitable to reverse the unfortunate changes
Both of these approaches imply that the SQL log was indeed maintained as some of the recovery models, are such that the log file get truncated (its data lost) after each successful batch/transaction. And neither of these approaches is easy, the latter in particular probably require third party software (or a lenghty procedure) etc.
Depending on how your backups are set up, you may be able to do a point in time restore. Talk to your DBA. You may also want to take the DB offline ASAP to prevent more changes that would eventually be lost when you do the restore.