数据库项目组日常运维及应急故障处理手册docx.docx

数据库项目组日常运维及应急故障处理手册docx.docx

《数据库项目组日常运维及应急故障处理手册docx.docx》由会员分享，可在线阅读，更多相关《数据库项目组日常运维及应急故障处理手册docx.docx（147页珍藏版）》请在冰豆网上搜索。

数据库项目组日常运维及应急故障处理手册docx

常见问题及处理方案

CPU使用率高的问题

通过操作系统命令toptopasglance等查看top进程号，确认是系统进程还是oracle应用进程，查询当前top进程执行的操作和sql语句进行分析。

根据进程号获取正在执行的sql

SELECTa.osuser,a.username,b.address,b.hash_value,b.sql_textfromv$sessiona,v$sqltextb,v$processp

wherep.spid=&spid

andp.addr=a.paddr

anda.STATUS='ACTIVE'

anda.sql_address=b.address

orderbyaddress,piece;

数据库无法连接

数据库无法连接，一般可能是如下原因造成：

（1）数据库宕了

（2）监听异常

（3）数据库挂起

（4）归档目录满

（5）数据库或应用主机的网卡出现问题不能正常工作

（6）应用主机到数据库主机的网络出现问题。

1、数据库宕了

立即启动数据库。

2、监听异常

此时一般体现为：

监听进程占用CPU资源大；

监听日志异常。

此时，立即重启监听，监听重启一般能在1分钟之内完成。

3、数据库挂起

立即重启数据库。

4、归档目录满

（1）在没有部署OGG数据同步的情况下，立即清理归档日志文件。

（2）如果部署了OGG数据同步，查看OGG正在读取的归档日志文件，立即

清理OGG不再需要的日志文件。

5、数据库或应用主机的网卡出现问题不能正常工作。

立即联系主机工程师处理。

6、应用主机到数据库主机的网络出现问题。

立即联系网络维护人员查看。

CRS/GI无法启动

对于10g及11gR1版本的CRS问题

1、进入/tmp目录下，看是否产生了crsctl.xxxxx文件

如果有的话，看文件内容，一般会提示OCR无法访问，或者心跳IP无法

正常绑定等信息。

2、如果/tmp目录下没有crsctl.xxxxx文件

此时查看ocssd.log文件，看是否能从中得到有价值的信息。

可能的问题：

网络心跳不通。

3、/tmp目录无crsctl.xxxxx且日志中没有报错信息，只有停CRS时的日志信

息。

此时可能是RAC两个节点对并发裸设备的访问有问题，此时考虑：

（1）停掉两个节点的CRS。

（2）两个节点先同时去激活并发VG，然后再激活VG。

（3）重新启动CRS。

对于11gR2的GI问题

分析$GRID_HOME/log/nodename目录下的日志文件，看是否能从中找出无法启动的原因。

常见问题：

1、心跳IP不同。

2、ASM实例无法启动。

对CRS的故障诊断和分析,参加本文档中RAC部分的MOS文档.

数据库响应慢

应急处理步骤：

（1）找到占用CPU资源大的sql或者模块，然后停掉此应用模块。

（2）如果属于由于种种原因引起的数据库hang住情况，立即重启数据

库，此时重启需要约15分钟时间。

重要说明：

如果重启数据库的话，会有如下负面影响：

（1）要kill掉所有连接到数据库中的会话，所有会话都会回滚。

（2）立即重启的话，不能获取并保留分析数据库挂起原因的信息，在后续分析问题时，没有足够信息用于分析问题产生的根本原因。

一般正常重启的话，都需要手动获取用于分析数据库重启原因的信息，以便编写分析报告，但是在最长情况下，获取日志信息可能就要40分钟时间。

此时一般做systemstatedump，且如果是rac情况的话，需要2个节点都做，且需要做2次或以上。

常规处理步骤，分如下几种情况处理：

（1）所有业务模块都慢。

（2）部分业务模块慢。

（3）数据库hang住。

所有业务模块都慢

此时首先查看系统资源，看是否属于CPU资源使用率100%的问题，如果是，参考本章“CPU使用率高的问题”解决办法。

如果系统资源正常，那很可能是数据库hang住了，此时参考数据库Hang部分。

