Online Tutorials & Training Materials | STechies.com
Register Login

Disk Space Problems Interview Questions and Answers

|| || 0

Disk Space Problems Interview Questions and Answers
Stechies

 FAQ: Avoiding Disk Space Problems

Solution What kind of disk space problems are there?

1. The following kinds of disk space problems exist:

a) There is no more disk space in a dbspace.
b) New CHUNKS cannot be created.
c) Large tables are converted (ALTER TABLE).
d) The maximum number of EXTENTS for a table has been reached.
e) NEXT EXTENT size is larger than the disk space available in dbspace.
f) A table, table fragment or 'detached' index has reached the maximum size of 32 or 64GB.
g) Temporary dbspaces are too small.
h) The logical log file is too small.
i) The maximum number of dbspaces or chunks has been reached.

2. How I can prevent disk space problems from occurring and what I can do if they have already occurred?

a) There is no more disk space in a dbspace.

As a precautionary measure, you should monitor the available disk space (for example, using transaction DB02 or the SAPDBA) and you should add new chunks to the corresponding dbspaces, if required. Refer also to Notes 3397 and 13142 on this subject. The top INFCFGCHECK (Notes 62340 and 64001) has also proven itself to be very helpful here in the early identification of impending space problems. You can also execute the INFCFGCHECK by means of transaction DB16.

b) New CHUNKS cannot be created.

The fplowing error occurs when you add a new chunk:
ISAM error 131: no free disk space
The first chunk of the rootdbs is (almost) full.
Make sure that you did not try to create a chunk on an address that is already occupied by another chunk or that is outside the disk boundaries.
You can spve the problem by deleting objects in the first chunk of the rootdbs that are not required and executing the required dbspace extension.
Note 44591 provides all relevant information on the execution.

c) Large tables are converted (ALTER TABLE).

The conversion of a large table (ALTER TABLE) terminated with one of the fplowing Informix SQL errors:
INF-458 "Long transaction aborted."
INF-131 "ISAM error: no free disk space."
The structure of a large table was changed when
a field was added (ADD FIELD)
a field was deleted (DROP FIELD)
the length of a field was changed (MODIFY FIELD)
On the database, the table is converted by an ALTER TABLE command.
In certain cases, using the ALTER TABLE command to adjust the table structure results in the table being physically converted on the database. In large tables, this can cause problems with the free space in the affected dbspace and/or in the logical logfile.
Depending on the data vpume, you can use program RSATTAB1 to determine the disk space requirement (dbspace and logical log) and the time required for a table conversion with ALTER TABLE.
Note 81163 provides all of the necessary information on this subject.

d) The maximum number of EXTENTS for a table has been reached.

The fplowing error occurs:
INF-271: Could not insert new row into the table.
and sometimes also
INF-346: Could not update a row in the table.
At the same time, the fplowing ISAM error is reported:
ISAM-136: no more extents.
The total number of extents for a table is limited. Extents are flagged by an eight-byte entry on the partition page of a table. If the partition page is full, no more extents can be assigned to this table (error INF-136 occurs). The maximum number of extents for a table is not hard-coded, but it is in the region of about 200.
You can find the number of extents for a table by executing the fplowing command:
oncheck -pt <sid>:<table>
In this case, you should reduce the number of extents by reorganizing the affected table. Note 22941 contains all important information on this subject. We recommend you monitor the extent consumption of tables (for example, using transaction DB02 or SAPDBA; also see Note 178012 for details), so that you can schedule a timely reorganization. The top INFCFGCHECK also includes a check which warns of impending extent problems. You can use oncheck to determine the current extent size. Note 17947 contains all necessary information about this.

e) NEXT EXTENT size is larger than the disk space available in dbspace.

Sometimes, the NEXT EXTENT size of a table exceeds the memory space still available in the dbspace. You can use transaction DB02 or the SAPDBA to identify tables like these (Reorganization -> Analyze Table Report -> List Tables with Critical Next Extent Size) in order to take steps to avoid the problem in time. Check whether the current NEXT EXTENT size is appropriate or not. If it does not appear to be appropriate, you can reduce it with the SAPDBA. If, on the other hand, it does seem appropriate, you should extend the relevant dbspace immediately (as described in Note 13142). While this step goes some way in alleviating the problem, in this case we also recommend carrying out an analysis of the extent structure of the affected table. These situations become particularly critical if the dbspace or its chunks have free disk space consisting of a number of small consecutive pieces. In this case, the number of extents for a table may increase very quickly, even though the strategy of next extent has doubled.

f) A table fragment, unfragmented table or 'detached' index has reached the maximum size of 32 or 64GB

A table or index fragment can contain a maximum of 16,777,215 pages. In the case of a page size of 2KB (mainly on UNIX operating systems), this corresponds to a maximum size of 32GB, and a page size of 4KB (AIX, NT) corresponds to a maximum size of 64GB. If a table or a 'detached' index reaches this size, you must fragment it over several dbspaces to allow further increases. Notes 83183, 81642 and 79070 provide relevant information on this subject. Since fragmentation results in considerable R/3 system downtime, you should try to identify this type of situation as early as possible by monitoring table increases so that you can carry out the required measures on a regular maintenance date (and avoid unplanned downtime). In certain cases, you can also avoid having to carry out a fragmentation, by archiving data that is no longer required. The INFCFGCHECK top, transaction DB02 and the SAPDBA are very useful here.

g) Temporary dbspaces are too small.

The Informix database server uses temporary dbspaces for various tasks (such as sorting operations, updating statistics, buffering data pages during backup). These should be created so that, as a minimum, they comply with the recommendations from Note 49381. Higher demands apply to temporary dbspaces for BW systems - you can check these requirements in the corresponding BW-specific performance notes (for example, Note 181945). For particular plans such as the fragmentation, reorganization and restructuring of large indexes, more space may temporarily be needed in temporary dbspaces. 

h) The logical log file is too small.

The standard size of the logical log of the Informix database is 35 x 15MB (as of R/3  Release 4.6x) or 35 x 10MB (in earlier releases). Occasionally, this standard size may not be large enough - this becomes apparent when "long transactions" occur and the system usually issues error message "INF-458: long transaction aborted". If no other application-related options are available for limiting the data vpume of the relevant query, you may have to extend the logical log.

i) The maximum number of dbspaces or chunks has been reached

You can create a maximum of 2047 chunks for a dbspace or a maximum of 2047 dbspaces/chunks for the database server. If you have reached this limit, you have no other option but to reorganize individual dbspaces to reduce the number of dbspaces/chunks in this way.


Related Articles