i tried to insert table from too big flat file. after few hours when it didnt finished (and eat all my drive space) i cancel the query (which also take long time).
since then i cant reach all that DB tables. when i tring to expand tables' folder from object explorer window, i get error message :
(ERROR 1222) Lock request time out period exceeded. (.Net SqlClient
Data Provider).
i also tried restore this DB from backup
Restore of database 'WorkTablesDB' failed.
(Microsoft.SqlServer.Management.RelationalEngineTasks)
ADDITIONAL INFORMATION:
System.Data.SqlClient.SqlError: Exclusive access could not be obtained
because the database is in use. (Microsoft.SqlServer.SmoExtended)
any option how to get this DB to work again?
The solution to this problem is to close SSMS. it will prompt you to either close any open transaction or not.
Choose yes to commit all open transactions and lunch it again. it will run
Related
I accidentally dropped SQL Server database connection in SQL Server Management Studio. After i dropped the Connection and pushed "OK" the database was put into single user mode and then the database was taken offline and not shown in the object-explorer.
Is there any Point to rettach the database? I dont find any .BAK Datas or the Databasename in the Restore Options.
I tryed already, but get errors
USE master;
GO
ALTER DATABASE MyDB SET MULTI_USER
GO
I hope there is something i can do. Thx
EDIT:
Steps i did right Click on the Database -> Task -> Detach , than i was in the following Windows and clicked on "Drop Conections" and clicked "OK" and than she went into single user mode and went offline. But after a refresh i didnt saw her in my object Explorer. I followed this steps:
Getting exclusive access to restore SQL Server databases
so any way to get into single user mode to get her back?
See if any *.mdf files exist in file system for the dropped database. If you find, restore.
I'm practicing a SharePoint 2010 to 2013 migration and having trouble restoring a database. After backing up a database on a SP2010/SQL 2008 server, I'm trying to restore it to a database I've freshly created on my SP2013/SQL 2012 server.
Though the UI, I've taken the destination database offline. I select the .bak file, select my destination database, and attempt the restoration. I get an error: Exclusive access could not be obtained because the database is in use.
Why is this happening? I've taken the database offline, I don't see how it could possibly be in use.
In the restoration window, I've tried going to Options and selecting Overwrite the existing database (WITH REPLACE) as well as Close existing connections to destination database.
Still the same error message. How do I get past this error?
Try this, I had the same issue last week!
ALTER DATABASE [Test4] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
RESTORE DATABASE [Test4]
FROM DISK = 'c:\test4.BAK'
WITH MOVE 'Test4_Data' TO 'c:\data\Test4.mdf',
MOVE 'Test4_Log' TO 'c:\data\Test4_log.ldf'
detailed explanation can be found at http://www.mssqltips.com/sqlservertip/1407/getting-exclusive-access-to-restore-sql-server-databases/
Due to one of the array disk failure in HP-server, sql server 2000 is failing to start, giving error WMI provider error . However to avoid any risk i just want to take backup without being server started, by saving the primary data file MDF,Transactional file LDF, etc.
If there is any possibility then help me.
Should just be able to copy these files and attach them to a new instance on a different server. Make sure you reference the transaction when you attach to the new server. There will be a place in the attach dialog to specify the location of both the mdf and ldf file. Any transactions that were incomplete when the server went down will be rolled back, which is usually what you want.
You can usually use sp_attach_db to attach your MDF/LDF files. These are not backups but they are the next best thing if that's all you have. So copy the MDF and LDF files somewhere and then sort out the WMI issue.
A WMI failure is not that catastrophic. It is a layer that allows external processes to inspect and alter SQL Server (among other thins). If WMI failure is the worst thing that has happened then your database will not be affected.
So I have been neglecting to do any backups of my fogbugz database, and now the fogbugz ldf file is over 2 and half gigs. Thats been built up over the six months we've been using fogbugz.
I backed up the database, then I backed up, and truncated the transaction log, yet the transaction log is still 2 and a half gigs. I did a shrink on the log file and its still 2 and a half gigs. Nothing I do seems to shrink the file in size.
Is there anyway to fix the problem? Or is the only way back at this point to detach the database, delete the log file and then reattach with a new one?
Perform a full backup of your database. Don't skip this. Really.
Change the backup method of your database to "Simple"
Open a query window and enter "checkpoint" and execute
Perform another backup of the database
Change the backup method of your database back to "Full" (or whatever it was, if it wasn't already Simple)
Perform a final full backup of the database.
Run below queries one by one
USE Database_Name
select name,recovery_model_desc from sys.databases
ALTER DATABASE Database_Name SET RECOVERY simple
DBCC SHRINKFILE (Database_Name_log , 1)
Welcome to the fickle world of SQL Server log management.
SOMETHING is wrong, though I don't think anyone will be able to tell you more than that without some additional information. For example, has this database ever been used for Transactional SQL Server replication? This can cause issues like this if a transaction hasn't been replicated to a subscriber.
In the interim, this should at least allow you to kill the log file:
Perform a full backup of your database. Don't skip this. Really.
Change the backup method of your database to "Simple"
Open a query window and enter "checkpoint" and execute
Perform another backup of the database
Change the backup method of your database back to "Full" (or whatever it was, if it wasn't already Simple)
Perform a final full backup of the database.
You should now be able to shrink the files (if performing the backup didn't do that for you).
Good luck!
This is one of the best suggestion in which is done using query. Good for those who has a lot of databases just like me. Can run it using a script.
https://medium.com/#bharatdwarkani/shrinking-sql-server-db-log-file-size-sql-server-db-maintenance-7ddb0c331668
USE DatabaseName;
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE DatabaseName
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (DatabaseName_Log, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE DatabaseName
SET RECOVERY FULL;
GO
Ensure the database's backup mode is set to Simple (see here for an overview of the different modes). This will avoid SQL Server waiting for a transaction log backup before reusing space.
Use dbcc shrinkfile or Management Studio to shrink the log files.
Step #2 will do nothing until the backup mode is set.
You have to shrink & backup the log a several times to get the log file to reduce in size, this is because the the log file pages cannot be re-organized as data files pages can be, only truncated. For a more detailed explanation check this out.
WARNING : Detaching the db & deleting the log file is dangerous! don't do this unless you'd like data loss
I had the same problem, my database log file size was about 39 gigabyte, and after shrinking (both database and files) it reduced to 37 gigabyte that was not enough, so I did this solution:
(I did not need the ldf file (log file) anymore)
(**Important) : Get a full backup of your database before the process.
Run "checkpoint" on that database.
Detach that database (right click on the database and chose tasks >>
Detach...) {if you see an error, do the steps in the end of this text}
Move MyDatabase.ldf to another folder, you can find it in your hard disk in the same folder as your database (Just in case you need it in the future for some reason such as what user did some task).
Attach the database (right click on Databases and chose Attach...)
On attach dialog remove the .ldf file (which shows 'file not found' comment) and click Ok. (don`t worry the ldf file will be created after the attachment process.)
After that, a new log file create with a size of 504 KB!!!.
In step 2, if you faced an error that database is used by another user, you can:
1.run this command on master database "sp_who2" and see what process using
your database.
2.read the process number, for example it is 52 and type "kill 52", now your
database is free and ready to detach.
If the number of processes using your database is too much:
1.Open services (type services in windows start) find SQL Server ... process
and reset it (right click and chose reset).
Immediately click Ok button in the detach dialog box (that showed the
detach error previously).
I am trying to hack opening a MDF file in a new database. We lost the backup.
After reading numerous articles, I came to the point where the only thing that separates me from a successful solution is setting the db into a single user mode.
I issue "sp_dboption 'MyDbName',single,true"
SQL Server reports that "The command(s) completed successfully."
Then I run "DBCC CHECKDB ('MyDbName',REPAIR_ALLOW_DATA_LOSS)"
and it complains that "Repair statement not processed. Database needs to be in single user mode."
This is frustrating to no end. It's like an intentional convoluted torture by MSFT developers.
I am not a DB admin, I am a programmer that needs to make this database restored, at least the stored procedures that we lost.
Thanks for your help!
You could try getting into single user mode by using the -m switch on the command line, as opposed to your sp_dboption command:
http://msdn.microsoft.com/en-us/library/aa178018(SQL.80).aspx