onunload issue 9.2fc2

Hello, we use onunload once a month to obtain a snapshot of a database for the purpose of a restore onto a test server. In the past we were using IDS 732 and the process for a 24 gig database takes 1.25 to 1.5 hours. After the upgrade to 9.2fc2 the onunload is taking 3.5 hrs. (we are on hp-ux 11.11) We have since upgraded the test server to 9.2fc6 and the onunload is taking the normal 1.5 hrs. The commands are the same onunload -t /dev/rmt/1m -s 70000000 dbname (block size is not specified as Iassume it is detecting it from the onconfig.std). Has any one else experienced this issue with the 9.2fc2 engine or does anyone have recommendations? Our fall back at this point will be to use ontape restore correcting for the raw device paths and then to rename the database or to do a leisurely onunload/onload from the test server/db to the target test database. 3.5 hrs is just too long a time to have the engine in a shared lock mode for the whole database. Thanks in advance, Doug

OK, several things, the latest 7.xx release is 7.31xD8, there is no 7.32 version of IDS. I'll assume you mean 7.31 here. Next, unfortunately moving to 9.2x was not an upgrade it was actually a downgrade. IDS 7.31 and 9.30 were built from equivalent sources. The 9.2x releases are significantly slower than 7.31 for most OLTP and DSS applications. Fix? You should upgrade to AT LEAST 9.40, but preferably to 10.00xC4 or later. Finally, it is dangerous to use the onconfig.std as you ONCONFIG file. You should rename it something like onconfig.<myservername>. The problem is that if you decide to perform a minor version update in-place (a bad idea in itself, but common enough to protect oneself against) that install will overwrite the onconfig.std with a default one with none of your customizations in it. Not even the location and size of the rootdb. Art S. Kagel ----- Original Message ----- From: Doug Fossmeyer <ids@iiug.org> At: 5/31 17:25:40 Hello, we use onunload once a month to obtain a snapshot of a database for the purpose of a restore onto a test server. In the past we were using IDS 732 and the process for a 24 gig database takes 1.25 to 1.5 hours. After the upgrade to 9.2fc2 the onunload is taking 3.5 hrs. (we are on hp-ux 11.11) We have since upgraded the test server to 9.2fc6 and the onunload is taking the normal 1.5 hrs. The commands are the same onunload -t /dev/rmt/1m -s 70000000 dbname (block size is not specified as Iassume it is detecting it from the onconfig.std). Has any one else experienced this issue with the 9.2fc2 engine or does anyone have recommendations? Our fall back at this point will be to use ontape restore correcting for the raw device paths and then to rename the database or to do a leisurely onunload/onload from the test server/db to the target test database. 3.5 hrs is just too long a time to have the engine in a shared lock mode for the whole database. Thanks in advance, Doug ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

Thank you Art for pointing out the IDS version issue. Mea Culpa on my posting. I mis-stated our IDS versions. I was thinking c4gl when I stated 7x IDS versions, then things went to hades in a handbasket from that point forward. Platforms were: IDS 731UD3 to IDS 9.4FC2 >>> kagel@bloomberg.net 06/01/2006 6:46 AM >>> OK, several things, the latest 7.xx release is 7.31xD8, there is no 7.32 version of IDS. I'll assume you mean 7.31 here. Next, unfortunately moving to 9.2x was not an upgrade it was actually a downgrade. IDS 7.31 and 9.30 were built from equivalent sources. The 9.2x releases are significantly slower than 7.31 for most OLTP and DSS applications. Fix? You should upgrade to AT LEAST 9.40, but preferably to 10.00xC4 or later. Finally, it is dangerous to use the onconfig.std as you ONCONFIG file. You should rename it something like onconfig.<myservername>. The problem is that if you decide to perform a minor version update in-place (a bad idea in itself, but common enough to protect oneself against) that install will overwrite the onconfig.std with a default one with none of your customizations in it. Not even the location and size of the rootdb. Art S. Kagel ----- Original Message ----- From: Doug Fossmeyer <ids@iiug.org> At: 5/31 17:25:40 Hello, we use onunload once a month to obtain a snapshot of a database for the purpose of a restore onto a test server. In the past we were using IDS 732 and the process for a 24 gig database takes 1.25 to 1.5 hours. After the upgrade to 9.2fc2 the onunload is taking 3.5 hrs. (we are on hp-ux 11.11) We have since upgraded the test server to 9.2fc6 and the onunload is taking the normal 1.5 hrs. The commands are the same onunload -t /dev/rmt/1m -s 70000000 dbname (block size is not specified as Iassume it is detecting it from the onconfig.std). Has any one else experienced this issue with the 9.2fc2 engine or does anyone have recommendations? Our fall back at this point will be to use ontape restore correcting for the raw device paths and then to rename the database or to do a leisurely onunload/onload from the test server/db to the target test database. 3.5 hrs is just too long a time to have the engine in a shared lock mode for the whole database. Thanks in advance, Doug ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum. ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

