oracle backup and import commands

1. Backup
emp:
1. cd to oracle installation bin directory;

2. Full mode:
EXP [USER]/[PASSWORD]@[INSTANCE_NAME] BUFFER=64000 FILE=[XXX].dmp FULL=Y

3. User mode:
EXP [USER]/[PASSWORD]@[INSTANCE_NAME] BUFFER=64000 FILE=[XXX].dmp OWNER=[USER]

4. Table mode:
EXP [USER]/[PASSWORD]@[INSTANCE_NAME] BUFFER=64000 FILE=[XXX ].dmp OWNER=[USER] TABLES=[USER]

Second, import
imp:
1. cd to oracle installation bin directory;

2. Complete mode:
imp [USER]/[PASSWORD]@[INSTANCE_NAME] BUFFER=64000 FILE=[ XXX].dmp FULL=Y;

3. User mode:
imp [USER]/[PASSWORD]@[INSTANCE_NAME] BUFFER=64000 FROMUSER=[SOURCE_USER_NAME] TOUSER=[TARGET_USER_NAME] FILE=[XXX].dmp

4. Table mode:
imp [USER]/[PASSWORD]@[INSTANCE_NAME] BUFFER=64000 OWNER=[USER] TABLES=[USER] FILE=[XXX].dmp

------------------ -------------------------------------------------- -------------
Detailed explanation of parameters:
Import/Export are the two oldest command-line tools that ORACLE has survived. In fact, I never think Exp/Imp is a good backup method. The correct way is Exp/Imp can only be a good dump tool, especially in the dumping of small databases, table space migration, table extraction, and detection of logical and physical conflicts. Of course, we can also use it as a logical auxiliary backup after the physical backup of the small database, which is also a good suggestion. For larger and larger databases, especially with the emergence of TB-level databases and more and more data warehouses, EXP/IMP is becoming more and more powerless. At this time, database backups are turned to RMAN and third-party tools. The following explains the use of EXP/IMP.
　　How to display the help of exp in different character sets: set nls_lang=simplified chinese_china.zhs16gbk, by setting environment variables, the help of exp can be displayed in Chinese, if set nls_lang=American_america. character set, then the help is in English



EXP All parameters (default values ​​of parameters in parentheses):
USERID Username/password For example: USERID=duanl/duanl     
FULL Export the entire database (N)
BUFFER The size of the data buffer        
OWNER owner user name list, which user object you want to export, use owner=username
FILE output file (EXPDAT.DMP)   
TABLES table name list, specify the exported table name, such as: TABLES=table1, table2
COMPRESS Import an extent (Y)  
RECORDLENGTH IO record length
GRANTS export permission (Y)           
INCTYPE incremental export type
INDEXES export index (Y)          
RECORD track incremental export (Y)
ROWS export data row (Y)       
PARFILE parameter file name, if you exp parameter Many, can be saved as parameter files.
CONSTRAINTS export constraints (Y)   
CONSISTENT crosstab consistency
LOG screen output log file   
STATISTICS analysis objects (ESTIMATE)
DIRECT direct path (N)             
TRIGGERS export triggers (Y)
FEEDBACK display every x row ( 0) progress
FILESIZE Maximum size of each dump file
QUERY Clause for selected export table subsets The
following keywords are used only for transportable tablespaces
TRANSPORT_TABLESPACE Exports transportable tablespace metadata (N)
TABLESPACES List of tablespaces to be transported


