Re: 10g data pump question

From: hpuxrac <johnbhurley_at_sbcglobal.net>
Date: Sat, 22 Nov 2008 05:58:17 -0800 (PST)
Message-ID: <76f99714-6e4d-4f3f-8bee-aa88f9c54527@s20g2000yqh.googlegroups.com>


On Nov 21, 5:29 pm, joel garry <joel-ga..._at_home.com> wrote:

snip

> > impdp / DIRECTORY=$DIRECTORY \
> >   LOGFILE=$LOG_FILE_NAME \
> >   NETWORK_LINK=IMPDP_${SOURCE_DB} \
> >   SCHEMAS=${SOURCE_SCHEMA} \
> >   REMAP_SCHEMA=${SOURCE_SCHEMA}:${TARGET_SCHEMA} \
> >   PARALLEL=4
>
> > Just seems like 3 of the 4 workers are pretty lazy and I wonder if
> > there's any real benefit to setting parallel gt 1.
>
> How many files do you have in the dump?
>
> See metalink Note:365459.1
>
> " The first worker begins to load all the metadata – the tablespaces,
> schemas, etc., until all the tables are created.
> Once the tables are created, the first worker starts loading data
> instead of metadata and the rest of the workers start loading data
> too.
> Once the table data is loaded, the first worker returns to loading
> metadata again. The rest of the workers are idle until the first
> worker loads all the metadata up to package bodies.
> Multiple workers load package bodies in parallel.
> One worker loads metadata up to and including secondary tables.
> Multiple workers load secondary table data.
> One worker loads the remaining metadata.
>
> Note: One worker creates all the indexes but uses PX processes up to
> the PARALLEL value so indexes get created faster.
>
> Thus, an import job can be started with a PARALLEL = 10, and the user
> will only see one worker being utilized at certain points during job
> execution. No other workers or Parallel Execution Processes will be
> working until all the tables are created. When the tables are created,
> a burst of workers and possibly PX processes will execute in parallel
> until the data is loaded, then the worker processes will become idle.
> ...
> For Data Pump Import, the PARALLEL parameter value should not be much
> larger than the number of files in the dump file set. "

A much better and more in depth explanation of what I was trying to get across ... thanks Joel! Received on Sat Nov 22 2008 - 07:58:17 CST

Original text of this message