index rebuilds happen when server boots

This is IDS12.10.TC4IE on windows server 2012 R2. What would cause a bunch of indexes to be recreated when the server boots (and IDS starts)? This only happened once. I can’t find anything in ph_task on it so I’m curious why triggered this.

The index is not recoverable until a checkpoint completes after the index is created. I am guessing that did not occur. Sent from my iPad > On Sep 21, 2014, at 4:49 PM, "BillHatVerizon" <garage_dba@verizon.net> wrote: > > This is IDS12.10.TC4IE on windows server 2012 R2. > What would cause a bunch of indexes to be recreated when the server boots (and > IDS starts)? > This only happened once. > I can’t find anything in ph_task on it so I’m curious why triggered this. > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >

We saw this at a customer quite recently. Windows has run out of some = kind of buffer memory after 6 months - so nothing new (like a new = connection) worked on the Informix side. Had to cycle the entire server = to free up the Windows memory - at which point the engine needed 8 hours = to rebuild indexes. Customer is now rebooting their machines every = quarter. Windoze. Sigh. This happened on 3 of their 36 Windows = servers. j. On Sep 21, 2014, at 5:48 PM, BillHatVerizon <garage_dba@verizon.net> = wrote: > This is IDS12.10.TC4IE on windows server 2012 R2.=20 > What would cause a bunch of indexes to be recreated when the server = boots (and=20 > IDS starts)?=20 > This only happened once.=20 > I can=92t find anything in ph_task on it so I=92m curious why = triggered this.=20 >=20 >=20 > = **************************************************************************= *****=20 > Forum Note: Use "Reply" to post a response in the discussion forum.=20= >=20

Thanks but Fernando wrote in in English. I will try that first. -----Original Message----- From: Madison Pruet Sent: Sunday, September 21, 2014 4:58 PM To: ids@iiug.org Subject: Re: index rebuilds happen when server boots [33836] The index is not recoverable until a checkpoint completes after the index is created. I am guessing that did not occur. Sent from my iPad > On Sep 21, 2014, at 4:49 PM, "BillHatVerizon" <garage_dba@verizon.net> wrote: > > This is IDS12.10.TC4IE on windows server 2012 R2. > What would cause a bunch of indexes to be recreated when the server boots (and > IDS starts)? > This only happened once. > I can’t find anything in ph_task on it so I’m curious why triggered this. > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

I didn't reply to this one... The only reason I can think of is that something was not but a checkpoint didn't occur... so it may had to re-do it... during logical recovery. On Sun, Sep 21, 2014 at 11:06 PM, BillHatVerizon <garage_dba@verizon.net> wrote: > Thanks but Fernando wrote in in English. I will try that first. > > -----Original Message----- > From: Madison Pruet > Sent: Sunday, September 21, 2014 4:58 PM > To: ids@iiug.org > Subject: Re: index rebuilds happen when server boots [33836] > > > > The index is not recoverable until a checkpoint completes after the index > is created. I am guessing that did not occur. > > Sent from my iPad > > > On Sep 21, 2014, at 4:49 PM, "BillHatVerizon" <garage_dba@verizon.net> > wrote: > > > > This is IDS12.10.TC4IE on windows server 2012 R2. > > What would cause a bunch of indexes to be recreated when the server boots > (and > > IDS starts)? > > This only happened once. > > I can’t find anything in ph_task on it so I’m curious why triggered > this. > > > > > > > ******************************************************************************* > > > 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. > > -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... --047d7bacb4467db06905039bf59a

If you can't read Base-64 fluently, then what Madison said was: The index is not recoverable until a checkpoint completes after the index > is created. I am guessing that did not occur. > > Sent from my iPad > > > On Sep 21, 2014, at 4:49 PM, "BillHatVerizon" <garage_dba@verizon.net> > wrote: > > > > This is IDS12.10.TC4IE on windows server 2012 R2. > > What would cause a bunch of indexes to be recreated when the server boots > (and > > IDS starts)? > > This only happened once. > > I canât find anything in ph_task on it so Iâm curious why triggered > this. > On Sun, Sep 21, 2014 at 2:58 PM, Madison Pruet <mpruet@us.ibm.com> wrote: > > > The index is not recoverable until a checkpoint completes after the index > is created. I am guessing that did not occur. > > Sent from my iPad > > > On Sep 21, 2014, at 4:49 PM, "BillHatVerizon" <garage_dba@verizon.net> > wrote: > > > > This is IDS12.10.TC4IE on windows server 2012 R2. > > What would cause a bunch of indexes to be recreated when the server boots > (and > > IDS starts)? > > This only happened once. > > I can’t find anything in ph_task on it so I’m curious why triggered > this. > > > > > > > ******************************************************************************* > > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2013.0521 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused." --089e01493e463f76d705039c2388