IMP All parameters (default values ​​for parameters in parentheses):
USERID Username/Password          
FULL Import Entire File (N)
BUFFER Data Buffer Size        
FROMUSER Everyone Username List
FILE Input File (EXPDAT.DMP)   
TOUSER Username List
SHOW List Only out file contents (N)
TABLES table name list
IGNORE ignore creation errors (N)   
RECORDLENGTH IO record length
GRANTS import permission (Y)         
INCTYPE incremental import type
INDEXES import index (Y)         
COMMIT commit array insert (N)
ROWS import data rows (Y)      
PARFILE parameter file name
LOG screen output log file  
CONSTRAINTS Import limit (Y)
DESTROY Overwrite tablespace data file (N)
INDEXFILE Write table/index information to the specified file
SKIP_UNUSABLE_INDEXES Skip maintenance of unavailable indexes (N)
ANALYZE Execute the ANALYZE statement (Y)
FEEDBACK Show progress every x rows (0)
TOID_NOVALIDATE Skip checksum for specified type id
FILESIZE Maximum size of each dump file
RECALCULATE_STATISTICS Recalculate statistics (N)
The following keywords are only used for transportable tables SPACE
TRANSPORT_TABLESPACE Import transportable tablespace metadata (N)
TABLESPACES Tablespace
DATAFILES to be transported to the database
Datafiles to be transported to the database TTS_OWNERS Users who own the data in the transportable tablespace set

Notes on incremental parameters: exp/imp Incremental isn't really incremental, so it's best not to use it.

How to use:
Exp parameter_name=value or Exp parameter_name=(value1, value2...)
Just enter the parameter help=y to see all the help.

EXP common options
1.FULL, this is used to export the entire database. When ROWS=N is used together, the structure of the entire database can be exported. For example:
exp userid=test/test file=./db_str.dmp log=./db_str.log full=y rows=n compress=y direct=y
2. OWNER and TABLE, these two options are used to define the object of EXP . OWNER defines the object that exports the specified user; TABLE specifies the table name of EXP, for example:
exp userid=test/test file=./db_str.dmp log=./db_str.log owner=duanl
exp userid=test/test file=./ db_str.dmp log=./db_str.log table=nc_data,fi_arap
3.BUFFER and FEEDBACK, when exporting more data, I will consider setting these two parameters. For example:
exp userid=test/test file=yw97_2003.dmp log=yw97_2003_3.log feedback=10000 buffer=100000000 tables=WO4,OK_YT
4.FILE and LOG, these two parameters specify the backup DMP name and LOG name respectively, including File names and directories, see above for examples.
5. The COMPRESS parameter does not compress the content of the exported data. Used to control how the storage statement for exported objects is generated. The default value is Y. Using the default value, the init extent of the object's storage statement is equal to the sum of the extents of the currently exported object. COMPRESS=N is recommended.
6. FILESIZE This option is available in 8i. If the exported dmp file is too large, it is better to use the FILESIZE parameter to limit the file size not to exceed 2G. For example:
exp userid=duanl/duanl file=f1,f2,f3,f4,f5 filesize=2G owner=scott
This will create a series of files such as f1.dmp, f2.dmp, each with a size of 2G, if exported The total amount is less than 10G
EXP does not need to create f5.bmp.

IMP common options
1, FROMUSER and TOUSER, use them to import data from one SCHEMA to another SCHEMA. For example: Suppose we export the object of test when we do exp, and now we want to import the object into the user:
imp userid=test1/test1 file=expdat.dmp fromuser=test1 touser=test1
2, IGNORE, GRANTS and INDEXES, where the IGNORE parameter The existence of the table will be ignored and the import will continue. This is very useful when the storage parameters of the table need to be adjusted. We can first build the table with reasonable storage parameters according to the actual situation, and then directly import the data. GRANTS and INDEXES indicate whether to import authorization and index. If you want to rebuild the index with new storage parameters, or to speed up the entry, we can consider setting INDEXES to N, while GRANTS is generally Y. For example: imp userid=test1/test1 file=expdat.dmp fromuser=test1 touser=test1 indexes=N

tablespace transfer
     Table space transfer is a new method added by 8i to quickly move data between databases. It is to attach the format data files on one database to another database instead of exporting the data to Dmp files. is very useful because transferring tablespaces moves data as fast as copying files.
