reduce size of root dbspace

How to reduce size of root dbspace in Informix 11.7 ? Currently I have moved logical logs, physical logs, databases, temporary dbspace all out of root space. Currently only 6% of my root dbspace is used after importing required databases and there is slim chance that the database will grow in size as it is for evaluation only and I can reduce crap data if more space is required. Will onparams work for this ? How exactly do specify rootdbs to be reduce ? Also in windows root dbspace pathname is like D:\\\\Informix\\\\olr_te~1\\\\dbspaces\\\\rootdbs.000 For other dbspaces it is showing properly as D:\\\\Informix\\\\olr_test1\\\\dbspaces\\\\<dbspacename without suffix ".000" appended to it> When specifying is the rootdbs to be specified as rootdbs or rootdbs.000 Regards Prajakta

Hello again, Prajakta, As you may already know, I'm also testing 11.70.TC5DE (32-bit WinVista SP2). If I recall correctly, you're testing FC5 (64-bit)? >How to reduce size of root dbspace in Informix 11.7 ? >Currently I have moved logical logs, physical logs, databases, temporary >dbspace all out of root space. >Currently only 6% of my root dbspace is used after importing required >databases and there is slim chance that the database will grow in size as it >is for evaluation only and I can reduce crap data if more space is required. IDS is new to me, but FWIW: Although you're just testing 11.70, my common sense tells me that you should keep the logs in rootdbs and never shrink its size because logs can grow very large over time, the server also needs additional space for other internal administration, etc. When installing 11.70, I'm assuming you chose to define a customized instance?, chose how much disk space, transaction logging yes/no, etc. etc., so the install program calculated a certain size for rootdbs. I wouldn't touch it!.. I think if rootdbs gets messed up, the server crashes and/or you could loose everything, unless you have a full backup of the folder that holds the dbspaces?

CORRECTION: The physical log can be moved to physdbs, but if physical log remains in rootdbs (default), the log should be about 30% smaller size than rootdbs size.

AFAIK you cannot shrink a chunk one it has been used to create or add on to a dbspace. The only way would be to export all of the databases, modify the ONCONFIG file to make the rootdb space smaller, reinitialize the instance, recreate the other dbspaces, move the logs again, import the databases. As to why your initial rootdb chunk is named rootdb.000 that is what it was named when the instance was created. Probably you let the install script create the instance and that is how it created that initial chunk while all of the other dbspaces you created manually and you named the chunk files differently, without the .000 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, Jul 18, 2012 at 2:08 AM, PRAJAKTA CHIKHALE <prajakta_s_c@yahoo.co.in > wrote: > How to reduce size of root dbspace in Informix 11.7 ? > Currently I have moved logical logs, physical logs, databases, temporary > dbspace all out of root space. > Currently only 6% of my root dbspace is used after importing required > databases and there is slim chance that the database will grow in size as > it > is for evaluation only and I can reduce crap data if more space is > required. > > Will onparams work for this ? > > How exactly do specify rootdbs to be reduce ? > Also in windows root dbspace pathname is like > D:\\\\Informix\\\\olr_te~1\\\\dbspaces\\\\rootdbs.000 > > For other dbspaces it is showing properly as > D:\\\\Informix\\\\olr_test1\\\\dbspaces\\\\<dbspacename without suffix ".000" appended > to > it> > > When specifying is the rootdbs to be specified as rootdbs or rootdbs.000 > > Regards > Prajakta > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --bcaec51a758ef4d9df04c5191f09

Frank: Actually best practices is to keep rootdb, logical logs, and physical logs in three independent dbspaces preferably on separate physical disk structures and separate from the data chunks. This is because the rootdb space is always busy and any write to the data will also write to the logical logs while the first write to any page will also cause a physical log record to be written. Note that the logical logs rarely grow. They are <almost> fixed. Yes, you can configure the engine to automatically add more logs if all logs fill up, however, since you should be archiving the logical logs either constantly (ontape -c) or as they fill (using the ALARMPROGRAM to run ontape -a when one fills) and given that filling the logs to the high watermark will cause transactions to rollback allowing logs to be reused, this is a rare thing. At any rate these automatic logs are created in the rootdb space regardless of where you move the manually created logical log to, so... 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, Jul 18, 2012 at 2:47 AM, FRANK J. COMPUTER <frank_in_pr@hotmail.com>wrote: > Hello again, Prajakta, > > As you may already know, I'm also testing 11.70.TC5DE (32-bit WinVista > SP2). > If I recall correctly, you're testing FC5 (64-bit)? > > >How to reduce size of root dbspace in Informix 11.7 ? > >Currently I have moved logical logs, physical logs, databases, temporary > >dbspace all out of root space. > >Currently only 6% of my root dbspace is used after importing required > >databases and there is slim chance that the database will grow in size as > it > >is for evaluation only and I can reduce crap data if more space is > required. > > IDS is new to me, but FWIW: Although you're just testing 11.70, my common > sense tells me that you should keep the logs in rootdbs and never shrink > its > size because logs can grow very large over time, the server also needs > additional space for other internal administration, etc. When installing > 11.70, I'm assuming you chose to define a customized instance?, chose how > much > disk space, transaction logging yes/no, etc. etc., so the install program > calculated a certain size for rootdbs. I wouldn't touch it!.. I think if > rootdbs gets messed up, the server crashes and/or you could loose > everything, > unless you have a full backup of the folder that holds the dbspaces? > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --14dae9340e1bd6439004c5193191

