Hello Art!
I sensed that you were going to respond quickly to my queries. It is something I always appreciate.
Regarding migration to a new version of Informix, in this case 14.10, it will be impossible, since the provider of our application has a new version of its application that works with Oracle. For this reason, until the new system is implemented, I must keep the current one running with Informix.
This is something that frustrates me since Informix seems to me to be a much better database engine than Oracle. But unfortunately, there is nothing I can do to change the situation.
Returning to the topic of my query, I am interested in the idea of making an ALTER to the tables and creating them in another DBSPACE. Related to this, I have some doubts:
1 - After creating the tables in the new DBSPACE, can I recreate the tables in the original DBSPACE ?. I suppose so, using the same command that was used to move them from DBSPACE. I ask this because all my tables are in a single DBSPACE. I understand this would involve doing the job 2 times for each table, but I would like to keep all the tables together.
2 - Assuming that when you return the table to its original DBSPACE, it runs out of space, how could I solve it?
3 - Does this process also copy the indexes of the tables ?.
4 - The NEXT SIZE value could be indicated as a percentage ratio of the size of each table ?. This because the table would already be compacted by calling it somehow.
Forgive me for so many questions, but I am extremely suspicious and cautious when working in a production environment.
Thanks for your reply again !!!
------------------------------
Gustavo Echenique
------------------------------
Original Message:
Sent: Sun May 17, 2020 11:09 PM
From: Art Kagel
Subject: Table resizing queries
Gustavo:
You do not have to go through that old procedure, nor do you have to export and import the table (nor the whole database) if you up grade to a modern release of Informix! First, in v7.31, while you cannot change the FIRST extent size, you can change the NEXT SIZE (later releases do let you change the first extent size which is helpful when using the built-in defragmentation features in later releases.
That said, since you are currently stuck in v7.31, let me address you direct issues:
Your questions are the following:
1 - Have you successfully carried out this procedure?
Many times in various different versions of the operation.
2 - Should I take into account the elimination of all foreign key constraints that refer to the modified table and its subsequent recreation? At this point I assume yes.
Yes. You have to drop all constraints and indexes OR create the new ones on the new table with different names.
3 - Do you have any alternative solution to this problem?
Yes, you can use:
ALTER TABLE <tablename> NEXT SIZE <large extent size>;
ALTER FRAGMENT ON TABLE <tablename> INIT IN <dbspace>;
The dbspace can be any dbspace, even the same space that the table currently resides in. However, if you use an new empty dbspace then the new table will have a single large contiguous extent because of extent coalescing (contiguous extents are merged into a single extent), or at least one for each chunk that the table has to span if it is bigger than a single chunk in the dbspace. Since this is completely carried out inside the engine's code, it is faster than copying the data from the original table to a new one. It will be even a bit faster if you first drop the constraints and make the table RAW before the reorg then alter it back to STANDARD afterwards, recreate the constraints, then take an archive (RAW tables are not logged, so you will need the archive in order to be able to recover.
Oh, and DO NOT TRY THE oncheck -me option, it doesn't always work and can corrupt the table!
If you really want to improve performance, you may want to try fragmenting the table across several dbspaces so that the engine can ignore the fragment(s) that contain older data that you no longer need access to.
Again, the current release, version 14.10, offers several other options and you can get a VERY inexpensive computer to run it on that will be far faster than what you have now. Feature-wise you can probably get away with using the Workgroup Edition or maybe even the Express Edition.
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.
Original Message------
Dear colleagues:
I have the following situation: my database consists of almost a thousand tables, of which a couple of dozen exceed 30 million records. I even have one with 170 million records.
I have noticed that many processes accessing the database have increased their time significantly, and this is surely due to the fragmentation of the mentioned tables.
Now, when I took a database administration course taught by Informix Argentina, the instructor told me that the only way to change the Extent was to do a dbexport and dbimport (with the Extent and Next data calculated again) from the database .
This is impractical due to the size of the database, which occupies 104GB in flat files (dbexport), since it would take a long weekend of 3 or 4 days. It is as a consequence of the old age of the database version (IDS 7.31TD6) running on a Windows 2000 Advanced Server, and the server (IBM x366 with a 2GB transfer optical disk storage).
But researching, I found the following link: https://www.ibm.com/support/pages/how-reorganize-table-effectively
I did the test in a test environment with a single table, as the page indicates, but instead of dropping it, I renamed it and when I wanted to create the indexes and constraints, they still existed.
My questions to you are the following:
1 - Have you successfully carried out this procedure?
2 - Should I take into account the elimination of all foreign key constraints that refer to the modified table and its subsequent recreation? At this point I assume yes.
3 - Do you have any alternative solution to this problem?
4 - Can you add something to what is exposed by the article exposed in the link?
In advance, I appreciate your kind attention and the time dedicated to my consultation.
#Informix