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 [EMAIL PROTECTED] Quad/Tech International, Sussex, WI USA -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jesse, Rich INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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.com -- Author: Deshpande, Kirti INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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.com -- Author: Khedr, Waleed INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
