Re: Moving tables from one tablespace to another tablespace

And, therefore...?

In case of long, array inserts are NOT performed in import. A record is committed as soon as it's inserted. Imagine a multi-thousand row table that issues a commit after each row; your log buffers will be flushed so frequently that you will experience severe log buffer related waits. COPY lets you do in chunks by specifying COPYCOMMIT, not for each row. That was the point. In import specifying COMMIT=Y does a commit after each row (in case of LONGs), a frequency impossible to control.

Your excerpt from the doc simply reiterated what I mentioned. So are you merely reinforcing the post with an extract from the docs or proving it wrong?

Arup

• Original Message ----- To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com> Sent: Friday, January 17, 2003 12:44 PM

> "It lets you control the commit frequency; something impossible in
> export/import."
>
>
>

http://download-west.oracle.com/docs/cd/A87860_01/doc/server.817/a76955/ch02
> .htm#40480
>
> COMMIT
> Default: N
>
> Specifies whether Import should commit after each array insert. By
default,
> Import commits only after loading each table, and Import performs a
rollback
> when an error occurs, before continuing with the next object.
>
> If a table has nested table columns or attributes, the contents of the
> nested tables are imported as separate tables. Therefore, the contents of
> the nested tables are always committed in a transaction distinct from the
> transaction used to commit the outer table.
>
> If COMMIT=N and a table is partitioned, each partition and subpartition in
> the Export file is imported in a separate transaction.
>
> Specifying COMMIT=Y prevents rollback segments from growing inordinately
> large and improves the performance of large imports. Specifying COMMIT=Y
is
> advisable if the table has a uniqueness constraint. If the import is
> restarted, any rows that have already been imported are rejected with a
> nonfatal error.
>
> If a table does not have a uniqueness constraint, Import could produce
> duplicate rows when you reimport the data.
>
> For tables containing LONG, LOB, BFILE, REF, ROWID, UROWID, DATE, or type
> columns, array inserts are not done. If COMMIT=Y, Import commits these
> tables after each row.
>
>
> -----Original Message-----
> Sent: Friday, January 17, 2003 8:45 AM
> To: Multiple recipients of list ORACLE-L
>
>
> You could use COPY command. Create a new table exactly as the old table in
> the new tablespace from the DDL scripts. Then use the COPY command to
insert
> rows. It lets you control the commit frequency; something impossible in
> export/import.
>
> HTH.
>
> Arup
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: Post, Ethan
> INET: Ethan.Post_at_ps.net
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Arup Nanda
  INET: arupnanda_at_hotmail.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).