When you do a create index instead of logging (keeping track)= of each row added to the index, the entire index is logged as a sing= le record(action). This means if the system shutdown after the index = is created but before the next checkpoint. The index is drop and re-c= reated John F. Miller III STSM, Lead Architect mille= r3@us.ibm.com 503-747-1366 IBM Informix Dynamic Server (IDS) -----ids-bounces@iiug.org wrote: -----= >To: ids@iiug.org >From: "Jonathan Leffler" >Sent b= y: ids-bounces@iiug.org >Date: 09/21/2014 05:01PM >Subject: Re:= index rebuilds happen when server boots [33840] > >If you can= 't read Base-64 fluently, then what Madison said was: The >index is= not recoverable until a checkpoint completes after the index > > = is created. I am guessing that did not occur. > > Sent from my &= gt;iPad > > > On Sep 21, 2014, at 4:49 PM, "BillHatVerizon" &= gt;<garage=5Fdba@verizon.net> > wrote: > > > > This= is IDS12.10.TC4IE >on windows server 2012 R2. > > What would = cause a bunch of indexes >to be recreated when the server boots >= (and > > IDS starts)? > > >This only happened once. &= gt; > I can=E2t find anything in ph=5Ftask on it >so I=E2m curious= why triggered > this. > On Sun, Sep 21, 2014 at >2:58 PM, = Madison Pruet <mpruet@us.ibm.com> wrote: > > >DQpUaGUg= aW5kZXggaXMgbm90IHJlY292ZXJhYmxlIHVudGlsIGEgY2hlY2twb2ludCBjb >21wbGV= 0 > > >ZXMgYWZ0ZXIgdGhlIGluZGV4DQppcyBjcmVhdGVkLiAgSSBhbSBndW= Vzc2luZyB0aGF0I >GRpZCBu > > >b3Qgb2NjdXIuDQoNClNlbnQgZ= nJvbSBteSBpUGFkDQoNCj4gT24gU2VwIDIxLCAyMDE0L >CBhdCA0 > > = >OjQ5IFBNLCAiQmlsbEhhdFZlcml6b24iIDxnYXJhZ2VfZGJhQHZlcml6b24ubmV0Pg0Kd >3JvdGU6 > > >DQo+DQo+IFRoaXMgaXMgSURTMTIuMTAuVEM0SUUgb2= 4gd2luZG93cyBzZXJ2ZXIgMjAxM >iBSMi4N > > >Cj4gV2hhdCB3b= 3VsZCBjYXVzZSBhIGJ1bmNoIG9mIGluZGV4ZXMgdG8gYmUgcmVjcmVhd >GVkIHdo &g= t; > >ZW4gdGhlIHNlcnZlciBib290cw0KKGFuZA0KPiBJRFMgc3RhcnRzKT8NCj4= gVGhpcyBvb >mx5IGhh > > >cHBlbmVkIG9uY2UuDQo+IEkgY2Fuw6= LigqzihKJ0IGZpbmQgYW55dGhpbmcgaW4gcGhfd >GFzayBv > > >b= iBpdCBzbyBJw6LigqzihKJtIGN1cmlvdXMgd2h5IHRyaWdnZXJlZA0KdGhpcy4NCj4NC >= ;j4NCj4N > > >CioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio= qKioqKioqKioqKioqKioqK >ioqKioq > > >KioqKioqKioqKioqKi= oqKioqKioqKioNCg0KPiAgIEZvcnVtIE5vdGU6IFVzZSAiUmVwb >HkiIHRv > >IHBvc3QgYSByZXNwb25zZSBpbiB0aGUgZGlzY3Vzc2lvbiBmb3J1bS4NCj4=3D > = > > > > >********************************************= ************************* >********** > Forum Note: Use "Reply" t= o post a response in the >discussion forum. > > -- Jonatha= n Leffler ><jonathan.leffler@gmail.com> #include <disclaimer= .h> Guardian of >DBD::Informix - v2013.0521 - http://dbi.perl.org= "Blessed are we who >can laugh at ourselves, for we shall never cea= se to be amused." >--089e01493e463f76d705039c2388 >***********= ********************************************************** >*********= * Forum Note: Use "Reply" to post a response in the >discussion fo= rum.

In our situation, there was no index creation. The engine decided that = the indexes needed to be recreated and it did so. j. On Sep 21, 2014, at 8:09 PM, John Miller iii <miller3@us.ibm.com> wrote: > When you do a create index instead of logging (keeping track)=3D of = each=20 >=20 > row added to the index, the entire index is logged as a sing=3D le=20 >=20 > record(action). This means if the system shutdown after the index =3D=20= >=20 > is created but before the next checkpoint. The index is drop and=20 >=20 > re-c=3D reated=20 >=20 > John F. Miller III=20 >=20 > STSM, Lead Architect=20 >=20 > mille=3D r3@us.ibm.com=20 >=20 > 503-747-1366=20 >=20 > IBM Informix Dynamic Server (IDS)=20 >=20 > -----ids-bounces@iiug.org wrote: -----=3D=20 >=20 >> To: ids@iiug.org=20 >=20 >> From: "Jonathan Leffler"=20 >=20 >> Sent b=3D y: ids-bounces@iiug.org=20 >=20 >> Date: 09/21/2014 05:01PM=20 >=20 >> Subject: Re:=3D index rebuilds happen when server boots [33840]=20 >=20 >>=20 >=20 >> If you can=3D 't read Base-64 fluently, then what Madison said was: = The=20 >=20 >> index is=3D not recoverable until a checkpoint completes after the=20 >=20 > index=20 >=20 >>> =3D is created. I am guessing that did not occur. > > Sent from my=20= >=20 > &=3D gt;iPad > > > On Sep 21, 2014, at 4:49 PM, "BillHatVerizon"=20 >=20 > &=3D gt;<garage=3D5Fdba@verizon.net> > wrote: > > > > This=3D is=20 >=20 > IDS12.10.TC4IE=20 >=20 >> on windows server 2012 R2. > > What would =3D cause a bunch of = indexes=20 >=20 >> to be recreated when the server boots >=3D (and > > IDS starts)? > >=20= >=20 >> This only happened once. &=3D gt; > I can=3DE2t find anything in=20 >=20 > ph=3D5Ftask on it=20 >=20 >> so I=3DE2m curious=3D why triggered > this. > On Sun, Sep 21, 2014 at=20= >=20 >> 2:58 PM, =3D Madison Pruet <mpruet@us.ibm.com> wrote: > >=20 >=20 >> DQpUaGUg=3D=20 >=20 > aW5kZXggaXMgbm90IHJlY292ZXJhYmxlIHVudGlsIGEgY2hlY2twb2ludCBjb=20 >=20 >> 21wbGV=3D 0 > >=20 >=20 >> ZXMgYWZ0ZXIgdGhlIGluZGV4DQppcyBjcmVhdGVkLiAgSSBhbSBndW=3D=20 >=20 > Vzc2luZyB0aGF0I=20 >=20 >> GRpZCBu > >=20 >=20 >> b3Qgb2NjdXIuDQoNClNlbnQgZ=3D=20 >=20 > nJvbSBteSBpUGFkDQoNCj4gT24gU2VwIDIxLCAyMDE0L=20 >=20 >> CBhdCA0 > >=20 >=20 > =3D=20 >=20 >> OjQ5IFBNLCAiQmlsbEhhdFZlcml6b24iIDxnYXJhZ2VfZGJhQHZlcml6b24ubmV0Pg0Kd=20= >=20 >> 3JvdGU6 > >=20 >=20 >> DQo+DQo+IFRoaXMgaXMgSURTMTIuMTAuVEM0SUUgb2=3D=20 >=20 > 4gd2luZG93cyBzZXJ2ZXIgMjAxM=20 >=20 >> iBSMi4N > >=20 >=20 >> Cj4gV2hhdCB3b=3D=20 >=20 > 3VsZCBjYXVzZSBhIGJ1bmNoIG9mIGluZGV4ZXMgdG8gYmUgcmVjcmVhd=20 >=20 >> GVkIHdo &g=3D t; >=20 >=20 >> ZW4gdGhlIHNlcnZlciBib290cw0KKGFuZA0KPiBJRFMgc3RhcnRzKT8NCj4=3D=20 >=20 > gVGhpcyBvb=20 >=20 >> mx5IGhh > >=20 >=20 >> cHBlbmVkIG9uY2UuDQo+IEkgY2Fuw6=3D=20 >=20 > LigqzihKJ0IGZpbmQgYW55dGhpbmcgaW4gcGhfd=20 >=20 >> GFzayBv > >=20 >=20 >> b=3D=20 >=20 > iBpdCBzbyBJw6LigqzihKJtIGN1cmlvdXMgd2h5IHRyaWdnZXJlZA0KdGhpcy4NCj4NC=20= >=20 >> =3D ;j4NCj4N > >=20 >=20 >> CioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio=3D=20 >=20 > qKioqKioqKioqKioqKioqK=20 >=20 >> ioqKioq > >=20 >=20 >> KioqKioqKioqKioqKi=3D=20 >=20 > oqKioqKioqKioNCg0KPiAgIEZvcnVtIE5vdGU6IFVzZSAiUmVwb=20 >=20 >> HkiIHRv >=20 >=20 >> IHBvc3QgYSByZXNwb25zZSBpbiB0aGUgZGlzY3Vzc2lvbiBmb3J1bS4NCj4=3D3D > =3D = >=20 >=20 >>=20 >=20 >>>=20 >=20 >> ********************************************=3D=20 >=20 > *************************=20 >=20 >> ********** > Forum Note: Use "Reply" t=3D o post a response in the=20 >=20 >> discussion forum. > > -- Jonatha=3D n Leffler=20 >=20 >> <jonathan.leffler@gmail.com> #include <disclaimer=3D .h> Guardian of=20= >=20 >> DBD::Informix - v2013.0521 - http://dbi.perl.org=3D "Blessed are we = who=20 >=20 >> can laugh at ourselves, for we shall never cea=3D se to be amused."=20= >=20 >> --089e01493e463f76d705039c2388=20 >=20 >> ***********=3D=20 >=20 > **********************************************************=20 >=20 >> *********=3D * Forum Note: Use "Reply" to post a response in the=20 >=20 >> discussion fo=3D rum.=20 >=20 >=20 > = **************************************************************************= *****=20 > Forum Note: Use "Reply" to post a response in the discussion forum.=20= >=20

