Re: Reversion from IDS 9.40 to 9.21 fails

There needs to be a reverted format style checkpoint at the end of the reversion or the old version of the instance will have to try to process log records from the 9.4 server. If any of the log records have changed their format, then that would create a problem. Fundamentally - 9.4 knows about 9.21, but 9.21 knows nothing about 9.4. M.P. "Neil Truby" <neil.truby@ardenta.com> wrote in message news:btk2a3$7v6dq$1@ID-162943.news.uni-berlin.de... > Thanks Madison. > As you can see from below, the onmode -b revision process leaves the > database offline. So at what point could we issue a checkpoint? > > What do you infer from the absence of the checkpoint? > > cheers > Neil > > "Madison Pruet" <mpruet@comcast.net> wrote in message > news:2KeLb.88807$I07.421506@attbi_s53... > > Neil, > > > > On the failure below, I'm not seeing something that I think is rather > > important. That is, I don't see any evidence of a hard checkpoint (i.e. > > non-fuzzy) after the reversion has been done. I think that is probably > > causing the failure because otherwise, the 9.21 server will be trying to > > process 9.4 log records. I do know that a couple of the log records > changed > > a bit with 9.4 because of some 64-bit alignment issues. > > > > You might want it try to issue an onmode -c as part of the reversion > > process. > > > > M.Pruet > > > > > > "Neil Truby" <neil.truby@ardenta.com> wrote in message > > news:btjhun$7r28c$1@ID-162943.news.uni-berlin.de... > > > HP-UX 11.11 > > > IDS 9.20 FC4 to IDS 9.40 FC2 > > > > > > We are testing the above upgrade. On three of the four databases to be > > > converted we have had no problems in the conversion process (we did > > > encounter a bug with slow index builds, a known problem kindly > identified > > by > > > Jonathan Leffler due to be fixed in 9.40 FC3). On the fourth, it also > > > converts OK but sporadically - perhaps 2 times in 10 - the reversion > back > > > from 9.40 (level 0) to 9.21 will fail. This is an *absolute* > show-stopper > > > for this client. The database in question is mission-critical, and is > > > 500GBytes in size, so dbexport/dbimport, or a restore, is not viable. > > > > > > A call has been raised with Tech Support (389466). Because this is not > a > > > "down" system we will have to work hard to ensure that it receives a > > > prioroty that refelects the imprtance of the issue to the client. > > > > > > Any insight gratefully received. I attach the online log from the > > reversion > > > process and the subsequent attempt to bring the server back online. > > > > > > thanks > > > Neil Truby t:01932 724027 > > > Director m:07798 811708 > > > Ardenta Limited e:neil.truby@ardenta.com > > > > > > ==================================== > > > 11:37:18 Maximum server connections 0 > > > 11:37:18 Update reserved page status of conversion > > > 11:37:18 Quiescent Mode > > > 11:37:18 Succeeded > > > 11:37:19 Checkpoint Completed: duration was 0 seconds. > > > 11:37:19 Checkpoint loguniq 112336, logpos 0x28ac018, timestamp:> > 761991795 > > > > > > 11:37:19 Maximum server connections 0 > > > 11:37:19 Internal Conversion Completed Successfuly > > > 11:37:19 Conversion Enabling Client Connections > > > 11:37:19 Building 'sysmaster' database ... > > > 11:37:20 On-Line Mode > > > 11:37:24 Booting Language <spl> from module <> > > > > > > 11:05:03 Maximum server connections 3 > > > 11:08:53 Shutdown Mode > > > 11:08:54 Quiescent Mode > > > 11:08:55 Checkpoint Completed: duration was 0 seconds. > > > 11:08:55 Checkpoint loguniq 112336, logpos 0x1018, timestamp:761722097 > > > > > > 11:08:55 Maximum server connections 3 > > > 11:08:56 Reversion to version 9.2 Started > > > 11:08:56 Beginning process of reverting system to 9.2 ... > > > 11:08:57 ** WARNING: Value for config parameter LRU_MAX_DIRTY will be> > > truncated from decimal value 4.000 to integer value 4. > > > Please check onconfig parameter value before reinitializing the Server. > > > > > > 11:08:57 ** WARNING: Value for config parameter LRU_MIN_DIRTY will be> > > truncated from decimal value 2.000 to integer value 2. > > > Please check onconfig parameter value before reinitializing the Server. > > > > > > 11:08:58 Booting Language <spl> from module <> > > > 11:08:58 Loading Module <SPLNULL> > > > 11:08:58 On-Line Mode > > > 11:08:58 ON-Bar reversion test start: > > > 11:08:58 ON-Bar reversion test completed successfully. > > > 11:08:58 'onpload' reversion test start: > > > 11:08:59 'onpload' reversion test completed successfully. > > > 11:09:00 Reversion test for R-tree indexes started > > > 11:09:01 Reversion test for R-tree indexes completed successfully > > > 11:09:02 PAM reversion test completed successfully. > > > 11:09:06 Quiescent Mode > > > 11:09:10 Checking database trade for revertibility ... > > > 11:09:11 Database trade is revertible ... > > > 11:09:12 Checking database bo_repositoryo for revertibility ... > > > 11:09:13 Database bo_repositoryo is revertible ... > > > 11:09:14 Checking database bo_docagento for revertibility ... > > > 11:09:15 Database bo_docagento is revertible ... > > > 11:09:16 Checking database onpload for revertibility ... > > > 11:09:17 Database onpload is revertible ... > > > 11:09:18 Checking database startup for revertibility ... > > > 11:09:20 Database startup is revertible ... > > > 11:09:20 Checking database stores7 for revertibility ... > > > 11:09:21 Database stores7 is revertible ... > > > 11:09:22 Checking database dba for revertibility ... > > > 11:09:23 Database dba is revertible ... > > > 11:09:24 Checking database cats for revertibility ... > > > 11:09:26 Database cats is revertible ... > > > 11:09:26 Checking database live for revertibility ... > > > 11:09:30 Database live is revertible ... > > > 11:09:30 Checking database londis_syn for revertibility ... > > > 11:09:32 Database londis_syn is revertible ... > > > 11:09:32 Checking database londis_vw for revertibility ... > > > 11:09:35 Database londis_vw is revertible ... > > > 11:09:36 Checking database live_dummy for revertibility ... > > > 11:09:40 Database live_dummy is revertible ... > > > 11:09:41 On-Line Mode > > > 11:09:41 ON-Bar reversion start: > > > 11:09:41 WARNING:Target server version must have a certified Storage> > > Manager > > > installed after conversion/reversion and before bringing up > > > server. > > > 11:09:41 ON-Bar reversion completed successfully. > > > 11:09:42 ... reverting 'onpload' database. > > > 11:09:42 ... 'onpload' reversion completed successfully. > > > 11:09:42 PAM reversion completed successfully. > > > 11:09:46 ... dropping 'sysmaster' database> > > "crap.txt" 181 lines, 9064 characters > > > $ wc crap*> > > 181 1145 9064 crap.txt > > > $ cat crap.txt> > > 11:05:03 Maximum server connections 3 > > > 11:08:53 Shutdown Mode > > > 11:08:54 Quiescent Mode > > > 11:08:55 Checkpoint Completed: durati

