Imported db restore filling rootdbs
On IDS 11.50.FC7 (AIX 6.1), the poster found that each onbar restore of an instance made rootdbs grow ~40MB, once filling it completely and blocking the server after log rollforward (assert failure during sysadmin/AUS index recreation). IBM support blamed the Automated Update Statistics/sysadmin database activity and closed the PMR without further help. Suggested workarounds: place a 'stop' file in $INFORMIXDIR/etc/sysadmin so scheduler tasks don't run during/after the restore (remove it and restart later), or move the sysadmin database out of rootdbs, e.g. via sysadmin:task('sysadmin reset','new_dbspace'). The poster said he would try these; no confirmation of the outcome is recorded.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Using
IDS11.5.FC7XO,
Server : AIX .6.1
Each time I restored an instance I can see an increase in rootdbs size =
of
about 40MB or more on the average. Once, rootdbs was filled up right af=
ter
the rollforwad of the logs and the instance was blocked. Is this expect=
ed
behavior with IDS11.5.FC7X0 ? Has anyone else experienced this ? Resto=
re
of the same instance under 7.31.UD8 did not do that, whatever the size =
of
the rootdbs while the backup was taken, remained the same after the
restore. Though this behavior is very different with IDS11.5. Any thoug=
hts
or suggestions on this will be greatly appreciated! Contacted IBM suppo=
rt,
the tech person's answer to me was not acceptable, for he pointed out "=
AUS
'Automated Update Statistics"
Quote from IBM support " Please be aware that the AUS will activate eve=
ry
time the server is initialized unless it is deactivated. This results i=
n
evaluation of all the data and updates to the sysadmin database, regard=
less
if it was turned on/off on the source server."
He wanted a test case, can't provide backups due to SOX regulations and=
they contain personal information, that will lead to big violations. Th=
ey
did not offer to dial in to diagnose and debug, that sucks to me. Then =
they
closed the PMR.
11:33:48 Dataskip is now OFF for all dbspaces
11:33:48 Dropping temporary TBLspace 0x100120, recovering 8 pages.
11:33:48 Dropping temporary TBLspace 0x100123, recovering 4 pages.
11:33:48 Begin recreating indexes deferred during recovery.
11:33:48 Recreating index:
'sysadmin:"informix".aus_work_info-aus_work_info_idx1'
11:33:48 Checkpoint Completed: duration was 0 seconds.
11:33:48 Fri May 18 - loguniq 572607, logpos 0xe72620, timestamp:
0x27d6bd4f Interval: 31819
11:33:48 Maximum server connections 1
11:33:48 Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns bloc=
ked
0, Plog used 41, Llog used 2
11:33:48 On-Line Mode
11:33:49 Completed recreating indexes.
11:33:49 CDR Initialization failed (inactive).
11:33:50 SCHAPI: Started dbScheduler thread.
11:33:50 Booting Language <spl> from module <>
11:33:50 Loading Module <SPLNULL>
11:33:50 SCHAPI: Started 2 dbWorker threads.
11:33:52 Logical Log 572607 Complete, timestamp: 0x27d6d842.
11:33:52 Checkpoint Completed: duration was 0 seconds.
11:33:52 Fri May 18 - loguniq 572608, logpos 0x3f018, timestamp: 0x27d6=
d87c
Interval: 31820
11:33:52 Maximum server connections 1
11:33:52 Checkpoint Statistics - Avg. Txn Block Time 0.008, # Txns bloc=
ked
0, Plog used 173, Llog used 115
11:33:53 Logical Log 572607 - Backup Started
11:33:53 WARNING: DBspace rootdbs is full
11:33:53 Assert Failed: Exception Caught. Type: MT_EX_OS, Context: mem
11:33:53 IBM Informix Dynamic Server Version 11.50.FC7XO
11:33:53 Who: Session(29, informix@, 0, 7000000331e6548)
Thread(185, dbWorker3, 7000000331a59b0, 4)
File: mtex.c Line: 417
11:33:53 Action: Please notify IBM Informix Technical Support.
11:33:53 stack trace for pid 23593076 written
to /cbpt0atdb03/opt/app/informix/tmp/af.4a16be1
11:33:53 See Also: /cbpt0atdb03/opt/app/informix/tmp/af.4a16be1
I had deactivated AUS on the destination server during the restore and =
it
is still happening. This sounds more like a defect to me. The workarou=
nd
for future restore were to increase rootdbs on the source instance to a=
llow
room for it to grow during the restore. Which to me seems silly.......I=
don't see that as an alternative, while one can be in a situation where=
you
have to restore the db unexpectedly. One thing I notice, in that partic=
ular
instance, is that the rollforward of the logs contain a lot of recreati=
ng
of indexes, due to nightly bacth jobs dropping and recreating indexes t=
hat
are logged. Though this practice is not new, it was there under 7.31 wi=
th
no negative impact. Is there any change in onbar algorithm between IDS7=
.x
and IDS11.x.
I look forward into reading your much anticipated answers.
Regards,
jp
=
Place a file named "stop" in $INFORMIXDIR/etc/sysadmin that will prevent
any tasks from running when you start the restore. If you want tasks
running, you can shutdown the server after the restore completes and has
been first brought fully online to complete the recovery process, delete
the stop file, and restart the server without it in place.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions
and do not reflect on my employer, Advanced DataTools, the IIUG, nor any
other organization with which I am associated either explicitly,
implicitly, or by inference. Neither do those opinions reflect those of
other individuals affiliated with any entity with which I am affiliated nor
those of the entities themselves.
On Wed, Aug 22, 2012 at 12:23 PM, jpierrot@chubb.com <jpierrot@chubb.com>wrote:
> Using
> IDS11.5.FC7XO,
> Server : AIX .6.1
>
> Each time I restored an instance I can see an increase in rootdbs size =
> of
> about 40MB or more on the average. Once, rootdbs was filled up right af=
> ter
> the rollforwad of the logs and the instance was blocked. Is this expect=
> ed
> behavior with IDS11.5.FC7X0 ? Has anyone else experienced this ? Resto=
> re
> of the same instance under 7.31.UD8 did not do that, whatever the size =
> of
> the rootdbs while the backup was taken, remained the same after the
> restore. Though this behavior is very different with IDS11.5. Any thoug=
> hts
> or suggestions on this will be greatly appreciated! Contacted IBM suppo=
> rt,
> the tech person's answer to me was not acceptable, for he pointed out "=
> AUS
> 'Automated Update Statistics"
>
> Quote from IBM support " Please be aware that the AUS will activate eve=
> ry
> time the server is initialized unless it is deactivated. This results i=
> n
> evaluation of all the data and updates to the sysadmin database, regard=
> less
> if it was turned on/off on the source server."
> He wanted a test case, can't provide backups due to SOX regulations and=
>
> they contain personal information, that will lead to big violations. Th=
> ey
> did not offer to dial in to diagnose and debug, that sucks to me. Then =
> they
> closed the PMR.
>
> 11:33:48 Dataskip is now OFF for all dbspaces
> 11:33:48 Dropping temporary TBLspace 0x100120, recovering 8 pages.
> 11:33:48 Dropping temporary TBLspace 0x100123, recovering 4 pages.
> 11:33:48 Begin recreating indexes deferred during recovery.
> 11:33:48 Recreating index:
> 'sysadmin:"informix".aus_work_info-aus_work_info_idx1'
> 11:33:48 Checkpoint Completed: duration was 0 seconds.
> 11:33:48 Fri May 18 - loguniq 572607, logpos 0xe72620, timestamp:
> 0x27d6bd4f Interval: 31819
>
> 11:33:48 Maximum server connections 1
> 11:33:48 Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns bloc=
> ked
> 0, Plog used 41, Llog used 2
>
> 11:33:48 On-Line Mode
> 11:33:49 Completed recreating indexes.
> 11:33:49 CDR Initialization failed (inactive).
> 11:33:50 SCHAPI: Started dbScheduler thread.
> 11:33:50 Booting Language <spl> from module <>
> 11:33:50 Loading Module <SPLNULL>
> 11:33:50 SCHAPI: Started 2 dbWorker threads.
> 11:33:52 Logical Log 572607 Complete, timestamp: 0x27d6d842.
> 11:33:52 Checkpoint Completed: duration was 0 seconds.
> 11:33:52 Fri May 18 - loguniq 572608, logpos 0x3f018, timestamp: 0x27d6=
> d87c
> Interval: 31820
>
> 11:33:52 Maximum server connections 1
> 11:33:52 Checkpoint Statistics - Avg. Txn Block Time 0.008, # Txns bloc=
> ked
> 0, Plog used 173, Llog used 115
>
> 11:33:53 Logical Log 572607 - Backup Started
> 11:33:53 WARNING: DBspace rootdbs is full
> 11:33:53 Assert Failed: Exception Caught. Type: MT_EX_OS, Context: mem
> 11:33:53 IBM Informix Dynamic Server Version 11.50.FC7XO
> 11:33:53 Who: Session(29, informix@, 0, 7000000331e6548)
> Thread(185, dbWorker3, 7000000331a59b0, 4)
> File: mtex.c Line: 417
> 11:33:53 Action: Please notify IBM Informix Technical Support.
> 11:33:53 stack trace for pid 23593076 written
> to /cbpt0atdb03/opt/app/informix/tmp/af.4a16be1
> 11:33:53 See Also: /cbpt0atdb03/opt/app/informix/tmp/af.4a16be1
>
> I had deactivated AUS on the destination server during the restore and =
> it
> is still happening. This sounds more like a defect to me. The workarou=
> nd
> for future restore were to increase rootdbs on the source instance to a=
> llow
> room for it to grow during the restore. Which to me seems silly.......I=
>
> don't see that as an alternative, while one can be in a situation where=
> you
> have to restore the db unexpectedly. One thing I notice, in that partic=
> ular
> instance, is that the rollforward of the logs contain a lot of recreati=
> ng
> of indexes, due to nightly bacth jobs dropping and recreating indexes t=
> hat
> are logged. Though this practice is not new, it was there under 7.31 wi=
> th
> no negative impact. Is there any change in onbar algorithm between IDS7=
> ..x
> and IDS11.x.
>
> I look forward into reading your much anticipated answers.
>
> Regards,
>
> jp
> =
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--14dae93409039f056f04c7dd4fcf
Oh, another option, move the sysadmin database to a different dbspace than
rootdbs. There are instructions for doing that on the IBM developer
community site and you can search for it on google.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions
and do not reflect on my employer, Advanced DataTools, the IIUG, nor any
other organization with which I am associated either explicitly,
implicitly, or by inference. Neither do those opinions reflect those of
other individuals affiliated with any entity with which I am affiliated nor
those of the entities themselves.
On Wed, Aug 22, 2012 at 12:23 PM, jpierrot@chubb.com <jpierrot@chubb.com>wrote:
> Using
> IDS11.5.FC7XO,
> Server : AIX .6.1
>
> Each time I restored an instance I can see an increase in rootdbs size =
> of
> about 40MB or more on the average. Once, rootdbs was filled up right af=
> ter
> the rollforwad of the logs and the instance was blocked. Is this expect=
> ed
> behavior with IDS11.5.FC7X0 ? Has anyone else experienced this ? Resto=
> re
> of the same instance under 7.31.UD8 did not do that, whatever the size =
> of
> the rootdbs while the backup was taken, remained the same after the
> restore. Though this behavior is very different with IDS11.5. Any thoug=
> hts
> or suggestions on this will be greatly appreciated! Contacted IBM suppo=
> rt,
> the tech person's answer to me was not acceptable, for he pointed out "=
> AUS
> 'Automated Update Statistics"
>
> Quote from IBM support " Please be aware that the AUS will activate eve=
> ry
> time the server is initialized unless it is deactivated. This results i=
> n
> evaluation of all the data and updates to the sysadmin database, regard=
> less
> if it was turned on/off on the source server."
> He wanted a test case, can't provide backups due to SOX regulations and=
>
> they contain personal information, that will lead to big violations. Th=
> ey
> did not offer to dial in to diagnose and debug, that sucks to me. Then =
> they
> closed the PMR.
>
> 11:33:48 Dataskip is now OFF for all dbspaces
> 11:33:48 Dropping temporary TBLspace 0x100120, recovering 8 pages.
> 11:33:48 Dropping temporary TBLspace 0x100123, recovering 4 pages.
> 11:33:48 Begin recreating indexes deferred during recovery.
> 11:33:48 Recreating index:
> 'sysadmin:"informix".aus_work_info-aus_work_info_idx1'
> 11:33:48 Checkpoint Completed: duration was 0 seconds.
> 11:33:48 Fri May 18 - loguniq 572607, logpos 0xe72620, timestamp:
> 0x27d6bd4f Interval: 31819
>
> 11:33:48 Maximum server connections 1
> 11:33:48 Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns bloc=
> ked
> 0, Plog used 41, Llog used 2
>
> 11:33:48 On-Line Mode
> 11:33:49 Completed recreating indexes.
> 11:33:49 CDR Initialization failed (inactive).
> 11:33:50 SCHAPI: Started dbScheduler thread.
> 11:33:50 Booting Language <spl> from module <>
> 11:33:50 Loading Module <SPLNULL>
> 11:33:50 SCHAPI: Started 2 dbWorker threads.
> 11:33:52 Logical Log 572607 Complete, timestamp: 0x27d6d842.
> 11:33:52 Checkpoint Completed: duration was 0 seconds.
> 11:33:52 Fri May 18 - loguniq 572608, logpos 0x3f018, timestamp: 0x27d6=
> d87c
> Interval: 31820
>
> 11:33:52 Maximum server connections 1
> 11:33:52 Checkpoint Statistics - Avg. Txn Block Time 0.008, # Txns bloc=
> ked
> 0, Plog used 173, Llog used 115
>
> 11:33:53 Logical Log 572607 - Backup Started
> 11:33:53 WARNING: DBspace rootdbs is full
> 11:33:53 Assert Failed: Exception Caught. Type: MT_EX_OS, Context: mem
> 11:33:53 IBM Informix Dynamic Server Version 11.50.FC7XO
> 11:33:53 Who: Session(29, informix@, 0, 7000000331e6548)
> Thread(185, dbWorker3, 7000000331a59b0, 4)
> File: mtex.c Line: 417
> 11:33:53 Action: Please notify IBM Informix Technical Support.
> 11:33:53 stack trace for pid 23593076 written
> to /cbpt0atdb03/opt/app/informix/tmp/af.4a16be1
> 11:33:53 See Also: /cbpt0atdb03/opt/app/informix/tmp/af.4a16be1
>
> I had deactivated AUS on the destination server during the restore and =
> it
> is still happening. This sounds more like a defect to me. The workarou=
> nd
> for future restore were to increase rootdbs on the source instance to a=
> llow
> room for it to grow during the restore. Which to me seems silly.......I=
>
> don't see that as an alternative, while one can be in a situation where=
> you
> have to restore the db unexpectedly. One thing I notice, in that partic=
> ular
> instance, is that the rollforward of the logs contain a lot of recreati=
> ng
> of indexes, due to nightly bacth jobs dropping and recreating indexes t=
> hat
> are logged. Though this practice is not new, it was there under 7.31 wi=
> th
> no negative impact. Is there any change in onbar algorithm between IDS7=
> ..x
> and IDS11.x.
>
> I look forward into reading your much anticipated answers.
>
> Regards,
>
> jp
> =
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--20cf303dd33e01190904c7dd5d1b
Something like "execute function sysadmin:task('sysadmin reset',
'new_dbspace');
Documented in the Administrator reference.
Regards
On Wed, Aug 22, 2012 at 5:37 PM, Art Kagel <art.kagel@gmail.com> wrote:
> Oh, another option, move the sysadmin database to a different dbspace than
> rootdbs. There are instructions for doing that on the IBM developer
> community site and you can search for it on google.
>
> Art
>
> Art S. Kagel
> Advanced DataTools (www.advancedatatools.com)
> Blog: http://informix-myview.blogspot.com/
>
> Disclaimer: Please keep in mind that my own opinions are my own opinions
> and do not reflect on my employer, Advanced DataTools, the IIUG, nor any
> other organization with which I am associated either explicitly,
> implicitly, or by inference. Neither do those opinions reflect those of
> other individuals affiliated with any entity with which I am affiliated nor
> those of the entities themselves.
>
> On Wed, Aug 22, 2012 at 12:23 PM, jpierrot@chubb.com
> <jpierrot@chubb.com>wrote:
>
> > Using
> > IDS11.5.FC7XO,
> > Server : AIX .6.1
> >
> > Each time I restored an instance I can see an increase in rootdbs size =
> > of
> > about 40MB or more on the average. Once, rootdbs was filled up right af=
> > ter
> > the rollforwad of the logs and the instance was blocked. Is this expect=
> > ed
> > behavior with IDS11.5.FC7X0 ? Has anyone else experienced this ? Resto=
> > re
> > of the same instance under 7.31.UD8 did not do that, whatever the size =
> > of
> > the rootdbs while the backup was taken, remained the same after the
> > restore. Though this behavior is very different with IDS11.5. Any thoug=
> > hts
> > or suggestions on this will be greatly appreciated! Contacted IBM suppo=
> > rt,
> > the tech person's answer to me was not acceptable, for he pointed out "=
> > AUS
> > 'Automated Update Statistics"
> >
> > Quote from IBM support " Please be aware that the AUS will activate eve=
> > ry
> > time the server is initialized unless it is deactivated. This results i=
> > n
> > evaluation of all the data and updates to the sysadmin database, regard=
> > less
> > if it was turned on/off on the source server."
> > He wanted a test case, can't provide backups due to SOX regulations and=
> >
> > they contain personal information, that will lead to big violations. Th=
> > ey
> > did not offer to dial in to diagnose and debug, that sucks to me. Then =
> > they
> > closed the PMR.
> >
> > 11:33:48 Dataskip is now OFF for all dbspaces
> > 11:33:48 Dropping temporary TBLspace 0x100120, recovering 8 pages.
> > 11:33:48 Dropping temporary TBLspace 0x100123, recovering 4 pages.
> > 11:33:48 Begin recreating indexes deferred during recovery.
> > 11:33:48 Recreating index:
> > 'sysadmin:"informix".aus_work_info-aus_work_info_idx1'
> > 11:33:48 Checkpoint Completed: duration was 0 seconds.
> > 11:33:48 Fri May 18 - loguniq 572607, logpos 0xe72620, timestamp:
> > 0x27d6bd4f Interval: 31819
> >
> > 11:33:48 Maximum server connections 1
> > 11:33:48 Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns bloc=
> > ked
> > 0, Plog used 41, Llog used 2
> >
> > 11:33:48 On-Line Mode
> > 11:33:49 Completed recreating indexes.
> > 11:33:49 CDR Initialization failed (inactive).
> > 11:33:50 SCHAPI: Started dbScheduler thread.
> > 11:33:50 Booting Language <spl> from module <>
> > 11:33:50 Loading Module <SPLNULL>
> > 11:33:50 SCHAPI: Started 2 dbWorker threads.
> > 11:33:52 Logical Log 572607 Complete, timestamp: 0x27d6d842.
> > 11:33:52 Checkpoint Completed: duration was 0 seconds.
> > 11:33:52 Fri May 18 - loguniq 572608, logpos 0x3f018, timestamp: 0x27d6=
> > d87c
> > Interval: 31820
> >
> > 11:33:52 Maximum server connections 1
> > 11:33:52 Checkpoint Statistics - Avg. Txn Block Time 0.008, # Txns bloc=
> > ked
> > 0, Plog used 173, Llog used 115
> >
> > 11:33:53 Logical Log 572607 - Backup Started
> > 11:33:53 WARNING: DBspace rootdbs is full
> > 11:33:53 Assert Failed: Exception Caught. Type: MT_EX_OS, Context: mem
> > 11:33:53 IBM Informix Dynamic Server Version 11.50.FC7XO
> > 11:33:53 Who: Session(29, informix@, 0, 7000000331e6548)
> > Thread(185, dbWorker3, 7000000331a59b0, 4)
> > File: mtex.c Line: 417
> > 11:33:53 Action: Please notify IBM Informix Technical Support.
> > 11:33:53 stack trace for pid 23593076 written
> > to /cbpt0atdb03/opt/app/informix/tmp/af.4a16be1
> > 11:33:53 See Also: /cbpt0atdb03/opt/app/informix/tmp/af.4a16be1
> >
> > I had deactivated AUS on the destination server during the restore and =
> > it
> > is still happening. This sounds more like a defect to me. The workarou=
> > nd
> > for future restore were to increase rootdbs on the source instance to a=
> > llow
> > room for it to grow during the restore. Which to me seems silly.......I=
> >
> > don't see that as an alternative, while one can be in a situation where=
> > you
> > have to restore the db unexpectedly. One thing I notice, in that partic=
> > ular
> > instance, is that the rollforward of the logs contain a lot of recreati=
> > ng
> > of indexes, due to nightly bacth jobs dropping and recreating indexes t=
> > hat
> > are logged. Though this practice is not new, it was there under 7.31 wi=
> > th
> > no negative impact. Is there any change in onbar algorithm between IDS7=
> > ..x
> > and IDS11.x.
> >
> > I look forward into reading your much anticipated answers.
> >
> > Regards,
> >
> > jp
> > =
> >
> >
> >
> >
>
>
*******************************************************************************
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
>
> --20cf303dd33e01190904c7dd5d1b
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--
Fernando Nunes
Portugal
http://informix-technology.blogspot.com
My email works... but I don't check it frequently...
--00235429cfacb4489a04c7dd83a4
Thanks! I will try that.
jp
=
From: "Fernando Nunes" <domusonline@gmail.com> =
=
To: ids@iiug.org =
=
Date: 08/22/2012 12:49 PM =
=
Subject: Re: Imported db restore filling rootdbs [28116] =
=
Sent by: ids-bounces@iiug.org =
=
Something like "execute function sysadmin:task('sysadmin reset',
'new_dbspace');
Documented in the Administrator reference.
Regards
On Wed, Aug 22, 2012 at 5:37 PM, Art Kagel <art.kagel@gmail.com> wrote:=
> Oh, another option, move the sysadmin database to a different dbspace=
than
> rootdbs. There are instructions for doing that on the IBM developer
> community site and you can search for it on google.
>
> Art
>
> Art S. Kagel
> Advanced DataTools (www.advancedatatools.com)
> Blog: http://informix-myview.blogspot.com/
>
> Disclaimer: Please keep in mind that my own opinions are my own opini=
ons
> and do not reflect on my employer, Advanced DataTools, the IIUG, nor =
any
> other organization with which I am associated either explicitly,
> implicitly, or by inference. Neither do those opinions reflect those =
of
> other individuals affiliated with any entity with which I am affiliat=
ed
nor
> those of the entities themselves.
>
> On Wed, Aug 22, 2012 at 12:23 PM, jpierrot@chubb.com
> <jpierrot@chubb.com>wrote:
>
> > Using
> > IDS11.5.FC7XO,
> > Server : AIX .6.1
> >
> > Each time I restored an instance I can see an increase in rootdbs s=
ize
=3D
> > of
> > about 40MB or more on the average. Once, rootdbs was filled up righ=
t
af=3D
> > ter
> > the rollforwad of the logs and the instance was blocked. Is this
expect=3D
> > ed
> > behavior with IDS11.5.FC7X0 ? Has anyone else experienced this ? Re=
sto=3D
> > re
> > of the same instance under 7.31.UD8 did not do that, whatever the s=
ize
=3D
> > of
> > the rootdbs while the backup was taken, remained the same after the=
> > restore. Though this behavior is very different with IDS11.5. Any
thoug=3D
> > hts
> > or suggestions on this will be greatly appreciated! Contacted IBM
suppo=3D
> > rt,
> > the tech person's answer to me was not acceptable, for he pointed o=
ut
"=3D
> > AUS
> > 'Automated Update Statistics"
> >
> > Quote from IBM support " Please be aware that the AUS will activate=
eve=3D
> > ry
> > time the server is initialized unless it is deactivated. This resul=
ts
i=3D
> > n
> > evaluation of all the data and updates to the sysadmin database,
regard=3D
> > less
> > if it was turned on/off on the source server."
> > He wanted a test case, can't provide backups due to SOX regulations=
and=3D
> >
> > they contain personal information, that will lead to big violations=
.
Th=3D
> > ey
> > did not offer to dial in to diagnose and debug, that sucks to me. T=
hen
=3D
> > they
> > closed the PMR.
> >
> > 11:33:48 Dataskip is now OFF for all dbspaces
> > 11:33:48 Dropping temporary TBLspace 0x100120, recovering 8 pages.
> > 11:33:48 Dropping temporary TBLspace 0x100123, recovering 4 pages.
> > 11:33:48 Begin recreating indexes deferred during recovery.
> > 11:33:48 Recreating index:
> > 'sysadmin:"informix".aus_work_info-aus_work_info_idx1'
> > 11:33:48 Checkpoint Completed: duration was 0 seconds.
> > 11:33:48 Fri May 18 - loguniq 572607, logpos 0xe72620, timestamp:
> > 0x27d6bd4f Interval: 31819
> >
> > 11:33:48 Maximum server connections 1
> > 11:33:48 Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns
bloc=3D
> > ked
> > 0, Plog used 41, Llog used 2
> >
> > 11:33:48 On-Line Mode
> > 11:33:49 Completed recreating indexes.
> > 11:33:49 CDR Initialization failed (inactive).
> > 11:33:50 SCHAPI: Started dbScheduler thread.
> > 11:33:50 Booting Language <spl> from module <>
> > 11:33:50 Loading Module <SPLNULL>
> > 11:33:50 SCHAPI: Started 2 dbWorker threads.
> > 11:33:52 Logical Log 572607 Complete, timestamp: 0x27d6d842.
> > 11:33:52 Checkpoint Completed: duration was 0 seconds.
> > 11:33:52 Fri May 18 - loguniq 572608, logpos 0x3f018, timestamp:
0x27d6=3D
> > d87c
> > Interval: 31820
> >
> > 11:33:52 Maximum server connections 1
> > 11:33:52 Checkpoint Statistics - Avg. Txn Block Time 0.008, # Txns
bloc=3D
> > ked
> > 0, Plog used 173, Llog used 115
> >
> > 11:33:53 Logical Log 572607 - Backup Started
> > 11:33:53 WARNING: DBspace rootdbs is full
> > 11:33:53 Assert Failed: Exception Caught. Type: MT_EX_OS, Context: =
mem
> > 11:33:53 IBM Informix Dynamic Server Version 11.50.FC7XO
> > 11:33:53 Who: Session(29, informix@, 0, 7000000331e6548)
> > Thread(185, dbWorker3, 7000000331a59b0, 4)
> > File: mtex.c Line: 417
> > 11:33:53 Action: Please notify IBM Informix Technical Support.
> > 11:33:53 stack trace for pid 23593076 written
> > to /cbpt0atdb03/opt/app/informix/tmp/af.4a16be1
> > 11:33:53 See Also: /cbpt0atdb03/opt/app/informix/tmp/af.4a16be1
> >
> > I had deactivated AUS on the destination server during the restore =
and
=3D
> > it
> > is still happening. This sounds more like a defect to me. The worka=
rou=3D
> > nd
> > for future restore were to increase rootdbs on the source instance =
to
a=3D
> > llow
> > room for it to grow during the restore. Which to me seems
silly.......I=3D
> >
> > don't see that as an alternative, while one can be in a situation
where=3D
> > you
> > have to restore the db unexpectedly. One thing I notice, in that
partic=3D
> > ular
> > instance, is that the rollforward of the logs contain a lot of
recreati=3D
> > ng
> > of indexes, due to nightly bacth jobs dropping and recreating index=
es
t=3D
> > hat
> > are logged. Though this practice is not new, it was there under 7.3=
1
wi=3D
> > th
> > no negative impact. Is there any change in onbar algorithm between
IDS7=3D
> > ..x
> > and IDS11.x.
> >
> > I look forward into reading your much anticipated answers.
> >
> > Regards,
> >
> > jp
> > =3D
> >
> >
> >
> >
>
>
***********************************************************************=
********
> > Forum Note: Use "Reply" to post a response in the discussion forum.=
> >
> >
>
> --20cf303dd33e01190904c7dd5d1b
>
>
>
>
***********************************************************************=
********
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--
Fernando Nunes
Portugal
http://informix-technology.blogspot.com
My email works... but I don't check it frequently...
--00235429cfacb4489a04c7dd83a4
***********************************************************************=
********
Forum Note: Use "Reply" to post a response in the discussion forum.
=
Thanks!
jp
=
From: "Art Kagel" <art.kagel@gmail.com> =
=
To: ids@iiug.org =
=
Date: 08/22/2012 12:38 PM =
=
Subject: Re: Imported db restore filling rootdbs [28115] =
=
Sent by: ids-bounces@iiug.org =
=
Oh, another option, move the sysadmin database to a different dbspace t=
han
rootdbs. There are instructions for doing that on the IBM developer
community site and you can search for it on google.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinion=
s
and do not reflect on my employer, Advanced DataTools, the IIUG, nor an=
y
other organization with which I am associated either explicitly,
implicitly, or by inference. Neither do those opinions reflect those of=
other individuals affiliated with any entity with which I am affiliated=
nor
those of the entities themselves.
On Wed, Aug 22, 2012 at 12:23 PM, jpierrot@chubb.com
<jpierrot@chubb.com>wrote:
> Using
> IDS11.5.FC7XO,
> Server : AIX .6.1
>
> Each time I restored an instance I can see an increase in rootdbs siz=
e =3D
> of
> about 40MB or more on the average. Once, rootdbs was filled up right =
af=3D
> ter
> the rollforwad of the logs and the instance was blocked. Is this expe=
ct=3D
> ed
> behavior with IDS11.5.FC7X0 ? Has anyone else experienced this ? Rest=
o=3D
> re
> of the same instance under 7.31.UD8 did not do that, whatever the siz=
e =3D
> of
> the rootdbs while the backup was taken, remained the same after the
> restore. Though this behavior is very different with IDS11.5. Any tho=
ug=3D
> hts
> or suggestions on this will be greatly appreciated! Contacted IBM sup=
po=3D
> rt,
> the tech person's answer to me was not acceptable, for he pointed out=
"=3D
> AUS
> 'Automated Update Statistics"
>
> Quote from IBM support " Please be aware that the AUS will activate e=
ve=3D
> ry
> time the server is initialized unless it is deactivated. This results=
i=3D
> n
> evaluation of all the data and updates to the sysadmin database, rega=
rd=3D
> less
> if it was turned on/off on the source server."
> He wanted a test case, can't provide backups due to SOX regulations a=
nd=3D
>
> they contain personal information, that will lead to big violations. =
Th=3D
> ey
> did not offer to dial in to diagnose and debug, that sucks to me. The=
n =3D
> they
> closed the PMR.
>
> 11:33:48 Dataskip is now OFF for all dbspaces
> 11:33:48 Dropping temporary TBLspace 0x100120, recovering 8 pages.
> 11:33:48 Dropping temporary TBLspace 0x100123, recovering 4 pages.
> 11:33:48 Begin recreating indexes deferred during recovery.
> 11:33:48 Recreating index:
> 'sysadmin:"informix".aus_work_info-aus_work_info_idx1'
> 11:33:48 Checkpoint Completed: duration was 0 seconds.
> 11:33:48 Fri May 18 - loguniq 572607, logpos 0xe72620, timestamp:
> 0x27d6bd4f Interval: 31819
>
> 11:33:48 Maximum server connections 1
> 11:33:48 Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns bl=
oc=3D
> ked
> 0, Plog used 41, Llog used 2
>
> 11:33:48 On-Line Mode
> 11:33:49 Completed recreating indexes.
> 11:33:49 CDR Initialization failed (inactive).
> 11:33:50 SCHAPI: Started dbScheduler thread.
> 11:33:50 Booting Language <spl> from module <>
> 11:33:50 Loading Module <SPLNULL>
> 11:33:50 SCHAPI: Started 2 dbWorker threads.
> 11:33:52 Logical Log 572607 Complete, timestamp: 0x27d6d842.
> 11:33:52 Checkpoint Completed: duration was 0 seconds.
> 11:33:52 Fri May 18 - loguniq 572608, logpos 0x3f018, timestamp: 0x27=
d6=3D
> d87c
> Interval: 31820
>
> 11:33:52 Maximum server connections 1
> 11:33:52 Checkpoint Statistics - Avg. Txn Block Time 0.008, # Txns bl=
oc=3D
> ked
> 0, Plog used 173, Llog used 115
>
> 11:33:53 Logical Log 572607 - Backup Started
> 11:33:53 WARNING: DBspace rootdbs is full
> 11:33:53 Assert Failed: Exception Caught. Type: MT_EX_OS, Context: me=
m
> 11:33:53 IBM Informix Dynamic Server Version 11.50.FC7XO
> 11:33:53 Who: Session(29, informix@, 0, 7000000331e6548)
> Thread(185, dbWorker3, 7000000331a59b0, 4)
> File: mtex.c Line: 417
> 11:33:53 Action: Please notify IBM Informix Technical Support.
> 11:33:53 stack trace for pid 23593076 written
> to /cbpt0atdb03/opt/app/informix/tmp/af.4a16be1
> 11:33:53 See Also: /cbpt0atdb03/opt/app/informix/tmp/af.4a16be1
>
> I had deactivated AUS on the destination server during the restore an=
d =3D
> it
> is still happening. This sounds more like a defect to me. The workaro=
u=3D
> nd
> for future restore were to increase rootdbs on the source instance to=
a=3D
> llow
> room for it to grow during the restore. Which to me seems silly......=
.I=3D
>
> don't see that as an alternative, while one can be in a situation whe=
re=3D
> you
> have to restore the db unexpectedly. One thing I notice, in that part=
ic=3D
> ular
> instance, is that the rollforward of the logs contain a lot of recrea=
ti=3D
> ng
> of indexes, due to nightly bacth jobs dropping and recreating indexes=
t=3D
> hat
> are logged. Though this practice is not new, it was there under 7.31 =
wi=3D
> th
> no negative impact. Is there any change in onbar algorithm between ID=
S7=3D
> ..x
> and IDS11.x.
>
> I look forward into reading your much anticipated answers.
>
> Regards,
>
> jp
> =3D
>
>
>
>
***********************************************************************=
********
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--20cf303dd33e01190904c7dd5d1b
***********************************************************************=
********
Forum Note: Use "Reply" to post a response in the discussion forum.
=
Hi Fellows,
Just one thing I observed today regarding the below suggestion :
First time I tried that back in August it worked but I just restored th=
at
same instance again today even with the existence of that file (stop) =
it
did fill up or increase the size of my rootdbs. Is it fair to say that =
this
work around is not 100% reliable.
Source instance rootdbs size during backup
prptg@cbsreapdb01(informix):/cbsreapdb01/opt/app/informix
$ onstat-d |grep rootdbs
rootdbs 1/70 0 100000 47316
rootdbs 70/114 0 100000 156
rootdbs 114/0 1000000 150000 77052
47MB in one chunk and 77MB in the other
Target instance rootdbs size after restore
trptg@cbsreapdb02(informix):/cbsreapdb02/opt/app/informix
$ onstat-d |grep rootdbs
rootdbs 1/70 0 100000 26836
rootdbs 70/114 0 100000 156
rootdbs 114/0 1000000 150000 3324
left after restore
26.8MB in one chunk and 3MB in the other
Contents of /cbsreapdb02/opt/app/informix/v11.50.FC7X0/etc/sysadmin
Note : the stop file has been there since August 22nd
drwxrwsr-x 2 informix informix 4096 Jun 23 2011 conv/
-rw-r--r-- 1 informix informix 976 May 25 2011 db_create.sql=
-rw-r--r-- 1 informix informix 22798 May 25 2011 db_install.sq=
l
-rw-r--r-- 1 informix informix 1087 May 25 2011 db_uninstall.=
sql
-rw-r--r-- 1 informix informix 52279 May 25 2011 sch_aus.sql
-rw-r--r-- 1 informix informix 808 May 25 2011 sch_sqlcap.sq=
l
-rw-r--r-- 1 informix informix 28002 May 25 2011 sch_tasks.sql=
-rw-r--r-- 1 informix informix 1031 May 25 2011 start.sql
-rwxr--r-- 1 informix informix 0 Aug 22 13:39 stop*
Please advise!
jp
=
From: "Art Kagel" <art.kagel@gmail.com> =
=
To: ids@iiug.org =
=
Date: 08/22/2012 12:35 PM =
=
Subject: Re: Imported db restore filling rootdbs [28114] =
=
Sent by: ids-bounces@iiug.org =
=
Place a file named "stop" in $INFORMIXDIR/etc/sysadmin that will preven=
t
any tasks from running when you start the restore. If you want tasks
running, you can shutdown the server after the restore completes and ha=
s
been first brought fully online to complete the recovery process, delet=
e
the stop file, and restart the server without it in place.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinion=
s
and do not reflect on my employer, Advanced DataTools, the IIUG, nor an=
y
other organization with which I am associated either explicitly,
implicitly, or by inference. Neither do those opinions reflect those of=
other individuals affiliated with any entity with which I am affiliated=
nor
those of the entities themselves.
On Wed, Aug 22, 2012 at 12:23 PM, jpierrot@chubb.com
<jpierrot@chubb.com>wrote:
> Using
> IDS11.5.FC7XO,
> Server : AIX .6.1
>
> Each time I restored an instance I can see an increase in rootdbs siz=
e =3D
> of
> about 40MB or more on the average. Once, rootdbs was filled up right =
af=3D
> ter
> the rollforwad of the logs and the instance was blocked. Is this expe=
ct=3D
> ed
> behavior with IDS11.5.FC7X0 ? Has anyone else experienced this ? Rest=
o=3D
> re
> of the same instance under 7.31.UD8 did not do that, whatever the siz=
e =3D
> of
> the rootdbs while the backup was taken, remained the same after the
> restore. Though this behavior is very different with IDS11.5. Any tho=
ug=3D
> hts
> or suggestions on this will be greatly appreciated! Contacted IBM sup=
po=3D
> rt,
> the tech person's answer to me was not acceptable, for he pointed out=
"=3D
> AUS
> 'Automated Update Statistics"
>
> Quote from IBM support " Please be aware that the AUS will activate e=
ve=3D
> ry
> time the server is initialized unless it is deactivated. This results=
i=3D
> n
> evaluation of all the data and updates to the sysadmin database, rega=
rd=3D
> less
> if it was turned on/off on the source server."
> He wanted a test case, can't provide backups due to SOX regulations a=
nd=3D
>
> they contain personal information, that will lead to big violations. =
Th=3D
> ey
> did not offer to dial in to diagnose and debug, that sucks to me. The=
n =3D
> they
> closed the PMR.
>
> 11:33:48 Dataskip is now OFF for all dbspaces
> 11:33:48 Dropping temporary TBLspace 0x100120, recovering 8 pages.
> 11:33:48 Dropping temporary TBLspace 0x100123, recovering 4 pages.
> 11:33:48 Begin recreating indexes deferred during recovery.
> 11:33:48 Recreating index:
> 'sysadmin:"informix".aus_work_info-aus_work_info_idx1'
> 11:33:48 Checkpoint Completed: duration was 0 seconds.
> 11:33:48 Fri May 18 - loguniq 572607, logpos 0xe72620, timestamp:
> 0x27d6bd4f Interval: 31819
>
> 11:33:48 Maximum server connections 1
> 11:33:48 Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns bl=
oc=3D
> ked
> 0, Plog used 41, Llog used 2
>
> 11:33:48 On-Line Mode
> 11:33:49 Completed recreating indexes.
> 11:33:49 CDR Initialization failed (inactive).
> 11:33:50 SCHAPI: Started dbScheduler thread.
> 11:33:50 Booting Language <spl> from module <>
> 11:33:50 Loading Module <SPLNULL>
> 11:33:50 SCHAPI: Started 2 dbWorker threads.
> 11:33:52 Logical Log 572607 Complete, timestamp: 0x27d6d842.
> 11:33:52 Checkpoint Completed: duration was 0 seconds.
> 11:33:52 Fri May 18 - loguniq 572608, logpos 0x3f018, timestamp: 0x27=
d6=3D
> d87c
> Interval: 31820
>
> 11:33:52 Maximum server connections 1
> 11:33:52 Checkpoint Statistics - Avg. Txn Block Time 0.008, # Txns bl=
oc=3D
> ked
> 0, Plog used 173, Llog used 115
>
> 11:33:53 Logical Log 572607 - Backup Started
> 11:33:53 WARNING: DBspace rootdbs is full
> 11:33:53 Assert Failed: Exception Caught. Type: MT_EX_OS, Context: me=
m
> 11:33:53 IBM Informix Dynamic Server Version 11.50.FC7XO
> 11:33:53 Who: Session(29, informix@, 0, 7000000331e6548)
> Thread(185, dbWorker3, 7000000331a59b0, 4)
> File: mtex.c Line: 417
> 11:33:53 Action: Please notify IBM Informix Technical Support.
> 11:33:53 stack trace for pid 23593076 written
> to /cbpt0atdb03/opt/app/informix/tmp/af.4a16be1
> 11:33:53 See Also: /cbpt0atdb03/opt/app/informix/tmp/af.4a16be1
>
> I had deactivated AUS on the destination server during the restore an=
d =3D
> it
> is still happening. This sounds more like a defect to me. The workaro=
u=3D
> nd
> for future restore were to increase rootdbs on the source instance to=
a=3D
> llow
> room for it to grow during the restore. Which to me seems silly......=
.I=3D
>
> don't see that as an alternative, while one can be in a situation whe=
re=3D
> you
> have to restore the db unexpectedly. One thing I notice, in that part=
ic=3D
> ular
> instance, is that the rollforward of the logs contain a lot of recrea=
ti=3D
> ng
> of indexes, due to nightly bacth jobs droppin
Has the server been bounced since the file was created?
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions
and do not reflect on my employer, Advanced DataTools, the IIUG, nor any
other organization with which I am associated either explicitly,
implicitly, or by inference. Neither do those opinions reflect those of
other individuals affiliated with any entity with which I am affiliated nor
those of the entities themselves.
On Thu, Oct 18, 2012 at 1:29 PM, <jpierrot@chubb.com> wrote:
> Hi Fellows,
>
> Just one thing I observed today regarding the below suggestion :
> First time I tried that back in August it worked but I just restored that
> same instance again today even with the existence of that file (stop) it
> did fill up or increase the size of my rootdbs. Is it fair to say that this
> work around is not 100% reliable.
>
> Source instance rootdbs size during backup
>
> prptg@cbsreapdb01(informix):/cbsreapdb01/opt/app/informix
> $ onstat-d |grep rootdbs> rootdbs 1/70 0 100000 47316
> rootdbs 70/114 0 100000 156
> rootdbs 114/0 1000000 150000 77052
>
> * 47MB in one chunk and 77MB in the other*
>
> Target instance rootdbs size after restore
>
> trptg@cbsreapdb02(informix):/cbsreapdb02/opt/app/informix
> $ onstat-d |grep rootdbs> rootdbs 1/70 0 100000 26836
> rootdbs 70/114 0 100000 156
> rootdbs 114/0 1000000 150000 3324
>
> left after restore
>
> *26.8MB in one chunk and 3MB in the other*
>
>
> *Contents of **/cbsreapdb02/opt/app/informix/v11.50.FC7X0/etc/sysadmin *
> *Note : the stop file has been there since August 22nd*
>
> *drwxrwsr-x 2 informix informix 4096 Jun 23 2011 conv/*
> *-rw-r--r-- 1 informix informix 976 May 25 2011 db_create.sql*
> *-rw-r--r-- 1 informix informix 22798 May 25 2011 db_install.sql*
> *-rw-r--r-- 1 informix informix 1087 May 25 2011 db_uninstall.sql*
> *-rw-r--r-- 1 informix informix 52279 May 25 2011 sch_aus.sql*
> *-rw-r--r-- 1 informix informix 808 May 25 2011 sch_sqlcap.sql*
> *-rw-r--r-- 1 informix informix 28002 May 25 2011 sch_tasks.sql*
> *-rw-r--r-- 1 informix informix 1031 May 25 2011 start.sql*
> *-rwxr--r-- 1 informix informix 0 Aug 22 13:39 stop**
>
> Please advise!
>
>
> jp
> [image: Inactive hide details for "Art Kagel" ---08/22/2012 12:35:25
> PM---Place a file named "stop" in $INFORMIXDIR/etc/sysadmin that w]"Art
> Kagel" ---08/22/2012 12:35:25 PM---Place a file named "stop" in
> $INFORMIXDIR/etc/sysadmin that will prevent any tasks from running whe
>
>
> From:
> "Art Kagel" <art.kagel@gmail.com>
> To:
> ids@iiug.org
> Date:
> 08/22/2012 12:35 PM
> Subject:
> Re: Imported db restore filling rootdbs [28114]
> Sent by:
> ids-bounces@iiug.org
> ------------------------------
>
>
>
> Place a file named "stop" in $INFORMIXDIR/etc/sysadmin that will prevent
> any tasks from running when you start the restore. If you want tasks
> running, you can shutdown the server after the restore completes and has
> been first brought fully online to complete the recovery process, delete
> the stop file, and restart the server without it in place.
>
> Art
>
> Art S. Kagel
> Advanced DataTools (www.advancedatatools.com)
> Blog: http://informix-myview.blogspot.com/
>
> Disclaimer: Please keep in mind that my own opinions are my own opinions
> and do not reflect on my employer, Advanced DataTools, the IIUG, nor any
> other organization with which I am associated either explicitly,
> implicitly, or by inference. Neither do those opinions reflect those of
> other individuals affiliated with any entity with which I am affiliated
> nor
> those of the entities themselves.
>
> On Wed, Aug 22, 2012 at 12:23 PM, jpierrot@chubb.com
> <jpierrot@chubb.com>wrote:
>
> > Using
> > IDS11.5.FC7XO,
> > Server : AIX .6.1
> >
> > Each time I restored an instance I can see an increase in rootdbs size =
> > of
> > about 40MB or more on the average. Once, rootdbs was filled up right af=
> > ter
> > the rollforwad of the logs and the instance was blocked. Is this expect=
> > ed
> > behavior with IDS11.5.FC7X0 ? Has anyone else experienced this ? Resto=
> > re
> > of the same instance under 7.31.UD8 did not do that, whatever the size =
> > of
> > the rootdbs while the backup was taken, remained the same after the
> > restore. Though this behavior is very different with IDS11.5. Any thoug=
> > hts
> > or suggestions on this will be greatly appreciated! Contacted IBM suppo=
> > rt,
> > the tech person's answer to me was not acceptable, for he pointed out "=
> > AUS
> > 'Automated Update Statistics"
> >
> > Quote from IBM support " Please be aware that the AUS will activate eve=
> > ry
> > time the server is initialized unless it is deactivated. This results i=
> > n
> > evaluation of all the data and updates to the sysadmin database, regard=
> > less
> > if it was turned on/off on the source server."
> > He wanted a test case, can't provide backups due to SOX regulations and=
> >
> > they contain personal information, that will lead to big violations. Th=
> > ey
> > did not offer to dial in to diagnose and debug, that sucks to me. Then =
> > they
> > closed the PMR.
> >
> > 11:33:48 Dataskip is now OFF for all dbspaces
> > 11:33:48 Dropping temporary TBLspace 0x100120, recovering 8 pages.
> > 11:33:48 Dropping temporary TBLspace 0x100123, recovering 4 pages.
> > 11:33:48 Begin recreating indexes deferred during recovery.
> > 11:33:48 Recreating index:
> > 'sysadmin:"informix".aus_work_info-aus_work_info_idx1'
> > 11:33:48 Checkpoint Completed: duration was 0 seconds.
> > 11:33:48 Fri May 18 - loguniq 572607, logpos 0xe72620, timestamp:
> > 0x27d6bd4f Interval: 31819
> >
> > 11:33:48 Maximum server connections 1
> > 11:33:48 Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns bloc=
> > ked
> > 0, Plog used 41, Llog used 2
> >
> > 11:33:48 On-Line Mode
> > 11:33:49 Completed recreating indexes.
> > 11:33:49 CDR Initialization failed (inactive).
> > 11:33:50 SCHAPI: Started dbScheduler thread.
> > 11:33:50 Booting Language <spl> from module <>
> > 11:33:50 Loading Module <SPLNULL>
> > 11:33:50 SCHAPI: Started 2 dbWorker threads.
> > 11:33:52 Logical Log 572607 Complete, timestamp: 0x27d6d842.
> > 11:33:52 Checkpoint Completed: duration was 0 seconds.
> > 11:33:52 Fri May 18 - loguniq 572608, logpos 0x3f018, timestamp: 0x27d6=
> > d87c
> > Interval: 31820
> >
> > 11:33:52 Maximum server connections 1
> > 11:33:52 Checkpoint Statistics - Avg. Txn Block Time 0.008, # Txns bloc=
> > ked
> > 0, Plog used 173, Llog used 115
> >
> > 11:33:53 Logical Log 572607 - Backup Started
> > 11:33:53 WARNING: DBspace rootdbs is full
> > 11:33:53 Assert Failed: Exception Caught. Type: MT_EX_OS, Context: mem
> > 11:33:53 IBM Informix Dynamic Server Version 11.50.FC7XO
> > 11:33:53 Who: Session(29, informix@, 0, 7000000331e6548)
> > Thread(185
Yes, it has.
jp
=
From: "Art Kagel" <art.kagel@gmail.com> =
=
To: ids@iiug.org =
=
Date: 10/18/2012 02:02 PM =
=
Subject: Re: Imported db restore filling rootdbs [28569] =
=
Sent by: ids-bounces@iiug.org =
=
Has the server been bounced since the file was created?
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinion=
s
and do not reflect on my employer, Advanced DataTools, the IIUG, nor an=
y
other organization with which I am associated either explicitly,
implicitly, or by inference. Neither do those opinions reflect those of=
other individuals affiliated with any entity with which I am affiliated=
nor
those of the entities themselves.
On Thu, Oct 18, 2012 at 1:29 PM, <jpierrot@chubb.com> wrote:
> Hi Fellows,
>
> Just one thing I observed today regarding the below suggestion :
> First time I tried that back in August it worked but I just restored =
that
> same instance again today even with the existence of that file (stop)=
it
> did fill up or increase the size of my rootdbs. Is it fair to say tha=
t
this
> work around is not 100% reliable.
>
> Source instance rootdbs size during backup
>
> prptg@cbsreapdb01(informix):/cbsreapdb01/opt/app/informix
> $ onstat-d |grep rootdbs> rootdbs 1/70 0 100000 47316
> rootdbs 70/114 0 100000 156
> rootdbs 114/0 1000000 150000 77052
>
> * 47MB in one chunk and 77MB in the other*
>
> Target instance rootdbs size after restore
>
> trptg@cbsreapdb02(informix):/cbsreapdb02/opt/app/informix
> $ onstat-d |grep rootdbs> rootdbs 1/70 0 100000 26836
> rootdbs 70/114 0 100000 156
> rootdbs 114/0 1000000 150000 3324
>
> left after restore
>
> *26.8MB in one chunk and 3MB in the other*
>
>
> *Contents of **/cbsreapdb02/opt/app/informix/v11.50.FC7X0/etc/sysadmi=
n *
> *Note : the stop file has been there since August 22nd*
>
> *drwxrwsr-x 2 informix informix 4096 Jun 23 2011 conv/*
> *-rw-r--r-- 1 informix informix 976 May 25 2011 db_create.sql*
> *-rw-r--r-- 1 informix informix 22798 May 25 2011 db_install.sql*
> *-rw-r--r-- 1 informix informix 1087 May 25 2011 db_uninstall.sql*
> *-rw-r--r-- 1 informix informix 52279 May 25 2011 sch_aus.sql*
> *-rw-r--r-- 1 informix informix 808 May 25 2011 sch_sqlcap.sql*
> *-rw-r--r-- 1 informix informix 28002 May 25 2011 sch_tasks.sql*
> *-rw-r--r-- 1 informix informix 1031 May 25 2011 start.sql*
> *-rwxr--r-- 1 informix informix 0 Aug 22 13:39 stop**
>
> Please advise!
>
>
> jp
> [image: Inactive hide details for "Art Kagel" ---08/22/2012 12:35:25
> PM---Place a file named "stop" in $INFORMIXDIR/etc/sysadmin that w]"A=
rt
> Kagel" ---08/22/2012 12:35:25 PM---Place a file named "stop" in
> $INFORMIXDIR/etc/sysadmin that will prevent any tasks from running wh=
e
>
>
> From:
> "Art Kagel" <art.kagel@gmail.com>
> To:
> ids@iiug.org
> Date:
> 08/22/2012 12:35 PM
> Subject:
> Re: Imported db restore filling rootdbs [28114]
> Sent by:
> ids-bounces@iiug.org
> ------------------------------
>
>
>
> Place a file named "stop" in $INFORMIXDIR/etc/sysadmin that will prev=
ent
> any tasks from running when you start the restore. If you want tasks
> running, you can shutdown the server after the restore completes and =
has
> been first brought fully online to complete the recovery process, del=
ete
> the stop file, and restart the server without it in place.
>
> Art
>
> Art S. Kagel
> Advanced DataTools (www.advancedatatools.com)
> Blog: http://informix-myview.blogspot.com/
>
> Disclaimer: Please keep in mind that my own opinions are my own opini=
ons
> and do not reflect on my employer, Advanced DataTools, the IIUG, nor =
any
> other organization with which I am associated either explicitly,
> implicitly, or by inference. Neither do those opinions reflect those =
of
> other individuals affiliated with any entity with which I am affiliat=
ed
> nor
> those of the entities themselves.
>
> On Wed, Aug 22, 2012 at 12:23 PM, jpierrot@chubb.com
> <jpierrot@chubb.com>wrote:
>
> > Using
> > IDS11.5.FC7XO,
> > Server : AIX .6.1
> >
> > Each time I restored an instance I can see an increase in rootdbs s=
ize
=3D
> > of
> > about 40MB or more on the average. Once, rootdbs was filled up righ=
t
af=3D
> > ter
> > the rollforwad of the logs and the instance was blocked. Is this
expect=3D
> > ed
> > behavior with IDS11.5.FC7X0 ? Has anyone else experienced this ? Re=
sto=3D
> > re
> > of the same instance under 7.31.UD8 did not do that, whatever the s=
ize
=3D
> > of
> > the rootdbs while the backup was taken, remained the same after the=
> > restore. Though this behavior is very different with IDS11.5. Any
thoug=3D
> > hts
> > or suggestions on this will be greatly appreciated! Contacted IBM
suppo=3D
> > rt,
> > the tech person's answer to me was not acceptable, for he pointed o=
ut
"=3D
> > AUS
> > 'Automated Update Statistics"
> >
> > Quote from IBM support " Please be aware that the AUS will activate=
eve=3D
> > ry
> > time the server is initialized unless it is deactivated. This resul=
ts
i=3D
> > n
> > evaluation of all the data and updates to the sysadmin database,
regard=3D
> > less
> > if it was turned on/off on the source server."
> > He wanted a test case, can't provide backups due to SOX regulations=
and=3D
> >
> > they contain personal information, that will lead to big violations=
.
Th=3D
> > ey
> > did not offer to dial in to diagnose and debug, that sucks to me. T=
hen
=3D
> > they
> > closed the PMR.
> >
> > 11:33:48 Dataskip is now OFF for all dbspaces
> > 11:33:48 Dropping temporary TBLspace 0x100120, recovering 8 pages.
> > 11:33:48 Dropping temporary TBLspace 0x100123, recovering 4 pages.
> > 11:33:48 Begin recreating indexes deferred during recovery.
> > 11:33:48 Recreating index:
> > 'sysadmin:"informix".aus_work_info-aus_work_info_idx1'
> > 11:33:48 Checkpoint Completed: duration was 0 seconds.
> > 11:33:48 Fri May 18 - loguniq 572607, logpos 0xe72620, timestamp:
> > 0x27d6bd4f Interval: 31819
> >
> > 11:33:48 Maximum server connections 1
> > 11:33:48 Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns
bloc=3D
> > ked
> > 0, Plog used 41, Llog used 2
> >
> > 11:33:48 On-Line Mode
> > 11:33:49 Completed recreating indexes.
> > 11:33:49 CDR Initialization failed (inactive).
> > 11:33:50 SCHAPI: Started dbScheduler thread.
> > 11:33:50 Booting Language <spl> from module <>
> > 11:33:50 Loading Module <SPLNULL>
> > 11:33:50 SCHAPI: Started 2 dbWorker threads.
> > 11:33:52 Logical Log 572607 Complete, timestamp: 0x27d6d842.
> > 11:33:52 Checkpoint Completed: dura