Is it possible to restore a detached database (no re-attachement)?
There is a big database, but no diskspace is available to create a backup.
So, I was thinking to detach the database, copy it to another server.
This other server uses powershell scripts to restore the database.
Will this work with a detached database? I cannot re-attach it with this script. Just restore.
Restore-SqlDatabase -ServerInstance $serverInstance -Database $myDb -BackupFile "detachedFile" -Credential $Cred
Backup of a database is different format (.bak). The files you get in the detach operation: mdf, ndf data file format , ldf log file format are different formats.
You can read about the formats. I have put the content below from the site for easier reference.
Usually, database backup files with .bak extension contain data in the
standard Microsoft Tape Format (MTF) used by Microsoft itself as
well as many backup tools for the Microsoft Windows platform.
Microsoft Tape Format is used while writing and reading data to and
from removable storage devices during storage management or data
protection operations such as data transfers, copies, backup and
restore. In the case of SQL Server, MTF files contain data and log
information (MDF and LDF files) necessary for restoring the database.
The MDF file is the Main Data File or primary database data file, that
binds all other files in that database together. The LDF is the Log
Data File and it contains all log information and is crucial for a
database restore process.
You cannot use Restore database command against mdf,ldf files. You need to use attach, detach approach for them to be available in another environment. As #Peter Smith suggested, you can use the powershell scripts to do the same.
Related
I'm working on a small project to backup and restore databases to different name(s), and I can't seem to figure it out.
I'm using SSMS v18.11.1 with SQL Server 2016, and I have seven databases, let's call them DBCompanyA_1 ... DBCompanyA_7. Their .mdf and .ldf files are stored in the default location of
C:\Program Files\Microsoft SQL Server/MSSQL13.MSSQLSERVER\MSSQL\DATA
I want to make a full backup of each of those 7 databases (with logs) and then restore them to a different name. Using my example above, let's say that I want to restore them to DBCompanyB_1 ... DBCompanyB_7.
The problem I keep encountering is that all attempts (using MOVE) overwrites the existing DBCompanyA_n databases, which is bad. I want to use backup and restore so that the DBs originals' permissions will carry over to the new DBs.
I don't care if the backup procedure is via UI or script, but the restore must be using T-SQL.
I'm curious what inside of a SQL Server database (a .mdf file) since it has been 4 gb and how do I open it to find something interesting in it?
Extracted from data-recovery-solutions:
MDF files are the primary database files of SQL database server and
they are saved as .MDF extension. Being the primary database, MDF
files store all the user database and other database objects like
tables, keys, indices, views, functions, columns, triggers etc. Also,
these files include all the startup info of the SQL Server database.
In an MS SQL Server, each database contains one primary MDF file.
It is a binary kind of file which can’t be opened normally. It is the
main database file that can be attached to a running SQL Server to
access the database using SQL transaction Statements. But, these MDF
files are prone to corruption. Even a smaller corruption in MDF files
makes your entire database contents inaccessible.
See here for a MDF viewer
I have a database in SQL server management studio named wardobsliveisle. I want to create another database in SQL server management studio that is the exact same copy of wardobsliveisle but I want to call it demosql. How do I do this?
You have database wardobsliveisle in SSMS and now you want to create an other database demosql from wardobsliveisle. The process given below creates a copy of wardobsliveisle with new name demosql. This new database has now separate .ldf and .mdf files and it is absolutely a separate copy of your original database.
Follow the steps
Right click on Databases in your Object Explorer in SSMS.
Select Restore Files and Filegroups..., a wizard opens
Type a new database name demosql in To Database box and select source
database (Not a backup file) from From Database dropdown.
Click OK button
It will take a few minutes or less.
Taken from MSDN:
General Steps for Using Backup and Restore to Copy a Database
When you use backup and restore to copy a database to another instance of SQL Server, the source and destination computers can be any platform on which SQL Server runs.
The general steps are:
Back up the source database, which can reside on an instance of SQL Server 2005 or later. The computer on which this instance of SQL Server is running is the source computer.
On the computer to which you want to copy the database (the destination computer), connect to the instance of SQL Server on which you plan to restore the database. If needed, on the destination server instance, create the same backup devices as used to the backup of the source databases.
Restore the backup of the source database on the destination computer. Restoring the database automatically creates all of the database files.
The following topics address additional considerations that may affect this process.
Before You Restore Database Files
Restoring a database automatically creates the database files that are needed by the restoring database. By default, the files that are created by SQL Server during the restoration process use the same names and paths as the backup files from the original database on the source computer.
Optionally, when restoring the database, you can specify the device mapping, file names, or path for the restoring database. This might be necessary in the following situations:
The directory structure or drive mapping used by the database on the original computer not exist on the other computer. For example, perhaps the backup contains a file that would be restored to drive E by default, but the destination computer lacks a drive E.
The target location might have insufficient space.
You are reusing a database name that exists on the restore destination and any of its files is named the same as a database file in the backup set, one of the following occurs:
If the existing database file can be overwritten, it will be overwritten (this would not affect a file that belongs to a different database name).
If the existing file cannot be overwritten, a restore error would occur.
To avoid errors and unintended consequences, before the restore operation, you can use the backupfile history table to find out the database and log files in the backup you plan to restore.
Moving the Database Files
If the files within the database backup cannot be restored onto the destination computer because of the reasons mentioned earlier, it is necessary to move the files to a new location while they are being restored. For example:
You want to restore a database from backups created in the default location of the earlier version.
It may be necessary to restore some of the database files in the backup to a different drive because of capacity considerations. This is likely to be a common occurrence because most computers within an organization do not have the same number and size of disk drives or identical software configurations.
It may be necessary to create a copy of an existing database on the same computer for testing purposes. In this case, the database files for the original database already exist, so different file names need to be specified when the database copy is created during the restore operation.
For more information, see "To restore files and filegroups to a new location," later in this topic.
Changing the Database Name
The name of the database can be changed as it is restored to the destination computer, without having to restore the database first and then change the name manually. For example, it may be necessary to change the database name from Sales to SalesCopy to indicate that this is a copy of a database.
The database name that is explicitly supplied when you restore a database is used automatically as the new database name. Because the database name does not already exist, a new one is created by using the files in the backup.
I've dropped some offline databases through SMSS to free space. But I've discovered that, when I drop an offline database, its disk files are not deleted.
http://msdn.microsoft.com/en-us/library/ms178613.aspx
Dropping a database deletes the database from an instance of SQL Server and deletes the physical disk files used by the database. If the database or any one of its files is offline when it is dropped, the disk files are not deleted. These files can be deleted manually by using Windows Explorer. To remove a database from the current server without deleting the files from the file system, use sp_detach_db.
Since I don't have direct access to the server, is there a way of showing these databases again in SMSS or deleting their disk files via SMSS?
I'm using SQL Server 2008 R2.
Thanks
Try this. Execute the following statements
USE master
GO
ALTER DATABASE DataBase_Name
SET OFFLINE WITH ROLLBACK IMMEDIATE
GO
DROP DATABASE DataBase_Name
GO
How do I export a SQL Server 2000/2005 database to MDF/LDF files? I do not have access to detach the database nor do I have access to login to the database server to copy the files directly.
Can you run commands against the database from a query window? Do you know of a network path accessible to both you and the SQL Server instance? If so then you can issue the following query (instead of trying to coax some backup through the UI):
BACKUP DATABASE dbname TO DISK = '\\some_network_path_you\have_access_to\db.bak'
WITH COPY_ONLY, INIT;
COPY_ONLY is important so that you don't disrupt the production server's log chain.
Then you can copy that file and run RESTORE DATABASE wherever you like.
You don't want to somehow get access to the MDF / LDF files. For one, in order to copy those, you need to shut down the source SQL Server and detach them. This can lead to many bad things, but most importantly downtime on the production server, and the risk that if something should go wrong, you now have ZERO copies of your database.
Then you request that your dba provide the data to you.