Did you drop an index? the same thing can hap= pen with a drop index. I would check your logical log records during= this time period for a drop or create index. John F. Miller III= STSM, Lead Architect miller3@us.ibm.com 503-747-1366 IBM Info= rmix Dynamic Server (IDS) -----ids-bo= unces@iiug.org wrote: ----- >To: ids@iiug.org >From:= "Jack Parker" >Sent by: ids-bounces@iiug.org >Date: 09/21/201= 4 05:17PM >Subject: Re: index rebuilds happen when server boots [338= 42] > >In our situation, there was no index creation. The engin= e decided >that =3D the indexes needed to be recreated and it did so= . j. On >Sep 21, 2014, at 8:09 PM, John Miller iii <miller3@us.= ibm.com> wrote: > > When you do a create index instead of logg= ing (keeping track)=3D3D >of =3D each=3D20 >=3D20 > row adde= d to the index, the entire index is >logged as a sing=3D3D le=3D20 &= gt;=3D20 > record(action). This means if the >system shutdown aft= er the index =3D3D=3D20=3D >=3D20 > is created but >before t= he next checkpoint. The index is drop and=3D20 >=3D20 > re-c=3D3D>reated=3D20 >=3D20 > John F. Miller III=3D20 >=3D20 >= STSM, Lead >Architect=3D20 >=3D20 > mille=3D3D r3@us.ibm.com= =3D20 >=3D20 > >503-747-1366=3D20 >=3D20 > IBM Inform= ix Dynamic Server (IDS)=3D20 >=3D20 >> -----ids-bounces@iiug.o= rg wrote: -----=3D3D=3D20 >=3D20 >> To: >ids@iiug.org=3D20= >=3D20 >> From: "Jonathan Leffler"=3D20 >=3D20 >> Se= nt >b=3D3D y: ids-bounces@iiug.org=3D20 >=3D20 >> Date: 09= /21/2014 05:01PM=3D20 > >=3D20 >> Subject: Re:=3D3D index r= ebuilds happen when server boots >[33840]=3D20 >=3D20 >>= =3D20 >=3D20 >> If you can=3D3D 't read Base-64 >fluently,= then what Madison said was: =3D The=3D20 >=3D20 >> index is=3D= 3D >not recoverable until a checkpoint completes after the=3D20 >= =3D20 > >index=3D20 >=3D20 >>> =3D3D is created. I = am guessing that did not occur. >> > Sent from my=3D20=3D >= ;=3D20 > &=3D3D gt;iPad > > > On Sep 21, 2014, at >4= :49 PM, "BillHatVerizon"=3D20 >=3D20 > &=3D3D >gt;<gar= age=3D3D5Fdba@verizon.net> > wrote: > > > > This=3D3D is= =3D20 >=3D20 >> IDS12.10.TC4IE=3D20 >=3D20 >> on wi= ndows server 2012 R2. > > What >would =3D3D cause a bunch of = =3D indexes=3D20 >=3D20 >> to be recreated >when the serv= er boots >=3D3D (and > > IDS starts)? > >=3D20=3D >=3D2= 0 >> >This only happened once. &=3D3D gt; > I can=3D3DE= 2t find anything in=3D20 >>=3D20 > ph=3D3D5Ftask on it=3D20 &= gt;=3D20 >> so I=3D3DE2m curious=3D3D why >triggered > this= . > On Sun, Sep 21, 2014 at=3D20=3D >=3D20 >> 2:58 PM, &g= t;=3D3D Madison Pruet <mpruet@us.ibm.com> wrote: > >=3D20 >= =3D20 >> >DQpUaGUg=3D3D=3D20 >=3D20 > >aW5kZXgga= XMgbm90IHJlY292ZXJhYmxlIHVudGlsIGEgY2hlY2twb2ludCBjb=3D20 >>=3D20 = >> 21wbGV=3D3D 0 > >=3D20 >=3D20 >> >ZXMgYWZ0= ZXIgdGhlIGluZGV4DQppcyBjcmVhdGVkLiAgSSBhbSBndW=3D3D=3D20 >=3D20 >>Vzc2luZyB0aGF0I=3D20 >=3D20 >> GRpZCBu > >=3D20 >= ;=3D20 >> >b3Qgb2NjdXIuDQoNClNlbnQgZ=3D3D=3D20 >=3D20 >= ; >nJvbSBteSBpUGFkDQoNCj4gT24gU2VwIDIxLCAyMDE0L=3D20 >=3D20 >= > CBhdCA0 > >>=3D20 >=3D20 > =3D3D=3D20 >=3D20 = >> >OjQ5IFBNLCAiQmlsbEhhdFZlcml6b24iIDxnYXJhZ2VfZGJhQHZlcml6b24= ubmV0Pg0Kd >=3D20=3D >=3D20 >> 3JvdGU6 > >=3D20 &g= t;=3D20 >> >DQo+DQo+IFRoaXMgaXMgSURTMTIuMTAuVEM0SUUgb2=3D3D=3D= 20 >=3D20 > >4gd2luZG93cyBzZXJ2ZXIgMjAxM=3D20 >=3D20 >= ;> iBSMi4N > >=3D20 >=3D20 >> >Cj4gV2hhdCB3b=3D3D= =3D20 >=3D20 > >3VsZCBjYXVzZSBhIGJ1bmNoIG9mIGluZGV4ZXMgdG8gYm= UgcmVjcmVhd=3D20 >=3D20 >> >GVkIHdo &g=3D3D t; >=3D= 20 >=3D20 >> >ZW4gdGhlIHNlcnZlciBib290cw0KKGFuZA0KPiBJRFMg= c3RhcnRzKT8NCj4=3D3D=3D20 >>=3D20 > gVGhpcyBvb=3D20 >=3D20= >> mx5IGhh > >=3D20 >=3D20 >> >cHBlbmVkIG9uY= 2UuDQo+IEkgY2Fuw6=3D3D=3D20 >=3D20 > >LigqzihKJ0IGZpbmQgYW55d= GhpbmcgaW4gcGhfd=3D20 >=3D20 >> GFzayBv > >=3D20 >&g= t;=3D20 >> b=3D3D=3D20 >=3D20 > >iBpdCBzbyBJw6LigqzihK= JtIGN1cmlvdXMgd2h5IHRyaWdnZXJlZA0KdGhpcy4NCj4NC=3D >20=3D >=3D20= >> =3D3D ;j4NCj4N > >=3D20 >=3D20 >> >CioqKi= oqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio=3D3D=3D20 >=3D20 > >= ;qKioqKioqKioqKioqKioqK=3D20 >=3D20 >> ioqKioq > >=3D20 &= gt;=3D20 >> >KioqKioqKioqKioqKi=3D3D=3D20 >=3D20 > = >oqKioqKioqKioNCg0KPiAgIEZvcnVtIE5vdGU6IFVzZSAiUmVwb=3D20 >=3D20 &g= t;> >HkiIHRv >=3D20 >=3D20 >> >IHBvc3QgYSByZXN= wb25zZSBpbiB0aGUgZGlzY3Vzc2lvbiBmb3J1bS4NCj4=3D3D3D > >=3D3D =3D = >=3D20 >=3D20 >>=3D20 >=3D20 >>>=3D20 >=3D2= 0 >> >********************************************=3D3D=3D20 = >=3D20 > >*************************=3D20 >=3D20 >> = ********** > Forum Note: Use >"Reply" t=3D3D o post a response in = the=3D20 >=3D20 >> discussion forum. >> > -- Jonatha= =3D3D n Leffler=3D20 >=3D20 >> <jonathan.leffler@gmail.com>= ; >#include <disclaimer=3D3D .h> Guardian of=3D20=3D >=3D2= 0 >> DBD::Informix >- v2013.0521 - http://dbi.perl.org=3D3D "B= lessed are we =3D who=3D20 >=3D20 > >> can laugh at oursel= ves, for we shall never cea=3D3D se to be >amused."=3D20=3D >=3D= 20 >> --089e01493e463f76d705039c2388=3D20 >=3D20 >> &g= t;***********=3D3D=3D20 >=3D20 > >***************************= *******************************=3D20 >=3D20 >>> *********= =3D3D * Forum Note: Use "Reply" to post a response in >the=3D20 >= =3D20 >> discussion fo=3D3D rum.=3D20 >=3D20 >=3D20 > = =3D >****************************************************************= ***** >*****=3D *****=3D20 > Forum Note: Use "Reply" to post a r= esponse in the >discussion forum.=3D20=3D >=3D20 >********= ************************************************************* >******= **** Forum Note: Use "Reply" to post a response in the >discussion= forum.