There are some rules about transporting tablespaces, namely:
• The source database and the target database must run on the same hardware platform.
· The source database and the target database must use the same character set.
The source database and the target database must have data blocks of the same size. The
target database cannot have a tablespace with the same name as the migration tablespace
. SYS objects cannot be migrated
. A self-contained set of objects must be transferred
. There are some objects, such as materialized views, Function-based indexes, etc. cannot be transported. The following method
can be used to check whether a tablespace or a set of tablespaces conforms to the transport standard:
exec sys.dbms_tts.transport_set_check('tablespace_name',true);
select * from sys.transport_set_violation;
if No row selection means that the tablespace contains only table data and is self-contained. For some non-self-contained tablespaces, such as data tablespaces and index tablespaces, they can be transferred together.
The following is a brief usage step, if you want to refer to the detailed usage method, you can also refer to the ORACLE online help.
1. Set the tablespace to read-only (assuming the tablespace names are APP_Data and APP_Index)
alter tablespace app_data read only;
alter tablespace app_index read only;
2. Issue the EXP command
SQL>host exp userid=”””sys/password as sysdba”””
transport_tablespace=y tablespace=(app_data, app_index) It
should be noted that in
order to execute EXP in SQL , USERID must use three quotation marks, and in UNIX, you must also pay attention to avoid the use of "/"
. In 816 and later, you must use sysdba to operate
. This command must be placed on one line in SQL (here because the display problem is placed in Two lines)
3. Copy data files to another location, that is, the target database
   can be cp (unix) or copy (windows) or transfer files through ftp (must be in bin mode)
4. Set the local table space to read and write
5. Attach the data file to the target database
imp file=expdat.dmp userid=”””sys/password as sysdba””” transport_tablespace=y “datafile=(c:\temp\app_data,c:\temp\app_index)”
6. Set the target database tablespace to read and write
alter tablespace app_data read write;
alter tablespace app_index read write;

the method of optimizing EXP/IMP:
     When the amount of data that needs exp/imp is relatively large, this process takes a long time. We can use some methods to optimize the operation of exp/imp.
exp: Using the direct path direct=y
oracle will avoid the sql statement processing engine, read data directly from the database file, and then write the export file.
It can be observed in the export log: exp-00067: table xxx will be exported in If the conventional path
     does not use the direct path, the value of the buffer parameter must be large enough. There are some parameters that are incompatible with direct=y, so the direct path cannot be used to export the movable tablespace, or the query parameter can be used to      export
     the database subset.
When the database runs under different os, the value of the recordlength parameter must be consistent.

imp: optimize through the following ways
1. Avoid disk sorting
Set sort_area_size to a larger value, such as 100M
2. Avoid log switching waiting
Increase the weight Make the number of log groups and increase the size of the log file.
3. Optimize the log buffer,
such as expanding the log_buffer capacity by 10 times (maximum should not exceed 5M)
4. Use the array to insert and submit
commit = y
Note: The array method cannot handle LOB and For tables of LONG type, for such a table, if commit = y is used, a commit will be performed every time a row is inserted.
5. Use NOLOGGING to reduce the size of the redo log
When importing, specify the parameter indexes=n, only

import
     . question. In the EXP/IMP process, we need to pay attention to the parameters of four character sets: the client character set of the export end, the database character set of the export end, the client character set of the import end, and the database character set of the import end.
We first need to look at these four charset parameters.
View information about the character set of the database:
SQL> select * from nls_database_parameters;
PARAMETER VALUE
------------------------------ --- -------------------------------------------------- ---------------------------
NLS_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_CURRENCY $
NLS_ISO_CURRENCY AMERICA
NLS_NUMERIC_CHARACTERS .,
NLS_CHARACTERSET ZHS16GBK
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT DD-MON-RR
NLS_DATE_LANGUAGE AMERICAN
NLS_SORT BINARY
NLS_TIME_FORMAT HH.MI.SSXFF AM
NLS_TIMESTAMP_FORMAT DD-MON-RR HH.MI.SSXFF AM
NLS_TIMERR_TZ_FORMAT HH.MI.SSXFF AM TZH:TZM
NLS_TIMESTAMP_TZ_FORMAT DD-MON-RR .SSXFF AM TZH:TZM
NLS_DUAL_CURRENCY $
NLS_COMP BINARY
NLS_NCHAR_CHARACTERSET ZHS16GBK
NLS_RDBMS_VERSION 8.1.7.4.1
NLS_CHARACTERSET: ZHS16GBK is the character set of the current database.

