Bring Sybase database offline - database

Is there a way to bring a database offline in Sybase ASE 16.0?
I know a database gets set offline when loading a dump, but that can't be the only way to set a database offline.
There is also an official article for that, but it's locked behind a PayWall...

DBA-level direct edit of system catalog would place it into that state. Try it on a dev instance to see if this is what you were looking for in re: offline database command.
sp_configure 'allow updates',1
go
reconfigure with override
go
update master..sysdatabases
set status=512
where name='<database of interest>'
go
sp_configure 'allow updates',0
go
reconfigure with override
go
Other states you might look into would be:
512 offline
1024 read only
2048 dbo use only
4096 single user
Some of these states can be set via the sp_dboption calls, like
master..sp_dboption <database of interest>, "read", true
go

The only idea that comes to mind would be:
dbcc dbreboot('shutdown',<dbname1>[,<dbname2>, ...,<dbnameN>])
The only documentation I'm finding is this wiki page for dbcc dbreboot().
Keep in mind that online database will not make the database available again. To make the database available you'll need to run dbcc dbreboot('restart',<dbname>).

Related

How do I fix this 'Restore of database AdventureWorks2014 failed' permanently?

When I try to restore AdventureWorks2014, I get this
'Exclusive access could not be obtained because the database is in
use.(Microsoft.SqlServer.SmoExtended)'
Of course there is no query window open. I do not have this issue with other databases. The only difference that I found between AdventureWorks2014 and the rest of my databases is compatibility level, 2014 and 2019 respectively. But it was not the solution. I checked the Microsoft link provided with error message which took me to Microsoft home page. I could not find what I was looking for in Documentation. So I went around by setting the database offline or checking 'Close existing connections to destination database' option. Both of them works but I would like to find a permanent solution. Is there one?
Set the Database to SINGLE_USER before the RESTOE:
USE master
ALTER DATABASE AdventureWorks2014 SET SINGLE_USER WITH ROLLBACK IMMEDIATE
RESTORE AdventureWorks2014.....
Something was blocking your database restore. To find out what, issue the restore as T-SQL (even if you're going through some sort of UI, script it out so you can run it by hand) in one window and note the SPID for that window. If you don't know where to find that in your UI of choice (my guess is that you're using SSMS, but maybe not!), you can issue a query of SELECT ##SPID to find it. Before starting up your restore, open another window/session and get this query ready to run:
select *
from sys.dm_os_waiting_tasks
where session_id = «spid from your restore session»;
Kick off your restore and then run the above query to see what is blocking.

Database Keeps Going into Recovery Pending State

I have a SQL server database that has been running perfectly fine on my machine for about 6 months, a couple days ago out of nowhere it was inaccessible (Pending Recovery).
I did a bunch of Googling and have tried the following things to fix the issue but thus far restoring it from a previous backup is the only thing that seems to work.
I have tried (From SMS and SQLCMD):
ALTER DATABASE mydatabase SET EMERGENCY
ALTER DATABASE mydatabase set single_user
DBCC CHECKDB (mydatabase, REPAIR_ALLOW_DATA_LOSS) WITH ALL_ERRORMSGS;
ALTER DATABASE mydatabase set multi_user
Step #3 errors out with: "cannot open mydatabase is already open and can only have one user at a time"
Second try:
EXEC sp_resetstatus 'mydatabase';
ALTER DATABASE mydatabase SET EMERGENCY
DBCC CHECKDB ('mydatabase')
ALTER DATABASE mydatabase SET SINGLE_USER WITH ROLLBACK IMMEDIATE
DBCC CHECKDB ('mydatabase', REPAIR_ALLOW_DATA_LOSS)
ALTER DATABASE mydatabase SET MULTI_USER
Step #5 errors out with the same error.
My question is what could be causing this in the first place and how can I fix it properly without having to do a restore twice a day.
Database is already open and can only have one user at a time, this is error number 924. The complete error message looks like this:
An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.ConnectionInfo)
Msg 924, Level 14, State 1, Line 1 Database ‘db_name’ is already open and can only have one user at a time.
The level 14 belongs to security level errors like a permission denied. It means that it cannot be open because someone is using it.
Use the sp_who or sp_who2 stored procedures. You can also use the kill command to kill the processes that are active in the database.
I also found this thread useful: How to fix Recovery Pending State in SQL Server Database?
what could be causing this in the first place and how can I fix it properly without having to do a restore
The most likely cause is a a hardware or driver problem with your hard disk.
In my case, I had databases set up on my local machine but on an external drive mapped to my hard drive. I have the external drive connected to my docking station all the time but I had to disconnect the hard drive and after I connected it again - the databases that are restored on the external drive went into Recover Pending mode.
In my case what helped me was to set the database offline in Microsoft SQL Server Management Studio by right clicking on the database - Tasks - Take Offline. The status of the database changes to Offline. After that bring the database online again by right clicking on the database - Tasks - Bring online.
The database was successfully recovered without any issues. But if the cause is different these steps may not help.
Take the database offline
Bring the database back online

SQL Server production server - all databases are in recovery pending state

All the databases in my SQL Server production server are in recovery pending state. I tried to execute different queries but they were of no use. Please help me as production work has been stopped at client side.
Tried to execute alter commands - but show error as following:
Msg 5120, Level 16, State 101, Line 1 Unable to open the physical file
"G:\Data\MSSQL\Database.mdf". Operating system error 3: "3(The system
cannot find the path specified.)". File activation failure. The
physical file name "G:\Data\MSSQL\Data\Database_log.ldf" may be
incorrect. Msg 945, Level 14, State 2, Line 1 Database 'Database'
cannot be opened due to inaccessible files or insufficient memory or
disk space. See the SQL Server errorlog for details
Msg 5069, Level 16, State 1, Line 1
Recovery pending means that for some reason SQL cannot run restart recovery on the database. Usually this is because the log is missing or corrupt.
Check to see if you can find the Database.mdf and Database_log.ldf files in the folder specified.
Check your system has not run out of disk space.
This could be caused by a hard drive failure. You may need to do a full restore of your last full back, any differentials and then restore the logs up until the log error occurred.
See similar issue here
My team encountered this error many times for my clients & I know, It is not easy to manage in the Production server. In your case Error 5120 –This error comes when the database is in Read Only Mode.
To fix this you can below code
USE [master]
GO
ALTER DATABASE [SQLAuthority] SET READ_WRITE WITH NO_WAIT
GO
After fixing 5120, you can process to fix "databases are in recovery pending state"
Recovery Pending – If the SQL Server knows that database recovery needs to be run but something is preventing it from starting, the Server marks the db in ‘Recovery Pending’ state. This is different from the SUSPECT state because it cannot be said that recovery is going to fail – it just hasn’t started yet.
Execute the following set of queries:
ALTER DATABASE [DBName] SET EMERGENCY; GO
ALTER DATABASE [DBName] set single_user GO
DBCC CHECKDB ([DBName], REPAIR_ALLOW_DATA_LOSS) WITH ALL_ERRORMSGS; GO
ALTER DATABASE [DBName] set multi_user GO
Note: You can also read the Microsoft Warning on DBCC CHECKDB REPAIR ALLOW DATA LOSS.
It might be because of following possible causes:
Permissions
Find your SQL Server instance in the services list and double-click it, then select the Log On tab. It is this log on account that must have sufficient permissions to write to the temporary backup folder location. Check the permissions on the temporary backup folder by right-clicking it in Windows Explorer, selecting Properties, then navigating to the Security tab. Make sure that the account SQL Server is using has explicit read/write permissions for this folder.
Mapped Drives
Use a fully qualified UNC path instead of a mapped drive letter.
Lack Of Domain Trust
You can resolve this issue by ensuring that a trust between the two domains is established. You may also need to configure the SQL Server service account with pass-through authentication between the domains.
Please refer more here for recovery db
Execute these queries to fix SQL server database in recovery pending state:
ALTER DATABASE [DBName] SET EMERGENCY
GO
ALTER DATABASE [DBName] SET single_user
GO
DBCC CHECKDB ([DBName], REPAIR_ALLOW_DATA_LOSS) WITH ALL_ERRORMSGS
GO
ALTER DATABASE [DBName] SET multi_user
GO
EMERGENCY mode marks the SQL Server database as READ_ONLY, deactivates logging, and gives the permission to system admin only. This method is capable of resolving any technical issue and bringing the database back to the accessible state. The database will automatically come out of the EMERGENCY mode.