"Madison Pruet" <mpruet@comcast.net> wrote in message news:wdjLb.475$I06.2334@attbi_s01... > There needs to be a reverted format style checkpoint at the end of the > reversion or the old version of the instance will have to try to process log > records from the 9.4 server. If any of the log records have changed their > format, then that would create a problem. > > Fundamentally - 9.4 knows about 9.21, but 9.21 knows nothing about 9.4. So, in your view, no viable workaround - even having an IBM engineer dial in and patch the logs - until mid-2004? cheers Neil

We have a patch that we are currently testing. I'm fairly sure that tech support has a tool to force a checkpoint at a certain point which would eliminate the problem. Also, you could escalate the case for a patch. M.Pruet "Neil Truby" <neil.truby@ardenta.com> wrote in message news:btkf97$8gif1$1@ID-162943.news.uni-berlin.de... > > "Madison Pruet" <mpruet@comcast.net> wrote in message > news:wdjLb.475$I06.2334@attbi_s01... > > There needs to be a reverted format style checkpoint at the end of the > > reversion or the old version of the instance will have to try to process > log > > records from the 9.4 server. If any of the log records have changed their > > format, then that would create a problem. > > > > Fundamentally - 9.4 knows about 9.21, but 9.21 knows nothing about 9.4. > > So, in your view, no viable workaround - even having an IBM engineer dial in > and patch the logs - until mid-2004? > > cheers > Neil > >

> Also, you could escalate the case for a patch. That would be brilliant. This is he client who is suffering seriously from the deferred B-tree cleaner bug (or feature) of 9.21, and who has been forced to abandon successive 9.30/9.40 upgrades due to known bugs encountered in testing. Would we escalate this request through the original Tech Support technician? cheers Neil "Madison Pruet" <mpruet@comcast.net> wrote in message news:JCjLb.789813$Fm2.764282@attbi_s04... > We have a patch that we are currently testing. I'm fairly sure that tech > support has a tool to force a checkpoint at a certain point which would > eliminate the problem. > > Also, you could escalate the case for a patch. > > M.Pruet > > > "Neil Truby" <neil.truby@ardenta.com> wrote in message > news:btkf97$8gif1$1@ID-162943.news.uni-berlin.de... > > > > "Madison Pruet" <mpruet@comcast.net> wrote in message > > news:wdjLb.475$I06.2334@attbi_s01... > > > There needs to be a reverted format style checkpoint at the end of the > > > reversion or the old version of the instance will have to try to process > > log > > > records from the 9.4 server. If any of the log records have changed > their > > > format, then that would create a problem. > > > > > > Fundamentally - 9.4 knows about 9.21, but 9.21 knows nothing about 9.4. > > > > So, in your view, no viable workaround - even having an IBM engineer dial > in > > and patch the logs - until mid-2004? > > > > cheers > > Neil > > > > > >

"Madison Pruet" <mpruet@comcast.net> wrote in message news:JCjLb.789813$Fm2.764282@attbi_s04... > We have a patch that we are currently testing. I'm fairly sure that tech > support has a tool to force a checkpoint at a certain point which would > eliminate the problem. > > Also, you could escalate the case for a patch. This has been done, through the UK Technician. We're hoping for a positive answer on Monday ....