Let's check the client's character set information again:
the parameter NLS_LANG=_< territory > of the client's character set.
language: Specifies the language used for oracle messages, the display of the day and month in the date.
Territory: Specifies the format of currencies and numbers, the locale, and the custom for calculating days and days.
Characterset: Controls the character set used by the client application. Usually set or equal to the client's code page. Or set to UTF8 for unicode applications.
In Windows, the query and modification of NLS_LANG can be performed in the registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Oracle\HOMExx\
xx refers to the system number when there are multiple Oracle_HOMEs.

In unix:
$ env|grep NLS_LANG
NLS_LANG=simplified chinese_china.ZHS16GBK

Modification available:
$ export NLS_LANG=AMERICAN_AMERICA.UTF8

Usually it is best to set the client character set to be the same as the database side when exporting. When importing data, there are mainly the following two situations:
(1) The source database and the target database have the same character set settings.
At this time, it is only necessary to set the client NLS_LANG of the export and import side to be equal to the database character set.
(2) The character set of the source database and the target database are different.
     First, set the NLS_LANG of the export client to be consistent with the database character set of the export, export the data, and then set the NLS_LANG of the import client to be consistent with the export, and import the data, so that the conversion occurs only on the database side, and only once.
     In this case, only when the character set of the import-side database is a strict superset of the export-side database character set, the data can be imported successfully; otherwise, there may be data inconsistencies or garbled characters.

Problems with different versions of EXP/IMP
     Generally speaking, it is not a big problem to import from a lower version to a higher version. The trouble is to import data from a higher version to a lower version. Before Oracle9i, EXP/IMP between different versions of Oracle can be Solve the problem by the following methods:
1. Run the lower version of catexp.sql on the higher version database;
2. Use the lower version EXP to export the higher version data;
3. Use the lower version IMP to import the database to the lower version database 4. Re-run the catexp.sql script of
the higher version on the database of the higher version.
But in 9i, the above method does not solve the problem. If you directly use the lower version of EXP/IMP, the following error will occur:
EXP-00008: orACLE error %lu encountered orA
-00904: invalid column name
This is already a published BUG, ​​and it needs to wait until Oracle10.0 to solve it. The BUG number is 2261722. You can go to METALINK to view detailed information about this bug.
BUG belongs to BUG, ​​our work still needs to be done, and we will solve it by ourselves before the support of Oracle. Execute the following SQL in Oracle9i to rebuild the exu81rls view.
Create or REPLACE view exu81rls
(objown,objnam,policy,polown,polsch,polfun,stmts,chkopt,enabled,spolicy)
AS select u.name, o.name, r.pname, r.pfschma, r.ppname, r.pfname,
decode(bitand(r.stmt_type,1), 0,'', 'Select,')
|| decode(bitand(r.stmt_type,2), 0,'', 'Insert,')
|| decode(bitand(r.stmt_type,4), 0,'', 'Update,')
|| decode(bitand(r.stmt_type,8), 0,'', 'Delete,'),
r.check_opt, r.enable_flag,
DECODE(BITAND(r.stmt_type, 16), 0, 0, 1)
from user$ u, obj$ o, rls$ r
where u.user# = o.owner#
and r.obj# = o.obj#
and (uid = 0 or
uid = o.owner# or
exists ( select * from session_roles where role='Select_CATALOG_ROLE')
)
/
grant select on sys.exu81rls to public; You can use EXP/IMP across versions, but you must use the correct versions of EXP and IMP:
/


1. Always use the version of IMP to match the version of the database. For example, to import into 817, use 817's IMP tool.
2. Always use the version of EXP to match the lowest version in the two databases, such as: import from 9201 to 817, use the 817 version of the EXP tool.