I was tasked to remove a bunch of Files and Filegroups from a SQL database. Now I have read multiple sites but they all use DBCC SHRINKFILE (N'filename', EMPTYFILE).
From the MS document on SHRINKFILE it states"
EMPTYFILE
Migrates all data from the specified file to other files in the same filegroup.
I do not want to migrate the data, I want to purge it. Is there any way to purge the data so I can remove the files/filegroups without needing to use SHRINKFILE?
I also do not want to take the database offline if that can be prevented. These files and groups are created by one of our systems, so would prefer that the database remain online so the system can use the database.
It creates a new Group on a monthly basis, and a File for each day. The data we want to remove is from 2019, and no longer needed and we need to recover the space.
TIA
What I ended up doing was setting the database to RESTRICTED_USER for a couple of minutes, set all the filegroups to READWRITE, then set the database back to MULTI_USER. Thus keeping the downtime to a minimum.
After that I ran the DROP TABLE, DBCC SHRINKFILE (..., EMPTYFILE) and REMOVE FILE commands and it cleared up the space on the drive.
Thank you for those that commented, it helped in getting the script working. :)
Related
I need a backup from a database that makes a backup from the whole database but changes a few fields in table with random data (instead of the real data).
What is a good way to do that?
Thanks in advance ;-)
There is no silver bullet or one size fits all script for this issue, however the process itself is not a big deal, if I follow your question to the letter, you are looking for guidance on how to script the following 3 operations
Backup the database
Restore into a temporary location
Execute scripts to anonymize the data
Backup the anonymized data
See issue 1
This is a common development scenario, but also comes up when we want to otherwise test or demonstrate an application to prospective clients. Read over this tip for detailed information as well as a solution Automatically Create and Anonymize Downstream Databases from Azure
Scripting Backups
MSDN is a good source of scripts for common SQL Server tasks, there are many different flavours for scripting backups and many of them will be dependent on what resources your database is hosted on, this is a good start, but google or SO is your friend here: Create a Full Database Backup (SQL Server)
USE SQLTestDB;
GO
BACKUP DATABASE SQLTestDB
TO DISK = 'E:\Backups\SQLTestDB.Bak'
WITH FORMAT,
MEDIANAME = 'E_Backups',
NAME = 'Full Backup of SQLTestDB';
GO
Restoring backups
You can easily use Backup to clone an existing database and restore it into the same server as long as you use a different database name, and you restore to different logical files on disk
by default a restore operation would try to use the original filenames but that will not work when we restore side-by-side the original source database, because those files are still in use by the source database!
Have a read over Restore a Database to a New Location (SQL Server)
First you need to know the names of the files stored within the backup, then you can construct a query that will restore the database mapped to new files.
This answer to How do you backup and restore a database as a copy on the same server? should help a lot.
Putting that together we get:
BACKUP DATABASE SQLTestDB TO DISK = 'E:\Backups\SQLTestDB.Bak'
GO
-- use the filelistonly command to work out what the logical names
-- are to use in the MOVE commands. the logical name needs to
-- stay the same, the physical name can change
restore filelistonly from disk='E:\Backups\SQLTestDB.Bak'
-- --------------------------------------------------
--| LogicalName | PhysicalName |
-- --------------------------------------------------
--| SQLTestDB | C:\mssql\data\SQLTestDB.mdf |
--| SQLTestDB_log | C:\mssql\data\SQLTestDB_log.ldf |
-- -------------------------------------------------
restore database SQLTestDB_Temp from disk='E:\Backups\SQLTestDB.Bak'
with move 'SQLTestDB' to 'C:\mssql\data\SQLTestDB_Temp.mdf',
move 'SQLTestDB_log' to 'C:\mssql\data\SQLTestDB_log.ldf'
It is possible to put this script into a stored proc so you can reuse it, one issue is how to use the results from RESTORE FILELISTONLY, you'll find this answer will help if you want to go down that path: https://stackoverflow.com/a/4018782/1690217
Anonymizing Data
This is where things get specific, now that your database has been restored to a temporary location, you can pretty much do whatever you want to the data in a series of INSERT, UPDATE, or `DELETE' statements that you need, you could even modify the schema to remove particularly sensitive or audit or other logging tables that you may have that you don't need to distribute.
Do not leave audit tables in the database that you have anonymized, unless you plan on anonymizing the context within those logs as well! Depending on your circumstances, also consider nulling out all IMAGE and VARBINARY columns as their contents will be particularly hard to process sufficiently.
I wont go into the specifics, there are already healthy discussions on this topic on SO:
Anonymizing customer data for development or testing
Backup the Anonymized data
When you have finished scrubbing or anonymizing your database, simply complete your script with a call to backup the temporary DB that has been anonymized.
I have been using DBCC SHRINKFILE with EMPTYFILE to move data from one secondary data files data to another. There is currently four files in the filegroup and there is over 1TB free of space between those files.
Oddly, I've had the system alert me that the filegroup that these files belongs to is full and that no space could be allocated for a table (user) table.
I've used this numerous times before and never had this happen and some googling couldn't seem to find any other incidents that people had reported. Anybody have any ideas?
Version of SQL Server is 2008R2
I had this exact problem. It turned out that a nightly maintenance process was issuing an ALTER INDEX command on an index in the same file while the DBCC SHRINKFILE WITH EMPTYFILE was running. Makes sense that ALTER INDEX wouldn't work while the file is marked to not accept new data.
In our environment, we resolved this by preventing the nightly maintenance process from issuing this command and issuing it manually outside of the time that we allow the SHRINKFILE to run.
When I want to restore a database I think that the best option is to create a backup of the database. However, I can create a script that saves schema and database, save primary keys, foreign keys, triggers, indexes...
In this case of script the result is the same as restore's ? I ask this because the script has a size about 1MB and the backup about 4MB.
I ask this because I would like to change the collation of all my columns of all my tables and I try some scripts but this does not work, so I am thinking in the possibility to create and script, so when I create the tables these are created with the collation of database. This collation I set in the script when I create the database.
Is it a good option to use a script for that or I can lost some type of restrictions or other design elements?
Thanks.
You can see Full Database Backup at msdn. The primary difference is that the transaction log is backed up. This provides you with many options such as differential backups that will eventually lead to less space needed in your drives to store your data.
In addition, using the backup schemes will provide you with easier ways to organize where,when and how(that is strategies) you backup.
There are ways to implement a full db backup by scripts look here, where you will lose nothing.
I have a SQL Server 2005 database from which I'm removing several large tables to an archive database. The original database should shrink considerably.
To make the archive database, I was going to restore a copy of the original and just remove the current tables from that.
Is this the best way to go about it? What should I do with logs/shrinking to make sure the final sizes are as small as possible? The archive database may grow a little, but the original continues its normal growth.
That seems like an ok way to do it. Set the recovery model to simple, then truncate and shrink the log files. This will make it as small as possible.
See here for a good way to do it.
Note: This assumes you don't want or need to recover the archive database back to specific points in time. The reason being that Simple recovery model does not save the transactions in a transaction log. So as your archive database changes "a little" (as you said), it won't save the transactions to a log.
I use this script and this is very useful in developing.
BACKUP log [CustomerServiceSystem] with truncate_only
go
DBCC SHRINKDATABASE ([CustomerServiceSystem], 10, TRUNCATEONLY)
go
Redesign the db
Try one of these sql commands:
DBCC SHRINKDATABASE
DBCC SHRINKFILE
Or right click into Sql Server Management Studio Object Explorer's database and select Tasks-Shrink.
I have a table in a database that I would like to backup daily, and keep the backups of the last two weeks. It's important that only this single table will be backed up.
I couldn't find a way of creating a maintenance plan or a job that will backup a single table, so I thought of creating a stored procedure job that will run the logic I mentioned above by copying rows from my table to a database on a different server, and deleting old rows from that destination database.
Unfortunately, I'm not sure if that's even possible.
Any ideas how can I accomplish what I'm trying to do would be greatly appreciated.
You back up an entire database.
A table consists of entries in system tables (sys.objects) with permissions assigned (sys.database_permissions), indexes (sys.indexes) + allocated 8k data pages. What about foreign key consistency for example?
Upshot: There is no "table" to back up as such.
If you insist, then bcp the contents out and backup that file. YMMV for restore.
You can create a DTS/SSIS package to do this.
I've never done this, but I think you can create another file group in your database, and then move the table to this filegroup. Then you can schedule backups just for this file group. I'm not saying this will work, but it's worth your time investigating it.
To get you started...
http://decipherinfosys.wordpress.com/2007/08/14/moving-tables-to-a-different-filegroup-in-sql-2005/
http://msdn.microsoft.com/en-us/library/ms179401.aspx