increase physical log chunk size

HI, Folks, I used the following 3 steps(see below) to increase the Physical log size. Basically, I dropped the dbspace "dbphylog" that includes only one chunk. then recreated it ( reuse the same raw chunk) with bigger size. Question: I did not do a level 0 backup between step (1) and (2), is there any potential problem? Thanks, Frank fqu@dolly $ onstat -version Program Name: onstat Build Version: 10.00.UC5 Build Number: N202 Build Host: ibm6c1b Build OS: AIX 5.2 Build Date: Thu May 18 00:09:08 CDT 2006 GLS Version: glslib-4.00.UC8 (1)informix@erin $ onspaces -d dbphylog WARNING: Dropping a DBspace. Do you really want to continue? (y/n)y Space successfully dropped. ** WARNING ** A level 0 archive will need to be done before any chunks from DBspace dbphylog can be reused (see Dynamic Server Administrator's manual). (2)informix@erin $ onspaces -c -d dbphylog -p /usr/informix/dev-links/db1/DBPHYLOG -o 4 -s 2048000 -m /usr/informix/dev-links/db1/MDBPHYLOG 4 Verifying physical disk space, please wait ... Verifying physical disk space, please wait ... Space successfully added. ** WARNING ** A level 0 archive of Root DBSpace will need to be done (3) increase Onconfig parameter PHYSFILE and bounce instance

Hi, The 0 level backup is needed to ensure future restores to work fine. For such situations, you can always go for 0 level backup on /dev/null. change TAPEDEV to /dev/null or to the link that will point to /dev/null and perform 0 level backup. This will not take much time. * Note: Do not forget to change TAPEDEV back to its original location. Thanks, Nilesh

Thank you, Nilesh !! On Feb 1, 2008 4:28 PM, NILESH BHAVSAR <nilesh_bhavsar@satyam.com> wrote: > Hi, > > The 0 level backup is needed to ensure future restores to work fine. > > For such situations, you can always go for 0 level backup on /dev/null. > change TAPEDEV to /dev/null or to the link that will point to /dev/null > and perform 0 level backup. This will not take much time. > > * Note: Do not forget to change TAPEDEV back to its original location. > > Thanks, > > Nilesh > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > See you at the IIUG Informix 2008 Conference > The Power Conference for Informix Professionals > April 27 - 30, 2008 Marriott Overland Park (Kansas City), Kansas > http://www.iiug.org/conf > Registration Now Open!! >

NILESH BHAVSAR wrote: > Hi, > > The 0 level backup is needed to ensure future restores to work fine. > Except, note that an archive to /dev/null will ensure nothing at all, except that the messages will go away! ONLY do this if you will be guaranteeing that a level 0 archive will be made before the next system crash! ;-) Otherwise you will have to make the same system level changes again after a restore. Oh, and PLEASE do not cut out all of the original posting, most of us follow this list via the email gateway and doing so makes it hard to join the discussion. Art S. Kagel Oninit > For such situations, you can always go for 0 level backup on /dev/null. > change TAPEDEV to /dev/null or to the link that will point to /dev/null > and perform 0 level backup. This will not take much time. > > * Note: Do not forget to change TAPEDEV back to its original location. > > Thanks, > > Nilesh > ================================================================================ =========== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.oninit.com/home/disclaimer.php ================================================================================ ===========

