Results 1 to 9 of 9
  1. #1
    Join Date
    Nov 2006
    Posts
    7

    Unanswered: Chunk size limit of 2Gb in informix when creating Dbspace

    Hi that means i can never create a database with a size limit higher than 2Gb izzit?

    is there anyway i can bypass this limitation?

    or do i have to but the new version of informix product?

    can anyone give me more information on this?

  2. #2
    Join Date
    Aug 2005
    Posts
    140
    No, the 2gb limif is for chunk size not for database size.
    The 2gb is the limit for offset+size of the chunk, so you cannot crate a 2gb chunk with 0.5 gb offset because its more than 2gb.
    But dbspace can have as many
    chunks as you need(there is also limit of 1024 chunks).

    In this group, there are a lot of similiar discussion so check out them.

  3. #3
    Join Date
    Nov 2006
    Posts
    7
    hi thanx for the great information but i still have enquiry what is the difference between chunk size and database size

    i read the ibm informix tutorial and it saids that u need to specify the offset to avoid overwriting the database data izzit true?

    or i can just append with offset setting as 0?

  4. #4
    Join Date
    Aug 2005
    Posts
    140
    It seems you should read documentation more carefully
    From documentation:

    Many computer systems and some disk-drive manufacturers keep information for a physical disk drive on the drive itself. This information is sometimes referred to as a volume table of contents (VTOC) or disk label. The VTOC is commonly stored on the first track of the drive. A table of alternate sectors and bad-sector mappings (also called a revectoring table) might also be stored on the first track.

    If you plan to allocate partitions at the start of a disk, you might need to use offsets to prevent the database server from overwriting critical information required by the operating system. For the exact offset required, refer to your disk-drive manuals

    In other words, the offset allows you to define more than one dbspace or
    chunk on the same device such that no two chunks overlap.

    Check out the documentation...there are a lot of information about using offset when creating/adding chunks.

  5. #5
    Join Date
    Aug 2006
    Location
    The Netherlands
    Posts
    248
    Hi,

    About your question in difference between chunk size and dbspace size: a chunk is a physical unit of storagespace while a dbspace is a locigal unit. In a way you can compare it to the regular way of disk partitioning. A sector (like a chunk) is the smallest unit of storagespace and a cluster (like a dbspace) consists of one or more sectors. For storing a file on disk the filesystem uses clusters, not sectors. In the same way for storing a database on disk the server uses dbspaces, not chunks.

    And regarding the offset; if you create a chunk in a separate partition on a disk that's also occupied by the server you should always use offset 0 because of simplicity. I think you should consider the offset for the first chunk only when you use a separate disk for your dbspace. And more I think you need these considerations only with raw dbspaces because otherwise the operating system will take care of the necesary administrative overhead of the disk.

    Regards

  6. #6
    Join Date
    Nov 2006
    Posts
    7
    so am i right to say when i want to add on more chunks to a dbspace
    unless the chunks will be on different disk

    else i do not have to specify the offset?

    because my concern is that i am afraid by not specifying the offset i may accidentally overwrite some data...

    sorry for my ignorance but can further clarify on this?

  7. #7
    Join Date
    Aug 2006
    Location
    The Netherlands
    Posts
    248
    The straightforward (and by this to me preferable) way of creating chunks is to create one chunk in one logical volume or unit (i.e. a disk partition or a UNIX character special file). This way it's not necerary to use an offset > 0 and there's no risk of overwriting existing data. Therefore you should not create logical volumes in your OS for DBMS storagespace bigger than 2 GB because there's no way for the storage manager to address the area beyond the 2 GB boundary.
    (Actually the absolute limit is 4 GB because when the offset of the last chunk in the logical volume is specified as 2 GB and it's size is specified as the maximum of 2 GB it gives a total of 4 GB beyond which nothing can be addressed anymore by the storage manager).

    If you insist on creating two or more chunks in one logical volume you have to use the offset, but usually the offset for the first chunk is specified as 0. Only for the subsequent chunks it's specified as the total size of the previous chunks in the volume. In all cases the offset for the first chunk in the first logical volume has to be > 0 only when it's located at the beginning of a disk.

    Regards

  8. #8
    Join Date
    Jan 2004
    Location
    San Antonio, Texas
    Posts
    47
    I am sort of surprised that no one has mentioned the 2Gb limit went away with IDS 10. We use 100GB LV's with no issues. We do use off-sets but since our DB's are large there are not too many of them. I decided 100Gb was our limit so that off-sets would not become confusing. As long as you are in the same instance it will not allow you to overwrite what you have already allocated. I think they are working on this so you do not have issues with any instance.

    And just so you know if you happen to have an LV larger than 2 GB on DEC it will allocate it and then you cannot access your data. :-)

    DBAGIRL

  9. #9
    Join Date
    Jan 2007
    Posts
    30

    Chunk management using offset

    Hi,

    I have 3 DBspaces namely rootdbs, plogdbs, llogdbs. Proposed size of each DBspaces are as following:

    rootdbs - 1 GB
    plogdbs - 3 GB
    llogdbs - 3 GB

    Each of the DBsapces should be in a link /dev/inmx/raw_d1 where raw_d1 is the linked to a Raw Device.

    Please tell me how to manager such situations using onspaces command.

    Regards

    Saikat

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •