Level 1 - contains the basic level of trace information. For example, this trace level will display the bind variables in PL/SQL and SQL statements.
续上篇：http://blog.csdn.net/bisal/article/details/39225373
环境：RHEL 6.5(x86-64) + Oracle 11.2.0.4 声明：推进SCN属于非常规恢复范畴，不建议非专业人员操作，否则后果自负。 需求：我这里演示下推进SCN 10W数量级，实际需求推进多少可以根据ORA-600 [2662] [a] [b] [c] [d] [e]具体值来确认。
AWR是ORACLE数据库重要的诊断工具，但是有时可能遇到AWR快照无法获取的问题，影响性能监测。本文介绍如何诊断和解决这类问题。
客户的一套开发环境，大概了解到的背景是清理空间时redo被运维人员当作log误删除，一线同事先接手处理，过程中遇到问题升级到我这里继续分析。 接手后，数据库处于mount状态，之前恢复过程中已经做过resetlogs的操作，也设置了"_allow_resetlogs_corruption"隐藏参数为true，目前直接开库会提示需要恢复，重新进行resetlogs时报错ORA-600 [2662]，起初看到这个错误心中略有些放松，根据经验，推下SCN就好了：
诊断 ’library cache: mutex X’ 等待 (Doc ID 2331144.1)
崔华，网名 dbsnake Oracle ACE Director，ACOUG 核心专家 在很多数据恢复的场景中，我们可能需要调节SCN，但是一个重要的隐含参数_minimum_giga_scn，在Oracle 11.2.0.2打上相关的SCN的补丁以及后续的版本中已经被废弃。 Connected to Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 Connected as SYS SQL> select count(*) from
崔华，网名 dbsnake Oracle ACE Director，ACOUG 核心专家 编辑手记：感谢崔华授权我们独家转载其精品文章，也欢迎大家向“Oracle”社区投稿。 我们都知道在 Oracle 数据库里是“读不阻塞写，写不阻塞读”，那么是否可以认为在正常情况下，select 操作是怎样都能执行，始终不会被 hang 住的呢？注意这里提到的是正常情况下，不包括那些由于 latch 被 hold 住、或者 bug 等相关异常导致的 select 操作 hang 住的情况。 答案是：不可以这样认为
在Oracle中，Redo日志文件包含所有的数据库变化历史记录，例如所有的DML变化（INSERT、UPDATE、DELETE和SELECT FOR UPDATE）和所有DDL语句造成的数据字典对象的更改及递归语句的更改等，所以redo文件可以最大限度地保证数据的一致性与安全性。万一数据库出现故障可以启用数据恢复。但是redo日志被误删了怎么办呢？本文通过一个案例来了解一下redo日志被误删，强制开库遭遇ORA-16433，供大家参考。
《一个执行计划异常变更的案例 - 外传之rolling invalidation》
墨墨导读：客户的一套开发环境，清理空间时redo被运维人员当作log误删除，一线同事先接手处理，过程中遇到问题升级本文做出分析。
因为TRACE的目标范围不同，所以导致必须使用不同的方法。若作用于数据库全局的，则改初始化参数。若只作用于当前会话的，则就用ALTER SESSION命令。若作用于其它会话的，则就用DBMS_SYSTEM包。
我们这里简单的以ORA - 942 table or view does not exist为例
在启动Oracle实例之前，必须定义ORACLE_SID，Oracle根据SID的HASH值来唯一确定一个实例的地址。当打开SQL*Plus工具，输入“sqlplus / as sysdba”以后，系统根据SID进行HASH，查找在共享内存中是否有相应的共享内存段（SHMID）存在，如果有，那么返回connected，否则返回connect to an idle instance，这个实例名是存放在SGA中的variable size中。
1.故障现象描述 2.确认故障现象 3.排查ASM层面 4.解决问题 1.故障现象描述 环境：AIX 7.1 + Standalone Oracle 11.2.0.4 现象：客户反映某11g版本的ADG备库无法正常进行任何查询，数据库alert发现ORA-00494：enqueue [CF] held for too long (more than 900 seconds) by 'inst 1, osid 18875390'. 2.确认故障现象 登录到db实例，尝试查询select open_mode
之前在《Oracle RAC环境下定位并杀掉最终阻塞的会话》中，最终使用一个SQL查询出RAC实例之间的所有阻塞关系。但是实际在某些极端的生产环境，是不允许执行复杂的SQL语句，即使允许执行可能现场也不方便复制SQL，手敲的话效率低下，那么本文就介绍另一种简单的方法来快速定位最终阻塞会话，也就是DBA常用的oradebug hanganalyze。 1.模拟故障 2.oradebug hanganalyze 3.分析trace文件 1.模拟故障 直接根据《Oracle RAC环境下定位并杀掉最终阻塞的会话》
作者 孟庆辉 沃趣科技数据库工程师 当数据库出现严重的性能问题或者hang了的时候，我们非常需要通过systemstate dump来知道进程在做什么，在等待什么，谁是资源的持有者，谁阻塞了别人。 在出现上述问题时，及时收集systemstate dump非常有助于问题原因的分析。 systemstate dump级别简介： 1. 级别2:dump(不包括lock element) 2. 级别10:dump 3. 级别11:dump+global cache of rac 4. 级别256:short s
主题：EXP导出aud$报错EXP-00008,ORA-00904 解决 环境：Oracle 11.2.0.4 问题：在自己的测试环境，导出sys用户下的aud$表报错。
彭小波 ACOUG核心成员，Oracle用户组年轻专家。擅长Oracle数据库架构规划、SQL,OWI方面的优化。曾服务于各大企业数据库的维护以及系统开发，目前从事百年人寿保险股份有限公司的数据库服务与运维工作。 产生的背景： Oracle为了将物理 IO 最小化，把最近使用过的数据块保持在内存中。为了管理这些内存，oracle 使用如图的结构，Hash Chain 的结构，Hash Chain 位于共享池中，使用典型内存结构 Bucket->Chain->Header 结构进行管理 lock#
原文链接：https://blogs.oracle.com/database4cn/10046casetrace
通过查询基本视图，确认数据库和实例处于正常运行状态，可以对外提供数据服务。1.1实例状态1.1实例状态SELECT instance_name,status FROM gv$instance;查询返回实例名称、状态，正常状态应为Open。$crsctl status resource –t集群状态select name,open_mode from v$PDBS;PDB状态GDSCTL> config shardSharding状态1.2会话信息1.2会话信息SELECTSESSIONS_CURRENT,
故障场景：AIX IBM存储更换存储控制器电源模块导致存储双控同时掉电，存储双控恢复供电后发生锁盘，IBM解盘后 RAC数据库无法正常启动，启动报错：ORA-00600: internal error code, arguments: [2131], [33], [32], [], [], [], [], [], [], [], [], []
本文作者系Scott（中文名陈晓辉），现任大连华信资深分析师 ，ORACLE数据库专家，曾就职于甲骨文中国。个人主页：segmentfault.com/u/db_perf ，经其本人授权发布。
因公司断电，导致生产数据库宕机，开启后，出现ORA-00600[2662]问题：ORA-00600: internal error code, arguments: [2662], [2], [1424107441], [2], [1424142235], [8388617], [], []。
环境：OEL 5.7 + Oracle 10.2.0.5 背景：在Oracle的运维过程中，时常会遇到一些场景是需要重建控制文件才可以解决的。本文的场景可以通过复制控制文件到新路径，运行一段时间后，再用老的控制文件启动数据库重现。
这两天我一直在想一个问题，那就是 Oracle 的执行计划到底存储在什么地儿？它会是一种什么样的格式？ 这里我试图对这个问题做一点我自己认为的解释，这个解释可能是有问题的。 朋友们在看这篇文章之前，应
通过Optimizer Trace（10053 Event）可以跟踪优化器（CBO）的动作内容，了解CBO是如何选择最优执行计划的，诊断SQL解析时的相关问题。
Oracle研究中心学习笔记：分享一篇关于Oracle数据库关于SQL解析的详细文档，该文档详细介绍使用10049 event事件来分析SQL语句的解析笔记。
跟踪文件（Trace File）一般位于“user_dump_dest”参数所指定的目录中，具体路径可以通过以下几种方式查询获得。
作者 | 胡佳伟：云和恩墨技术工程师，有多年数据库优化经验，在一线执行过多个包括通信、保险等行业的优化项目。
SQL_TRACE是Oracle提供的用于进行SQL跟踪的手段，是强有力的辅助诊断工具。在日常的数据库问题诊断和解决中，SQL_TRACE是非常常用的方法。可以设置SQL_TRACE为TRUE，但是一般不推荐在全局指定为TRUE，只建议在会话级别指定。若在全局设定则对性能会造成较大影响。
众所周知，TRUNCATE TABLE是一种快速清空表内数据的一种方式，与delete方式不同，truncate只产生非常少的redo和undo，就实现了清空表数据并降低表HWM的功能。本文主要围绕TRUNCATE TABLE的实现原理和TRUNCATE TABLE的恢复来展开。
主题：RAC某节点v$asm_disk查询hang分析处理 环境：Oracle 11.2.0.3 RAC 故障描述：RAC环境2个节点，节点1查询v$asm_disk正常返回结果，节点2查询v$asm_disk就会一直hang，查询会话对应event是ASM file metadata operation.
好奇心是我们学习过程中最好的老师，对于Oracle的研究和学习也是如此，在遇到未知的问题时要善于提出为什么。本文将从问题出发，和大家一起解密Oracle rdba结构。
墨墨导读：某客户的数据库一条insert某段时间突然变慢，平均单次执行逻辑读暴增至20万，本文分享整个处理过程。
墨墨导读：某客户的数据库一条insert某段时间突然变慢，平均单次执行逻辑读暴增至20万，最终定位为insert时因可用空间不充足递归清理recyclebin中的对象导致。
为了及时共享行业案例，通告共性问题，达成知识共享和提前预防，我们整理和编辑了《云和恩墨技术通讯》（8月刊），通过对过去一段时间的知识回顾和故障归纳，以期提供有价值的信息供大家参考。 同时，我们也希望能够将热点事件、新的产品特性及其他有价值的信息聚集起来，为您提供具有前瞻性的支持信息，保持对于当前最新的数据库新闻和事件的了解，其中包括重要数据库产品发布、警报、更新、新版本、补丁等。
优化器是 Oracle 数据库最引人入胜的部件之一，因为它对每一个 SQL 语句的处理都必不可少。优化器为每个 SQL 语句确定最有效的执行计划，这是基于给定的查询的结构，可用的关于底层对象的统计信息，以及所有与优化器和执行相关的特性。因此 Oracle 在每一个版本中，优化器都引入了新特性，本文将详细讲解 12C 中标量子查询自动转换的新特性的原理，优势，适用场景和案例分享。 1 12C 标量子查询自动转换说明 首先我们来看官方文档的说明： 标量子查询是出现在 SQL 语句的 SELECT 子句的子查询。
优化器是 Oracle 数据库最引人入胜的部件之一，因为它对每一个 SQL 语句的处理都必不可少。优化器为每个 SQL 语句确定最有效的执行计划，这是基于给定的查询的结构，可用的关于底层对象的统计信息，以及所有与优化器和执行相关的特性。因此 Oracle 在每一个版本中，优化器都引入了新特性，本文将详细讲解 12C 中标量子查询自动转换的新特性的原理，优势，适用场景和案例分享。
为了诊断SQL性能或者其他方面的问题，有时我们需要跟踪SQL语句和的执行过程，这时我们可以启用SQL Trace （10046 Event）来收集语句的执行过程和各种相关信息。
1、情况概述： 早上公司一个业务系统zabbix告警没正常同步数据，经过排查日志有connect reset情况：
我做实验的过程中有一个诡异的情况，我先把redo文件从操作系统层面都删除了，但是数据库正常创建表，insert数据，我理解的是当你commit的时候，会触发lgwr进程从redo log buffer中涮新redo 到redo 文件中，但是redo文件已经被删除了，就会报错，但是他并没有报错：
.原文：https://www.enmotech.com/web/detail/1/763/1.html
ORA-04030报错形如“ORA-04030 'out of process memory when trying to allocate %s bytes (%s,%s)'”，该错误意味着Oracle Server进程无法从操作系统分配更多内存。该内存由PGA组成，其内容取决于服务器配置。对于专用的服务器进程，内存包含堆栈以及用于保存用户会话数据、游标信息和排序区的UGA。在多线程服务器（共享服务器）中，UGA被分配在SGA中，所以在这种配置下UGA不是造成ORA-04030错误的原因。因此，ORA-04030表示进程需要更多内存（堆栈、UGA或PGA）来执行其任务。
墨墨导读：本文讲述各种场景下的通用处理思路，分享用到的一些脚本，帮助大家快速定位问题并解决，减少业务的中断事件。
数据库中的session在操作中可能会有各种各样的问题，比如一条sql语句执行失败，某一个应用在一些特定的场景下就会有一些性能问题等等，有时候在代码层去做一些debug来说肯定是不实际的，而且也不一定能够迅速的排查问题，对于session的监控显得尤为重要。可以灵活的开启和关闭，在数据库层面，session层面，甚至特定的应用层面都能够进行监控，今天和大家分享一下对于的session监控常用的一些方法。 1.dbms_system.set_sql_trace_in_session 可以对其他的session
作为一名混迹数据库江湖十几年的老DBA，当你对关系型数据库的了解越来越深入时，你会发现，Oracle数据库真的是强大到令人发紫！ Oracle数据库的强大，不仅体现在其对ACID的巧妙实现，其对高并发的完美支持，更重要的是他的可管理性，包括可度量、可回溯，以及出现问题后的问题核查接口和问题检查方法论，真是强大到令人发紫,这是其他关系型数据库短期内还无法超越的。 中亦科技小y（黄远邦) 问题引入 电话响了，是某银行一位熟悉的资深DBA的来电。 “小y,现在应用连接数据库会hang住，sysdba登陆也会han
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
