Sure. The original post mentioned 8.1.7.2!
-----Original Message-----
Sent: Tuesday, November 26, 2002 3:29 AM
To: Multiple recipients of list ORACLE-L
pdml on non-partitioned tables is there in 9i
hth
connor
- "Deshpande, Kirti" <kirti.deshpande_at_verizon.com>
wrote: > How true !! I just ignored the 'writing' part
of the
> parallelized 'reading'. Sorry.
> Thanks for catching it, Waleed.
> Our own update process, that I am baby sitting, was
> on my mind that involves a few partitioned tables...
>
>
> Regards,
>
> - Kirti
>
> -----Original Message-----
> Sent: Monday, November 25, 2002 9:09 PM
> To: Multiple recipients of list ORACLE-L
>
>
> PDML can be used only on partitioned segments. When
> PQO is used during an
> update on a non-partitioned segment, the parallel
> processes (slaves) work
> together to scan (read) the segment and find the
> rows that need to be
> updated. these rows get communicated back to the
> master process using the
> rowid. The master process starts to update rows
> serially using the rowid for
> update and this process could be slow and resources
> intensive specially when
> you are updating most of the rows in the table (you
> will see tons of db file
> sequential read).
>
> Regards,
>
> Waleed
>
> -----Original Message-----
> Sent: Monday, November 25, 2002 7:19 PM
> To: Multiple recipients of list ORACLE-L
>
>
> I would consider PDML to get the job done faster,
> provided there are enough
> resources.
> Using a cursor seems like a good idea, but avoid
> fetching across commits. We
> are going through a similar exercise, adding
> 10000000 to a cust_id field to
> denote the source of the data, and Developers
> complained about ORA-1555.
> Asked them not to commit as existing rollback
> segments and space were
> adequate ;)
>
> Good Luck,
>
> - Kirti
>
> -----Original Message-----
> Sent: Monday, November 25, 2002 3:04 PM
> To: Multiple recipients of list ORACLE-L
>
>
> I've got a real hot project (8.1.7.2 on HP/UX 11.0)
> that needs to have NULLs
> converted to spaces on three different columns.
> Each is a CHAR, so I
> shouldn't need to worry about chaining, since that
> column's full size has
> already been allocated in the block, right? But the
> first column has 1.2M
> NULLs out of 1.45M rows.
>
> My first test was to just UPDATE mytable SET mycol =
> ' ' WHERE mycol IS
> NULL, after removing the index on that column.
> Seeing as there were many
> more rows updated than I had anticipated, I was
> going to test the UPDATE
> using a cursor, and committing at every 10K rows
> (~120 total commits) to
> reduce rollback and locking issues.
>
> Thoughts? Since this table is used for
> time-and-attendance and directly
> affects payroll, downtime isn't possible.
>
> TIA!
>
> Rich
>
>
> Rich Jesse System/Database
> Administrator
> Rich.Jesse_at_qtiworld.com Quad/Tech
> International, Sussex, WI USA
> --
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Deshpande, Kirti
INET: kirti.deshpande_at_verizon.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).
Received on Tue Nov 26 2002 - 07:59:07 CST
