This is a discussion on platinum download within the DB2 forums, part of the Database Server Software category; --> I tried fast unload on a table that has 65 million rows. Basically I needed all the rows to ...
| |||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| I tried fast unload on a table that has 65 million rows. Basically I needed all the rows to be coped to a tape (TAPE3590) with where clause on an UPDATE TIMESTAMP field. This field indicates when the row was last updated. For my initial unload I specified UPDATE TIMESTAMP between '1900-01-01-00.00.00.000000' and '2003-08-13-00.00.00.000000'. The UPDATE TIMESTAMP is not an index field. This fast unload is going to be implemented as a dialy job to pick up all the changes or additions since the last unload. The problem was the initail unload took 2 hrs of clock time and 77 minutes of CPU. How can I improve on this time. It is done on a IBM 3270 OS 390 machine. The job card looks like this FASTUNLOAD SQL-ACCESS ONLY LOAD-CONTROL NONE OUTPUT-FORMAT FIXED SHRLEVEL CHANGE SORTNUM 02 select .... from table name where HSU_TS between '1900-01-01-00.00.00.000000' and '2003-08-13-00.00.00.000000'; |
| ||||
| Throw a non-unique index on the timestamp field. If this is going to be a daily job then your CPU savings will greatly offset your DASD cost for the extra index. I assume that your date range will change to extract only one day's activity after the initial download. klh sudhin@aol.com (Sam Moore) wrote in message news:<a551c85c.0308200544.54f9c2db@posting.google. com>... > I tried fast unload on a table that has 65 million rows. Basically I > needed all the rows to be coped to a tape (TAPE3590) with where clause > on an UPDATE TIMESTAMP field. This field indicates when the row was > last updated. For my initial unload I specified UPDATE TIMESTAMP > between '1900-01-01-00.00.00.000000' and '2003-08-13-00.00.00.000000'. > The UPDATE TIMESTAMP is not an index field. This fast unload is going > to be implemented as a dialy job to pick up all the changes or > additions since the last unload. > > The problem was the initail unload took 2 hrs of clock time and 77 > minutes of CPU. How can I improve on this time. It is done on a IBM > 3270 OS 390 machine. The job card looks like this > > FASTUNLOAD > SQL-ACCESS ONLY > LOAD-CONTROL NONE > OUTPUT-FORMAT FIXED > SHRLEVEL CHANGE > SORTNUM 02 > select .... from table name where HSU_TS between > '1900-01-01-00.00.00.000000' and '2003-08-13-00.00.00.000000'; |