Re: storage pool configuration.
Posted in 2013
Topics: Storage & Space Management, Server Administration, Migration, Import/Export & Data Conversion, Platform-Specific Issues, Jobs, Consulting & Announcements
OK, here's the deal:
- Chunks are marked as extendable or not extendable. Extendable means it
is possible to make the underlying file bigger if needed (so no RAW chunks
can be extendable). If it is extendable there is not current limit on the
maximum size. The only configurable is the amount that the chunk is
extended by.
- Dbspaces can be expandable meaning you can automatically add a chunk from
the storage pool when needed. However, the chunk files in the pool have to
already exist and be at least as big as the minimum expansion size assigned
to the dbspace. You cannot just create a new file at expansion time.
- Both are implemented by task manager tasks that awaken periodically and
check the chunks and dbspaces for fullness and extend chunks or expand
dbspaces when needed.
- You could implement your own tasks instead to have it behave any way you
want it to. Have it make the choice between extend or expand and create a
new file on the fly as needed. Your task can even use the existing API
functions to extend a chunk or expand a dbspace once it decides which is
needed and possibly creates the new file and adds it to the storage pool.
Art
Art S. Kagel, Principal Consultant
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 Tue, Dec 17, 2013 at 7:31 AM, Cesar Martins <
cesar.inacio.martins@gmail.com> wrote:
> Hi,
>
> ifx 11.70 FC7 .
> AIX 6.1
>
> I'm studying the best way to use the storage pool at v11.70 .
> Today we use v11.50 , I'm planning our migration to 11.70 and my desire is
> allow informix automatically admin my chunks growing and try start with
> "best" way already configured...
> I have no experience with storage pool yet...
>
> First I'm trying figure out if is possible to configure it for the way I
> consider more organized and flexible.
> which is :
> * all dbspaces will be created first manually with onspaces (old way),
> with just one chunk.
> * configure the storage pool pointing to directory
> * It should create automatically chunks for each dbspaces as need...
> * all chunks will start with 500 Mb of size.
> * all chunks will be expandable
> * all chunk should have a limit of 4G or 8G as max size... when reach
> this size, new one should be added to dbspace instead keep growing...
>
> I don't want just one chunk expandable "indefinable" because later I won't
> able to shrunk it...
>
> Is this possible?
> (using a directory)
>
> Regards
> Cesar
>
> _______________________________________________
> Informix-list mailing list
> Informix-list@iiug.org
> http://www.iiug.org/mailman/listinfo/informix-list
>
>
--089e01536a84f122f604edba6eb2
Hi Art,
Thanks for the fast answer...
Your explanation just confirm my suspicious...
Way the storage pool work is very discouraging for me...
The missing limit of expandable chunk is something what I don't understand
how this feature could be "born" without it...
We don't want one and inflexible chunk later. At any maintenance we will
not able to free space at the file system (I'm planning work with cooked
file + direct_io/concurrent_io) .
At least with "sliced" chunks is more viable since we can defrag tables,
freeing the lasts chunks then drop it...
The other option, pre-allocated storage pool entries / non-expandable chunk
(cooked file) just kill our objective which is use the only necessary of
the file system... on demand. (just like IBM slogan :)
Just a note, at first test I did here, if use a directory as storage pool ,
it create and add a new chunk at the dbspace on demand... and do this as
reactive way... works very well... the only "defect" (my option) it add
only one chunk to dbspace and keep it growing indefinitely...
At the moment I'm testing the load of the data (hpl, load, ...) and the
creating indexes... they grown fast and there is no way to "slice" the
extendable chunks.
Thanks anyway!
Cesar
2013/12/17 Art Kagel <art.kagel@gmail.com>
> OK, here's the deal:
> - Chunks are marked as extendable or not extendable. Extendable means it
> is possible to make the underlying file bigger if needed (so no RAW chunks
> can be extendable). If it is extendable there is not current limit on the
> maximum size. The only configurable is the amount that the chunk is
> extended by.
> - Dbspaces can be expandable meaning you can automatically add a chunk from
> the storage pool when needed. However, the chunk files in the pool have to
> already exist and be at least as big as the minimum expansion size assigned
> to the dbspace. You cannot just create a new file at expansion time.
> - Both are implemented by task manager tasks that awaken periodically and
> check the chunks and dbspaces for fullness and extend chunks or expand
> dbspaces when needed.
> - You could implement your own tasks instead to have it behave any way you
> want it to. Have it make the choice between extend or expand and create a
> new file on the fly as needed. Your task can even use the existing API
> functions to extend a chunk or expand a dbspace once it decides which is
> needed and possibly creates the new file and adds it to the storage pool.
>
> Art
>
> Art S. Kagel, Principal Consultant
>
> 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 Tue, Dec 17, 2013 at 7:31 AM, Cesar Martins <
> cesar.inacio.martins@gmail.com> wrote:
>
> > Hi,
> >
> > ifx 11.70 FC7 .
> > AIX 6.1
> >
> > I'm studying the best way to use the storage pool at v11.70 .
> > Today we use v11.50 , I'm planning our migration to 11.70 and my desire
> is
> > allow informix automatically admin my chunks growing and try start with
> > "best" way already configured...
> > I have no experience with storage pool yet...
> >
> > First I'm trying figure out if is possible to configure it for the way I
> > consider more organized and flexible.
> > which is :
> > * all dbspaces will be created first manually with onspaces (old way),
> > with just one chunk.
> > * configure the storage pool pointing to directory
> > * It should create automatically chunks for each dbspaces as need...
> > * all chunks will start with 500 Mb of size.
> > * all chunks will be expandable
> > * all chunk should have a limit of 4G or 8G as max size... when reach
> > this size, new one should be added to dbspace instead keep growing...
> >
> > I don't want just one chunk expandable "indefinable" because later I
> won't
> > able to shrunk it...
> >
> > Is this possible?
> > (using a directory)
> >
> > Regards
> > Cesar
> >
> > _______________________________________________
> > Informix-list mailing list
> > Informix-list@iiug.org
> > http://www.iiug.org/mailman/listinfo/informix-list
> >
> >
>
> --089e01536a84f122f604edba6eb2
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--bcaec54fb534cff10e04edbacfed
For what it's worth -- I'm in the final stages of completing a Proof of =
Technology on all the Informix storage management features such as =
reduplication of backups, fragmentation (and why), compress, repack, =
shrink, defragment, automatic and manual expansion of spaces, storage =
pool, and so on. Should be ready and published in the next month or so. =
It will have hands-on exercises with almost all of these things. You can =
have your local IBM office arrange for the PoT to be taught in your =
area.
Carlton
-------------------------------------------------
Carlton Doe
Flower Mound, TX
No trees were killed in the transmission of this email, however a large =
number of electrons were temporarily inconvenienced.=20
On Dec 17, 2013, at 7:22 AM, "Cesar Martins" =
<cesar.inacio.martins@gmail.com> wrote:
> Hi Art,=20
>=20
> Thanks for the fast answer...=20
> Your explanation just confirm my suspicious...=20
>=20
> Way the storage pool work is very discouraging for me...=20
>=20
> The missing limit of expandable chunk is something what I don't =
understand=20
> how this feature could be "born" without it...=20
> We don't want one and inflexible chunk later. At any maintenance we =
will=20
> not able to free space at the file system (I'm planning work with =
cooked=20
> file + direct_io/concurrent_io) .=20
> At least with "sliced" chunks is more viable since we can defrag =
tables,=20
> freeing the lasts chunks then drop it...=20
>=20
> The other option, pre-allocated storage pool entries / non-expandable =
chunk=20
> (cooked file) just kill our objective which is use the only necessary =
of=20
> the file system... on demand. (just like IBM slogan :)=20
>=20
> Just a note, at first test I did here, if use a directory as storage =
pool ,=20
> it create and add a new chunk at the dbspace on demand... and do this =
as=20
> reactive way... works very well... the only "defect" (my option) it =
add=20
> only one chunk to dbspace and keep it growing indefinitely...=20
>=20
> At the moment I'm testing the load of the data (hpl, load, ...) and =
the=20
> creating indexes... they grown fast and there is no way to "slice" the=20=
> extendable chunks.=20
>=20
> Thanks anyway!=20
> Cesar=20
>=20
> 2013/12/17 Art Kagel <art.kagel@gmail.com>=20
>=20
>> OK, here's the deal:=20
>> - Chunks are marked as extendable or not extendable. Extendable means =
it=20
>> is possible to make the underlying file bigger if needed (so no RAW =
chunks=20
>> can be extendable). If it is extendable there is not current limit on =
the=20
>> maximum size. The only configurable is the amount that the chunk is=20=
>> extended by.=20
>> - Dbspaces can be expandable meaning you can automatically add a =
chunk from=20
>> the storage pool when needed. However, the chunk files in the pool =
have to=20
>> already exist and be at least as big as the minimum expansion size =
assigned=20
>> to the dbspace. You cannot just create a new file at expansion time.=20=
>> - Both are implemented by task manager tasks that awaken periodically =
and=20
>> check the chunks and dbspaces for fullness and extend chunks or =
expand=20
>> dbspaces when needed.=20
>> - You could implement your own tasks instead to have it behave any =
way you=20
>> want it to. Have it make the choice between extend or expand and =
create a=20
>> new file on the fly as needed. Your task can even use the existing =
API=20
>> functions to extend a chunk or expand a dbspace once it decides which =
is=20
>> needed and possibly creates the new file and adds it to the storage =
pool.=20
>>=20
>> Art=20
>>=20
>> Art S. Kagel, Principal Consultant=20
>>=20
>> Advanced DataTools (www.advancedatatools.com)=20
>> Blog: http://informix-myview.blogspot.com/=20
>>=20
>> Disclaimer: Please keep in mind that my own opinions are my own =
opinions=20
>> and do not reflect on my employer, Advanced DataTools, the IIUG, nor =
any=20
>> other organization with which I am associated either explicitly,=20
>> implicitly, or by inference. Neither do those opinions reflect those =
of=20
>> other individuals affiliated with any entity with which I am =
affiliated nor=20
>> those of the entities themselves.=20
>>=20
>> On Tue, Dec 17, 2013 at 7:31 AM, Cesar Martins <=20
>> cesar.inacio.martins@gmail.com> wrote:=20
>>=20
>>> Hi,=20
>>>=20
>>> ifx 11.70 FC7 .=20
>>> AIX 6.1=20
>>>=20
>>> I'm studying the best way to use the storage pool at v11.70 .=20
>>> Today we use v11.50 , I'm planning our migration to 11.70 and my =
desire=20
>> is=20
>>> allow informix automatically admin my chunks growing and try start =
with=20
>>> "best" way already configured...=20
>>> I have no experience with storage pool yet...=20
>>>=20
>>> First I'm trying figure out if is possible to configure it for the =
way I=20
>>> consider more organized and flexible.=20
>>> which is :=20
>>> * all dbspaces will be created first manually with onspaces (old =
way),=20
>>> with just one chunk.=20
>>> * configure the storage pool pointing to directory=20
>>> * It should create automatically chunks for each dbspaces as need...=20=
>>> * all chunks will start with 500 Mb of size.=20
>>> * all chunks will be expandable=20
>>> * all chunk should have a limit of 4G or 8G as max size... when =
reach=20
>>> this size, new one should be added to dbspace instead keep =
growing...=20
>>>=20
>>> I don't want just one chunk expandable "indefinable" because later I=20=
>> won't=20
>>> able to shrunk it...=20
>>>=20
>>> Is this possible?=20
>>> (using a directory)=20
>>>=20
>>> Regards=20
>>> Cesar=20
>>>=20
>>> _______________________________________________=20
>>> Informix-list mailing list=20
>>> Informix-list@iiug.org=20
>>> http://www.iiug.org/mailman/listinfo/informix-list=20
>>>=20
>>>=20
>>=20
>> --089e01536a84f122f604edba6eb2=20
>>=20
>>=20
>>=20
>>=20
> =
**************************************************************************=
*****=20
>> Forum Note: Use "Reply" to post a response in the discussion forum.=20=
>>=20
>>=20
>=20
> --bcaec54fb534cff10e04edbacfed=20
>=20
>=20
> =
**************************************************************************=
*****=20
> Forum Note: Use "Reply" to post a response in the discussion forum.=20=
>=20
Hi Carlton,
Nice!
Thanks for the note, I will wait the publication, since I don't have any
rush over this yet.
Best regards
Cesar
2013/12/17 Carlton Doe <dbaresrc@xmission.com>
> For what it's worth -- I'm in the final stages of completing a Proof of =
> Technology on all the Informix storage management features such as =
> reduplication of backups, fragmentation (and why), compress, repack, =
> shrink, defragment, automatic and manual expansion of spaces, storage =
> pool, and so on. Should be ready and published in the next month or so. =
> It will have hands-on exercises with almost all of these things. You can =
> have your local IBM office arrange for the PoT to be taught in your =
> area.
>
> Carlton
>
> -------------------------------------------------
> Carlton Doe
> Flower Mound, TX
>
> No trees were killed in the transmission of this email, however a large =
> number of electrons were temporarily inconvenienced.=20
>
> On Dec 17, 2013, at 7:22 AM, "Cesar Martins" =
> <cesar.inacio.martins@gmail.com> wrote:
>
> > Hi Art,=20
> >=20
> > Thanks for the fast answer...=20
> > Your explanation just confirm my suspicious...=20
> >=20
> > Way the storage pool work is very discouraging for me...=20
> >=20
> > The missing limit of expandable chunk is something what I don't =
> understand=20
> > how this feature could be "born" without it...=20
> > We don't want one and inflexible chunk later. At any maintenance we =
> will=20
> > not able to free space at the file system (I'm planning work with =
> cooked=20
> > file + direct_io/concurrent_io) .=20
> > At least with "sliced" chunks is more viable since we can defrag =
> tables,=20
> > freeing the lasts chunks then drop it...=20
> >=20
> > The other option, pre-allocated storage pool entries / non-expandable =
> chunk=20
> > (cooked file) just kill our objective which is use the only necessary =
> of=20
> > the file system... on demand. (just like IBM slogan :)=20
> >=20
> > Just a note, at first test I did here, if use a directory as storage =
> pool ,=20
> > it create and add a new chunk at the dbspace on demand... and do this =
> as=20
> > reactive way... works very well... the only "defect" (my option) it =
> add=20
> > only one chunk to dbspace and keep it growing indefinitely...=20
> >=20
> > At the moment I'm testing the load of the data (hpl, load, ...) and =
> the=20
> > creating indexes... they grown fast and there is no way to "slice"
> the=20=
>
> > extendable chunks.=20
> >=20
> > Thanks anyway!=20
> > Cesar=20
> >=20
> > 2013/12/17 Art Kagel <art.kagel@gmail.com>=20
> >=20
> >> OK, here's the deal:=20
> >> - Chunks are marked as extendable or not extendable. Extendable means =
> it=20
> >> is possible to make the underlying file bigger if needed (so no RAW =
> chunks=20
> >> can be extendable). If it is extendable there is not current limit on =
> the=20
> >> maximum size. The only configurable is the amount that the chunk is=20=
>
> >> extended by.=20
> >> - Dbspaces can be expandable meaning you can automatically add a =
> chunk from=20
> >> the storage pool when needed. However, the chunk files in the pool =
> have to=20
> >> already exist and be at least as big as the minimum expansion size =
> assigned=20
> >> to the dbspace. You cannot just create a new file at expansion time.=20=
>
> >> - Both are implemented by task manager tasks that awaken periodically =
> and=20
> >> check the chunks and dbspaces for fullness and extend chunks or =
> expand=20
> >> dbspaces when needed.=20
> >> - You could implement your own tasks instead to have it behave any =
> way you=20
> >> want it to. Have it make the choice between extend or expand and =
> create a=20
> >> new file on the fly as needed. Your task can even use the existing =
> API=20
> >> functions to extend a chunk or expand a dbspace once it decides which =
> is=20
> >> needed and possibly creates the new file and adds it to the storage =
> pool.=20
> >>=20
> >> Art=20
> >>=20
> >> Art S. Kagel, Principal Consultant=20
> >>=20
> >> Advanced DataTools (www.advancedatatools.com)=20
> >> Blog: http://informix-myview.blogspot.com/=20
> >>=20
> >> Disclaimer: Please keep in mind that my own opinions are my own =
> opinions=20
> >> and do not reflect on my employer, Advanced DataTools, the IIUG, nor =
> any=20
> >> other organization with which I am associated either explicitly,=20
> >> implicitly, or by inference. Neither do those opinions reflect those =
> of=20
> >> other individuals affiliated with any entity with which I am =
> affiliated nor=20
> >> those of the entities themselves.=20
> >>=20
> >> On Tue, Dec 17, 2013 at 7:31 AM, Cesar Martins <=20
> >> cesar.inacio.martins@gmail.com> wrote:=20
> >>=20
> >>> Hi,=20
> >>>=20
> >>> ifx 11.70 FC7 .=20
> >>> AIX 6.1=20
> >>>=20
> >>> I'm studying the best way to use the storage pool at v11.70 .=20
> >>> Today we use v11.50 , I'm planning our migration to 11.70 and my =
> desire=20
> >> is=20
> >>> allow informix automatically admin my chunks growing and try start =
> with=20
> >>> "best" way already configured...=20
> >>> I have no experience with storage pool yet...=20
> >>>=20
> >>> First I'm trying figure out if is possible to configure it for the =
> way I=20
> >>> consider more organized and flexible.=20
> >>> which is :=20
> >>> * all dbspaces will be created first manually with onspaces (old =
> way),=20
> >>> with just one chunk.=20
> >>> * configure the storage pool pointing to directory=20
> >>> * It should create automatically chunks for each dbspaces as
> need...=20=
>
> >>> * all chunks will start with 500 Mb of size.=20
> >>> * all chunks will be expandable=20
> >>> * all chunk should have a limit of 4G or 8G as max size... when =
> reach=20
> >>> this size, new one should be added to dbspace instead keep =
> growing...=20
> >>>=20
> >>> I don't want just one chunk expandable "indefinable" because later
> I=20=
>
> >> won't=20
> >>> able to shrunk it...=20
> >>>=20
> >>> Is this possible?=20
> >>> (using a directory)=20
> >>>=20
> >>> Regards=20
> >>> Cesar=20
> >>>=20
> >>> _______________________________________________=20
> >>> Informix-list mailing list=20
> >>> Informix-list@iiug.org=20
> >>> http://www.iiug.org/mailman/listinfo/informix-list=20
> >>>=20
> >>>=20
> >>=20
> >> --089e01536a84f122f604edba6eb2=20
> >>=20
> >>=20
> >>=20
> >>=20
> > =
> **************************************************************************=
> *****=20
> >> Forum Note: Use "Reply" to post a response in the discussion forum.=20=
>
> >>=20
> >>=20
> >=20
> > --bcaec54fb534cff10e04edbacfed=20
> >=20
> >=20
> > =
> **************************************************************************=
> *****=20
> > Forum Note: Use "Reply" to post a response in the discussion forum.=20=
>
> >=20
>
>
>@@