I checked In sql server 2019(15.0.2070.41) and tried to remove with bellow mentioned command:
Alter database InMemoryCheckpoint
Remove file InMemoryCheckpointDF
Alter database InMemoryCheckpoint
Remove filegroup InMemoryCheckpointDF
You can't remove a memory-optimized filegroup.
The following limitations apply to a memory-optimized filegroup:
Once you use a memory-optimized filegroup, you can only remove it by
dropping the database. In a production environment, it is unlikely
that you will need to remove the memory-optimized filegroup.
https://learn.microsoft.com/en-us/sql/relational-databases/in-memory-oltp/the-memory-optimized-filegroup?view=sql-server-ver15
!!! Please use this method in case of corrupted database that contains memory optimized table (you can't use DBCC check on databases that contains memory optimized tables) !!!
WARNING: This is an unsupported operation. There have been reports of unrecoverable log corruption when using this.
It's a hack method and it's risky. Microsoft didn't verified this solution
Before doing anything take backup
1- Delete memory optimized tables
2- Detach Database
3- Create new database with same files without memory optimized filegroup
4- Modify database files and change it to detached database (mdf,ldf,ndf) files
alter database test1 modify file (name='test1' , filename='C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\test.mdf')
alter database test1 modify file (name='test1_log' , filename='C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\test_log.ldf')
5- Now try to to repair database:
alter database test1 set emergency
alter database test1 set single_user with ROLLBACK IMMEDIATE;
dbcc checkdb(test1,repair_allow_data_loss)
alter database test1 set multi_user
alter database test1 set online
6- After successfully repair database remove memory optimized filegroup from database
ALTER DATABASE [test1] REMOVE FILEGROUP [memory_optimized_filegroup_0]
Follow steps correctly for prevent log corruption
Step 4: Alter log file name must be done correctly
Step 5: DBCC is Important to prevent corruption
Also for getting best result:
Don't use database while doing steps (Insert - Update - Changing
Schema)
do CHECKPOINT to flush log to data file then shrink log file
you will never have log corruption issue
Don't forget:
Before using your database do this steps for checking issue:
Insert or update 1 row in database
Do CHECKPOINT
Restart server
If database got online i think you did all steps correctly else Restore database from backup and forget about removing memory optimized filegroup
Used these commands and they worked fine for me:
USE [<dbname>]
GO
ALTER DATABASE [<dbname>] REMOVE FILE [<filename>]
GO
ALTER DATABASE [<dbname>] REMOVE FILEGROUP [<Group Name>]
GO
Related
I am trying to backup an Oracle 19c Database using RMAN but I seem to be running into a few hiccups. What I did first was create test tables and users in the database before backup. Within RMAN I then ran
RMAN> BACKUP DATABASE PLUS ARCHIVELOG;
With the database backed up I then dropped the test tables and users I created and starting restoring the database
RMAN> restore controlfile from 'LOCATIN OF CONTROLFILE';
RMAN> ALTER DATABASE MOUNT;
RMAN> RESTORE DATABASE;
RMAN> RECOVER DATABASE;
RMAN> ALTER DATABASE OPEN RESETLOGS;
When I then connected to the database, it is missing all the tables and users I deleted. I'm not sure whether if I needed to update my datafiles or there is a step that I am overlooking. Thank you
You have to use
Set until SCn
and provide a SCn before you are dropping the tables and and tablespaces.
You can also create a restore point before dropping tables and use rman command to restore database to restore point 'rspname'
This is impossible! Firstly, rman run with "PLUS ARCHIVELOG" so your database is currently in archivelog mode. Secondly, you restore controlfile & database then perform "COMPLETE" recovery so at the time of complete - your test tables and users must be there.
If you would have followed the steps them you must see the tables. To avoid confusion use set until time or SCN or Time
SET UNTIL SCN <scn after object creation>;
SET UNTIL SEQUENCE <seq no after table creation>;
set until time <time after table creation>;
Also pls verify did you connect to right database
Here is the example
RMAN> restore controlfile from 'LOCATIN OF CONTROLFILE';
RMAN> ALTER DATABASE MOUNT;
RMAN>RUN
{allocate channel c1 device type disk;
allocate channel c2 device type disk;
set until time '2020-03-19:15:30:00';
restore database;
recover database;
ALTER DATABASE OPEN RESETLOGS;
}
I have two machine A and B and i want two setup standby database in machine B, so i have followed below steps..
Install oracle 11g express in machine A and same install in another
machine B for standby.
Enable Archive mode in both machine A and B.
Create TableSpace with name tbs_test on both machine.
Create user testuser on both machine & grant permission for dba.
In Machine A, i have create a table Tb_Employee and insert data
into table Tb_Employee on table space tbs_test.
Now take backup from some script on machine A and trying to
restore on machine B but not succeed due to some error mentioned in below statement.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
*
ERROR at line 1:
ORA-00283: recovery session canceled due to errors
ORA-19909: datafile 1 belongs to an orphan incarnation
ORA-01110: data file 1: 'C:\ORACLEXE\APP\ORACLE\ORADATA\XE\SYSTEM.DBF'
I have used following script to take backup(Full backup + Archive)
Step 1 Execute Begin Backup Script
conn / as sysdba;
alter system checkpoint;
alter tablespace SYSAUX begin backup;
alter tablespace SYSTEM begin backup;
alter tablespace TBS_Test begin backup;
exit;
Step 2 Copy SYSAUX.DBF, SYSTEM.DBF and TBS_Test.DBF files to backup directory
Step 3 create standby control file through execute following script
conn / as sysdba;
alter database backup controlfile to trace as 'C:\Backup\controlfile.txt' reuse;
alter database backup controlfile to 'C:\Backup\controlfile.ctl' reuse;
alter database create standby controlfile as 'C:\Backup\controlfile_standby.ctl';
exit
Step 4 copy stand by control file as Control.DBF into backup directory
Step 5 After copied files Execute End Backup Script
conn / as sysdba;
alter tablespace SYSAUX end backup;
alter tablespace SYSTEM end backup;
alter tablespace UNDOTBS1 end backup;
alter tablespace TBS_Test end backup;
exit;
Step 6 Execute script for Archive log
conn / as sysdba;
alter system checkpoint;
alter system archive log current;
disconnect;
exit;
Step 7 After execute script copy all archive files into backup directory("C:/Backup")
After just restore file into Machine B.
Not sure Oracle Express support standby (please consult the
documentation - as I remember Data Guard is licensed on top of
Enterprize Edition)
In order to configure standby it is not enough just to backup one
instance and restore to another - for this you will have to make
some more configurations (for example - to name instances according,
FORCE LOGGING, backup controlfile for standby, set LOG_ARCHIVE_DEST
parameters and many others, see documentation)
Your question is too "wide" we don't know what and how it has been done (put the scripts here), and in which order.
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
I have been created new database and the log file groth very past, and I get error mesaage that the log is full due to 'BACKUP'.
I looked in the differences between this Database and other databases in the SERVER, and I seen that in all databases log_reuse_wait is 0 and log_reuse_wait_desc is NOTHING and in my database log_reuse_wait is 0 and log_reuse_wait_desc is LOG_BACKUP.
I want to change this property in my database to 0 and NOTHING.
How can I do that?
This is a read-only status variable. It tells you why the log cannot be truncated at this point.
You have to remove the cause of that condition instead of just changing the value (which isn't even possible).
Either backup the database log or switch to SIMPLE recovery mode. You should probably read a little on both just to understand the implications.
David W.'s script did not quite work for me. (SQL Server 2008 r2)
I needed to modify it slightly. Using the script as is I got the message that there was no such file for database [master]. Alter the DATABASE as David W. recommends and then switch to the target database and run the DBCC SHRINKFILE() command.
Also the first argument to DBCC SHRINKFILE() must be the logical name of the database log file, which is represented in the following script as logical_file_name_for_LOG
USE [master]
GO
ALTER DATABASE <db name> SET RECOVERY full
GO
ALTER DATABASE <db name> SET RECOVERY SIMPLE WITH NO_WAIT;
GO
USE [db name]
GO
DBCC SHRINKFILE('<logical_file_name_for_LOG>', 0, TRUNCATEONLY)
i found the solution.
even the database is in SIMPLE mode is wait to BACKUP_LOG, so you need to change the recovery mode to FULL and then back to SIMPLE with no wait
USE [master]
GO
ALTER DATABASE <db name> SET RECOVERY full
GO
ALTER DATABASE <db name> SET RECOVERY SIMPLE WITH NO_WAIT;
GO
USE [db name]
GO
DBCC SHRINKFILE('<log file name>', 0, TRUNCATEONLY)
I know this is old, but the answers are wrong.
If the database has recovery mode FULL and that is intended, then do not change it to simple.
The log_reuse_wait_desc says what the state is before the log can be reused or shrinked. In this case it is LOG_BACKUP, meaning that, to shrink the transaction log, you need to backup the transaction log first and shrink it or backup the log and let the SQLServer reuse the log space.
A description of the log_reuse_wait_desc states can be found here
I have an MDF file and no LDF files for a database created in MS SQL Server 2005. When I try to attach the MDF file to a different SQL Server, I get the following error message.
The log cannot be rebuilt because there were open transactions/users when the database was shutdown, no checkpoint occurred to the database, or the database was read-only. This error could occur if the transaction log file was manually deleted or lost due to a hardware or environment failure.
I would like to accomplish any one of the following options:
Attach the database without data loss (unlikely but would save me some time).
Attach the database with data loss (whatever transactions were open are lost).
Recover the schema only (no data) from the MDF file.
What SQL commands can I try to get my database going again?
I found the following document on Experts Exchange.
patrikt:
You will have data loss but it can be done.
1. Detach database and move your mdf to save location.
2. Create new databse of same name, same files, same file location and same file size.
3. Stop SQL server.
4. Swap mdf file of just created DB to your save one.
5. Start SQL. DB will go suspect.
6. ALTER DATABASE yourdb SET EMERGENCY
7. ALTER DATABASE yourdb SET SINGLE_USER
8. DBCC CHECKDB (yourdb, REPAIR_ALLOW_DATA_LOSS)
9. ALTER DATABASE yourdb SET MULTI_USER
10. ALTER DATABASE yourdb SET ONLINE
Here are details that cover parts 2) and 3) in case re-creating log doesn’t work which can happen if MDF file is corrupted.
You can recover data and structure only by reading MDF file with some third party tool that can de-code what’s written as binary data but even with such tools you can’t always do the job completely.
In such cases you can try ApexSQL Recover. From what I know this is the only tool that can do this kind of job but it’s quite expensive.
Much better idea is to try to recover these from any old backups if you have any.
FROM a post at SQL Server Forums Attaching MDF without LDF:
If you want to attach a MDF without LDF you can follow the steps below
It is tested and working fine
Create a new database with the same name and same MDF and LDF files
Stop sql server and rename the existing MDF to a new one and copy the original MDF to this location and delete the LDF files.
Start SQL Server
Now your database will be marked suspect 5. Update the sysdatabases to update to Emergency mode. This will not use LOG files in start up
Sp_configure "allow updates", 1
go
Reconfigure with override
GO
Update sysdatabases set status = 32768 where name = "BadDbName"
go
Sp_configure "allow updates", 0
go
Reconfigure with override
GO
Restart sql server. now the database will be in emergency mode
Now execute the undocumented DBCC to create a log file
DBCC REBUILD_LOG(dbname,'c:\dbname.ldf') -- Undocumented step to
create a new log file.
(replace the dbname and log file name based on ur requirement)
Execute sp_resetstatus
Restart SQL server and see the database is online.
UPDATE: DBCC REBUILD_LOG does not existing SQL2005 and above. This should work:
USE [master]
GO
CREATE DATABASE [Test] ON
(FILENAME = N'C:\MSSQL\Data\Test.mdf')
FOR ATTACH_REBUILD_LOG
GO
have you tried to ignore the ldf and just attach the mdf:
sp_attach_single_file_db [ #dbname = ] 'dbname' , [ #physname = ] 'physical_name'
i don't know exactly what will happen to your open transactions (probably just lost), but it might get your data back online.
-don
See here : Rebuild master and restore system databases from complete disk failure which has a very nice explanation
Just had this problem myself, but none of the above answers worked for me.
But instead, I found this which worked a treat and so I thought I'd share this for everyone else:
http://www.kodyaz.com/articles/sql-server-attach-database-mdf-file.aspx
Found a another way that works completely:
Create new database with same name to default database location.
Stop SQL server.
Copy old mdf file to overwrite newly created mdf file and delete new ldf file
Start SQL Server, database will be in emergency mode
Detach the emergency mode database
Copy original ldf file to default database location (where new LDF file as created and deleted under step 3 above.
Attach the database MDF file.
I got a working database after trying all of the above that failed for me.
I hope it is easy to do so,
Open SQL Server
Click New Query
Execute the following query
sp_attach_single_file_db #dbname='dbname',#physname='C:\Database\dbname.MDF'
Where dbname is you want to show in Object Explorer, where #physname is the local filepath location of your mdf file.
Hope it will help someone, i done by above, got both structure and also data.
Tested in Sql Server 2000 and 2008. In Sql Server 2000 it is not working, but works perfectly in 2008.