New answers tagged


Looking at your server times: 23 seconds to restore a table with 1,6 million rows from a 1.8 GB dump file. That does not seem too bad. Might be faster, but doesn't seem very slow either. To speed up index creation (as well as UNIQUE and PK constraints) set maintenance_work_mem high enough temporarily (for the local session or transaction only). The manual: ...


In the restore you just give the db, mdb, and log different names. And there is an option to force - I think it is called replace. We do this all the time to create new test db.


Are you looking to do something like a re-name swap? Something like this: Load DB2 Rename DB1 to DB_temp Rename DB2 to DB1 Rename DB_temp to DB2 Then you re-load DB2 again the next time? If so you can simply alter the name of the DB rather than deal with the time a restore takes (the file names will remain the same but that really doesn't matter in ...


dont use "mysqldump" while restoring backup. Use "mysql". mysqldump is for taking backup, not for restoring.


Hmm... you say that you have a .csv dump of the tables of a database? What version of SQL Server was this database extracted from? 679 tables is a largish system and this will require a lot of work. Where are the inter-table relationships stored? You can't store FOREIGN KEY relationships in a .csv dump. Neither can you store CHECK CONSTRAINTs which MySQL ...


You need to check the actual size of the database files which you can check by running RESTORE FILELIST ONLY FROM <backup_device> This will give you information about the files contained in the backup and their sizes in bytes You need the same space available on the server as the database file size, the backups can be compressed. Now you need ...


I don't believe this is possible, typically the database would need to be shrunk before or after a restore. If this were me I'd restore the database on another server, maybe on a dev server, shrink the files, and then copy and restore locally.


The PITR process is as follows: Set up WAL archiving (via archive_command in postgres.conf) Create file-level backup of your database using some tool (I assume pg_basebackup does this?..) Save file-level backup with WAL archive somewhere Then when you need to restore you: Restore file-level backup into some location Copy WAL archive files into some ...


PITR restores forward, not backward. You must use a base backup which was taken before the point in time to which you want to recover.


put "", like this mysqldump -u root -p databasename > "c:/home/databasename_bkup.sql"


You have to start over and restore full and diffs with no recovery and then the tlogs with stand by option. This will allow you to restore tlogs later as well. You can configure logshipping with option of stand by, so you can read from the secondary database. There will be a .tuf (transaction undo file) file created when you restore tlogs with standby ...


Yes, if you want to apply additional transaction logs you will need to start back at your full backup. To quote MSDN, The database cannot be recovered until after the final transaction log has been applied. If you recover the database after restoring one of the intermediate transaction log backups, that before the end of the log chain, you cannot ...


You should use WITH STATS = 10 so that SSMS can show your the progress. Also, if you restored an older version of backup to a newer version of sql server, sql server will undergo an upgrade process .. something along the lines database 'your db name' running the upgrade step from version 661 to version 668 ..


Alright, let's assume you have full backup without archivelog. And your backup is output from rman backup such as rman> BACKUP DATABASE;. So, I'll explain how to restore it. 1. Make sure your DBID is same as your database. (Note : this process is used if you have full backup datafiles,controlfiles,spfile, and copy archivelog if you have.) SQL> SELECT ...

Top 50 recent answers are included