Nothing of that sort, Windows ran out of some kind of Buffer memory and = no new processes could be created by Informix (i.e. user sessions). = When the machine was finally rebooted, the engine decided that it needed = to rebuild indexes. No DDL executed at all. j. On Sep 21, 2014, at 9:03 PM, John Miller iii <miller3@us.ibm.com> wrote: > Did you drop an index? the same thing can hap=3D pen with a drop=20 >=20 > index.=20 >=20 > I would check your logical log records during=3D this time period for = a=20 >=20 > drop or create index.=20 >=20 > John F. Miller III=3D=20 >=20 > STSM, Lead Architect=20 >=20 > miller3@us.ibm.com=20 >=20 > 503-747-1366=20 >=20 > IBM Info=3D rmix Dynamic Server (IDS)=20 >=20 > -----ids-bo=3D unces@iiug.org wrote: -----=20 >=20 >> To: ids@iiug.org=20 >=20 >> From:=3D "Jack Parker"=20 >=20 >> Sent by: ids-bounces@iiug.org=20 >=20 >> Date: 09/21/201=3D 4 05:17PM=20 >=20 >> Subject: Re: index rebuilds happen when server boots [338=3D 42]=20 >=20 >>=20 >=20 >> In our situation, there was no index creation. The engin=3D e decided=20= >=20 >> that =3D3D the indexes needed to be recreated and it did so=3D . j. = On=20 >=20 >> Sep 21, 2014, at 8:09 PM, John Miller iii <miller3@us.=3D ibm.com>=20 >=20 > wrote:=20 >=20 >>> When you do a create index instead of logg=3D ing (keeping=20 >=20 > track)=3D3D3D=20 >=20 >> of =3D3D each=3D3D20 >=3D3D20 > row adde=3D d to the index, the = entire index=20 >=20 > is=20 >=20 >> logged as a sing=3D3D3D le=3D3D20 &=3D gt;=3D3D20 > record(action). = This=20 >=20 > means if the=20 >=20 >> system shutdown aft=3D er the index =3D3D3D=3D3D20=3D3D >=3D3D20 > is = created=20 >=20 > but=20 >=20 >> before t=3D he next checkpoint. The index is drop and=3D3D20 >=3D3D20 = >=20 >=20 > re-c=3D3D3D>reated=3D3D20 >=3D3D20 > John F. Miller III=3D3D20 >=3D3D20 = >=3D STSM,=20 >=20 > Lead=20 >=20 >> Architect=3D3D20 >=3D3D20 > mille=3D3D3D r3@us.ibm.com=3D =3D3D20 = >=3D3D20 >=20 >=20 >> 503-747-1366=3D3D20 >=3D3D20 > IBM Inform=3D ix Dynamic Server = (IDS)=3D3D20=20 >=20 >> =3D3D20=20 >=20 >>> -----ids-bounces@iiug.o=3D rg wrote: -----=3D3D3D=3D3D20 >=3D3D20 >> = To:=20 >=20 >> ids@iiug.org=3D3D20=3D >=3D3D20 >> From: "Jonathan Leffler"=3D3D20 = >=3D3D20 >>=20 >=20 > Se=3D nt=20 >=20 >> b=3D3D3D y: ids-bounces@iiug.org=3D3D20 >=3D3D20 >> Date: 09=3D = /21/2014=20 >=20 > 05:01PM=3D3D20=20 >=20 >>> =3D3D20 >> Subject: Re:=3D3D3D index r=3D ebuilds happen when server=20= >=20 > boots=20 >=20 >> [33840]=3D3D20 >=3D3D20 >>=3D =3D3D20 >=3D3D20 >> If you can=3D3D3D = 't read=20 >=20 > Base-64=20 >=20 >> fluently,=3D then what Madison said was: =3D3D The=3D3D20 >=3D3D20 >> = index=20 >=20 > is=3D3D=3D 3D=20 >=20 >> not recoverable until a checkpoint completes after the=3D3D20 >=3D = =3D3D20=20 >=20 >>=20 >=20 >> index=3D3D20 >=3D3D20 >>> =3D3D3D is created. I =3D am guessing that = did not=20 >=20 > occur.=20 >=20 >>>> Sent from my=3D3D20=3D3D >=3D ;=3D3D20 > &=3D3D3D gt;iPad > > > On = Sep 21,=20 >=20 > 2014, at=20 >=20 >> 4=3D :49 PM, "BillHatVerizon"=3D3D20 >=3D3D20 > &=3D3D3D=20 >=20 >> gt;<gar=3D age=3D3D3D5Fdba@verizon.net> > wrote: > > > > This=3D3D3D = is=3D=20 >=20 > =3D3D20 >=3D3D20=20 >=20 >>> IDS12.10.TC4IE=3D3D20 >=3D3D20 >> on wi=3D ndows server 2012 R2. > > = What=20 >=20 >> would =3D3D3D cause a bunch of =3D =3D3D indexes=3D3D20 >=3D3D20 >> = to be=20 >=20 > recreated=20 >=20 >> when the serv=3D er boots >=3D3D3D (and > > IDS starts)? > >=3D3D20=3D3= D=20 >=20 >> =3D3D2=3D 0 >>=20 >=20 >> This only happened once. &=3D3D3D gt; > I can=3D3D3DE=3D 2t find = anything=20 >=20 > in=3D3D20=20 >=20 >>> =3D3D20 > ph=3D3D3D5Ftask on it=3D3D20 &=3D gt;=3D3D20 >> so = I=3D3D3DE2m=20 >=20 > curious=3D3D3D why=20 >=20 >> triggered > this=3D . > On Sun, Sep 21, 2014 at=3D3D20=3D3D >=3D3D20 = >> 2:58=20 >=20 > PM,=20 >=20 > &g=3D t;=3D3D3D Madison Pruet <mpruet@us.ibm.com> wrote: > >=3D3D20 >=3D= =3D3D20=20 >=20 >>>=20 >=20 >> DQpUaGUg=3D3D3D=3D3D20 >=3D3D20 >=20 >=20 >> aW5kZXgga=3D = XMgbm90IHJlY292ZXJhYmxlIHVudGlsIGEgY2hlY2twb2ludCBjb=3D3D20=20 >=20 >>> =3D3D20 =3D >> 21wbGV=3D3D3D 0 > >=3D3D20 >=3D3D20 >>=20 >=20 >> ZXMgYWZ0=3D ZXIgdGhlIGluZGV4DQppcyBjcmVhdGVkLiAgSSBhbSBndW=3D3D3D=3D3D2= 0=20 >=20 >> =3D3D20 >>Vzc2luZyB0aGF0I=3D3D20 >=3D3D20 >> GRpZCBu > >=3D3D20 >=3D = ;=3D3D20 >>=20 >=20 >> b3Qgb2NjdXIuDQoNClNlbnQgZ=3D3D3D=3D3D20 >=3D3D20 >=3D ;=20 >=20 >> nJvbSBteSBpUGFkDQoNCj4gT24gU2VwIDIxLCAyMDE0L=3D3D20 >=3D3D20 >=3D > = CBhdCA0=20 >=20 >>=20 >=20 >>> =3D3D20 >=3D3D20 > =3D3D3D=3D3D20 >=3D3D20 =3D >>=20 >=20 >> OjQ5IFBNLCAiQmlsbEhhdFZlcml6b24iIDxnYXJhZ2VfZGJhQHZlcml6b24=3D=20 >=20 > ubmV0Pg0Kd=20 >=20 >> =3D3D20=3D3D >=3D3D20 >> 3JvdGU6 > >=3D3D20 &g=3D t;=3D3D20 >>=20 >=20 >> DQo+DQo+IFRoaXMgaXMgSURTMTIuMTAuVEM0SUUgb2=3D3D3D=3D3D=3D 20 >=3D3D20 = >=20 >=20 >> 4gd2luZG93cyBzZXJ2ZXIgMjAxM=3D3D20 >=3D3D20 >=3D ;> iBSMi4N > >=3D3D20 = >=3D3D20=20 >=20 >>>=20 >=20 >> Cj4gV2hhdCB3b=3D3D3D=3D =3D3D20 >=3D3D20 >=20 >=20 >> 3VsZCBjYXVzZSBhIGJ1bmNoIG9mIGluZGV4ZXMgdG8gYm=3D UgcmVjcmVhd=3D3D20=20= >=20 >> =3D3D20 >>=20 >=20 >> GVkIHdo &g=3D3D3D t; >=3D3D=3D 20 >=3D3D20 >>=20 >=20 >> ZW4gdGhlIHNlcnZlciBib290cw0KKGFuZA0KPiBJRFMg=3D=20 >=20 > c3RhcnRzKT8NCj4=3D3D3D=3D3D20=20 >=20 >>> =3D3D20 > gVGhpcyBvb=3D3D20 >=3D3D20=3D >> mx5IGhh > >=3D3D20 >=3D3D20= >>=20 >=20 >> cHBlbmVkIG9uY=3D 2UuDQo+IEkgY2Fuw6=3D3D3D=3D3D20 >=3D3D20 >=20 >=20 >> LigqzihKJ0IGZpbmQgYW55d=3D GhpbmcgaW4gcGhfd=3D3D20 >=3D3D20 >> = GFzayBv >=20 >=20 >> =3D3D20=20 >=20 >> &g=3D t;=3D3D20 >> b=3D3D3D=3D3D20 >=3D3D20 >=20 >=20 >> iBpdCBzbyBJw6LigqzihK=3D=20 >=20 > JtIGN1cmlvdXMgd2h5IHRyaWdnZXJlZA0KdGhpcy4NCj4NC=3D3D=20 >=20 >> 20=3D3D >=3D3D20=3D >> =3D3D3D ;j4NCj4N > >=3D3D20 >=3D3D20 >>=20 >=20 >> CioqKi=3D oqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio=3D3D3D=3D3D20 = >=3D3D20 >=20 >=20 >> =3D ;qKioqKioqKioqKioqKioqK=3D3D20 >=3D3D20 >> ioqKioq > >=3D3D20 &=3D = gt;=3D3D20=20 >=20 >>>=20 >=20 >> KioqKioqKioqKioqKi=3D3D3D=3D3D20 >=3D3D20 >=20 >=20 > =3D >oqKioqKioqKioNCg0KPiAgIEZvcnVtIE5vdGU6IFVzZSAiUmVwb=3D3D20 >=3D3D20= &g=3D=20 >=20 > t;>=20 >=20 >> HkiIHRv >=3D3D20 >=3D3D20 >>=20 >=20 >> IHBvc3QgYSByZXN=3D = wb25zZSBpbiB0aGUgZGlzY3Vzc2lvbiBmb3J1bS4NCj4=3D3D3D3D=20 >=20 >>=20 >=20 >> =3D3D3D =3D3D =3D >=3D3D20 >=3D3D20 >>=3D3D20 >=3D3D20 >>>=3D3D20 = >=3D3D2=3D 0 >>=20 >=20 >> ********************************************=3D3D3D=3D3D20 =3D >=3D3D20= >=20 >=20 >> *************************=3D3D20 >=3D3D20 >> =3D ********** > Forum = Note:=20 >=20 > Use=20 >=20 >> "Reply" t=3D3D3D o post a response