OK, that sounds better (or maybe it doesn't ;-( Hmmm, 9.40xC2 is far from the latest release, but I don't remember any specific performance problems with the early 9.40 releases. Running update stats after an in-place upgrade is required for general performance, but that should not affect onunload at all. On the other hand, if you've set up for large chunks that might exacerbate table fragmentation, but I doubt it. Worth checking out though. Do some of the affected tables have large numbers of interleaved extents? Perhaps a reorg could help. After that, without seeing things in action, I'm stumped. Art S. Kagel ----- Original Message ----- From: Doug Fossmeyer <ids@iiug.org> At: 6/01 10:48:18 Thank you Art for pointing out the IDS version issue. Mea Culpa on my posting. I mis-stated our IDS versions. I was thinking c4gl when I stated 7x IDS versions, then things went to hades in a handbasket from that point forward. Platforms were: IDS 731UD3 to IDS 9.4FC2 >>> kagel@bloomberg.net 06/01/2006 6:46 AM >>> OK, several things, the latest 7.xx release is 7.31xD8, there is no 7.32 version of IDS. I'll assume you mean 7.31 here. Next, unfortunately moving to 9.2x was not an upgrade it was actually a downgrade. IDS 7.31 and 9.30 were built from equivalent sources. The 9.2x releases are significantly slower than 7.31 for most OLTP and DSS applications. Fix? You should upgrade to AT LEAST 9.40, but preferably to 10.00xC4 or later. Finally, it is dangerous to use the onconfig.std as you ONCONFIG file. You should rename it something like onconfig.<myservername>. The problem is that if you decide to perform a minor version update in-place (a bad idea in itself, but common enough to protect oneself against) that install will overwrite the onconfig.std with a default one with none of your customizations in it. Not even the location and size of the rootdb. Art S. Kagel ----- Original Message ----- From: Doug Fossmeyer <ids@iiug.org> At: 5/31 17:25:40 Hello, we use onunload once a month to obtain a snapshot of a database for the purpose of a restore onto a test server. In the past we were using IDS 732 and the process for a 24 gig database takes 1.25 to 1.5 hours. After the upgrade to 9.2fc2 the onunload is taking 3.5 hrs. (we are on hp-ux 11.11) We have since upgraded the test server to 9.2fc6 and the onunload is taking the normal 1.5 hrs. The commands are the same onunload -t /dev/rmt/1m -s 70000000 dbname (block size is not specified as Iassume it is detecting it from the onconfig.std). Has any one else experienced this issue with the 9.2fc2 engine or does anyone have recommendations? Our fall back at this point will be to use ontape restore correcting for the raw device paths and then to rename the database or to do a leisurely onunload/onload from the test server/db to the target test database. 3.5 hrs is just too long a time to have the engine in a shared lock mode for the whole database. Thanks in advance, Doug ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum. ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum. ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

> From: Doug Fossmeyer <ids@iiug.org> > > We have since upgraded the test server to 9.2fc6 and the onunload is > taking > the normal 1.5 hrs. The commands are the same > onunload -t /dev/rmt/1m -s 70000000 dbname (block size is not specified as> I > assume it is detecting it from the onconfig.std). Are you sure that the blocksize is the same as it used to be? -- Bye now, Obnoxio "... no bill is required as no value was provided." -- Christine Normile