Replicating Production to Test Environment w/ 2 servers in each

I've got 4 servers total. The production side has live replication from EARTH to TR. The Dev side has live replication from KOHOUTEC to CROMELIN. I'd like to make a snapshot from EARTH to KOHOUTEC.
When I set this up, I get an error:
Cannot drop the table 'dbo.SomeTable' because it is being used for replication.
Googling around, I found this: http://support.microsoft.com/kb/326352.
That article uses this script:
sp_configure 'allow updates', 1
go
reconfigure with override
go
begin transaction
update sysobjects set replinfo = 0 where name = 'object_name'
commit transaction
go
sp_configure 'allow updates', 0
go
reconfigure with override
go
But is also has some pretty serious warnings:
IMPORTANT: The 3724 message may occur legitimately when an object is marked for replication. Do not use the following workaround if the object is being used for replication.
And:
IMPORTANT: Running sp_removedbreplication on a database removes all replication objects from the database. Therefore, all publications and subscriptions in the database are removed.
So I'm understandably a little nervous about doing this, especially since I'm not 100% sure what's going on in the first place.
At the end of the day, all I want is to have the development environment have a nightly copy of the production environment. If replication isn't the way to do it, I'm open to any suggestions.
Thanks!

SQL Server tells me database is in use but it isn't

SQL Server keeps telling me a database is in use when I try to drop it or restore it, but when I run this metadata query:
select * from sys.sysprocesses
where dbid
in (select database_id from sys.databases where name = 'NameOfDb')
It returns nothing.
Sometimes it will return 1 process which is a CHECKPOINT_QUEUE waittype. If I try to kill that process, it won't let me (cannot kill a non-user process).
Anyone have any idea what's wrong?
i like this script. Do not struggle with killing..
use master
alter database xyz set single_user with rollback immediate
restore database xyz ...
alter database xyz set multi_user
I was having the same issue when trying to restore a database from a backup. The solution for me was to ensure that I checked "Overrite the existing database(WITH REPLACE)" and "Close existing connections to destination database" in the Options page BEFORE doing the restore. Here is a screenshot below.
There could be lots of things blocking your database. For example, if you have a query window opened on that database, it would be locked by you. Not counting external accesses, like a web application on IIS.
If you really wanna force the drop on it, check the close existing connections option or try to manually stop SQL Server's service.

Resources