- Article Type: General
- Product: Aleph
- Product Version: 16.02
We ran into a tablespace filling up earlier today. After that space was increased and the system was stable, it was discovered we have many cases where the file_list should be changed to identify a different tablespace. Is there a document that best explains the ins and outs of doing that maintenance?
Secondly, the purpose of this incident is to request specific attention to our ILLSV file_list. There are several tables (z00, z01_ids, z02 and ids, z101 and id, z11 and id, z13 and id, z97 and ids) that I would like to redefine. I see most of these are associated with a p_manage job (01, 02, 05, 07, and 27). What is the best way to proceed with correcting these definitions? Can the manage jobs be run in ILLSV only?
The best resource that I have found on this topic is the System Administration Guide. It has an in-depth discussion of the file_list mechanism and how it works.
The main process to do Oracle table reorganization is as follows:
Figure out what tables you wish to change and the specific changes you wish to make
Do a sequential dump of the table (p_file_03)
Edit the file_list to change the parameters you wish to change
Do a sequential load of the table (p_file_04)
These steps can be done for specific tables in specific libraries.
For rebuilding indexes, however, you are probably best served to run the indexing programs, such as p_manage_01, p_manage_02, etc. These can certainly be run for specific libraries, including the ILLSV library. For these cases, you would want to edit the file_list, and drop and recreate the tables using util a/17/1, then run the specific services that rebuild these tables, one by one. Doing a complete run of these services to recreate an index table such as z11 should result in the automatic recreation of their Oracle indexes, so you should not need to run, for example, util a/17/2 for these indexes.
These operations have risks associated with them, as you have the potential to lose important data (for example by specifying the wrong table to drop). Because of this risk, you should make sure you have good backups of your database available, practice your entire procedure on the test database prior to doing it in production and use great caution as you proceed. I should also warn you that my advice is all based on reading documentation, not from actually trying the process, so taking care is even more strongly advised.
- Article last edited: 10/8/2013