DBA经常遇到的十个比较常见的问题

This document contains information about errors frequently encountered by
new DBAs, along with appropriate actions to be taken in each circumstance.

1)  ORA-1547
    a) on Rollback segment when importing.
       Specify commit=y and a large buffer on import. This way the Rollback
       will be released after each array, as opposed to each object.
    b) when allocating an extent on a tablespace with alot of free space.
       Select max(blocks) from DBA_FREE_SPACE. You may have free space but it
       might not be contiguous. Make sure it is greater than the extent it
       is trying to allocate. You can reduce the storage parameters NEXT and
       PCTINCREASE if it isn't.
2)  ORA-1556 max extents of 121 exceeded when storage is set for maxextents
    of 999.
    Most platforms have a max of 121 even though it allows you to specify
    999.  (see the readme for your platform)
3)  ORA-1090 shutdown in progress when starting up even after a shutdown was
    issued quite some time ago.
    If the background processes aren't running the SGA could have been left
    out there... Issue a startup force open (which does a shutdown abort
    first).
4)  IMP-0003, ORA-942 and IMP-00023 on import.
    Run catalog.sql and expvew.sql (renamed catexp.sql in v7) as sys before
    the import. Both files are in $ORACLE_HOME/rdbms/admin (UNIX).
5)  ORA-904 Invalid column name on import.
    Run expvew.sql (catexp.sql) before the import.
6)  ORA-1034 Oracle not available.
    Startup the DB first...if it is started check your searchpath.
    Make sure that ORACLE_SID is set correctly  For setuid issues, see
    PRE 1006554.6.
7)  ORA-1578 Oracle Data Block corrupted (file # num and block # num)
    To determine where the corruption is:
    select * from sys.dba_extents where file_id = filenum and blocknum
    between block_id and (block_id + blocks - 1);
    The filenum and blocknum are the numbers in the 1578 error.
    This query should give the segment_name and segment_type
    (i.e table and its name).
    In order to salvage the uncorrupted part of the table you can add
    an entry to the init.ora:
    event = "10231 trace name context forever"
    This will skip the corrupted block on a table scan. Export the table,
    drop and recreate it from import.
8)  ORA-604 what does it mean?
    Usually it comes with another error such as 1547....if it can't be found
    in any of the trace files try setting the following event in init.ora and
    restarting the DB.
    event="604 trace name errorstack forever"
    for the output of this look in the trace files in the directory given by
    the USER_DUMP_DEST parameter in init.ora.
9)  My create database is failing with ORA-1519: error while processing file
    Take out the INIT_SQL_FILES param out of init.ora, run the scripts
    by hand after the database is created.
10) Out of shared memory (ORA-4031).
    Try de-fragmenting the shared pool by running an 'alter system flush
    shared_pool' If that is not enough, increase the shared_pool_size
    parameter.

[[i] 本帖最后由 rwq_ 于 2007-4-22 16:44 编辑 [/i]]

谢谢老大分享

第10个不是de-fragmentation而是flush out，也就是清空cache了的explained sql statment，那些经常使用的sql遇到再次解析时，需要重新生成查询计划。

[quote]原帖由 [i]statistics[/i] 于 2007-4-23 20:14 发表 [url=http://www.loveunix.com/redirect.php?goto=findpost&pid=654773&ptid=71597][img]http://www.loveunix.com/images/common/back.gif[/img][/url]
第10个不是de-fragmentation而是flush out，也就是清空cache了的explained sql statment，那些经常使用的sql遇到再次解析时，需要重新生成查询计划。 [/quote]


哈哈，好眼力，


这只是基本的处理办法而已。关于ORA-04031问题，在METALINK上可以找到一大堆的资料出来。

谢谢老大分享

我是没有遇到的

thanks

学习了


只有几个问题碰到过

学习了


只有几个问题碰到过