friends,
I have a .dump file of oracle 10G that I have to restore with IMP in oracle 11G. but I don't know how to do it so that you don't put the tables inside the tablespace of the system.
The command I'm using is
imp system/passw file=backup_dpz.dmp fromuser=pepe touser=mario
The problem is that the origin has the tables in the tablespace of system and I want that the destiny has it inside the tablespace of mario.
Thank you
Related
I have a situation in which summing the size of the tables in a tablespace (using pg_class among others) reveals that there is 550G of datafiles in a particular tablespace in a particular database.
However, there is 670G of files in that directory on the server.
FWIW, I don't know how that can be. No files have been written to that directory via any mechanism other than Postgres. My best guess is perhaps the database crashed while an autovacuum was going on, leaving orphan files laying around...does that sound plausible?)
SO, I've worked out a way, by reading the contents of a ls command into the database, strip off the numeric extensions for tables > 1G in size, and compare them with the contents of pg_class, and have, in fact, found about 120G of files not reflected in pg_class.
My question is, is it safe for me to delete these files, or could they be in active use by the database but not reflected in pg_class?
Do not manually delete files in the PostgreSQL data directory.
This is not safe and will corrupt your database.
The safe way to purge any files that don't belong to the database is to perform a pg_dumpall, stop the server, remove the data directory and the contents of all tablespace directories, breate a new cluster with inindb and restore the dump.
If you want to investigate the issue, you could try to create a new tablespace and move everything from the old to the new tablespace. I will describe that in the rest of my answer.
Move all the tables and indexes in all databases to the new tablespace:
ALTER TABLE ALL IN TABLESPACE oldtblsp SET TABLESPACE newtblsp;
ALTER INDEX ALL IN TABLESPACE oldtblsp SET TABLESPACE newtblsp;
If oldtblsp is the default tablespace of a database:
ALTER DATABASE mydb SET TABLESPACE newtblsp;
Then run a checkpoint:
CHECKPOINT;
Make sure you forgot no database:
SELECT datname
FROM pg_database d
JOIN pg_tablespace s
ON d.dattablespace = s.oid
WHERE s.spcname = 'oldtblsp';
Make sure that there are no objects in the old tablespace by running this query in all databases:
SELECT t.relname, t.relnamespace::regnamespace, t.relkind
FROM pg_class t
JOIN pg_tablespace s
ON t.reltablespace = s.oid
WHERE s.spcname = 'oldtblsp';
This should return no results.
Now the old tablespace should be empty and you can
DROP TABLESPACE oldtblsp;
If you really get an error
ERROR: tablespace "tblsp" is not empty
there might be some files left behind.
Delete them at your own risk...
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.
Given a database dump how to specify a tablespace to be used by all tables during restore? The database has multiple tablespaces used by its table. Old tablespaces should be ignored (they are not relevant on new computer) and all tablespaces my by replaced by a new one.
dump with "--no-tablespaces" parameter to have tablespaces-free dump - but you can also use the same parameter on pg_restore if you cannot change dump commands
set global parameter "default_tablespace" on target DB to what is needed for restore (for example by using alter database xxxxx set DEFAULT_TABLESPACE='xxx')
run all pg_restore tasks
if necessary reset default_tablespace to original value
Is there any way of storing database other than the fixed data directory in postgres? I have a situation where I need to store database at any location irrespective of data directory.
You can add a tablespace.
A tablespace is basically a location to store databases and/or tables. You create a tablespace using CREATE TABLESPACE:
CREATE TABLESPACE mytablespace LOCATION '/path/to/some/location';
You can then create tables directly in that tablespace:
CREATE TABLE whatever (thing integer) TABLESPACE mytablespace;
Or set the default tablespace:
SET default_tablespace = mytablespace;
You can also set the default tablespace at database creation time:
CREATE DATABASE mydatabase TABLESPACE mytablespace;
You are looking for the 'Data Directory' in linux for example its in
/usr/local/pgsql/data
if you install from source code. Each distribution is different though, try reading up on
File Locations in postgres and Creating a Database Cluster
also try using the query
show data_directory;
in windows try looking around
C:\Program Files (x86)\PostgreSQL\[VERSION]\data\global
I have created a tablespace named hdd_tablespace and I wan't all new databases to be automatically created there. Basically when I execute:
CREATE DATABASE FOO;
I want this database to be created in hdd_tablespace.
I have updated postgresql.conf with:
default_tablespace = 'hdd_tablespace'
However, new databases are still created in pg_default.
Actually it turned out I had also to update template1 database that is a template database.
I had to;
ALTER DATABASE template1 SET TABLESPACE hdd_tablespace;