Tablespace size
The poster asked whether IDS 11 still enforces the maximum of 16 million pages (the ~16GB-per-tablespace limit) for a single table fragment. The answer given was simply "yes" — the limit remains, and the usual workaround is to fragment tables across dbspaces. The thread then turned into a disagreement over whether this limit is a genuine design/administration burden or something most DBAs never hit; no technical fix or change beyond fragmentation is recorded.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Does the 16g page tabelspace maxiumum still apply in IDS 11 please?
Neil Truby wrote: > Does the 16g page tabelspace maxiumum still apply in IDS 11 please? Yes. -- Cheers, Obnoxio The Clown http://obotheclown.blogspot.com -- This message has been scanned for viruses and dangerous content by OpenProtect(http://www.openprotect.com), and is believed to be clean.
"Obnoxio The Clown" <obnoxio@serendipita.com> wrote in message news:mailman.290.1235123545.1831.informix-list@iiug.org... > Neil Truby wrote: >> Does the 16g page tabelspace maxiumum still apply in IDS 11 please? > > Yes. Thanks for the reply. That's quite a disappointment. I imagine that this is quite a fundamental thing to address, or it would have been already, but I think Informix Development is going to have to Grasp the Nettle on this. I find it becoming an increasingly important factor in physical database design and administration. Sure, you can fragment around it, but this doesn't chime well with IBM's messaging about Informix ("Set it and Forget it", etc) ...
Neil Truby wrote: > "Obnoxio The Clown" <obnoxio@serendipita.com> wrote in message > news:mailman.290.1235123545.1831.informix-list@iiug.org... >> Neil Truby wrote: >>> Does the 16g page tabelspace maxiumum still apply in IDS 11 please? >> Yes. > > Thanks for the reply. > > That's quite a disappointment. > > I imagine that this is quite a fundamental thing to address, or it would > have been already, but I think Informix Development is going to have to > Grasp the Nettle on this. I find it becoming an increasingly important > factor in physical database design and administration. Sure, you can > fragment around it, but this doesn't chime well with IBM's messaging about > Informix ("Set it and Forget it", etc) ... 99% of DBA's /do/ just set it and forget it. Don't blame Informix for your ineptitude or laziness. -- Cheers, Obnoxio The Clown http://obotheclown.blogspot.com -- This message has been scanned for viruses and dangerous content by OpenProtect(http://www.openprotect.com), and is believed to be clean.
"Obnoxio The Clown" <obnoxio@serendipita.com> wrote in message news:mailman.291.1235126466.1831.informix-list@iiug.org... > Neil Truby wrote: >> "Obnoxio The Clown" <obnoxio@serendipita.com> wrote in message >> news:mailman.290.1235123545.1831.informix-list@iiug.org... >>> Neil Truby wrote: >>>> Does the 16g page tabelspace maxiumum still apply in IDS 11 please? >>> Yes. >> >> Thanks for the reply. >> >> That's quite a disappointment. >> >> I imagine that this is quite a fundamental thing to address, or it would >> have been already, but I think Informix Development is going to have to >> Grasp the Nettle on this. I find it becoming an increasingly important >> factor in physical database design and administration. Sure, you can >> fragment around it, but this doesn't chime well with IBM's messaging >> about Informix ("Set it and Forget it", etc) ... > > 99% of DBA's /do/ just set it and forget it. Don't blame Informix for your > ineptitude or laziness. Er, well, that's a bit harsh. I'm not blaming anyone for anything. I'm saying that a limitation, which once probably seemed as unlikely ever to be relevant as a 2g chunk size, is becoming more and more of a consideration as time goes by. And that, although it's fairly simple for an Informix God such as myself to workaround, the same is not necessarily true of others; that having to use fragmentation not for its intended purpose but to get around an increasingly wearisome product limitation is not consistent with the "Low Maintenance" marketing message; and that it really needs to be addressed. So, Bollocks to you and your uninformed opinion! (Which of course though I fully respect as equally valid to mine).
Neil Truby wrote: > "Obnoxio The Clown" <obnoxio@serendipita.com> wrote in message > news:mailman.291.1235126466.1831.informix-list@iiug.org... >> Neil Truby wrote: >>> "Obnoxio The Clown" <obnoxio@serendipita.com> wrote in message >>> news:mailman.290.1235123545.1831.informix-list@iiug.org... >>>> Neil Truby wrote: >>>>> Does the 16g page tabelspace maxiumum still apply in IDS 11 please? >>>> Yes. >>> Thanks for the reply. >>> >>> That's quite a disappointment. >>> >>> I imagine that this is quite a fundamental thing to address, or it would >>> have been already, but I think Informix Development is going to have to >>> Grasp the Nettle on this. I find it becoming an increasingly important >>> factor in physical database design and administration. Sure, you can >>> fragment around it, but this doesn't chime well with IBM's messaging >>> about Informix ("Set it and Forget it", etc) ... >> 99% of DBA's /do/ just set it and forget it. Don't blame Informix for your >> ineptitude or laziness. > > Er, well, that's a bit harsh. I'm not blaming anyone for anything. I'm > saying that a limitation, which once probably seemed as unlikely ever to be > relevant as a 2g chunk size, is becoming more and more of a consideration as > time goes by. > > And that, although it's fairly simple for an Informix God such as myself to > workaround, the same is not necessarily true of others; that having to use > fragmentation not for its intended purpose but to get around an increasingly > wearisome product limitation is not consistent with the "Low Maintenance" > marketing message; and that it really needs to be addressed. Quick straw poll at http://obotheclown.blogspot.com/ -- have you ever run into this ludicrously low limit. I'm curious to see what people have to say? -- Cheers, Obnoxio The Clown http://obotheclown.blogspot.com -- This message has been scanned for viruses and dangerous content by OpenProtect(http://www.openprotect.com), and is believed to be clean.