Currently Database is running on No-Archive Log mode. Can i Take only all datafiles (*.dbf) backup i.e. Excluding REDO and Control Files.
Also please let me know steps to restore the *.dbf file back in location.
If you want this database to be opened with simple startup command then you need redo and control files, since they are parts of the database.
However, if you don't have redo and control files in your cold backup then you will have to create control file with the script, usually generated with alter database backup controlfile to trace; and open the database with alter database open resetlogs - this command will create new redo logs.
Actually, you can open the database without the redo logs with alter database open resetlogs if this is a cold copy. The cold copy does not require recovery:
SQL> recover database until cancel using backup controlfile;
ORA-00279: change 6846169 generated at 01/20/2016 16:00:29 needed for thread 1
ORA-00289: suggestion : +DATA
ORA-00280: change 6846169 for thread 1 is in sequence #521
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
Media recovery cancelled.
SQL> alter database open resetlogs;
Database altered.
So no, you don't need redo logs with cold backups. The only requirement fot that is that the database have to be shutdown with immediate, not abort. So it would be consistent.
You also need the control files and red log files.
To restore, shutdown the database and copy the files back to their original locations. Then start the database.
Not recommended practice for a production environment. But I do this a lot with a test environment where I keep different version of the same database as cold backup sets.
Related
My Database is running in No-Archive Log mode. Control files and redo log files are multiplexed on two drives, say A and B. C drive has the rest of the files.
I did a cold backup and did only A and C (no B).
Now, when restoring, I copied control file from A do B. That was ok with control files to go further. But what to do with redo logs which are missing on B?Actually I have on B more recent logs, remaining from the scrapped database - they don't match the cold backup, so I am sure I can drop them but I didn't so far.
I can go as far as to MOUNT. When trying to open database - end of channel communication error. Alter database open resetlogs wants me to do recovery first. Recovery is not working.
Is this a result, that I kept on B non matching redo logs or would it be something different? I thought I would be able to open a database with one member in each redo group being corrupted (B drive) and one being fine (A drive redo logs).
Is there other option than re-create control files (which I have) and open with resetlogs?
It is oracle 12.1.0.1. I will check my trace file but I was thinking about something obvious here.
A database server crashed. I was able to get the mdf and the log file and I am trying to mount it on another server. I don't have backup as it was a development database.
When I try to attach the mdf and ldf files, Sql Server Management Studio give me this error:
TITLE: Microsoft SQL Server Management Studio
------------------------------
Attach database failed for Server
------------------------------
Could not redo log record (457:14202:19), for transaction ID (0:478674), on page (1:519205), database 'WSS_Content_5555' (database ID 15). Page: LSN = (370:463:113), type = 1. Log: OpCode = 2, context 2, PrevPageLSN: (298:40524:64).
Restore from a backup of the database, or repair the database.
During redoing of a logged operation in database 'WSS_Content_5555', an error occurred at log record ID (457:14202:19).
Typically, the specific failure is previously logged as an error in the Windows Event Log service.
Restore the database from a full backup, or repair the database.
Could not open new database 'WSS_Content_5555'.
CREATE DATABASE is aborted. (Microsoft SQL Server, Error: 3456)
I don't know how to repair the database. Does it need to be attached before beeing repaired? In that case, how can I attach it?
You can try a workaround. In short:
Create a dummy DB with the same name (may need to remove the real DB first, save the original files or rename then).
Take the dummy off line (detach and (set offline or stop the SQL service)).
Delete dummy files, replace then with the real DB files.
Try to re-attach de DB
Edit
As by OP comment note you also can need to rebuild the log (if you lost transactions)
ALTER DATABASE [MyDatabase ] REBUILD LOG ON (NAME=’MyDatabaseLog’,FILENAME=’D:\Microsoft SQL Server\YourDataPath\Data\Logfile.ldf’)
and put the DB in multiple users log (taking the DB off can require you to put it in single use mode)
ALTER DATABASE [nomdb] SET MULTI_USER
For all the gore details you can refer to the Paul Randal Article
(Note in this article the author uses EMERGENCY MODE to (attempt) repair the transaction log)
I already used it with success but depending on the extent of the damage or others details it can be a impossible task. Consider restoring a backup.
Note this stunts are fine in a development server but you really need to plan (and drill) for disaster recovery in a prodution server.
Problem:
Backups were failing in one of our servers with the below message: (Backups are taken via Netbackup)
Could not allocate space for object 'dbo.backupfile'.'PK__backupfi__57D1800AC4FFEEA3'
in database 'msdb' because the 'PRIMARY' filegroup is full. Create disk space by deleting
unneeded files, dropping objects in the filegroup, adding additional files to the
filegroup, or setting autogrowth on for existing files in the filegroup.>
DBMS MSG - SQL Message <3009><[Microsoft][ODBC SQL Server Driver][SQL Server]Could not
insert a backup or restore history/detail record in the msdb database. This may indicate a
problem with the msdb database.
On checking, I could see that the Mount Drive on which the primary data file of msdb resides, was full (Total size: 99GB, Free space: 0 bytes). The drive didn’t have any unwanted files which I could delete and gain some easy disk space. So I looked around the Drive and found a database log file which was 6GB in size and of which more than 5.5GB was free. I thought shrinking it will free up quite some space in the Drive and solve the problem for the time being. But when I attempted the shrink on the Log file, I got an error message saying ‘It has been marked SUSPECT by recovery’. Fearing the worst, I refreshed the database list in the Object Explorer and Bingo..!! there it was, marked as ‘Suspect’
Solution:
I checked the other drives in the server and found one with ample free space. So my next attempt was to detach the DB (say ‘XYZ’), move its log file to the other drive and then attach it. This would release enough space in the drive and would also let the DB recover from Suspect mode. So I tried detaching the DB, but it didn’t work.
Cannot detach a suspect database. It must be repaired or dropped. Cannot be opened as the DB is in Suspect mode
So I tried to bring it to Single User mode:
Execute the script to put the DB to single user mode
USE master;
GO
ALTER DATABASE [XYZ]
SET SINGLE_USER
WITH ROLLBACK IMMEDIATE;
GO
Set the database to offline.
-- Take the Database Offline
ALTER DATABASE [XYZ] SET OFFLINE WITH
ROLLBACK IMMEDIATE
GO
Now I was able to successfully detach the Database. After detaching, I copied the log file to the other drive which had enough free space. Then I tried to attach the DB back. But on attaching, It gave the below error msg:
Error: 5123 CREATE FILE encountered operating system error 5A(Access denied.)
To resolve it, the following are the steps I did:
Right click on the .mdf file -> Properties
Under the ‘Security’ Tad, press Continue
Click ‘Add’ to include you in ‘Groups or user names’
Give you login Id in the Pop -up that came up, ‘Check Names’ and ‘Ok’
After adding your login, click on it, and in the Box below (Permissions for User), check Allow ‘Full Control’ for the User. It is very important that you Check ‘Full control’ because by default the user will be having only ‘Read’ and ‘Read & Execute’ permissions. And if you try attaching with just those default permissions, you’ll again get Access denied errors.
After this, I was able to successfully attach the DB, and its status was found to be ‘Normal’.
Hope this will help somebody :)
Never detach a database in this situation. I also suggest not to Run DBCC CHECKDB with repair allow data loss option as you may loss your important data. You can check this reference: https://community.spiceworks.com/topic/1078473-sql-server-database-in-suspect-mode
Try to use master database It will reset the state of the database you can work with it.
EXEC sp_resetstatus your_db_name
ALTER DATABASE your_db_name SET EMERGENCY
DBCC checkdb (your_db_name)
ALTER database your_db_name SET SINGLE_USER with ROLLBACK IMMEDIATE
DBCC CHECKDB (your_db_name, REPAIR_ALLOW_DATA_LOSS)
Alter database your_db_name SET MULTI_USER
In my local C: drive I have a ldf file for a database that is hosted on one of our servers. I have a local copy of one of the databases that is 1 gb and a ldf (log file) of that database that is 16gb. It is eating up a lot of my local space on my hard drive. I would like to truncate that file. A lot of what I read online is don't, but it seems that they are talking about files on the server that the database is on. That isn't the case here, it is on my local machine.
The location of the file on my machine is:
C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA
How come I have a copy of that log file locally and also that database locally?
How would I go about truncating this file?
Thanks!
Go to the Object Explorer pane in SSMS and right click on the database in question. Choose tasks -> shrink -> files. Change the file type option to Log, click the "Reorganize pages before releasing unused space" option, and set the value to 1 MB. Hit OK.
If this doesn't work, check to see if your database is set up with a Full database recover model. Right click the database and go to properties. Choose Options, and check the Recover model option. Set to simple (if you can!!!), then shrink the logs.
The another option you can try is to use WITH TRUNCATE_ONLY:
BACKUP LOG databasename WITH TRUNCATE_ONLY
DBCC SHRINKFILE ( adventureworks_Log, 1)
but don't try this option in live environment, the far better option is to set database in simple recovery. see the below command to do this:
ALTER DATABASE mydatabase SET RECOVERY SIMPLE
DBCC SHRINKFILE (adventureworks_Log, 1)
My sql server marked one database as suspected , on checking i found my mdf,ldf files are missing, but no errors on chkdsk, what it means some virus ?
Either the files were deleted, or they have been moved and a master database backup restored from before the change in location. In both cases the physical files can only be deleted or moved if the database is offline - either because sql server was shut down or the database was closed.
Either of these things is highly unlikely to have happened accidentally. It's unlikely to be a generic virus or trojan as such would either have to specifically delete the files on startup before SQL Server started (assuming your database starts automatically) or shut down the database then specifically delete the files. Given that chkdsk doesn't report errors either it's unlikely to be a disk issue, so it's a virtual certainty that the cause of the error is deliberate database (mis)management.
I think the most likely option is that a dba has decided that the files should be moved elsewhere - typically this is done for space or performance reasons - for instance if a new drive is added to a machine that is running out of space then the database could be moved to that. For some reason a backup of the master database has subsequently been restored from a point before the move.
My first action would be to do a full scan of the system for all mdf/ldf files and (hopefully) locate them. I'd also do a scan of backups and look for the latest master database backup. You could either then try restoring the last master backup and see if that fixed the issue (i'd back up the current master first of course), and failing that, or directly, reattach the missing files.
If you cannot find the mdf/ldf files then your only option is restore from backup. If you don't have a backup then your database is lost.
http://support.microsoft.com/kb/180500
At startup, SQL Server attempts to obtain an exclusive lock on the device file. If the device is being used by another process (for example, backup software) or if the file is missing, the scenario described above will be encountered. In these cases, there is usually nothing wrong with the devices and database. For the database to recover correctly, the device must be made available, and the database status must be reset.
It means someone deleted the files.
They can not be deleted when in use so it happened:
when SQL Server was shut down
the database was closed (Express version usually)
the database was taken offline
All user dbs will share the same folder (edit) by default (end edit) so this is deliberate
The more exotic options include restoring the master db where the databases/MDF files listed in the restored master db do not exist etc. But I doubt it.
In this situation, you can check the SQL Server logs. Go to Management, Click on SQL Server Logs and click on current and check the message.
In my case, I got this:
Error 17207, severity 16, state 1 (it is related to log file deletion or corruption)
Solution:
Set the database into single user mode:
Alter database dbname set single_user
Now set the database into emergency mode:
Alter database dbname set emergency
Repair missing log file or corrupted log file with data loss.
DBCC CHECKDB ('dbname', REAPIR_ALLOW_DATA_LOSS)
Note: You may loss the data by using this command. It also depends on client's approval.
Now set the db in multi user mode;
alter database dbname set multi_user
In SQL Server suspect database is a mode when user unable to connect with database.
At this time user unable to perform any action and can not do anything like no open no backup and no restore etc.
Possible cause for this problem can be one of the following:
1. Database is corrupted
2. Insufficient memory state.
3. unexpected shutdown etc.
4. OS is unable to find the database file