There no indexes being built that I know of. The only think I did was set RTO_SERVER_RESTART 240 in the onconfig . Maybe he buffers did not flush in time? -----Original Message----- From: John Miller iii Sent: Sunday, September 21, 2014 7:09 PM To: ids@iiug.org Subject: Re: Re: index rebuilds happen when server boots [33841] When you do a create index instead of logging (keeping track)= of each row added to the index, the entire index is logged as a sing= le record(action). This means if the system shutdown after the index = is created but before the next checkpoint. The index is drop and re-c= reated John F. Miller III STSM, Lead Architect mille= r3@us.ibm.com 503-747-1366 IBM Informix Dynamic Server (IDS) -----ids-bounces@iiug.org wrote: -----= >To: ids@iiug.org >From: "Jonathan Leffler" >Sent b= y: ids-bounces@iiug.org >Date: 09/21/2014 05:01PM >Subject: Re:= index rebuilds happen when server boots [33840] > >If you can= 't read Base-64 fluently, then what Madison said was: The >index is= not recoverable until a checkpoint completes after the index > > = is created. I am guessing that did not occur. > > Sent from my &= gt;iPad > > > On Sep 21, 2014, at 4:49 PM, "BillHatVerizon" &= gt;<garage=5Fdba@verizon.net> > wrote: > > > > This= is IDS12.10.TC4IE >on windows server 2012 R2. > > What would = cause a bunch of indexes >to be recreated when the server boots >= (and > > IDS starts)? > > >This only happened once. &= gt; > I can=E2t find anything in ph=5Ftask on it >so I=E2m curious= why triggered > this. > On Sun, Sep 21, 2014 at >2:58 PM, = Madison Pruet <mpruet@us.ibm.com> wrote: > > >DQpUaGUg= aW5kZXggaXMgbm90IHJlY292ZXJhYmxlIHVudGlsIGEgY2hlY2twb2ludCBjb >21wbGV= 0 > > >ZXMgYWZ0ZXIgdGhlIGluZGV4DQppcyBjcmVhdGVkLiAgSSBhbSBndW= Vzc2luZyB0aGF0I >GRpZCBu > > >b3Qgb2NjdXIuDQoNClNlbnQgZ= nJvbSBteSBpUGFkDQoNCj4gT24gU2VwIDIxLCAyMDE0L >CBhdCA0 > > = >OjQ5IFBNLCAiQmlsbEhhdFZlcml6b24iIDxnYXJhZ2VfZGJhQHZlcml6b24ubmV0Pg0Kd >3JvdGU6 > > >DQo+DQo+IFRoaXMgaXMgSURTMTIuMTAuVEM0SUUgb2= 4gd2luZG93cyBzZXJ2ZXIgMjAxM >iBSMi4N > > >Cj4gV2hhdCB3b= 3VsZCBjYXVzZSBhIGJ1bmNoIG9mIGluZGV4ZXMgdG8gYmUgcmVjcmVhd >GVkIHdo &g= t; > >ZW4gdGhlIHNlcnZlciBib290cw0KKGFuZA0KPiBJRFMgc3RhcnRzKT8NCj4= gVGhpcyBvb >mx5IGhh > > >cHBlbmVkIG9uY2UuDQo+IEkgY2Fuw6= LigqzihKJ0IGZpbmQgYW55dGhpbmcgaW4gcGhfd >GFzayBv > > >b= iBpdCBzbyBJw6LigqzihKJtIGN1cmlvdXMgd2h5IHRyaWdnZXJlZA0KdGhpcy4NCj4NC >= ;j4NCj4N > > >CioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio= qKioqKioqKioqKioqKioqK >ioqKioq > > >KioqKioqKioqKioqKi= oqKioqKioqKioNCg0KPiAgIEZvcnVtIE5vdGU6IFVzZSAiUmVwb >HkiIHRv > >IHBvc3QgYSByZXNwb25zZSBpbiB0aGUgZGlzY3Vzc2lvbiBmb3J1bS4NCj4=3D > = > > > > >********************************************= ************************* >********** > Forum Note: Use "Reply" t= o post a response in the >discussion forum. > > -- Jonatha= n Leffler ><jonathan.leffler@gmail.com> #include <disclaimer= .h> Guardian of >DBD::Informix - v2013.0521 - http://dbi.perl.org= "Blessed are we who >can laugh at ourselves, for we shall never cea= se to be amused." >--089e01493e463f76d705039c2388 >***********= ********************************************************** >*********= * Forum Note: Use "Reply" to post a response in the >discussion fo= rum. ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

