Informix

Informix

Connect with Db2, Informix, Netezza, open source, and other data experts to gain value from your data, share insights, and solve problems.

 View Only
  • 1.  Rootdbs initially in a large chunk

    Posted 2 days ago

    Hi again Family.

    I want to create a totally new instance and start the rootdbs at 20GB, rather than the old (pre IDS-10) default max chunk size of 2GB.  I don't have the new machine yet so I can't try it myself.

    Is this doable or will that first oninit -i barf at that large first chunk size?

    Thanks.  (WOW! Only 3 sentences! What has happened to Jake?)



    ------------------------------
    +-----------------------------------------------------------+
    | I am pleased to report that I had no problems today. |
    | I had only issues, opportunities, challenges and valuable |
    | learning experiences. |
    +------------------------------------------ Jacob S --------+
    ------------------------------


  • 2.  RE: Rootdbs initially in a large chunk

    Posted 2 days ago
    Hi Jacob,
    20gb is not really large. 
    The rootdbs should be mostly used for administrative dbs, not for application data.
    It very much depends on the total size of the instance what you are putting there.
    You could have an instance just with a rootdbs, of course, though it is not recommended.

    Best.

    Gesendet von Outlook für Android





  • 3.  RE: Rootdbs initially in a large chunk

    Posted 2 days ago
    Nothing is ever in rootdbs, I just use 2gb by default 


    Cheers
    Paul

    Paul Watson
    Oninit LLC
    +1-913-387-7529
    www.oninit.com
    Oninit®️ is a registered trademark of Oninit LLC





  • 4.  RE: Rootdbs initially in a large chunk

    Posted 2 days ago
    Jacob:

    No problem. Just set ROOTSIZE in the ONCONFIG file before running the oninit -i.

    I do, however, question why one would want a massive rootdbs since there shouldn't be anything in there besides the reserved pages and most of the system databases.

    Art

    Art S. Kagel, President and Principal Consultant
    ASK Database Management


    Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on 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.









  • 5.  RE: Rootdbs initially in a large chunk

    Posted 2 days ago

    (3rd attempt to post my reply)

    Thanks, All. No quibble with your negative recommendations.

    The definitive response, from Art, was that it is doable.

    I agree that nothing should be in there but the administrative system databases (sysmaster, sysadmin, etc).  However, in my current environment where the rootdbs is 2 chunks totaling well over that 2GB, there is bleed-over into the second chunk.  (What in &^%$# are they doing in there?!)  So for the new instance I will start with the standard 2GB, add another 2GB chunk and leave it at that.

    As those Jurassic Park genetic engineers have yet to learn: Just because you can do it does not mean you should.



    ------------------------------
    Jacob Salomon
    ---
    Nobody goes there anymore, it's too crowded.  --Attr: Yogi Berra
    ------------------------------



  • 6.  RE: Rootdbs initially in a large chunk

    Posted 17 hours ago
    Depending on much you use sysadmin I would move that into its own space

    On 1/1/2026 8:29 AM, Jacob Salomon via IBM TechXchange Community wrote:
    0100019b79f6d0e6-405f44d7-4180-4833-90a3-613ede8e09ec-000000@email.amazonses.com">
    (3rd attempt to post my reply) Thanks, All. No quibble with your negative recommendations. The definitive response, from Art, was that it is... -posted to the "Informix" group





  • 7.  RE: Rootdbs initially in a large chunk

    Posted 16 hours ago

    As I said, Paul, I have no quibble with the "don't do it" suggestions.

    I just ran my old fragments.sh script against the sysadmin database. It occupies over 600,000 pages, 1.2GB.  And it is indeed in its own dbspace  Something to consider in our new installation.

    Thanks for the advice.



    ------------------------------
    Jacob Salomon
    ---
    Nobody goes there anymore, it's too crowded.  --Attr: Yogi Berra
    ------------------------------



  • 8.  RE: Rootdbs initially in a large chunk

    Posted 16 hours ago
    First post in this community-hi community! Here are my two cents on the issue. I can't think of a single good reason to need a large rootdbs. Whether you are storing logical logs, physical logs, sysadmin stats, databases there-all of that should be moved to different dbspaces after creation.
     
    I think I know what your problem is: you are trying to initialize a new DB by specifying too many logical logs that won't fit in the original rootdbs size. You don't need to do that. Instead, create the database with just a few logs, then create a new dbspace for the logical logs. Once you've created the new logs in that space, you can delete the original ones from the rootdbs. You should also move the physical log and the sysadmin database to another dbspace


    ------------------------------
    Jacobo BC
    ------------------------------



  • 9.  RE: Rootdbs initially in a large chunk

    Posted 16 hours ago
    First post here-hi community! Here are my two cents on the issue. I can't think of a single reason to need a large rootdbs. Whether you are storing logical logs, physical logs, or sysadmin stats there-all of that should be moved to different dbspaces after creation.
     
    I think I know what the problem is: you are trying to initialize a new DB by specifying too many logical logs that won't fit in the original rootdbs size. You don't need to do that. Instead, create the database with just a few logs, then create a new dbspace for the logical logs. Once you've created the new logs in that space, you can delete the original ones from the rootdbs. You should also move the physical log and the sysadmin database to another dbspace


    ------------------------------
    Jacobo BC
    ------------------------------