accept sch prompt "Schema : "
accept pwd prompt "Password (not displayed) : " hide
Minimalistic Oracle contains a collection of practical examples from my encounters with Oracle technologies. When relevant, I also write about other technologies, like Linux or PostgreSQL. Many of the posts starts with "how to" since they derive directly from my own personal experience. My goal is to provide simple examples, so that they can be easily adapted to other situations.
Tuesday, November 19, 2013
Errors ORA-31693 and ORA-29913 thrown during import
Yesterday when importing some test data from production to test, I encountered the following error during import:
. . imported "< schema name >"."< table name > ":"< partition name >" 77.08 KB 0 rows
ORA-31693: Table data object "< schema name >"."< table name > ":"< partition name >" failed to load/unload and is being skipped due to error:
ORA-29913: error in executing ODCIEXTTABLEOPEN callout
. . imported "< schema name >"."< table name > ":"< partition name >" 25.69 KB 0 rows
The preceeding export executed successfully, without any errors or warnings. I used multiple threads, and the result was 7 dump files.
I first tried reimporting the table, which in many similar cases actually work. This time, it didn't; the same error was thrown.
The solution was to remove the parallel directive from the import parameter file and reimport only the missing table:
USERID='/ AS SYSDBA'
DIRECTORY=DPUMP
DUMPFILE=EXDP_SCHEMA_EXPORT_201311181340_%U.DMP
LOGFILE=IMPDP_missing_tables.log
PARALLEL=1
TRANSFORM=OID:N
TABLE_EXISTS_ACTION=REPLACE
REMAP_SCHEMA=< schema_name >:
TABLES=< schema_name >.< table_name >
. . imported "< schema name >"."< table name > ":"< partition name >" 77.08 KB 0 rows
. . imported "< schema name >"."< table name > ":"< partition name >" 1.205 GB 6758593 rows
. . imported "< schema name >"."< table name > ":"< partition name >" 25.69 KB 0 rows
. . imported "< schema name >"."< table name > ":"< partition name >" 77.08 KB 0 rows
ORA-31693: Table data object "< schema name >"."< table name > ":"< partition name >" failed to load/unload and is being skipped due to error:
ORA-29913: error in executing ODCIEXTTABLEOPEN callout
. . imported "< schema name >"."< table name > ":"< partition name >" 25.69 KB 0 rows
The preceeding export executed successfully, without any errors or warnings. I used multiple threads, and the result was 7 dump files.
I first tried reimporting the table, which in many similar cases actually work. This time, it didn't; the same error was thrown.
The solution was to remove the parallel directive from the import parameter file and reimport only the missing table:
USERID='/ AS SYSDBA'
DIRECTORY=DPUMP
DUMPFILE=EXDP_SCHEMA_EXPORT_201311181340_%U.DMP
LOGFILE=IMPDP_missing_tables.log
PARALLEL=1
TRANSFORM=OID:N
TABLE_EXISTS_ACTION=REPLACE
REMAP_SCHEMA=< schema_name >:
TABLES=< schema_name >.< table_name >
. . imported "< schema name >"."< table name > ":"< partition name >" 77.08 KB 0 rows
. . imported "< schema name >"."< table name > ":"< partition name >" 1.205 GB 6758593 rows
. . imported "< schema name >"."< table name > ":"< partition name >" 25.69 KB 0 rows
Monday, November 18, 2013
How to use the APPEND hint to optimize INSERT statements
When using the APPEND hint, you are telling the optimizer to use direct-path INSERT.
Serialized inserts:
Simply specify the APPEND hint in each INSERT statement, either immediately after the INSERT keyword or immediately after the SELECT keyword in the subquery of the INSERT statement.
INSERT /*+ APPEND */ INTO sales SELECT product_id, customer_id, TRUNC(sales_date), 3, promotion_id, quantity, amount FROM sales_activity_direct;Parallelized inserts:
First, enable parallel DML in your session:
ALTER SESSION ENABLE PARALLEL DML;Then, specify the APPEND hint with the PARALLEL hint:
INSERT /*+ APPEND PARALLEL */ INTO sales SELECT product_id, customer_id, TRUNC(sales_date), 3, promotion_id, quantity, amount FROM sales_activity_direct;You can use NOLOGGING with APPEND to make the process even faster. NOLOGGING allows the direct-path INSERT operation to generate a negligible amount of REDO:
INSERT /*+ APPEND PARALLEL NOLOGGING */ INTO sales SELECT product_id, customer_id, TRUNC(sales_date), 3, promotion_id, quantity, amount FROM sales_activity_direct;
Note:
* If the database or tablespace is in FORCE LOGGING mode, then direct path INSERT always logs, regardless of the logging setting.
* Direct-path INSERT is the default insert method when running in parallel mode, but unless you have specified the DEGREE attribute for your table, you still need to use the PARALLEL hint for each insert operation.
* Oracle Database performs index maintenance at the end of direct-path INSERT operations on tables that have indexes.
What types of indexes can be created on a partitioned table?
My customer wanted to introduce partitioning on certain tables. I was asked me to give an overview of the different indexing options available after a table has been partitioned.
In short, there are four types of indexes to be considered for partitioned tables:
1. Local Partitioned Indexes
2. Global Partitioned Indexes
3. Global Non-partitioned Indexes
4. Bitmap Indexes
1. Local Partitioned Indexes
Local partitioned indexes always inherit the partitioning key from the table and are fully aligned with the table partitions. Oracle calls this concept "equipartitioning": "each partition of a local index is associated with exactly one partition of the table"
Local indexes can only be unique if the partitioning key is a part of the index key.
New partitions are added to local indexes only when you add a partition to the underlying table. Likewise, they are dropped only when you drop a partition from the underlying table. In other words, you cannot explicitly add a partition to a local index.
Two types of local indexes
There are two types of local indexes: Prefixed and non-prefixed.
Prefixed means that the table's partition key column is referenced first in the index, while a non-prefixed key does not.
Oracle states that non-prefixed local indexes are useful for historical databases, although I haven't had any expirence yet that would confirm this.
For an example of a unique local prefixed index along with some useful queries, click here
For an example of a local non-prefixed index along With some useful queries, click here
The obvious advantage of using local indexes is managebility and flexibilty. Any operation on a single partition will only affect the relevant index partition, and not the intire index as such.
2. Global Partitioned Indexes
Partitioned indexes whose patitions are not aligned with the table's partitions are called global partitioned indexes. In other Words, there is no relation between a table's partitions and a global index partition.
The keys in a particular index partition may refer to rows stored in multiple underlying table partitions or subpartitions.
Global partitioned indexes give the flexibility to choose a partitioning key that is most optimal for performance. Oracle also claims that under some circumstances, having multiple segments for an index can be beneficial for performance.
Two types of global partitioned indexes
There are two types of Global Partitioned Indexes:
* Global Hash Partitioned indexes: improves performance by spreading out contention when the index is monotonically growing on the right side of the index. Using a hashing algorithm, Oracle creates the specified number of hash partitions and spread the index Blocks uniformly accross these.
* Global Range Partitioned indexes: adds flexibility: the degree of partitioning and the partitioning key are independent from the table's partitioning method.
Both of these types can be defined on any type of partitioned table (list, range, hash etc.).
3. Global Non-partitioned Indexes
These are simply normal indexes. The fact that the underlying table is partitioned does not matter. The index spans all partitions.
Global indexes can be unique.
4. Bitmap Indexes
You can create bitmap indexes on partitioned tables, with the restriction that the bitmap indexes must be local to the partitioned table. They cannot be global indexes.
In short, there are four types of indexes to be considered for partitioned tables:
1. Local Partitioned Indexes
2. Global Partitioned Indexes
3. Global Non-partitioned Indexes
4. Bitmap Indexes
1. Local Partitioned Indexes
Local partitioned indexes always inherit the partitioning key from the table and are fully aligned with the table partitions. Oracle calls this concept "equipartitioning": "each partition of a local index is associated with exactly one partition of the table"
Local indexes can only be unique if the partitioning key is a part of the index key.
New partitions are added to local indexes only when you add a partition to the underlying table. Likewise, they are dropped only when you drop a partition from the underlying table. In other words, you cannot explicitly add a partition to a local index.
Two types of local indexes
There are two types of local indexes: Prefixed and non-prefixed.
Prefixed means that the table's partition key column is referenced first in the index, while a non-prefixed key does not.
Oracle states that non-prefixed local indexes are useful for historical databases, although I haven't had any expirence yet that would confirm this.
For an example of a unique local prefixed index along with some useful queries, click here
For an example of a local non-prefixed index along With some useful queries, click here
The obvious advantage of using local indexes is managebility and flexibilty. Any operation on a single partition will only affect the relevant index partition, and not the intire index as such.
2. Global Partitioned Indexes
Partitioned indexes whose patitions are not aligned with the table's partitions are called global partitioned indexes. In other Words, there is no relation between a table's partitions and a global index partition.
The keys in a particular index partition may refer to rows stored in multiple underlying table partitions or subpartitions.
Global partitioned indexes give the flexibility to choose a partitioning key that is most optimal for performance. Oracle also claims that under some circumstances, having multiple segments for an index can be beneficial for performance.
Two types of global partitioned indexes
There are two types of Global Partitioned Indexes:
* Global Hash Partitioned indexes: improves performance by spreading out contention when the index is monotonically growing on the right side of the index. Using a hashing algorithm, Oracle creates the specified number of hash partitions and spread the index Blocks uniformly accross these.
For an example, see this post
* Global Range Partitioned indexes: adds flexibility: the degree of partitioning and the partitioning key are independent from the table's partitioning method.
For an example, see this post
Both of these types can be defined on any type of partitioned table (list, range, hash etc.).
3. Global Non-partitioned Indexes
These are simply normal indexes. The fact that the underlying table is partitioned does not matter. The index spans all partitions.
Global indexes can be unique.
4. Bitmap Indexes
You can create bitmap indexes on partitioned tables, with the restriction that the bitmap indexes must be local to the partitioned table. They cannot be global indexes.
Friday, November 15, 2013
What is the difference between direct-path INSERT and conventional INSERT?
• During conventional INSERT operations, the database reuses free space in the table, interleaving newly inserted data with existing data. During such operations, the database also maintains referential integrity constraints.
• During direct-path INSERT operations, the database appends the inserted data after existing data in the table. Data is written directly into datafiles, bypassing the buffer cache. Free space in the existing data is not reused, and referential integrity constraints are ignored. These procedures combined can enhance performance.
Source: Oracle Documentation
• During direct-path INSERT operations, the database appends the inserted data after existing data in the table. Data is written directly into datafiles, bypassing the buffer cache. Free space in the existing data is not reused, and referential integrity constraints are ignored. These procedures combined can enhance performance.
Source: Oracle Documentation
Possible reason for RMAN-06059: "expected archived log not found, lost of archived log compromises recoverability"
After having changed the archive log destination, I received the following when performing ARCHIVELOG backups:
Starting backup at 25-NOV-2008
current log archived
released channel: t1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup command at 11/25/2008 10:57:56
RMAN-06059: expected archived log not found, lost of archived log compromises recoverability
ORA-19625: error identifying file /app/oracle/admin/PRODDP/archive670098694_1_1.arc
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
I needed to run a crosscheck after having pointed out the new archive log destination to the recovery catalog:
Starting backup at 25-NOV-2008
current log archived
released channel: t1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup command at 11/25/2008 10:57:56
RMAN-06059: expected archived log not found, lost of archived log compromises recoverability
ORA-19625: error identifying file /app/oracle/admin/PRODDP/archive670098694_1_1.arc
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
I needed to run a crosscheck after having pointed out the new archive log destination to the recovery catalog:
allocate channel for maintenance type disk; run { set archivelog destination to '/app/oracle/admin/PRODDB/archive'; change archivelog all crosscheck; }After this has been run, I could backup up the ARCHIVELOGS successfully using tape (or disk) backups:
run { allocate channel t1 type sbt PARMS="BLKSIZE=1048576" maxpiecesize 32G maxopenfiles 64; send 'NB_ORA_POLICY=O_SYR_loc1,NB_ORA_CLIENT=prodserver1-bkp.mydomain.net,NB_ORA_SCHED=O_SYR_loc1_user'; backup archivelog all; release channel t1; }
How to use dbms_random to generate an always-changing string
For a demonstration of Flashback Data Archive, I had to create a daily update to a column in a test table.
The following function did the trick:
select dbms_random.string( 'L',dbms_random.value(10,30) ) from dual;
by returning strings similar to jsytbbtmxrusgmlz or gilqpizjaislueuocqlxydpngtup
"L" is an optional paramter to the STRING function, stating what type of string that should be produced. "L" means "always lowercase".
The numbers 10 and 30 in the value () function returns a string between 10 and 30 characters in length.
Other types of strings you can generate are:
• 'u', 'U' - uppercase alpha characters
• 'l', 'L' - lowercase alpha characters
• 'a', 'A' - mixed case alpha characters
• 'x', 'X' - uppercase alpha-numeric characters
• 'p', 'P' - any printable characters
Oracle-Base contains an excellent article about dbms_random.
The following function did the trick:
select dbms_random.string( 'L',dbms_random.value(10,30) ) from dual;
by returning strings similar to jsytbbtmxrusgmlz or gilqpizjaislueuocqlxydpngtup
"L" is an optional paramter to the STRING function, stating what type of string that should be produced. "L" means "always lowercase".
The numbers 10 and 30 in the value () function returns a string between 10 and 30 characters in length.
Other types of strings you can generate are:
• 'u', 'U' - uppercase alpha characters
• 'l', 'L' - lowercase alpha characters
• 'a', 'A' - mixed case alpha characters
• 'x', 'X' - uppercase alpha-numeric characters
• 'p', 'P' - any printable characters
Oracle-Base contains an excellent article about dbms_random.
Subscribe to:
Posts (Atom)