Showing posts with label _partition_large_extents. Show all posts
Showing posts with label _partition_large_extents. Show all posts

Thursday, May 8, 2014

Import of Partitioned tables running for Long time


Hi,

Recently we did full import of our Database from 10g to 11g. There are couple issues found during import.
1) The export activity took around 3 hrs to complete but Import took around 20hrs to complete.
2) Database size has grown large than it is expected.

I tried to debug the issue and find the solution and below are the details.


 

Issue1:

Tablespaces with partitioned objects have grown from 20GB to 100GB.

This is issue is due to new hidden parameter _partition_large_extents introduced in 11gR2 specifically.

 
Solution:

Before start of import set the parameter _partition_large_extents to FALSE

 

Issue2:

Import during TUP1:
  full import of 10g database is done into 11g database as part of platform migration. This activity took around 20 hrs to complete.

Identified Time consuming tasks:

1)    We have partitoined table with around 4000+ partitions – 10 hrs – Due to large number of partitions and many partitions have data in them.

2)      Table Statistics import – 6 hrs

3)      Index statistics - 2 hr

 

Solution:

To minimize the downtime, the full database import is split and performed. Below is the complete set of activities tested with timing details captured. This total activity has brought down the total time to 4 hrs.

 1) Import Full database Import of full database excluding some objects & statistics.
Excluded partition tab;e and objects statistics
  e.g.: Impdp full=y exclude=TABLE:<TABLE NAME>
2) Imp excluded objects into a different table Import excluded Partitioned object sepeartely with merge partition option
 A separate table is created without any partitions using partitions=merge and remap_table options.
 
  e.g.: impdp TABLES=<TABLE_NAME> REMAP_TABLE= SOURCENAME:TARGETNAME 
3) Import Metadata Only Import of metadata only for excluded object into database
Imported only metadata only of excluded source table along with partitions
  e.g.: impdp CONTENT=METADATA_ONLY 
4) Insert data  Insert data from table created in step 2 to Table created in Step 3 using sqlplus
#Import data from non partitioned table to partitioned table
#5) Gather stats Gather statistics of all objects
This is estimated time and needs to be tested again.

Tuesday, April 8, 2014

export of partitioned tables from 10 to 11g resulted in huge increase in size


Observation :

performed completed export of 10g database to 11g Database using datapump utility. Some of the tablespaces are have default initial extent defined at database level. Due to this the import of objects lying under this tablespaces have grown hugely while importing.
 
e.g: Tablespace test has been created with default storage extents as 10g and any object create in this tablespace without nay storage clause has been allocated 64 KB. When this object is imported to 11g tablespace this object had been allocated a default of 8MB space even there is no data in this object.
 

Cause :

                10g

                The custom tablespaces in 10g are created with default initial extent size of database (64K by default for 10g) whereas the standard tablespaces are created with its own initial extent(Uniform) of 1MB. Each subpartition in custom tablespaces are created with a default initial extent of 64KB even there is no data in the database.

                11g

                Whereas the default initial extent size allocation for database from 11.2.0.2 is 8MB to improve performance. Hence as part of import the partitions created in custom tablespaces has picked up default value of 8MB for every empty sub partition created resulting in huge increase of database.

 

 

Solution:

                To prevent this default allocation we need set the hidden parameter _partition_large_extents to FALSE explicitly and then initiate the import.

 

Initial Extent Size of a Partition Changed to 8MB from 64KB After Upgrade to 11.2.0.2 or Later (Doc ID 1295484.1) explains on allocation of default size

 

I tested the scenario by creating one test partition with and without the init parameter and the results are as expected. I will include this step to my import process document.

1)      Create a empty table with partitions and it allocated 8MB ß Init parameter _partition_large_extents is not defined in pfile

2)      Set init parameter _partition_large_extents to FALSE and created a empty table with partitions in custom ts and it allocated only 64KB.