But this means that any changes to data since the last backup will be lost.ġ. If your backup files are lost or not available, your last resort option is to force SQL Server to rebuild the lost transaction log file. Or you may simply not have a backup plan in place ( gasp!). Your backup files may be corrupt or inaccessible. The best solution is to restore your database from the most recent backup. The database will either show as SUSPECT, IN_RECOVERY, or RECOVERY_PENDING. To find out what state the database is in, run the following query: Looking at our logs in this example, we find that the database log file is missing: Why is it unavailable? The SQL Server Logs is a good starting point to find out what happened to the database. You will now see that your database is still in the list, but is not available.įirst step is to figure out what is wrong with the database. After deleting the ldf file, restart SQL Server Service. Go to Windows explorer to the location where the ldf files reside, right click on your test database_log.ldf file and Delete.ĥ. After the service is stopped, you can delete the log (ldf) file. You can do this by right clicking on your instance in SSMS, and selecting ‘Stop’Ĥ. After making changes to your data, stop the SQL Server Service.
Here is one link for inserting random data:ģ. You can either manually insert, update, or delete record(s) in your database, or there are many scripts available to insert random data into a database table. First step is to take backup of the databaseĢ. For testing and practice in your environment, make sure you are using a test database that is un-essential and on an instance that is not used for production.ġ. For demonstration and practice purposes, I will show how to cause a test database to be in a SUSPECT or unusable condition. It’s always a good idea to plan for and practice dealing with IT problems before they actually occur.
0 kommentar(er)