> Actually best practices is to keep rootdb, logical logs, and physical logs in three independent dbspaces preferably on separate physical disk structures and separate from the data chunks. This is because the rootdb space is always busy and any write to the data will also write to the logical logs while the first write to any page will also cause a physical log record to be written. > That makes sense. In the old days we used to keep SE's transaction log, with no buffering, on reliable media like a tape device, although tapes slowed down throughput. Today, would make sense to use a fast device like SSD's for logs? What happens if rootdbs fills up or gets corrupted?

<cutting> > >That makes sense. In the old days we used to keep SE's transaction log, with >no buffering, on reliable media like a tape device, although tapes slowed down >throughput. Today, would make sense to use a fast device like SSD's for logs? > > What happens if rootdbs fills up or gets corrupted? Game over Cheers Paul

It really depends on the corruption... I've seen tech support almost recreate a rootdbs for a small instance after the sysadmin had created a new filesystem over it... I think the customer never really gave them the credits due... As foe SSDs I'm curious about opinions... I can think of a couple of reasons to use them: 1- Since the logs are circular the device usage will be uniform... And since they eventually fail after certain number of writes, this looks good 2- logical logs writes can become a bottleneck in certain conditions... Any speed improvement can be a good bonus On the other hnd a respectable DBA for a non respectable technology feels that since the main advantage of SSDs are for random access, using them for what is essentially sequential writes is not that usefull... Any idead or experiences? On Jul 18, 2012 2:47 PM, "Paul Watson" <paul@oninit.com> wrote: > <cutting> > > > >That makes sense. In the old days we used to keep SE's transaction log, > with > >no buffering, on reliable media like a tape device, although tapes slowed > down > >throughput. Today, would make sense to use a fast device like SSD's for > logs? > > > > What happens if rootdbs fills up or gets corrupted? > > Game over > > Cheers > Paul > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --20cf3074d9ae9c0d8c04c51b0fda

If rootdbs fills you will sometimes have problems including not being able to restart the instance. If the root dbspace becomes corrupted you will probably have to restore the instance from archive and roll forward logs. Sometimes oncheck can repair the damage, however, even then I would immediately export all of my databases for safety and find a time to rebuild the instance from scratch. Fortunately neither a full rootdb nor a corrupted one is a common occurrence. 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, Jul 18, 2012 at 9:42 AM, FRANK J. COMPUTER <frank_in_pr@hotmail.com>wrote: > > > Actually best practices is to keep rootdb, logical logs, and physical logs > in three independent dbspaces preferably on separate physical disk > structures and separate from the data chunks. This is because the rootdb > space is always busy and any write to the data will also write to the > logical logs while the first write to any page will also cause a physical > log record to be written. > > > > That makes sense. In the old days we used to keep SE's transaction log, > with > no buffering, on reliable media like a tape device, although tapes slowed > down > throughput. Today, would make sense to use a fast device like SSD's for > logs? > > What happens if rootdbs fills up or gets corrupted? > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --bcaec5186a165f6c3104c51b118a

Game Over?.. Is there any way to make IDS fault-tolerant (crash-proof)?

If it is setup correctly then it is bullet-proof Cheers Paul -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of FRANK J. COMPUTER Sent: Wednesday, July 18, 2012 10:07 AM To: ids@iiug.org Subject: Re: RE: reduce size of root dbspace [27652] Game Over?.. Is there any way to make IDS fault-tolerant (crash-proof)? **************************************************************************** *** Forum Note: Use "Reply" to post a response in the discussion forum.

Wow... IDS is fully fault tolerant apart from serious and rare bugs. A crash will not corrupt anything and the fast recovery assures that things get to good shape on startup. And you have mirroring... On Jul 18, 2012 4:07 PM, "FRANK J. COMPUTER" <frank_in_pr@hotmail.com> wrote: > Game Over?.. Is there any way to make IDS fault-tolerant (crash-proof)? > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --20cf3005dcb2ef545104c51c1a3f

IDS is arguably the MOST fault tolerant of any RDBMS on the market today or at any time in history. Look, if someone cracked your car's engine block with by pumping a .45 cal round into it, it would be game over for your car. Does that mean you have to make the engine block literally bullet proof? No, because that is not a likely event. Same with Informix. If someone were to trash the storage containing your IDS rootdb, your server is probably hosed - game over. However, #1 - IBM may be able to reconstruct the root dbspace's reserved information and recover most of your data if the database itself is not stored in the root dbspace. That is as long as the data dbspaces were not also trashed at the some time. #2 - You should have tested secured archives and backups of your logical logs in a safe place so that you can recover from even the worst catastrophic event up to and including the loss of the entire building containing your primary data server. In this case, who cares if rootdb was corrupted. #3 - Like having your engine hit with a .45 slug, finding your root dbspace corrupted is a very uncommon event. Not to worry. Heck, unlike Oracle, your can even keep your server going and recover if the configuration file ($ONCONFIG) is destroyed. Ever see what happens to an Oracle instance if the pfile or spfile are damaged? Now THAT's game over! 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, Jul 18, 2012 at 11:07 AM, FRANK J. COMPUTER <frank_in_pr@hotmail.com > wrote: > Game Over?.. Is there any way to make IDS fault-tolerant (crash-proof)? > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --14dae93406bb8181ad04c51d70ab