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
Related
Over the weekend my Dev server experienced a very interesting issue. I have a scripts that periodically take several databases offline, and then bring them back online again. They ran, and took all the specified databases offline, but then failed to bring them online again, the specified error message was:
Msg 5011, Level 14, State 7, Line 4 User does not have permission to
alter database 'XXX', the database does not exist, or the database is
not in a state that allows access checks. Msg 5069, Level 16, State 1,
Line 4 ALTER DATABASE statement failed.
This doesn't seem right to me as they we're run from a user account that has the following properties set:
I further validated that it wasn't a permissions issue by logging on to that server, running SSMS as an Administrator and logging in with my windows credentials (also a admin account) and executing the following SQL on the offline database:
USE [master]
GO
ALTER DATABASE [XXX] SET ONLINE
GO
With the same results...
I've looked at the SQL logs for more details about the specific error, however there are no entries associated with this issue. I can reproduce this issue on every database on this particular server. The only way I've been able to get the databases online is by de-attaching and reattaching them.
Most other stack overflow tickets involving this error message are specific to one database or a specific user account. My issue spans all databases and all admin users I've tried so far, also my issue occurred on a script that had previous worked fine on this server and account, clearly something has shifted over the weekend that is causing this query to now fail. I wonder if anyone else has experienced this issue before?
Update 1
This post talks about how file security can trigger this error message, I granted full access to the user group on one of the databases, then reran the online command, no luck. My SQL Server service is running under a service account that is part of the "Administrator" user group and has full access to all database files.
Update 2
All sorts of interesting idea's put forward here, also discussed here. Lots of commands and ideas on how to repair damaged databases with a several combinations of repair like SQL command, unfortunately none of them work in my situation, they either won't run on offline databases, or after detach and reattachment do not report any errors. Of course, there are always a number of posts simply insisting that the solution is permission based and that running: GRANT ALTER ON DATABASE will resolve all issues. For my admin user account it shouldn't make a difference, but it's a moot point as I can't even run that command on a offline database...
Finally tracked down the issue, apparently we had a completely unrelated SQL database instance on the same server in recovery mode. While it was recovering we we're unable to bring any offline instances online. Detach/re-attach would work, and we could restore the database just fine, but just not set it online.
The separate database finished recovering and we are now able to run the command without issue. I suppose in the future, if I don't care about the database that's in recovery(which I often don't) I'll following the linked steps to get rid of it, before restarting SQL Server and proceeding:
Stop SQL Server
Delete MDF + LDF
Start SQL Server
Restore (may need to drop first, comes up suspect)
I got an error message in my Log Reader Agent:
The process could not execute 'sp_replcmds' on 'Database Name'.
I created another agent profile with a large query timeout and a min value to batch, but it still doesn't work.
Can someone help me?
I'm using SQL Server 2008 and I'm trying to do a replication between databases on different servers.
It could be possible that owner of the database could be someone other than what you have permissions for. Below there's a simple command to change ownership...if you have the rights to do so.
--TSQL Code--
USE PublishedDatabase
GO
EXEC sp_changedbowner 'sa'
GO
There are a lot of things that can cause this error (which include, but is not limited to):
The database has been publication disabled
The account trying to run the log reader agent doesn't have the ability connect to the publisher server
The account trying to run the log reader agent doesn't have permission to run sp_replcmds
In my experience, there's a little more to the error in the replication monitor. Is this the case for you?
This could be due to Owner is not set for the database.
You can check by right clicking on database then choose Property and go to File Table and the Owner selection should be there.
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 have backed up and restored a MS SQL Server 2005 database to a new server.
What is the best way of recreating the login, the users, and the user permissions?
On SQL Server 2000's Enterprise Manager I was able to script the logins, script the users and script the user permissions all seperately. I could then run one after the other and the only remaining manual step was to set the login password (which do not script for security reasons)
This does not seem possible in SQL Server 2005's Management Studio, making everything very fiddly and time consuming. (I end up having to script the whole database, delete all logins and users from the new database, run the script, and then trawl through a mixture of error message to see what worked and what didn't.)
Does anyone have any experience and recommendations on this?
The easiest way to do this is with Microsoft's sp_help_revlogin, a stored procedure that scripts all SQL Server logins, defaults and passwords, and keeps the same SIDs.
You can find it in this knowledge base article:
http://support.microsoft.com/kb/918992
Run this:
EXEC sp_change_users_login 'Report'
This will show a list of all Orphaned users, for example:
Now execute this script here for each user, for example
exec sp_change_users_login 'Update_One', 'UserNameExample', 'UserNameExample'
This fixed my problem.
I use the SQL Compare product from Red Gate (http://www.red-gate.com/products/SQL_Compare/index.htm). There are other similar products around but I've had no reason to look for one as SQL Compare has never let me down.
You'll find it is useful for a lot more than the your current requirement as it will help synchronize all types of database object, not just login and permissions.
I've ran some "ALTER" scripts on the database [SQL Server Server 2005], and overwrote some sprocs. Is there any way to undo changes and get my old sprocs back?
Is there a way to get the scripts that were executed out of the .LDf file? That way i can re-run my initial "create" script for my sprocs.
I don't have a backup file with old sprocs.
p.s. i backed the DB up as per #Gulzar's deleted answer, and looks like I'm "hosed".
#Pittsburgh DBA: thanx for the solution, but it doesn't seem to work after the backup.
MORAL: Wait for 10 minutes before trying the suggested answers out
Update from Gulzar: What I meant was a file backup before trying anything (to be safe). Not a SQL Server backup.
FIRST: DO NOT TAKE ANY BACKUPS JUST YET.
There are several tools on the market to do this sort of thing.
You might try this one:
ApexSQL Log
In case anybody else has the same problem - Were you doing transaction log backups every X minutes? If so, you can use Quest LiteSpeed's log reader or Quest Toad for SQL Server's log reader to read the log file backups. It gives undo/redo scripts too for any transaction in the log backups or the ldf.
And after that, look into using ApexSQLScript to script out your databases on a regular basis (and store in version control).
yo do can!!
go to sql server managment studio,connect to your db, left click on your db and go to "tasks".
select restore -> database.
then click the "timeline" button and select 'especific date' and select the day before your mistake.
All programs that have access to your db mus be closed.
It worked for me, i had this very same probelm.