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.
It seems you should read documentation more carefully
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.
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.
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.
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. :-)