I'm facing a new problem about importing data on Oracle.
I've got a dump file of around 40GB, and I'm trying to import this to my Oracle Database 10g Release 10.2.0.4.0.
On our system we have 3 tablespaces (Datalob/Data and Index), one of our Customer is using only one tablespace (MIG).
if I try to import the data (from customer), I get the error ORA-01652 unable to extend segment by ... because i don't have enough space.
too bad, I can't make the tablespace bigger/ or is not allowed.
is there a way to import the tablespace for Datalob(all lob fields) to the tablespace DATALOB, all index to INDEX and normal data to DATA?
like Remap_Tablespace=MIG(LOB):DATALOB remap_tablespcae=MIG(IDX):INDEX
I'd use a sequential approach - not very elegant, but it should work:
import only the metadata (into your "table" tablespace)
move the LOB segments to the LOB tablespace
move the indices to the index tablespace
import the contents
Pre-create the table using the tablespaces you want and use TABLE_EXISTS_ACTION=APPEND.
Related
we have a huge DB with daily 20Mil records,
We have an interval partitioned table on creation time column(filled with Sysdate at before insert trigger)
As this data are important and cannot be purged and storage runs out after some time, We have used impdp and expdp to archive old data(we keep few months) and monthly export one partition and import it at archive DB
Disadvantage of this scenario is Dropping exported partition after complete import, Does not completely free the storage, it seems our tablespaces are the problem
Another disadvantage is the data is keep growing and export and import time has reached more than mere hours and it's nearly 2 days, which affects our service quality
Newly we're thinking about using Transportable Tablespaces
I'm not what scenario to use here
Is this right to do this:
daily create a tablespace with a datafile
make new tablespace transportable
alter user and set it's default tablespace to our new one
after some time when data are old, export table using:
expdp transport_tablespaces={our new tablespace}
copy data file from source DB to destination DB
import at destination DB using:
impdp transport_datafiles='/path/to/data/{data file name}.dbf'
if anything went well, drop source partition and free the space
Personally, I'm not sure if my scenario is right, did I understand Transportable Tablespace correctly?
If my scenario is correct, Can you provide a shell-script to automate this to be done
First, there's no such a thing as 'make a tablespace transportable' in Oracle.
You can do what you outline, but, there are some modifications:
As each of your new tablespaces will host a partition, you cannot export it as such, you must exchange the partition with a table, with indexes, ... and then do the export.
you may run into the limit on the number of tablespaces you can create and manage, .... or the number of data files, ...unless you pay attention to what you're doing, ...
on the archive db, you'll have to import the tablespace, then do an exchange partition again. And depending on the number of partitions you need to keep, you may again run into the limit on the number of tablespaces. What you can do is to import the tablespace, do an alter table move to put the data from this tablespace into one that has other partitions, and the drop the imported tablespace.
The Oracle new tablespace name must fit with the old tablespace name?
For example:
The dump file tablespace name is A,and i create a new tablespace B,and it could import table, but has many error?
ORA-00959:tablespace 'ECASYS'(old) not exits.
This is my import statement:
imp userid='ZHPE/zhpe#ORCL' file='E:\xxxx\xxxx2013-08-15Bak\130815.dmp' log='D:\app\Administrator\oradata\orcl\ZHPE.log' full=y ignore=y;
Is the new tablespace must must must fit the old one???
help!
If you're forced to use the legacy exp and imp tools then the tablespace cannot be changed during the import itself using command-line options. If you can, switch to using the datapump versions, expdp and impdp, and then follow #schurik's advice.
If you can't do that then you'll need a workaround, which is to create the schema objects manually first.
If you run imp with the indexfile option then it will create a file containing the DDL for the tables and indexes:
imp user/password indexfile=schema.sql file=...
The table creation DDL is commented out with REM markers, which you need to remove. You can then edit it to change the tablespace and any other storage options that are no longer appropriate. Then run that schema creation SQL to create all the tables as empty.
Then run the normal import again, but with the ignore=y flag so it doesn't complain (much) that the tables now already exist. The data will still be inserted into those existing tables.
This will be a bit slower if you create the indexes as well as the tables beforehand; normally it would create the tables, insert the data, and then build the indexes, which is more efficient. If the slowdown is significant then you can split your schema.sql into separate table and index creation files and do the same thing manually - create the tables, run the import with ignore=y and indexes=n (to stop it trying and failing to create them), and then create the indexes yourself afterwards.
Clearly this is a bit of a pain, and one of many reasons that switching to datapump is a good idea.
take a look at the REMAP_TABLESPACE import parameter e.g
REMAP_TABLESPACE=A:B
My question regards the situation were tablespace used for primary key index differs from tablespace used for the table itself. Will Oracle use this index or it becomes unusable?
Because when i tried to import the schema to Oracle that contains that table. Oracle complained with warning saying that index for this primary key is unusable. I've fixed the schema by change tablespace for primary key index, exported it again and it imported into database without warnings.
Does this means that primary key index tablespace must be always the same as the tablespace of the table itself? Or is it true for any kind of index (column index for example)?
Does this rule apply also for DB2?
Storing indexes and data in different tablespaces is perfectly acceptable. What happens when you do a:
alter index index_name rebuild;
Is the index still unusable after that? If not, check your import parameters on the table. For example, SQL*Loader can invalidate indexes with direct path loads (this is just a guess, you don't mention how you loaded the data).
If the index is still unusable, check for data anomalies, especially duplicate keys. Hope you fix it!
What Martin said is fine. However, there is no real need to separate the tablespaces. What you can do, to avoid tablespace errors on import (assuming you're using export/import and not datapump) is to create the user with a default tablespace that exists. Then import just the database and then add the indexes and constraints.
I have encountered a problem in importing the dump file to a new database.
When importing the dump file it requires a new tablespace which does not exist in the database.
To create the tablespace I need to hijack some scripts which is readonly.For this reason it is complicated to export the table structure through imp tool of Oracle so my colleage changed the dump file manually and it is able to be imported.
Is it OK to change the dump file manually in order to import the file if it is the quickest way?
if are comfortable to change the dump file manually then it is fine, keeping that you are aware of the the complete structure of the .dmp file.
i will suggest u to use data pump as it remaps the table space of the existing schema with the new one. and performance wise data pump is much faster then normal dump.
As an alternative, get a dummy database and
create the tablespace/schema.
Do the import there with ROWS=N
ALTER TABLE ... MOVE .... to put the tables into the desired tablespace
Export tables (structures) from there
import corrected structures
Import the data with IGNORE=Y so that the data can be imported over the existing structures.
if you create the user with a default tablespace that is a tablespace that exists, you can import with rows=n and ignore=y and that should bring the objects in for you into that tablespace.
I have a .dmp file that I would like to import into Oracle 9i. How do I do that?
Presuming you have a .dmp file created by oracle exp then
imp help=y
will be your friend. It will lead you to
imp file=<file>.dmp show=y
to see the contents of the dump and then something like
imp scott/tiger#example file=<file>.dmp fromuser=<source> touser=<dest>
to import from one user to another. Be prepared for a long haul though if it is a complicated schema as you will need to precreate all referenced schema users, and tablespaces to make the imp work correctly
I am Using Oracle Database Express Edition 11g Release 2.
Follow the Steps:
Open run SQl Command Line
Step 1: Login as system user
SQL> connect system/tiger
Step 2 : SQL> CREATE USER UserName IDENTIFIED BY Password;
Step 3 : SQL> grant dba to UserName ;
Step 4 : SQL> GRANT UNLIMITED TABLESPACE TO UserName;
Step 5:
SQL> CREATE BIGFILE TABLESPACE TSD_UserName
DATAFILE 'tbs_perm_03.dat'
SIZE 8G
AUTOEXTEND ON;
Open Command Prompt in Windows or Terminal in Ubuntu. Then Type:
Note : if you Use Ubuntu then replace " \" to " /" in path.
Step 6: C:\> imp UserName/password#localhost file=D:\abc\xyz.dmp log=D:\abc\abc_1.log full=y;
Done....
I hope you Find Right solution here.
Thanks.
i got solution what you are getting as per imp help=y it is mentioned that imp is only valid for TRANSPORT_TABLESPACE as below:
Keyword Description (Default) Keyword Description (Default)
--------------------------------------------------------------------------
USERID username/password FULL import entire file (N)
BUFFER size of data buffer FROMUSER list of owner usernames
FILE input files (EXPDAT.DMP) TOUSER list of usernames
SHOW just list file contents (N) TABLES list of table names
IGNORE ignore create errors (N) RECORDLENGTH length of IO record
GRANTS import grants (Y) INCTYPE incremental import type
INDEXES import indexes (Y) COMMIT commit array insert (N)
ROWS import data rows (Y) PARFILE parameter filename
LOG log file of screen output CONSTRAINTS import constraints (Y)
DESTROY overwrite tablespace data file (N)
INDEXFILE write table/index info to specified file
SKIP_UNUSABLE_INDEXES skip maintenance of unusable indexes (N)
FEEDBACK display progress every x rows(0)
TOID_NOVALIDATE skip validation of specified type ids
FILESIZE maximum size of each dump file
STATISTICS import precomputed statistics (always)
RESUMABLE suspend when a space related error is encountered(N)
RESUMABLE_NAME text string used to identify resumable statement
RESUMABLE_TIMEOUT wait time for RESUMABLE
COMPILE compile procedures, packages, and functions (Y)
STREAMS_CONFIGURATION import streams general metadata (Y)
STREAMS_INSTANTIATION import streams instantiation metadata (N)
DATA_ONLY import only data (N)
The following keywords only apply to transportable tablespaces
TRANSPORT_TABLESPACE import transportable tablespace metadata (N)
TABLESPACES tablespaces to be transported into database
DATAFILES datafiles to be transported into database
TTS_OWNERS users that own data in the transportable tablespace set
So, Please create table space for your user:
CREATE TABLESPACE <tablespace name> DATAFILE <path to save, example: 'C:\ORACLEXE\APP\ORACLE\ORADATA\XE\ABC.dbf'> SIZE 100M AUTOEXTEND ON NEXT 100M MAXSIZE 10G EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M;
imp system/system-password#SID file=directory-you-selected\FILE.dmp log=log-dir\oracle_load.log fromuser=infodba touser=infodba commit=Y
.dmp files are dumps of oracle databases created with the "exp" command. You can import them using the "imp" command.
If you have an oracle client intalled on your machine, you can executed the command
imp help=y
to find out how it works. What will definitely help is knowing from wich schema the data was exported and what the oracle version was.