I'm having some trouble backing up and restoring a database in pgAdmin.
With pgAdmin, the backup is pretty simple.
If I try to restore the data to my live database, I get all kinds of foreign key errors and duplicate data. So the only way for me now is to drop all constraints, drop all tables and run the restore.
Is there a simpler way to restore a live database? My systems are not directly connected, I'm using file transfer to copy over the backed up db dump.
Related
I have taken a backup of a table in pgadmin by rightclick->backup. Now i want to restore that backup with different name so that existing table isn't get affected.
Note - I can rename the existing table and restore the backup file. But often the db server hangs when i rename the active table in production. So this doesn't work for me.
Every time I create a new database it's creating a table in that database. I'm finding information about model databases for Microsoft SQL Server, but I can't find anything for Postgres.
You probably created that table in the template1 database.
When you create a database, Postgres doesn't really create it from scratch, it copies an existing one.
Quote from the manual
By default, the new database will be created by cloning the standard system database template1. A different template can be specified by writing TEMPLATE name.
Just connect to the template1 database and drop the table there.
I have server1 and server2 in my environment, both have db2 v11.1 installed.
I have already done an online tablespaces (TS1, TS2, TS3) incremental backup of my database GS_DB and obtained the below 3 images.
Image1 at timestamp1: 20190215162151 (full online backup of TS1,TS2,TS3)
Image2 at timestamp2: 20190215162254 (incremental online backup of TS1,TS2,TS3)
Image3 at timestamp3: 20190215162725 (incremental online backup of TS1,TS2,TS3)
In server1, suppose I want to restore my db to image2 (20190215162254), I can do:
db2ckrst -d GS_DB -t 20190215162254 -r tablespace
Suggested restore order of images using timestamp 20190215162254 for database gs_db.
====================================================================
restore db gs_db tablespace ( TS1, TS2, TS3 ) incremental taken at 20190215162254
restore db gs_db incremental taken at 20190215162151
restore db gs_db incremental taken at 20190215162254
====================================================================
If I follow the order and restore to the existing GS_DB in server1, it is working fine.
Now I transferred 3 images to server2 and created an empty database GS_DB in server2, then try to use the above command to restore tablespaces TS1,TS2,TS3 to GS_DB in server2:
db2 restore db gs_db2 tablespace ( TS1, TS2, TS3 ) incremental taken at 20190215162254
SQL2560N The table space restore operation failed because the target database is not identical to the source database.
Already stuck at the first command, does it mean we cannot restore tablespace backup image across two different db? Any way I can do it?
Thanks in advance!
Every database has an unique internal identifier called Seed. You can't create another database with the same Seed as the existing one, even you create it with the same name. These databases are different from the DB2's point of view.
Citation from the Restoring to an existing database article:
The database manager assigns the seed when you create the database.
Db2® always uses the seed from the backup image.
You can restore a table space into an existing database only if the table space exists and if the table spaces are the same, meaning that you did not drop
the table space and then re-create it between the backup and the
restore operations.
The database on disk and in the backup image must
be the same.
So, yes, you are not able to restore tablespace backup image across two different db in the way you try.
Read about the Database schema transporting feature.
I accidentally dropped original postgres database after installing postgreSQL software. Postgres user is still there, \du superuser. How to recover or recreate original postgres database?
https://www.postgresql.org/docs/current/static/sql-createdatabase.html
just run
create database postgres;
it will create db with default template (which is "template1"). If you did not modify it - it will be same is previous "postgres" db
You can only recover it if you have some previous backup of that database, by restoring that backup and then applying WAL files upto the time when drop database statement was issued.
There is no other way to recover a dropped database.
I have a production Postgresql database which consist of 70 tables. Some of them are very big and some are small. And I have my local Postgresql database on my local machine. I want to make some of my local database tables's content be the same as production ones. If I just backup some tables with pgAdmin on production database and then try to restore on my local machine I got constrain errors. Because for example table A has foreign key to table B and so on.
How could I copy some tables from production database and restore normally on my local machine which has already scheme and tables and without constrain errors?
P.s. I couldn't just dump all production database because some of tables are VERY BIG.
Dump complete production database, but without data in case of large tables:
$ pg_dump -t <VERY_BIG_TABLE_NAME> -s
If you want data also, avoid the -s option. Since you will have to repeat this 70 times, quicker solution is dividing tables into schemas:
$ pg_dump -n <SCHEMA_NAME_WITH_VERY_BIG_TABLES> -s
$ pg_dump -n <SCHEMA_NAME_WITH_SMALL_TABLES>
I'm not sure if I understood, but if you got constraint check errors you can disable the foreign key constraints, restore the tables and enable them again.
Re-create table structure in your local database but add DEFERRABLE INITIALLY DEFERRED options to problematic foreign key CONSTRAINTs
Use pg_dump to dump your selected table data from production DB to a file and write at the very beginning: BEGIN;. At the end of the file append:
UPDATE TABLE problem_no_1 SET fkey_column = NULL; for every FK column that causes problems and of course COMMIT; at the end
Execute this file on your local DB