Bill, this will most probably work. As far as I know, the load command issues an internal quiesce exclusive on the tblsp. and an exclusive lock on the table. This means that the requesting id, and only that id (not sysadm,dbadm nor anybody else) can access that tblsp. The lock is reset when the table is successfully loaded. In order to retain the lock thru all tables of that tblsp., you are right in using the "hold quiesce" option as this will release the lock on the tblsp. and the tables only at reset time. Therefore, I don't think that step 2 is required. The load command should look like: db2 load . . . into table T1 . . . hold quiesce . . .nonrecoverable (for tables 1 thru 9) If you use the nonrecoverable option, the tblsp. stays locked to you but in normal state and won't require to be backed up until table 10. db2 load . . . into table T1 . . . hold quiesce . . .(for tables 10) Also look at incremental maintence of summary tables in the load command for V7.x If you can't do it this way, you'll have to back up the tblsp. before running step 5 as the tblsp. will be in backup pending after tavle10 and the stored procs. won't be able to touch tables 1 thru 10. Then run the procs. and backup all the db if required. Of course, if you are not in log retain or archive, the backup of the tblsp. won't be needed. [EMAIL PROTECTED] wrote: > Hi, > > Our environment is UDB v7.2 running on AIX. > > We have an application that is going to be running a series of table loads > on a daily basis to refresh the data in their tables. We're currently > trying to architect the best solution for doing this. One of the main > concerns for the application is to ensure that no active users will be > getting in their way while the load process is running. Basically, what > they want to do is to force all users off the database (using the "force > applications" command), lock the tablespace with the tables being loaded > for exclusive use using the "quiesce tablespaces for table" command, run > the loads, run some stored procedures to rebuild some summary tables, run a > backup, and then release the lock with a "quiesce . . . reset" command. > There are 10 tables being loaded, and they all reside in the same > tablespace. I'm envisioning that this process will look something like > this: > > 1) db2 force application ( app1, app2, app3, etc . . . ) - this would > probably be done through a shell script running the "db2 list application" > command to get all the application handles > > 2) db2 quiesce tablespaces for table T1 exclusive > > 3) db2 load . . . into table T1 . . . hold quiesce . . . > > 4) perform loads for tables T2 through T10 with "hold quiesce" > > 5) run the stored procedures which will read the tables just loaded to > rebuild 2 "summary" tables (which reside in a different tablespace) > > 6) db2 backup database . . . > > 7) db2 quiesce tablespaces for table T1 reset > > This seems pretty straightforward to me, but this is the first application > that we've had that has done this kind of processing with UDB, so we have > no practical experience in doing this (yet). > > Any comments, warnings, corrections, advise, etc., would be welcome and > appreciated. > > Thanks, > > Bill Gallagher, DBA > Phoenix Life Insurance > Enfield, CT > > ===== > To unsubscribe, send 'unsubscribe' to [EMAIL PROTECTED] > For other info (and scripts), see http://people.mn.mediaone.net/scottrmcleod
begin:vcard n:Saint-Jacques;Pierre tel;cell:514-233-8679 tel;fax:514-737-1268 tel;work:514-737-4515 x-mozilla-html:FALSE org:SES Consultants Inc. adr:;;233 Simcoe Cr.;Mount-Royal;QC;H3P 1X1;Canada version:2.1 email;internet:[EMAIL PROTECTED] title:President fn:Pierre Saint-Jacques end:vcard