FRANK wrote: Are you certain that the physical log is even in the dbspace dbphylog? If it were, the engine would not have allowed you to drop it! Did you move it out first and then move it back afterwards? You didn't say. Art S. Kagel > HI, Folks, > > I used the following 3 steps(see below) to increase the Physical log size. > > Basically, I dropped the dbspace "dbphylog" that includes only one chunk. > then recreated it ( reuse the same raw chunk) with bigger size. > > Question: I did not do a level 0 backup between step (1) and (2), is there > any potential problem? > > Thanks, > Frank > > fqu@dolly $ onstat -version > Program Name: onstat > Build Version: 10.00.UC5 > Build Number: N202 > Build Host: ibm6c1b > Build OS: AIX 5.2 > Build Date: Thu May 18 00:09:08 CDT 2006 > GLS Version: glslib-4.00.UC8 > > (1)informix@erin $ onspaces -d dbphylog > WARNING: Dropping a DBspace. > Do you really want to continue? (y/n)y > Space successfully dropped. > ** WARNING ** A level 0 archive will need to be done before any chunks from > DBspace dbphylog can be reused (see Dynamic Server Administrator's manual). > > (2)informix@erin $ onspaces -c -d dbphylog -p > /usr/informix/dev-links/db1/DBPHYLOG -o 4 -s 2048000 -m > /usr/informix/dev-links/db1/MDBPHYLOG 4 > Verifying physical disk space, please wait ... > Verifying physical disk space, please wait ... > Space successfully added. > > ** WARNING ** A level 0 archive of Root DBSpace will need to be done > > (3) increase Onconfig parameter PHYSFILE and bounce instance > > > ================================================================================ =========== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.oninit.com/home/disclaimer.php ================================================================================ ===========

FRANK wrote: > Thank you, Nilesh !! > > On Feb 1, 2008 4:28 PM, NILESH BHAVSAR <nilesh_bhavsar@satyam.com> wrote: > > >> Hi, >> >> The 0 level backup is needed to ensure future restores to work fine. >> >> For such situations, you can always go for 0 level backup on /dev/null. >> change TAPEDEV to /dev/null or to the link that will point to /dev/null >> and perform 0 level backup. This will not take much time. >> >> * Note: Do not forget to change TAPEDEV back to its original location. >> >> Thanks, >> >> Nilesh >> >> >> >> >> > ********* http://veryeasytutorial.blogspot.com/2008/01/segregate-logical-log-and-physical- log.html

Art, Yes, we first moved the physical log to root dbs, then did the steps. Thanks, Frank On Mon, Feb 4, 2008 at 8:21 AM, Art S. Kagel (Oninit LLC) <art@oninit.com> wrote: > FRANK wrote: > > Are you certain that the physical log is even in the dbspace dbphylog? > If it were, the engine would not have allowed you to drop it! Did you > move it out first and then move it back afterwards? You didn't say. > > Art S. Kagel > > > HI, Folks, > > > > I used the following 3 steps(see below) to increase the Physical log > size. > > > > Basically, I dropped the dbspace "dbphylog" that includes only one > chunk. > > then recreated it ( reuse the same raw chunk) with bigger size. > > > > Question: I did not do a level 0 backup between step (1) and (2), is > there > > any potential problem? > > > > Thanks, > > Frank > > > > fqu@dolly $ onstat -version > > Program Name: onstat > > Build Version: 10.00.UC5 > > Build Number: N202 > > Build Host: ibm6c1b > > Build OS: AIX 5.2 > > Build Date: Thu May 18 00:09:08 CDT 2006 > > GLS Version: glslib-4.00.UC8 > > > > (1)informix@erin $ onspaces -d dbphylog > > WARNING: Dropping a DBspace. > > Do you really want to continue? (y/n)y > > Space successfully dropped. > > ** WARNING ** A level 0 archive will need to be done before any chunks > from > > DBspace dbphylog can be reused (see Dynamic Server Administrator's > manual). > > > > (2)informix@erin $ onspaces -c -d dbphylog -p > > /usr/informix/dev-links/db1/DBPHYLOG -o 4 -s 2048000 -m > > /usr/informix/dev-links/db1/MDBPHYLOG 4 > > Verifying physical disk space, please wait ... > > Verifying physical disk space, please wait ... > > Space successfully added. > > > > ** WARNING ** A level 0 archive of Root DBSpace will need to be done > > > > (3) increase Onconfig parameter PHYSFILE and bounce instance > > > > > > > > > > ================================================================================ =========== > Please access the attached hyperlink for an important electronic > communications disclaimer: > > http://www.oninit.com/home/disclaimer.php > > > > ================================================================================ =========== > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > See you at the IIUG Informix 2008 Conference > The Power Conference for Informix Professionals > April 27 - 30, 2008 Marriott Overland Park (Kansas City), Kansas > http://www.iiug.org/conf > Registration Now Open!! >