部分业务模块慢

分析运行慢的模块的sql语句：

（1）看是否是新上的sql。

（2）看执行计划是否高效。

（3）优化运行慢的模块的sql语句。

数据库hang住

应急处理方式：

重启数据库。

常规处理方式：

（1）分析alert日志，看是否能从alert日志中，可以很快找到引起问题的原

因。

（2）做3级别的hanganalyze，先做一次，然后隔一分钟以后再做一次。

并分析hanganalyze生成的trace文件，看是否可以找到引起数据库hang

住的会话的信息。

（3）做systemstatedump

此时生成systemstatedump的时间会比较长，尤其是在会话数量较多的情

况下。

且生成dump文件的大小较大，在G级别以上。

在生成一次以

后，过一分钟再收集一次，另外如果是RAC，那么两个节点都需要收

集。

对hang做dump请参考“对数据库HANG做DUMP一章”。

数据误删除

此问题，没有应急办法，只能按如下步骤处理：

1、对于10g及以上版本，看是否可以通过闪回进行恢复。

2、查看测试环境数据库，看其中是否有需要的数据。

3、使用备份进行恢复，此方法一般花费时间较长。

快速shutdown数据库

1.停止监听

2.做一个检查点操作

SQL>altersystemcheckpoint;

3.杀掉所有LOCAL=NO的操作系统进程

AIX、HP-UX、Linux、Solaris：

$ps-ef|grep$ORACLE_SID|grepLOCAL=NO|grep-vgrep|awk'{print$2}'|xargs-ikill-9{}

Windows：

SQL>select'orakill'||

（selectvaluefromv$parameterwherename='instance_name'）||''||p.spid

fromv$processp,v$bgprocessbp

wherep.ADDR=bp.PADDR（+）

andbp.PADDRisnull

andp.SPIDisnotnull;

在命令行执行：

C:

\>orakilldb17642

C:

\>orakilldb17644

4.停止数据库

SQL>shutdownimmediate

清理分布式事务

--9i需要设置_sum_debug_mode

SQL>altersessionset"_smu_debug_mode"=4;

altersessionsetnls_date_format='YYYY-MM-DDHH24:

MI:

SS';

columnlocal_trna_idformata20

columnglobal_tran_idformata25

SELECTLOCAL_TRAN_ID,GLOBAL_TRAN_ID,FAIL_TIME,STATE,MIXED

FROMDBA_2PC_PENDING;

LOCAL_TRAN_IDGLOBAL_TRAN_IDFAIL_TIMESTATEMIX

------------------------------------------------------------------------------

12.29.103137TAXIS.9572b613.12.29.10313730-aug-201110:

09:

11collectingno

SQL>commitforce'12.29.103137';

Commitcomplete.

SQL>EXECUTEDBMS_TRANSACTION.PURGE_LOST_DB_ENTRY（'12.29.103137'）;

PL/SQLproceduresuccessfullycompleted.

SQL>commit;--清理每个分布式事务都需要commit;

数据泵

1.相关参数

PARALLEL参数考虑

可以设置成物理CPU（不是逻辑CPU）数的两倍数目，然后调整

对于DataPumpExport，PARALLEL参数必须要小于等于dumpfiles数

对于DataPumpImport，PARALLEL不要比dump文件数大很多，可以大一些。

这个参数也指定了导入时创建索引的并行度。

PARALLEL只允许在企业版使用。

nohupexpdpsystem/managerschemas=kdjmDIRECTORY=DUMP_FILESPARALLEL=3dumpfile=expCASES_%U.dmplogfile=nnsiexp2008_12_28.log&

通配符%U,它指示文件将按需要创建,格式将为expCASES_nn.dmp,其中nn从01开始,然后按需要向上增加

相关监控

--监控长事务

setlinesize120

columnopnameheading'Operation'formata25

columntargetheading'Target'formata15

columnpctheading'Percent'format999

columnesheading'Elapsed|Seconds'format999999

columntrheading'Time|Remaining|Seconds'format99999

columnprogramformata30

columnmachineformata16

selectL.sidssid,

substr（opname,1,25）opname,

target,

trunc（（sofar/totalwork）*100）pct,

to_char（60*sofar*8192/（24*60*（last_update_time-start_time））/1024/1024/60,

