Our SQL2019 database used to have a FileTable that needed FileStream. The table has long been removed and there are now no other tables in the database using FileStream.
I've written the following SQL to remove FileStream from my database:
DBCC SHRINKFILE (N'MyDb_files', EMPTYFILE) -- MyDb_files is the name of the file
GO
ALTER DATABASE [MyDb] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
GO
ALTER DATABASE [MyDb] REMOVE FILE [MyDb_files]
GO
ALTER DATABASE [MyDb] REMOVE FILEGROUP [FILES] -- FILES is the name of the file group
GO
ALTER DATABASE [MyDb] SET MULTI_USER
GO
However, after executing above script, when I check system views, I see that the filegroup has been removed, but file state has only been set to OFFLINE - the file still shows up in sys.database_files view.
SELECT * FROM sys.filegroups -- FILES filegroup isn't listed
SELECT * FROM sys.database_files -- MyDb_files is still there. Only its state is changed from ONLINE to OFFLINE
I need to provide a T-SQL script to reliably remove FileStream file and filegroup from database. The script needs to be run on various environments where our product's database is deployed.
I don't know what else needs to be done in the script to actually remove the file that is still being shown as OFFLINE.
Related
I have a file with .backup extension but I need to get only the Insert Statements from this previously made back-up, the problem is that for some reason I can't restore this back-up anymore due to encoding errors, so my question is:
with this file .backup can I extract the insert statements without having to restore the entire database then making a pg_dump again?
After migrating my development database, I'm unable to run rails db:test:prepare.
My application uses the db/structure.sql file to update the test database:
# config/application.rb
config.active_record.schema_format = :sql
When I run rails db:migrate (which also runs db:structure:dump), my db/structure.sql is updated. Unfortunately, it now contains this line near the top after updating:
CREATE SCHEMA public;
This will bomb when loaded into a database that already contains the public schema.
I can manually update that line and the SQL dump loads successfully:
CREATE SCHEMA IF NOT EXISTS public;
...but I don't want to do that every time.
I expect the test database to be built successfully from the SQL dump in db/structure.sql when I run rails db:test:prepare because the SQL dump should not try to create the public schema.
My development environment config explicitly specified the "public" schema. I removed that specification, which allowed db:test:prepare to complete successfully.
# config/environments/development.rb
Rails.application.configure do
...
config.active_record.dump_schemas = "public" # <<-- DELETED!
end
You can configure which database schemas will be dumped when calling db:structure:dump by setting config.active_record.dump_schemas to one of the following options:
:schema_search_path: This looks for the schema names in the schema_search_path setting in config/database.yml.
"<some string>": It will dump the schema names in the string. Names here are comma separated values.
:all: No schema names are specified.
Or just don't set it at all, which is what I did.
If config.active_record.dump_schemas.blank? == true, ActiveRecord's Postgres adaptor will set the --schema=<schema name> flag on pg_dump, which in turn adds the line CREATE SCHEMA <schema name> to its output in db/structure.sql.
An interesting side effect is that now db:test:prepare inserts this instead:
CREATE SCHEMA _template;
I want to make a copy of a live Firebird .fdb database.
I understand that simply copying it could result in a corrupted database and I looked into using the gbak command because it is able to perform a backup while the database is running.
So that will give me a database backup but I would need to restore this before I can use it. My database is nearly 1GB and takes 10 minutes to restore which is too long. Is there any other method to simply copy a Firebird live database from one location to another safely?
So far I have used the following to backup (which works):
gbak -v -t -user SYSDBA -password "masterkey" 127.0.0.1:"C:/Files/Live/Database.fdb" "C:\Test\Test.fbk"
I also tried using the following to backup and restore at the same time:
gbak -c [options] <source database> stdout | gbak -r [options] stdin <target database>
but this kept giving the error:
Done with volume #1, "new.gbak"
Press return to reopen that file, or type a new
name followed by return to open a different file.
The risk of corruption is due to the way Firebird writes it file. Your copy might contain inconsistent data when copied at the same time that Firebird (re)writes a datapage. As far as I know the only real risk of corruption is during writes of index pages (and then only for index page splits), otherwise it just leads to inconsistent data and dangling transactions (which wouldn't be visible anyway as the transaction is not committed).
If you really don't want to use a backup, you can set the Firebird database in a backup state. This freezes the database and writes the changes to a delta file instead. You enable this state using ALTER DATABASE BEGIN BACKUP and end this state using ALTER DATABASE END BACKUP. See the documentation for ALTER DATABASE. This command was added in Firebird 2.0.
For the second part of your question (which really should have been posted as a separate question):
The command gbak -c doesn't create a backup, it Creates a database from a backup (it is the brother of -r (replace) but doesn't overwrite an existing database. See Restore Switches for more information.
See Create a Database Clone Without a Dump File for an example of how you can make a backup like this:
gbak -backup emptest stdout | gbak -replace stdin emptest_2
You can do
alter database begin backup;
then copy the file using standard file copy of your OS and
alter database end backup;
Also I strongly recommend reading these pages [1] [2] about nbackup.
i want to drop a database in oracle 10g..
i saw the command
DROP database.
How to run this query and drop database.
If i tried this query, it is showing error as invalid query.
Oracle documentation states:
Dropping a database involves removing
its datafiles, redo log files, control
files, and initialization parameter
files. The DROP DATABASE statement
deletes all control files and all
other database files listed in the
control file. To use the DROP DATABASE
statement successfully, all of the
following conditions must apply:
The database must be mounted and closed.
The database must be mounted exclusively--not in shared mode.
The database must be mounted as RESTRICTED.
An example of this statement is:
DROP DATABASE;
The DROP DATABASE statement has no
effect on archived log files, nor does
it have any effect on copies or
backups of the database. It is best to
use RMAN to delete such files. If the
database is on raw disks, the actual
raw disk special files are not
deleted.
If you used the Database Configuration
Assistant to create your database, you
can use that tool to delete (drop)
your database and remove the files.
I need to automate the creation of a duplicate db from the .bak of my production db. I've done the operation plenty of times via the GUI but when executing from the commandline I'm a little confused by the various switches, in particular, the filenames and being sure ownership is correctly replicated.
Just looking for the TSQL syntax for RESTORE that accomplishes that.
Assuming you're using SQL Server 2005 or 2008, the simplest way is to use the "Script" button at the top of the restore database dialog in SQL Server Management Studio. This will automatically create a T-SQL script with all the options/settings configured in the way you've filled in the dialog.
look here: How to: Restore a Database to a New Location and Name (Transact-SQL), which has a good example:
This example creates a new database
named MyAdvWorks. MyAdvWorks is a
copy of the existing AdventureWorks
database that includes two files:
AdventureWorks_Data and
AdventureWorks_Log. This database uses
the simple recovery model. The
AdventureWorks database already
exists on the server instance, so the
files in the backup must be restored
to a new location. The RESTORE
FILELISTONLY statement is used to
determine the number and names of the
files in the database being restored.
The database backup is the first
backup set on the backup device.
USE master
GO
-- First determine the number and names of the files in the backup.
-- AdventureWorks_Backup is the name of the backup device.
RESTORE FILELISTONLY
FROM AdventureWorks_Backup
-- Restore the files for MyAdvWorks.
RESTORE DATABASE MyAdvWorks
FROM AdventureWorks_Backup
WITH RECOVERY,
MOVE 'AdventureWorks_Data' TO 'D:\MyData\MyAdvWorks_Data.mdf',
MOVE 'AdventureWorks_Log' TO 'F:\MyLog\MyAdvWorks_Log.ldf'
GO
This may help also: Copying Databases with Backup and Restore