Is there any way that we can do DML operation with out logging it into log file?
For example, when I am inserting a row in database, this operation will be logged in log file irrespective of using transaction or not. But I don't want to log this operation in the log file.
No. Never. Not possible.
Every operation is logged for a reason: what if it fails halfways through? Server crashes? etc etc
In summary: the A, C and D in ACID
If you don't want this, then using I would really consider using non-ACID NoSQL alternatives.
SQL Server will always write an insert to the log file. It needs that information to recover a database in a consistent state when the server resets.
You can change to impact logging has by choosing the recovery model:
alter database YourDb set recovery { FULL | BULK_LOGGED | SIMPLE }
In simple mode, SQL Server logs just running transactions, and starts reusing parts of the log that are no longer needed. In simple mode, the log file typically remains small.
If you want to get rid of logs after an insert operation, you can use:
alter database YourDb set recovery simple with no_wait
dbcc shrinkfile(YourDbLog, 1)
alter database YourDb set recovery <<old model here>>
Note that this gets rid of all logs. You can only use the restore the last full backup after running this command.
Related
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
Scenario:
I have an application attempting to write to a SQL Server DB, and I'm getting the message:
The transaction log for database 'DB_NAME' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases
However, I see that there is plenty of space on the drive for the transaction log to be written and autogrowth is on. So from SQL Management Studio, I issue:
select name,
log_reuse_wait,
log_reuse_wait_desc
from sys.databases
where name = 'DB_NAME'
and can see that the log_reuse_wait is '3'.
Question:
Do SQL Server transaction logs get 'locked' in any way when this wait is in place?
Note that this is set to 'Simple' recover model. Please let me know if there is more information I need to provide to make this a complete question.
This article may be of help.
https://msdn.microsoft.com/en-us/library/ms190925.aspx
The log reuse wait you are encountering indicates that there is a backup in progress.
Even in simple recovery, a full database backup has to include part of the transaction log.
Here's my setup. Once a day, a full backup of my DB is retrieved from the production server and restored onto a local SQL Server instance. Every 15 minutes aftwerwards, a SQL transaction log is retrieved from production and restored locally.
RESTORE DATABASE [DBNAME] from disk=#path with NORECOVERY, REPLACE)
RESTORE LOG [DBNAME] from disk=#path with NORECOVERY
In case of a failure of the production environment, I need to be able to use the local DB instead. This means "finishing up the restore" and changing some configuration values like this :
RESTORE DATABASE [DBNAME] with RECOVERY
UPDATE [DBNAME].dbo.[TABLE] SET [COL1] = 1
I have put this code in a stored procedure (in another DB on the same SQL Server instance). However, I am unable to execute it as the second line causes an error:
Database 'DBNAME' cannot be opened. It is in the middle of a restore.
I assume this is due to pre-validation by the SQL Server engine (since the DB is not available until the RESTORE query is executed), but I would like to know how to work around it as cleanly as possible. I found a workaround, which I posted as an answer below, but it's definetely not a great way to solve the problem.
Thanks for the help!
You should be able to work around this by placing the second statement in an EXEC:
RESTORE DATABASE [DBNAME] with RECOVERY
EXEC('UPDATE [DBNAME].dbo.[TABLE] SET [COL1] = 1')
The issue you're likely seeing is that SQL Server wants to compile the entire stored procedure before it starts executing. In order to compile the UPDATE, it needs to, at the very least, confirm the existence of the table and column(s) involved.
So, put it in an EXEC so that it's not compiled until that part of the procedure is reached.
The workaround I have found is simple:
Create a stored procedure that executes the query on the database.
Call this SP in the first stored procedure.
However, I'd like to avoid cluttering up my SQL Server databases with unnecessary stored procedures if at all possible!
If you know roughly long it takes to restore you could put a delay in it maybe?
restore database [DBName] with recovery;
Begin
waitfor delay '00:01'; --one minute delay
update [DBTable] set [Col1]= 1;
END;
I am doing restores across servers via dynamic sql and linked servers as follows:
Exec ('USE MASTER; RESTORE DATABASE <dbname> FROM DISK = <path> WITH REPLACE, RECOVERY') AT <target server>
The database is set to single user mode before the above statement runs. However, on intermittent occasions, when trying to get the database back to multi user mode I get the a query timeout from the the target server and error:
ALTER DATABASE is not permitted while a database is in the Restoring state
I have looked around for this error but apparently I'm should not be getting it when using the RECOVERY option.
Any ideas please?
I managed to figure this out today. The culprit behind the issue was the default remote query time out for Sql Server which is 600s (10mins). More on this in the following link https://msdn.microsoft.com/en-us/library/ms189040(v=sql.105).aspx
My restore usually takes around 10mins to complete, sometimes a bit less so it succeeds and sometimes a bit more when it fails. Hence the issue was manifesting itself intermittently.
I increased the remote query time out on the source server to 36000s and it restored successfully. Just to prove the point, I decreased the remote query time out to a small figure like 60s and got the same symptom again.
Michelle - I set the database in single user to kill any running queries before the restore and to make sure there are no conflicts whilst the database is restored. This would eliminate the Exclusive Access could not be obtained because the database is in use error. Alternatively the database can be put to offline before the restore is initiated and back to online afterwards.
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.