'9999.0'）Rate,

round（elapsed_seconds/60,2）es,

round（time_remaining/60,2）tr,

program,

machine

fromv$session_longopsL,v$sessions

wheretime_remaining>0andl.sid=s.sid

orderbystart_time;

坏块恢复

在遇到坏块的时，一般应按以下的流程来处理：

1如果坏块的对象是索引，重建索引

2使用备份来进行恢复

3使用10231事件，或者DBMS_REPAIR.SKIP_CORRUPT_BLOCKS过程，让oracle跳过坏块，然后用exp导出表和使用CREATETABLEAS创建新表。

4尝试使用SQL脚本将完好的数据复制到一个新表中，或者用EXP配合QUERY参数导出完好的数据。

5手工修改坏块。

有两种情况是不能使用事件10231和DBMS_REPAIR.SKIP_CORRUPT_BLOCKS来跳过坏块的：

1硬件问题造成OS层不能读取数据。

2表中的非数据块，或者说是元数据块。

比如段头，ExtentMap块。

这种坏块是不能跳过的。

3在表中存在有其他异常的块，从单个块来看都没有损坏，checksum值也是正确的，但是有的块在段内却是有问题的。

比如在段的高水位下存在未格式化的块，查询这样的表时，会报ORA-8103错误；如果块的objectid与段在数据字典里的dataobjectid不相符，则会报ORA-1401错误。

Oracle数据文件的坏块，可分为物理坏块和逻辑坏块。

物理坏块（也称为介质坏块），指的是块格式本身是坏的，块内的数据没有任何意义。

而逻辑坏块，指的是块内的数据在逻辑上存在问题。

比如说索引块的索引值没有按从小到大排列。

物理坏块一般是由于内存问题、OS问题、IO子系统问题和硬件问题，逻辑坏块是由于ORACLEBUG等原因引起。

对数据库中的坏块进行验证。

RMAN>backupvalidatedatabase;

恢复一个数据文件上的多个坏块

RMAN>blockrecoverdatafile14block56,107,276,517;

检验后我们查V$DATABASE_BLOCK_CORRUPTION

SQL>select*fromv$database_block_corruption;

FILE#BLOCK#BLOCKSCORRUPTION_CHANGE#CORRUPTIO

---------------------------------------------------------

1427610CHECKSUM

1451710CHECKSUM

1410710CHECKSUM

145610CHECKSUM

还可以通过blockrecovercorruptionlist进行块的恢复，这是在大量块损坏时或全部块损坏时使用，

前提是先执行backupvalidatedatabase,在V$DATABASE_BLOCK_CORRUPTION里有对应的坏块的列表。

RMAN>blockrecovercorruptionlist;

SQLTUNING

SQLPROFILE

创建PROFILE

declare

v_hhintsys.sqlprof_attr;

cl_sql_textclob;

begin

selectSQL_TEXT

intocl_sql_text

fromv$sql

wheresql_id='1304vvhkfctzq'

andrownum<2;

v_hhint:

=sys.sqlprof_attr（'BEGIN_OUTLINE_DATA',

'IGNORE_OPTIM_EMBEDDED_HINTS',

'OPTIMIZER_FEATURES_ENABLE（''10.2.0.4''）',

'ALL_ROWS',

'OUTLINE_LEAF（@"SEL$1"）',

'INDEX_RS_ASC（@"SEL$1""T2"@"SEL$1"（"T2"."STATUS"））',

'END_OUTLINE_DATA'）;

dbms_sqltune.import_sql_profile（cl_sql_text,

v_hhint,

'SQLPROFILE_1304vvhkfctzq',

force_match=>true,

replace=>true）;

end;

/

获取PFOFILE的名字

SELECT name, created,category,sql_Text from dba_sql_profiles ORDER BY created DESC; 

删除PFOFILE

BEGIN 

  DBMS_SQLTUNE.DROP_SQL_PROFILE（name => 'PROFILE_NAME'）; 

END; 

/

获取OUTLINEHINT的信息

SELECTsql_attr.attr_valoutline_hints

FROMdba_sql_profilessql_profiles,sys.SQLPROF$ATTRsql_attr

WHEREsql_profiles.signature=sql_attr.signature

