Logical Logs not full

Posted in 2005

Topics: Stored Procedures & SPL, Logging & Checkpoints, Clustering, Grid & MACH11

Muthana.AL-Temimi@tu-harburg.hamburg.de — Tue, 1 Feb 2005 08:41:56 +0100 — source: Usenet: comp.databases.informix

This is a multi-part message in MIME format. ------_=_NextPart_001_01C50831.81451638 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C50831.81451638" ------_=_NextPart_002_01C50831.81451638 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Hello There, =20 I have found that the logical logs are not full and you can have a look: =20 address number flags uniqid begin size used %used 11b756a8 7 U-B---- 779 300035 5000 5000 100.00 11b756e0 8 U-B---- 780 3013bd 5000 4997 99.94 11b75718 9 U-B---- 781 302745 5000 4995 99.90 11b75750 10 U-B---- 782 303acd 5000 4996 99.92 11b75788 11 U-B---- 783 304e55 5000 5000 100.00 11b757c0 12 U---C-L 784 3061dd 5000 2118 42.36 11b757f8 13 U-B---- 775 307565 5000 5000 100.00 11b75830 14 U-B---- 776 3088ed 5000 5000 100.00 11b75868 15 U-B---- 777 309c75 5000 5000 100.00 11b758a0 16 U-B---- 778 30affd 5000 5000 100.00 10 active, 10 total =20 My question here: Is there are something wrong because I see that some = logical logs are not 100% full=20 for example 99.94% or 99.90%. Shall I delete them and create a new one = or what is the problem? =20 Regards Muthana =20 ------------------------------------------------------------------- Muthana AL-Temimi TUHH - IuK-Referat Schlo=DFm=FChlendamm 32 21073 Hamburg Email: muthana.al-temimi@tu-harburg.hamburg.de Tel.: 040 428 78 3294 EFax: 040 4279 35 160 =20 ------_=_NextPart_002_01C50831.81451638 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns=3D"http://www.w3.org/TR/REC-html40">; <head> <meta http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <meta name=3DProgId content=3DWord.Document> <meta name=3DGenerator content=3D"Microsoft Word 10"> <meta name=3DOriginator content=3D"Microsoft Word 10"> <link rel=3DFile-List href=3D"cid:filelist.xml@01C50839.E4A517B0">  <style>  </style>  </head> <body bgcolor=3Dwhite background=3D"cid:image001.jpg@01C50839.E4A517B0" = lang=3DDE link=3Dblue vlink=3Dpurple style=3D'tab-interval:35.4pt'> <img src=3D"cid:image001.jpg@01C50839.E4A517B0" v:src=3D"cid:image001.jpg@01C50839.E4A517B0" v:shapes=3D"_x0000_Mail" = width=3D0 height=3D0 class=3Dshape style=3D'display:none;width:0;height:0'> <div class=3DSection1> Hello There,<o:p></o:p> <o:p> </o:p> I have found that the logical logs are not full and you can have a = look:<o:p></o:p> <o:p> </o:p> address=A0 = number=A0=A0 flags=A0=A0=A0 uniqid=A0=A0 begin=A

↪ replying to Muthana.AL-Temimi@tu-harburg.hamburg.de

Brice — 1 Feb 2005 14:32:31 -0800 — source: Usenet: comp.databases.informix

Muthana, If you are using unbuffered logging on any of your databases, then their is a fair chance that you will not fill a logical log before it needs to be backed-up. In unbuffered logging, a logical log will be backed-up as soon as a transaction is committed. You can confirm the type of logging your databases are using with "onmonitor -- > status --> databases"; If you have "U" or "A" (ascii) logging then the logs may not be filled before they need to be backed-up. Hope this helps. Brice Avila Muthana.AL-Temimi@tu-harburg.hamburg.de wrote: > This is a multi-part message in MIME format.

↪ replying to Brice

Art S. Kagel — Tue, 01 Feb 2005 17:46:04 -0500 — source: Usenet: comp.databases.informix

Brice wrote: > Muthana, > > If you are using unbuffered logging on any of your databases, then > their is a fair chance that you will not fill a logical log before it > needs to be backed-up. In unbuffered logging, a logical log will be > backed-up as soon as a transaction is committed. You can confirm the > type of logging your databases are using with "onmonitor -- > status > --> databases"; If you have "U" or "A" (ascii) logging then the logs > may not be filled before they need to be backed-up. Uh, no. You're mistaking the flushing of the logical log buffer to the logical log on disk with the archiving of the logical log file itself and switching logs. Confusion. If a database is set to UNBUFFERED logging then whenever a transaction in that database is committed or rolled back the current logical log buffer is flushed to the logical log file on disk. If ALL databases in an instance are BUFFERED logging then the current logical log buffer is not flushed until it fills up. In a mixed instance with both BUFFERED and UNBUFFERED logging it gets a bit confusing, but the rule still holds. As soon as a logical log buffer contains a COMMIT or ROLLBACK record for a transaction on an UNBUFFERED database it is flushed. This means that BUFFERED LOG databases will gain some safety from processing of UNBUFFERED LOG database transactions. UNBUFFERED LOG is just safer and a bit slower. In any event NONE of this has anything to do with either backing up the logical logs or with switching to the next logical log file before the current one is full. The partial logs are the result of one or more of: - Manual running of onmode -l for no particular reason or just to be able to use onlog on that log file without freezing transactions. - OnBar scripts switching logs so onbar can have a logical log to archive for sure. - There is a similar practice among DBAs to run a manual onmode -l to switch logs before taking any archive with either ontape or onbar. This is so that the archive will capture all committed transactions to the moment of the archive start and so that a restore will have a clean logical log to begin the logical restore with. It is just normal DBA paranoia anyway since IDS takes care of all that for you. Art S. Kagel > Hope this helps. > > Brice Avila

Related threads

Glossary

logical log