ITPub博客

新连接报ORA-12560df -h检查空间满但du -sh /oracle却只有700多G，检查删除文件未释放空间发现有个进程占用较大空间kill掉进程后空间恢复

原表非分区表：T_EC_EVENT_CONTENT创建中间表：INIT_T_EC_EVENT_CONTENT创建中间分区表create table INIT_T_EC_EVENT_CONTENT(  EVENTID      VARCHAR2(50),  JHDATE       DATE not null,&nbsp

应用人员反馈数据库异常，连不上数据库，报错检查alert日志，无法打开日志：服务器后台无法正常登录数据库，通过prelim方式也登录不了数据库：$ sqlplus / as sysdbaSQL*plus: Release 11.2.0.4.0 Production on Thu oct 10 12:11:40 2024copyright(c)1982,2013,oracle. All rights

通过rman做check数据文件后，查询出对象及类型：SELECT e.owner,        e.segment_type,        e.segment_name,      &nb

1、问题描述在使用duplicate搭建DG时报错 包括rman copy，rman备份2、问题分析由于数据文件逻辑坏块导致物理备份不能正常进行。使用rman检查数据文件47 SELECT tablespace_name, segment_type, owner, segment_nameFROM dba_extents    &nbsp

表有坏块时，全表查询会报错：这时候如果有前面正常的rman备份，那么我们就可以通过rman备份直接对数据文件块做恢复先对数据文件做个逻辑检查：RMAN> backup check logical VALIDATE DATAFILE '+EXB_DATA/exb/datafile/cuteinfo.290.948015321';Starting backup at 13-APR

虚拟机查看磁盘空间均足够，但oracle数据库实例频繁宕机alert告警:Mon Sep 30 04:24:37 2024Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\trace\orcl_ckpt_3268.trc:ORA-00206: error in writing (block 3, # blocks 1) of cont

job执行plsql存储过程异常终止报错，alert日志如下查看导出dump文件Dump file /oracle/app/diag/rdbms/syora/SYORA2/incident/incdir_603756/SYORA2_ora_99344_i603756.trc发现有个删除触发器相关的表，检查框住的存储过程，发现里面有触发器的禁用启用，没有授权增删改系统表权限导致。但是原先是正常的，异

集群起来后gipcd服务不能正常启动检查gipcd日志：2024-08-26 00:29:50.745: [GIPCXCPT][2] gipcPostF [gipcd_ExitCB : gipcd.c : 431]: EXCEPTION[ ret gipcretInvalidObject (3) ]  failed to post obj 0000000000000000, flags

通过 sqlplus / as sysdba 连接数据库，第一次查询正常，再次查询报ORA-01000错误：SQL> select * from dba_tablespace_usage_metrics;select * from dba_tablespace_usage_metrics*ERROR at line 1:ORA-01000: maximum open cursors exce

oracle11g环境，alert日志一直报如下日志：Wed Aug 07 09:40:46 2024Maximum of 148 enabled roles exceeded for user ZHIS. Not loading all the roles.Maximum of 148 enabled roles exceeded for user ZHIS. Not loading all t

方式一：su - oraclesqlplus "/ as sysdba"SQL>select 'copy datafile '||''''||file_name||''''||' to '||''''||'/oradata/dkwhdb_

select * from v$fast_start_transactions;USN        SLT        SEQ STATE          &nbs

目标库上执行：迁移过程带lob字段的T_EC_EVENT表特别慢，停机时间太长，通过物化视图提前迁移T_EC_EVENT表。含lob字段大表通过dblink，创建物化视图（不停机）SQL> create materialized view T_EC_EVENT on prebuilt table refresh fast as select * from T_EC_EVENT@his_lk;

一个典型的增量备份案例，是按照一周为一个周期来进行备份：时间备份级别星期天晚上level   0 星期一晚上level   2 星期二晚上level   2 星期三晚上level   1 星期四晚上level   2星期五晚上level   2 星期六晚上level   21、l

检查alert日志，发现pga资源分配时报内存不足：由于pga内存不足，而导致的数据库宕机。查看操作系统日志：发现在宕机之前，出现了虚拟内存不足的情况。检查确认设置的虚拟内存大小为50多G：按道理不该出现虚拟内存不足的情况，检查操作系统发现，默认C盘剩余空间比较少剩余空间不足于支撑50G的虚拟内存空间，所以导致交换内存出现异常，最终导致实例宕机。安装服务器一般C盘的物理空间会被服务器当做虚拟内存使

解析非常高，通过时间模型可以看到解析占比非常高解析大致可以分为硬解析（ hard parse）、软解析（ soft parse）和软软解析（ soft soft parse）。如，执行一条 SQL 的时候，如果该 SQL 在共享池中不存在，这就是硬解析，需要首先分配共享池空间，创建父游标的结构，然后创建一个子游标。如果下一次再执行一条类似的 SQL，该 SQL 的父游标存在，经过检查发现子游标是可

当业务卡的时候，发现大量等待事件为enq: SQ – contention，检查awr的top 5事件：sql语句对sequence的调用非常频繁：SQL> select SEQUENCE_OWNER,SEQUENCE_NAME,CACHE_SIZE from dba_sequences where SEQUENCE_name=&#

一大早就有喊业务卡的，检查等待事件源头，均为oracle写等待查看IO负载持续维持在100%繁忙后台有两个并行rman备份在，停止备份io繁忙没有好转，检查最近ash报告，发现DDTEK ODBC Oracle程序模块占用最高检查该模块，发现是通过odbc过来的挖掘程序。等待事件是直接路径读：检查后台，发现直接路径读和DDTEK ODBC Oracle等待事

业务连接报ora-01033： 检查服务器，发现有重启记录，oracle进程存在，数据库状态处于mount状态，检查日志，发现在数据库启动时没有正常open：连入数据库：Select * from v$backup发现数据文件都处于热备模式Alter database end backupAlter database open成功打开。造