ANDsql_profiles.name='SQLPROFILE_1304vvhkfctzq'

ORDERBYsql_attr.attr#ASC;

STA

InordertoexecuteSqlTuningAdviserAPI,onemustbegrantedwith“ADVISER”role.

grantadviserto;

–foraspecificstatementfromAWR

SETSERVEROUTPUTON

 --TuningtaskcreatedforspecificastatementfromtheAWR.

DECLARE

  l_sql_tune_task_id VARCHAR2（100）;

BEGIN

  l_sql_tune_task_id:

=DBMS_SQLTUNE.create_tuning_task（

                      begin_snap =>764,

                      end_snap   =>938,

                      sql_id     =>'19v5guvsgcd1v',

                      scope      =>DBMS_SQLTUNE.scope_comprehensive,

                      time_limit =>60,

                      task_name  =>'19v5guvsgcd1v_AWR_tuning_task',

                      description=>'Tuningtaskforstatement19v5guvsgcd1vinAWR.'）;

  DBMS_OUTPUT.put_line（'l_sql_tune_task_id:

'||l_sql_tune_task_id）;

END;

–orforaspecificstatementfromSharedLibraryCache

DECLARE

  l_sql_tune_task_id VARCHAR2（100）;

BEGIN

  l_sql_tune_task_id:

=DBMS_SQLTUNE.create_tuning_task（

                          sql_id     =>'fhahkc71k304u',

                          scope      =>DBMS_SQLTUNE.scope_comprehensive,

                          time_limit =>60,

                          task_name  =>'fhahkc71k304u_tuning_task',

                          description=>'Tuningtaskforstatementfhahkc71k304u.'）;

  DBMS_OUTPUT.put_line（'l_sql_tune_task_id:

'||l_sql_tune_task_id）;

END;

/

--Interruptandresumeatuningtask.

EXECDBMS_SQLTUNE.interrupt_tuning_task（task_name=>'emp_dept_tuning_task'）;

EXECDBMS_SQLTUNE.resume_tuning_task（task_name=>'emp_dept_tuning_task'）;

--Cancelatuningtask.

EXECDBMS_SQLTUNE.cancel_tuning_task（task_name=>'emp_dept_tuning_task'）;

--Resetatuningtaskallowingittobere-executed.

EXECDBMS_SQLTUNE.reset_tuning_task（task_name=>'emp_dept_tuning_task'）;

executethetuningtask

EXECDBMS_SQLTUNE.execute_tuning_task（task_name=>'fhahkc71k304u_AWR_tuning_task'）;

reporttuningtaskfindings

SETLONG100000;

SETPAGESIZE1000

SETLINESIZE300

SELECTDBMS_SQLTUNE.report_tuning_task（'fhahkc71k304u_AWR_tuning_task'）ASrecommendationsFROMdual;

SETPAGESIZE24

acceptrecommendations

executedbms_sqltune.accept_sql_profile（task_name=>'fhahkc71k304u_AWR_tuning_task',replace=>TRUE）;

usefulviews

DBA_ADVISOR_TASKS

DBA_ADVISOR_FINDINGS

DBA_ADVISOR_RECOMMENDATIONS

DBA_ADVISOR_RATIONALE

DBA_SQLTUNE_STATISTICS

DBA_SQLTUNE_BINDS

DBA_SQLTUNE_PLANS

DBA_SQLSET

DBA_SQLSET_BINDS

DBA_SQLSET_STATEMENTS

DBA_SQLSET_REFERENCES

DBA_SQL_PROFILES

V$SQL

V$SQLAREA

V$ACTIVE_SESSION_HISTORY

收集统计信息

execdbms_stats.gather_table_stats（

ownname=>'SYS',

tabname=>'T2',

estimate_percent=>100,

cascade=>true,

method_opt=>'forallcolumnssize1'）;

显示执行计划

select*fromtable（dbms_xplan.display）;

select*fromtable（dbms_xplan.display_cursor（null,null,'ALLSTATSLAST'））;

select*fromtable（dbms_xplan.display_awr（'a7tgurqg403wp',null,null,'ALL'））;

显示执行计划的outline

select*fromtable（dbms_xplan.display_cursor（'sql_id',null,'outline'））;

显