Skip to main content
ExLibris
  • Subscribe by RSS
  • Ex Libris Knowledge Center

    Nagios gives: "warning ... cannot allocate a next extent."

    • Article Type: General
    • Product: Aleph
    • Product Version: 20

    Description:
    Our university IT uses Nagios as a system monitor. In the past several days, we started to receive warnings. Please take a look at the following warning message and help us on this.

    ==============================================
    Nagios wrote:
    > abccat.aleph20: warning: ABC01.Z95(TABLE) ABC01.Z98(TABLE) ABC01.Z980(TABLE) ABC10.Z980(TABLE) ABC01.Z00R(TABLE) cannot allocate a next extent.
    >
    > Notification Type: PROBLEM
    > Service: oracle
    ...
    ...
    > State: WARNING
    > Date/Time: Thu Apr 15 06:37:24 EDT 2010

    Resolution:
    As can be seen in the abcl01 file_list, these tables reside in the TS4D tablespace.

    util o/14/1 doesn't show any special problem with the TS4D. (See KB 16384-19858 for interpretation.)

    These grep's in the $LOGDIR directory get no hits:

    > grep -i z95 *pc_server_6998.log.*04.*
    > grep -i z00r *pc_server_6998.log.*04.*

    I tried to look at the Oracle alert log, but had the problem with permissions described in KB 16384-21059. Please log on as root, update the permissions as described, and then do the above greps in the alert log.

    If you don't get hits, it may be that your datafiles are AUTOEXTENSIBLE (see KB 16384-19858) and that, though there was a temporary problem in allocating another extent, once space was added by AUTOEXTEND, the problem was fixed.

    If so, this may be why Nagios only shows this as a "WARNING".

    [Site replied that the datafiles are *not* AUTOEXTENSIBLE.]

    [From Jerry:] If/when you see the message again, I think you should:

    1) Do util o/14/1 to confirm that the tablespace the table resides in is not out of space

    2) Check the Oracle alert log to see if there's any error message there

    3) If not, contact Nagios Support to see why these messages are being written.

    [From site:] Our university IT staff fixed this problem. Here's what they found and did:

    Basically, the next chunk of disk that would
    have been added to a number of tables was larger than the free space
    in the table space. So, if the table needed to extend, it could not
    have.

    Although the next_extent size for these tables is large at 2gb, the
    tables themselves are large. So, I added a 4gb extention to the
    tablespace, and that seems to have cleared the problem.


    • Article last edited: 10/8/2013