Maybe that is what happened here. I thought that perhaps the engine had the last date built for each index and just rebuilt them if they were x days old. I just realized that I installed Windows patches that night so maybe that had some side effect. Maybe the OS killed the IDS without waiting for the service to stop. -----Original Message----- From: Jack Parker Sent: Sunday, September 21, 2014 8:21 PM To: ids@iiug.org Subject: Re: index rebuilds happen when server boots [33844] Nothing of that sort, Windows ran out of some kind of Buffer memory and = no new processes could be created by Informix (i.e. user sessions). = When the machine was finally rebooted, the engine decided that it needed = to rebuild indexes. No DDL executed at all. j. On Sep 21, 2014, at 9:03 PM, John Miller iii <miller3@us.ibm.com> wrote: > Did you drop an index? the same thing can hap=3D pen with a drop=20 >=20 > index.=20 >=20 > I would check your logical log records during=3D this time period for = a=20 >=20 > drop or create index.=20 >=20 > John F. Miller III=3D=20 >=20 > STSM, Lead Architect=20 >=20 > miller3@us.ibm.com=20 >=20 > 503-747-1366=20 >=20 > IBM Info=3D rmix Dynamic Server (IDS)=20 >=20 > -----ids-bo=3D unces@iiug.org wrote: -----=20 >=20 >> To: ids@iiug.org=20 >=20 >> From:=3D "Jack Parker"=20 >=20 >> Sent by: ids-bounces@iiug.org=20 >=20 >> Date: 09/21/201=3D 4 05:17PM=20 >=20 >> Subject: Re: index rebuilds happen when server boots [338=3D 42]=20 >=20 >>=20 >=20 >> In our situation, there was no index creation. The engin=3D e decided=20= >=20 >> that =3D3D the indexes needed to be recreated and it did so=3D . j. = On=20 >=20 >> Sep 21, 2014, at 8:09 PM, John Miller iii <miller3@us.=3D ibm.com>=20 >=20 > wrote:=20 >=20 >>> When you do a create index instead of logg=3D ing (keeping=20 >=20 > track)=3D3D3D=20 >=20 >> of =3D3D each=3D3D20 >=3D3D20 > row adde=3D d to the index, the = entire index=20 >=20 > is=20 >=20 >> logged as a sing=3D3D3D le=3D3D20 &=3D gt;=3D3D20 > record(action). = This=20 >=20 > means if the=20 >=20 >> system shutdown aft=3D er the index =3D3D3D=3D3D20=3D3D >=3D3D20 > is = created=20 >=20 > but=20 >=20 >> before t=3D he next checkpoint. The index is drop and=3D3D20 >=3D3D20 = >=20 >=20 > re-c=3D3D3D>reated=3D3D20 >=3D3D20 > John F. Miller III=3D3D20 >=3D3D20 = >=3D STSM,=20 >=20 > Lead=20 >=20 >> Architect=3D3D20 >=3D3D20 > mille=3D3D3D r3@us.ibm.com=3D =3D3D20 = >=3D3D20 >=20 >=20 >> 503-747-1366=3D3D20 >=3D3D20 > IBM Inform=3D ix Dynamic Server = (IDS)=3D3D20=20 >=20 >> =3D3D20=20 >=20 >>> -----ids-bounces@iiug.o=3D rg wrote: -----=3D3D3D=3D3D20 >=3D3D20 >> = To:=20 >=20 >> ids@iiug.org=3D3D20=3D >=3D3D20 >> From: "Jonathan Leffler"=3D3D20 = >=3D3D20 >>=20 >=20 > Se=3D nt=20 >=20 >> b=3D3D3D y: ids-bounces@iiug.org=3D3D20 >=3D3D20 >> Date: 09=3D = /21/2014=20 >=20 > 05:01PM=3D3D20=20 >=20 >>> =3D3D20 >> Subject: Re:=3D3D3D index r=3D ebuilds happen when server=20= >=20 > boots=20 >=20 >> [33840]=3D3D20 >=3D3D20 >>=3D =3D3D20 >=3D3D20 >> If you can=3D3D3D = 't read=20 >=20 > Base-64=20 >=20 >> fluently,=3D then what Madison said was: =3D3D The=3D3D20 >=3D3D20 >> = index=20 >=20 > is=3D3D=3D 3D=20 >=20 >> not recoverable until a checkpoint completes after the=3D3D20 >=3D = =3D3D20=20 >=20 >>=20 >=20 >> index=3D3D20 >=3D3D20 >>> =3D3D3D is created. I =3D am guessing that = did not=20 >=20 > occur.=20 >=20 >>>> Sent from my=3D3D20=3D3D >=3D ;=3D3D20 > &=3D3D3D gt;iPad > > > On = Sep 21,=20 >=20 > 2014, at=20 >=20 >> 4=3D :49 PM, "BillHatVerizon"=3D3D20 >=3D3D20 > &=3D3D3D=20 >=20 >> gt;<gar=3D age=3D3D3D5Fdba@verizon.net> > wrote: > > > > This=3D3D3D = is=3D=20 >=20 > =3D3D20 >=3D3D20=20 >=20 >>> IDS12.10.TC4IE=3D3D20 >=3D3D20 >> on wi=3D ndows server 2012 R2. > > = What=20 >=20 >> would =3D3D3D cause a bunch of =3D =3D3D indexes=3D3D20 >=3D3D20 >> = to be=20 >=20 > recreated=20 >=20 >> when the serv=3D er boots >=3D3D3D (and > > IDS starts)? > >=3D3D20=3D3= D=20 >=20 >> =3D3D2=3D 0 >>=20 >=20 >> This only happened once. &=3D3D3D gt; > I can=3D3D3DE=3D 2t find = anything=20 >=20 > in=3D3D20=20 >=20 >>> =3D3D20 > ph=3D3D3D5Ftask on it=3D3D20 &=3D gt;=3D3D20 >> so = I=3D3D3DE2m=20 >=20 > curious=3D3D3D why=20 >=20 >> triggered > this=3D . > On Sun, Sep 21, 2014 at=3D3D20=3D3D >=3D3D20 = >> 2:58=20 >=20 > PM,=20 >=20 > &g=3D t;=3D3D3D Madison Pruet <mpruet@us.ibm.com> wrote: > >=3D3D20 >=3D= =3D3D20=20 >=20 >>>=20 >=20 >> DQpUaGUg=3D3D3D=3D3D20 >=3D3D20 >=20 >=20 >> aW5kZXgga=3D = XMgbm90IHJlY292ZXJhYmxlIHVudGlsIGEgY2hlY2twb2ludCBjb=3D3D20=20 >=20 >>> =3D3D20 =3D >> 21wbGV=3D3D3D 0 > >=3D3D20 >=3D3D20 >>=20 >=20 >> ZXMgYWZ0=3D ZXIgdGhlIGluZGV4DQppcyBjcmVhdGVkLiAgSSBhbSBndW=3D3D3D=3D3D2= 0=20 >=20 >> =3D3D20 >>Vzc2luZyB0aGF0I=3D3D20 >=3D3D20 >> GRpZCBu > >=3D3D20 >=3D = ;=3D3D20 >>=20 >=20 >> b3Qgb2NjdXIuDQoNClNlbnQgZ=3D3D3D=3D3D20 >=3D3D20 >=3D ;=20 >=20 >> nJvbSBteSBpUGFkDQoNCj4gT24gU2VwIDIxLCAyMDE0L=3D3D20 >=3D3D20 >=3D > = CBhdCA0=20 >=20 >>=20 >=20 >>> =3D3D20 >=3D3D20 > =3D3D3D=3D3D20 >=3D3D20 =3D >>=20 >=20 >> OjQ5IFBNLCAiQmlsbEhhdFZlcml6b24iIDxnYXJhZ2VfZGJhQHZlcml6b24=3D=20 >=20 > ubmV0Pg0Kd=20 >=20 >> =3D3D20=3D3D >=3D3D20 >> 3JvdGU6 > >=3D3D20 &g=3D t;=3D3D20 >>=20 >=20 >> DQo+DQo+IFRoaXMgaXMgSURTMTIuMTAuVEM0SUUgb2=3D3D3D=3D3D=3D 20 >=3D3D20 = >=20 >=20 >> 4gd2luZG93cyBzZXJ2ZXIgMjAxM=3D3D20 >=3D3D20 >=3D ;> iBSMi4N > >=3D3D20 = >=3D3D20=20 >=20 >>>=20 >=20 >> Cj4gV2hhdCB3b=3D3D3D=3D =3D3D20 >=3D3D20 >=20 >=20 >> 3VsZCBjYXVzZSBhIGJ1bmNoIG9mIGluZGV4ZXMgdG8gYm=3D UgcmVjcmVhd=3D3D20=20= >=20 >> =3D3D20 >>=20 >=20 >> GVkIHdo &g=3D3D3D t; >=3D3D=3D 20 >=3D3D20 >>=20 >=20 >> ZW4gdGhlIHNlcnZlciBib290cw0KKGFuZA0KPiBJRFMg=3D=20 >=20 > c3RhcnRzKT8NCj4=3D3D3D=3D3D20=20 >=20 >>> =3D3D20 > gVGhpcyBvb=3D3D20 >=3D3D20=3D >> mx5IGhh > >=3D3D20 >=3D3D20= >>=20 >=20 >> cHBlbmVkIG9uY=3D 2UuDQo+IEkgY2Fuw6=3D3D3D=3D3D20 >=3D3D20 >=20 >=20 >> LigqzihKJ0IGZpbmQgYW55d=3D GhpbmcgaW4gcGhfd=3D3D20 >=3D3D20 >> = GFzayBv >=20 >=20 >> =3D3D20=20 >=20 >> &g=3D t;=3D3D20 >> b=3D3D3D=3D3D20 >=3D3D20 >=20 >=20 >> iBpdCBzbyBJw6LigqzihK=3D=20 >=20 > JtIGN1cmlvdXMgd2h5IHRyaWdnZXJlZA0KdGhpcy4NCj4NC=3D3D=20 >=20 >> 20=3D3D >=3D3D20=3D >> =3D3D3D ;j4NCj4N > >=3D3D20 >=3D3D20 >>=20 >=20 >> CioqKi=3D oqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio=3D3D3D=3D3D20 = >=3D3D20 >=20 >=20 >> =3D ;qKioqKioqKioqKioqKioqK=3D3D20 >=3D3D20 >> ioqKioq > >=3D3D20 &=3D = gt;=3D3D20=20 >=20 >>>=20 >=20 >> KioqKioqKioqKioqKi=3D3D3D=3D3D20 >=3D3D20 >=20 >=20 > =3D >oqKioqKioqKioNCg0KPiAgIEZvcnVtIE5vdGU6IFVzZSAiUmVwb=3D3D20 >=3D3D20= &g=3D=20 >=20 > t;>=20 >=20 >> Hki