X

一线数据库工程师的精彩案例分享、新特性介绍、诊断工具和诊断方法、以及常用的测试案例 -- 欢迎光临Oracle数据库中文技术支持官方微博

Recent Posts

TimesTen

Oracle TimesTen 关系型内存数据库 18.1 新版本详解

提到TimesTen,首先来介绍一下什么是 Oracle TimesTen? 简单来说,Oracle TimesTen内存数据库是一个全功能,内存优化的关系型数据库。它主要面向有关系型数据库语义、强一致性和相关功能需求的OLTP应用程序,且具有大规模的水平扩展和超高吞吐量能力。。 TimesTen 是一款历经20年市场考验的,成熟的关系型内存数据库产品! TimesTen 早在1998年就作为全球首款内存关系型数据库面世。在过去的20年时间里,TimesTen 内存数据库不但为数以千计的企业客户提供高质量的服务,来满足他们对关键业务,核心系统的要求,而且推出了非常多的新版本,新功能来更好的兼容,无缝的集成Oracle数据库和其应用程序。 TimesTen利用内存计算优势,在应用层部署可以获得非常快的响应速度,可以在普通商用x86硬件服务器上,轻松达到微秒级的响应速度,以及相应在单位时间内超高的吞吐量。  TimesTen 内存数据库在部署上也是非常的灵活。 Classic 模式 TimesTen 本身就是一款关系型内存数据库产品。可以为应用程序提供独立的数据库服务! 这种场景下,TimesTen 作为数据库独立存储数据并可以结合强大的高可用性解决方案来实现既有高性能,也拥有内置的基于复制技术的高可用性和容灾能力。 TimesTen 通常建议部署在与应用相同的服务器上,数据库的总容量取决于服务器的物理内存容量。 具体产品说明,可以参考 TimesTen 传统版本白皮书:  https://www.oracle.com/technetwork/products/timesten/overview/wp-timesten-tech-132016.pdf  缓存模式 更为重要的一点是,对于已有的Oracle数据库用户也可以通过其高速缓存的配置来加速已有的Oracle数据库的OLTP应用。 值得一提的是,不同于其他NoSQL缓存需要重写应用程序,对于TimesTen的高速缓存来说,是一套简单的配置过程。 具体的配置可以参考 TimesTen 缓存白皮书: https://www.oracle.com/technetwork/database/database-technologies/timesten/overview/wp-timesten-cache-2215629.pdf   简单配置完成后,就可以将Oracle数据库中的热点数据子集缓存到一个或者多个 TimesTen 数据库中,使得Oracle应用程序充分利用TimesTen 丰富的 Oracle 缓存功能,极大的提高应用的响应性能。 TimesTen 的 缓存功能提供数据在Oracle数据库和 TimesTen 数据库之间的同步。通过TimesTen的高可用和容灾能力,还可以实现真正意义上的多维MAA(最大高可用架构)。 具体的配置方法和高可用案例,请参考TimesTen 高可用白皮书: https://www.oracle.com/technetwork/database/database-technologies/timesten/overview/wp-timesten-ha-2735640.pdf   分布式模式 在TimesTen 18.1版本中,TimesTen产品家族引入了全新的分布式数据库部署方式 - TimesTen Scaleout  TimesTen Scaleout 是速度最快的、基于SQL的、OLTP 优化的分布式关系型内存数据库。基于 TimesTen 内存数据库的行业实力,这款分布式新功能受益于 TimesTen 成熟产品的所有的领先功能。例如,TimesTen 横向扩展功能具有复杂的 SQL 处理引擎和基于成本的优化器,远比所谓的 "NewSQL" 数据库提供的产品更先进。 TimesTen Scaleout 支持标准的 API,如 JDBC,ODBC,OCI 和 Oracle 数据库兼容的 SQL,PL/SQL 和数据类型。 另外,与大多数 "NewSQL" 数据库不同,TimesTen Scaleout 基于原生引擎、支持完整的 ACID 事务属性、多语句事务、约束和全局二级索引。 这种新的横向扩展体系结构在18.1版本中可在多达64台主机上实现透明扩展,并通过 active-active 数据同步的方式实现内置多副本高可用能力。  在 TimesTen Scaleout 中,TimesTen 数据库作为分布式数据库部署在多节点环境中。通过利用 TimesTen 的并行跨节点处理,透明数据位置和可伸缩性,使得具有高吞吐量要求的应用程序可以在此模式下运行。 主要特点    -- 基于成熟、强大和高性能的内存数据库(TimesTen引擎)构建而成    -- 将多台计算机的强大功能整合为一个无共享架构的单一逻辑数据库    -- 为了简单起见,使用单个数据库映像进行透明的自动数据分发    -- 通过 K-safety 提供自动高可用性    -- 完全分布式的高性能 ACID 事务处理可随时提供数据一致性    -- 集中部署以便于管理和监控    -- 使用标准数据库API和标准 SQL 应用场景 包括(但不限于)以下内容: -- 实时计费 -- 实时风控 -- 实时交易 -- 实时授权 -- 实时设备跟踪 (IoT) 架构特点 TimesTen Scaleout 的所有安装,配置和管理任务均可方便地集中管理,并可从单个管理实例执行。此实例不参与应用程序 SQL 或事务执行, 而是存储有关系统配置和拓扑的元数据以及各种组件的状态。它编排跨所有配置主机的 TimesTen 软件的安装和配置。管理员永远不必登录到其他用户数据存放的主机来执行这些管理操作。为了提高可用性,还可以配置第二个管理实例。 应用开发 对于绝大多数的分布式系统来说,都要求应用程序根据具体分布式产品的要求重新定制开发。 而 TimesTen Scaleout 的分布式数据库不但支持丰富的开发 API,而且实现了支持 SQL 应用的能力! 对于应用开发者来说,只需要做极小的代码改造(比如连接串指向变更、failover 处理等),即可享受到分布式数据库带来的高并发、高吞吐量的服务! TimesTen 18.1 在 GitHub 上发布了开源的样例程序。感兴趣的朋友们可以看一下基于 JDBC 和 ODBC 的样例程序与当前实际运行中的业务系统的 SQL 应用程序有多少区别。 https://github.com/oracle/oracle-timesten-samples/tree/master/quickstart/scaleout/sample_config 运维能力 TimesTen Scaleout 拥有强大的运维交付能力!它不但推出全新的中控命令行工具,而且还支持通过图形界面工具管理、开发和运维TimesTen Scaleout。 用户能够通过全新的中控命令行工具来实现一键安装、一键管理的需求! 下面列出产品自带安装样例的简要说明: ttGridRollout 一键安装 <installation_dir>/bin/ttGridRollout <config_file_name>  ttGridAdmin一键监控  ttGridAdmin 中控(Central Management)命令工具是 TimesTen Scaleout 的核心管理工具。用户、DBA 只需要登录管理实例,运行 ttGridAdmin 命令,即可实现对分布式内存数据库的监控、配置、管理、问题诊断等一系列操作。这也是真正意义上的可交付、可运维的分布式系统! 具体的 ttGridAdmin 命令选项如下: 图形化工具 让人兴奋的是,用户可以通过 SQL Developer 免费工具轻松的来监控、开发、配置和管理数十个节点的分布式数据库! OTN 官网提供了虚拟机镜像,可以方便的上手进行产品的体验 http://www.oracle.com/technetwork/database/database-technologies/timesten/downloads/index.html   可以通过下面的链接,直接下载虚拟机 OVA 镜像文件(内置入门手册实践) 强力推荐!http://www.oracle.com/technetwork/database/database-technologies/timesten/downloads/timesten-181-vm-download-4480199.html 我们很高兴能够在产品发布后短短一个月时间内,帮助国内某客户将其基于 TimesTen 传统架构的生产环境成功改造为 TimesTen Scaleout,整个过程用户代码几乎没有更改,并获得了三倍以上的性能提升! 最后,值得一提的是,Oracle TimesTen 内存数据库产品家族在中国还拥有非常丰富的原厂资源,实现了从销售团队、现场运维团队、远程支持团队、OU 培训以及研发团队的本地化支持。欢迎下载体验TimesTen 产品! 转载文章,原文出自 https://mp.weixin.qq.com/s/nvGsYjIyKaw8YlLXzdo1ug

提到TimesTen,首先来介绍一下什么是 Oracle TimesTen? 简单来说,Oracle TimesTen内存数据库是一个全功能,内存优化的关系型数据库。它主要面向有关系型数据库语义、强一致性和相关功能需求的OLTP应用程序,且具有大规模的水平扩展和超高吞吐量能力。。 TimesTen 是一款历经20年市场考验的,成熟的关系型内存数据库产品! TimesTen 早在1998年就作为全球首款内存...

技术支持通讯

又有新的数据库中文文档添加到 My Oracle Support 中了! (2018年11月)

最新翻译的文档列表: <Document 2469644.1> 在64位 OL7 或者 RHEL7 上安装 Oracle 18c 数据库的要求 <Document 2469645.1> 在64位 OL6 或者 RHEL6 上安装 Oracle 18c 数据库的要求 <Document 2469647.1> Oracle DB 18c - 手动升级到 Non-CDB Oracle Database 18c 的完整核对清单 <Document 2469646.1> Oracle 18c - 配置只读 OracleHome / DBCA / Patching / Upgrade <Document 2469648.1> Oracle Database 12c Release 2 (12.2) 升级新特性 <Document 2469591.1> 12.2 Oracle Net Tracing新特性 - 产生Trace文件时限制时间 (Client, Server 和 Listener) <Document 2469594.1> 12c 客户端通过 SQL*Plus 远程连接会有将近 9 - 10秒延迟 <Document 2469592.1> 18c 自适应序列 (Scalable Sequences) <Document 2469593.1> 18.1 新特性:内联外部表 (Inline External Table) <Document 2469595.1> 12c 中不必要的 Invalidations <Document 2469596.1> 使用 Resource Manager 限制每个会话级别的 PGA 使用情况 - 12.2新功能 <Document 2469597.1> 12.2新特性 - 使用PDB Performance Profiles在PDB间管理OS资源 <Document 2469585.1> 12.2 新功能:Database In-Memory (IM) 快速启动 <Document 2469586.1> 12.2.0.1 DataPump用户:DataPump导出作业结束时的长等待时间 <Document 2469587.1> 由于频繁等待 ”Streams AQ: Enqueue Blocked On Low Memory" 而导致Datapump Expdp或Impdp变慢 <Document 2469588.1> 当数据库应用2018年4月DBBP后导入转储文件时出现错误 'ORA-39142: incompatible version number 4.2' <Document 2469601.1> Alert - 应用 12.1.0.2.180417DBBP 或更高版本后 DataPump 中出现的问题 <Document 2469673.1> 18c:如何在线合并分区和子分区 <Document 2469602.1> enq:MS - Contention 物化视图刷新期间的争用 <Document 2469604.1> 12.2:删除物化视图非常慢或挂起 <Document 2469607.1> 用户不应使用"_ORACLE_SCRIPT"=TRUE参数 <Document 2472643.1> 如何在 12.2.0.1 通过 dblink 在线克隆 PDB <Document 2471049.1> 如何启用和禁用并行 <Document 2469640.1> Oracle 12.2 中的索引监控功能 <Document 2469649.1> Optimizer Expression Statistics监控功能导致 SYSAUX 空间激增 <Document 2469650.1> 如何在 Active Data Guard 备库中生成AWR <Document 2469635.1> 容器数据库重复报 ORA-12012, ORA-20001, ORA-06512 <Document 2469636.1> Sql 等待 'PGA Memory Operation' <Document 2469637.1> 如何在12.2或更高版本的PDB级别创建AWR报告 <Document 2469639.1> 高版本数(>1024)的SQL语句在升级到12.2及更高版本后会导致数据库性能下降 <Document 2469656.1> 18c新特性Memoptimized Rowstore <Document 2469675.1> ORA-16086:Redo无法写入standby redo log 报有 RFS[368]: No standby redo logfiles selected (reason:7) <Document 2469657.1> 使用12c DBMS_SCHEDULER BACKUP_SCRIPT计划RMAN备份的范例 <Document 2469658.1> 在11.2.0.4 /12.1.0.2/12.2和18.2上应用 July (DBPSU/BP/RU)之后,Rman 备份报告 RMAN-06091: No Channel Allocated For Maintenance (of An Appropriate Type) <Document 2469660.1> 12.1.0.2 Rman备份hang住,等待Enq: TC - Contention <Document 2469609.1> Grid Infrastructure 12.2 新特性: Clusterware 文件必须存放在ASM里 <Document 2469619.1> 在 SLES 12上安装Oracle Clusterware 12c(12cR1 & 12cR2) 失败报 CRS-8503 [Signal / Exception: 11] 错 <Document 2469620.1> CRSD 频繁显示 Unresponsive/Intermediate/Offline 状态 <Document 2469641.1> 12.2: 'IPC Send timeout' 随后发生实例崩溃 <Document 2469642.1> ALERT: 在12.1.0.2和12.2的GI Home安装完2017年10月到2018年7月之间的PSU/RU需要禁用diagsnap中的pstack <Document 2469643.1> 12c以及以上版本的diagsnap是什么? <Document 2469671.1> 如何理解 TimesTen 警告"waiting for latch"信息 <Document 2471015.1> 如何理解 TimesTen AWT 缓存模式中发现的 Oracle 错误代码 <Document 2469672.1> 如何理解 TimesTen 服务器属性(MaxConnsPerServer,ServersPerDSN 和 ServerPool) <Document 2459143.1> DBaaS Monitor 被 Oracle SQL Developer Web 取代 <Document 2459126.1> Dbaas实例的备份在180分钟内没有被删除,导致DBaas的实例删除失败 <Document 2459125.1> Paas/Dbaas 中如何为本地磁盘备份和云端备份指定不同的恢复窗口 <Document 2459124.1> 如何批量删除云端Storage Container中的对象 完整的列表请点击这里   或登录 My Oracle Support  并查找: 中文文档列表 - Oracle Database (文档 ID 1533057.1)

最新翻译的文档列表: <Document 2469644.1> 在64位 OL7 或者 RHEL7 上安装 Oracle 18c 数据库的要求 <Document 2469645.1> 在64位 OL6 或者 RHEL6 上安装 Oracle 18c 数据库的要求<Document 2469647.1> Oracle DB 18c - 手动升级到 Non-CDB Oracle Database...

技术支持通讯

又有新的数据库中文文档添加到 My Oracle Support 中了! (2018年9月)

最新翻译的文档列表: Note 2440136.1 在64位OL7或者RHEL7上安装Oracle 12.2数据库的要求 Note 2440151.1 可查询的补丁清单 - ORA-20001的问题/解决方案: Latest xml inventory is not loaded into table Note 2440158.1 SRDC - 待处理/失败的补丁请求的数据收集 Note 2440159.1 SRDC - 补丁Rollback问题的数据收集 Note 2440160.1 SRDC - 补丁冲突的数据收集 Note 2440161.1 SRDC - OPatch 失败报错 "Can't Find Path For Shared Library: Libfl.sl " Note 2440162.1 SRDC - OPatch MOS 自动化 Note 2440163.1 SRDC - 数据库Cloning 问题的数据收集 Note 2440164.1 SRDC - 补丁安装问题的数据收集 Note 2440189.1 SRDC - 卸载问题的数据收集 Note 2440190.1 SRDC - 升级问题的数据收集 Note 2440211.1 SRDC - 升级之前或之后的INVALID对象 Note 2440212.1 SRDC - 数据库升级缓慢或Hung问题的数据收集 Note 2440213.1 SRDC - OPatch失败“ld:738和780 ERROR” Note 2440196.1 SRDC - Catbundle/Catwinbundle 诊断问题的信息收集 Note 2440197.1 SRDC - Opatch 由于错误 "genclntsh could not locate shrept.lst" 失败 Note 2440198.1 SRDC - PSU/SPU 或 Bundle Patch下载问题的信息收集 Note 2440100.1 在12c上执行查询语句报错ORA-01792 Note 2440131.1 12.2中删除了RDBMS Banner选项 Note 2440155.1 SRDC - 启动关闭 - 操作系统资源紧张:提供的证据清单 Note 2440156.1 SRDC - 启动关闭 – Oracle执行文件、空间和权限问题:提供的证据清单 Note 2440157.1 SRDC - ORA-30013: 提供的证据清单 Note 2440219.1 SRDC - 慢的DDL处理:提供的证据清单 Note 2440220.1 SRDC - DDL 错误:提供的证据清单 Note 2440221.1 SRDC - 自动维护任务,配置和相关问题:提供的证据清单 Note 2440222.1 SRDC – 外部 Jobs 和相关问题:提供的证据清单 Note 2440223.1 SRDC - Open Cursors:提供的证据清单 Note 2440224.1 SRDC - ORA-3136的数据收集 Note 2440225.1 SRDC - Windows AWE或VLM上的数据库:提供的证据清单 Note 2440226.1 SRDC - Job 配置: 提供的证据清单 Note 2440228.1 SRDC - alert日志错误ORA-609和12537,12637和12547 的数据收集 Note 2440229.1 SRDC - TNS-12514问题的数据收集 Note 2440230.1 SRDC – OCI客户端连接问题的数据收集 Note 2440232.1 SRDC - alert日志中TNS错误的数据收集 Note 2440233.1 SRDC - TNS-12599的数据收集 Note 2440234.1 SRDC – 与Undo有关的等待事件:提供的证据清单 Note 2440235.1 SRDC - ORA-1562: 提供的证据清单 Note 2440236.1 SRDC – 与Tuned_Undoretention相关的问题: 提供的证据清单 Note 2440238.1 SRDC - ORA-1548: 需要提供的证据清单 Note 2440239.1 SRDC - ORA-1552: 提供的证据清单 Note 2440194.1 SRDC - 启动关闭:事务恢复:提供的证据清单 Note 2440195.1 SRDC – 表空间管理:提供的证据清单 Note 2440199.1 SRDC - 无效组件和对象:提供证据清单 Note 2440200.1 SRDC - ORA-4023 : 提供的证据清单 Note 2440261.1 SRDC – 本地连接发生ORA-12547: 提供证据清单 Note 2440262.1 SRDC – DST版本升级: 提供的证据清单 Note 2440263.1 SRDC - DST升级11gR2及以上: 提供的证据清单 Note 2440264.1 SRDC -语言排序: 提供的证据清单 Note 2440265.1 SRDC - ORA-4063 : 提供的证据清单 Note 2440266.1 SRDC – 对象失效: 提供的证据清单 Note 2440267.1 SRDC - DMU扫描或转换阶段问题-提供的证据清单 Note 2440132.1 12c等待事件: 'acknowledge over PGA limit' Note 2440268.1 SRDC - LogMiner性能问题的信息收集 Note 2440269.1 SRDC - 传统导入问题的信息收集 Note 2440270.1 SRDC - 数据泵导出API问题的信息收集 Note 2440274.1 SRDC – 未知的内存问题: 提供的证据清单 Note 2440271.1 SRDC - 并行执行问题的数据收集 Note 2440272.1 SRDC - 在使用COMPRESS或DBMS_COMPRESSION时发生ORA错误需要提供的数据 Note 2440273.1 SRDC -针对压缩表/索引执行DML命令慢需要收集的数据 Note 2440137.1 12.1的MMON的监控SQL消耗很高的CPU以及频繁出现ORA-12850 或者 ORA-12751错误 Note 2440138.1 12.2.0或更高数据库版本上(比如18c)自动执行job "SYS"."ORA$AT_OS_OPT_SY_<NN>报出ORA-12012错误 Note 2440139.1 升级DB到12.2.0.1版本之后,由于统计信息顾问导致SYSAUX 过快增长 Note 2440275.1 SRDC - 如何收集DBMS_STATS问题的标准信息 Note 2440276.1 SRDC - 如何使用TFA(推荐方式)或者手工方式收集 ORA-00060 Deadlock 问题的标准信息 Note 2440277.1 SRDC -使用TFA(推荐的)或者手工步骤收集数据库性能问题的标准信息 Note 2440278.1 SRDC - 使用TFA(推荐的)或者手工步骤收集AWR使用过多 SYSAUX 空间的问题的标准信息 Note 2440279.1 SRDC -如何收集数据库 Replay 预处理问题的标准信息 Note 2440280.1 SRDC -如何收集数据库 Replay 初始化时性能问题的标准信息 Note 2440133.1 RAC 12c DDL的性能问题:节点的CPU数量不同导致大量的"enq: IV - contention" Note 2440134.1 (DB41) diagsnap 和其它组件对一些clusterware进程收集stack traces造成进程hang和节点驱逐 Note 2440135.1 在12c GI中如何重建共享ASM密码文件 Note 2440140.1 使用DGMGRL(Dataguard Broker 命令行)执行12c Dataguard Swithover的最佳实践 Note 2440214.1 SRDC - FRA问题所需的诊断数据收集 Note 2440215.1 SRDC - ORA-01410所需的诊断数据收集 Note 2440216.1 SRDC - RMAN跨平台/版本问题所需的诊断数据收集 Note 2440217.1 SRDC - UNDO Corruption 所需的诊断数据收集 Note 2440218.1 SRDC - 索引Corruption 的数据收集 Note 2442701.1 SRDC - Oracle TimesTen 内存 RDBMS 的数据收集 - 基线数据 Note 2442702.1 SRDC - Oracle TimesTen 内存 RDBMS 的数据收集 - 复制数据 Note 2442989.1 SRDC - Oracle TimesTen 内存 RDBMS 的数据收集 - 编程数据 完整的列表请点击这里   或登录 My Oracle Support  并查找: 中文文档列表 - Oracle Database (文档 ID 1533057.1)

最新翻译的文档列表: Note 2440136.1 在64位OL7或者RHEL7上安装Oracle 12.2数据库的要求 Note 2440151.1 可查询的补丁清单 - ORA-20001的问题/解决方案: Latest xml inventory is not loaded into table Note 2440158.1 SRDC - 待处理/失败的补丁请求的数据收集Note...

技术共享

11.2 例子: 使用opatch auto打Grid Home和DB Home都需要的RAC Rolling Installable one-off patch 的确切步骤

APPLIES TO: Oracle Database - Enterprise Edition - Version 11.2.0.4 and later Information in this document applies to any platform. GOAL Some bugs, especially ASM related, affect both GRID home and rdbms (database) home so the fix must be applied to both kinds of homes. Examples for such bug are: Bug 22901797 on 12.1.0.2.0 which is to solve the issue as described in note 2159643.1 - Solaris: Process spins/ASM and DB Crash if RAC Instance Is Up For > 248 Days by LMHB with ORA-29770 Bug 18740837 on 11.2.0.4 Bug 16870214 - DB startup fails with ORA-17510 if spfile is in 4k sector size diskgroup (Doc ID 16870214.8) on 11.2.0.3 or 11.2.0.4 Though GI upgrade is usually by GI PSU or Bundle Patch but occasionally when a certain fix has not been included in such bundle patch yet or customer prefers to apply one-off patch then this article is what you need. Rolling update means at any time there is at least one node running for active database service. SOLUTION Example - Apply one-off patch 16870214 upon 11.2.0.4.0 by “opatch auto” command which is suitable for rolling update. Environment: two nodes cluster with node names 'host1' and 'host2'. Grid home is /u01/app/11.2.0/grid and RDBMS Home is /u01/app/oracle/product/11.2.0/dbhome_1 Patch file name is p16870214_112040_Linux-x86-64.zip Prerequisites 1. Ensure that the Grid and Oracle home on which you are installing the patch is with a correct version. 2. Ensure OS platform is suitable for the patch. 3. About opatch tool, ensure that recent opatch tool is downloaded and unzipped to GI Home and RDBMS Home respectively: GI Home - /u01/app/11.2.0/grid/OPatch (as 'grid' user) RDBMS Home(s) - /u01/app/oracle/product/11.2.0/dbhome_1/OPatch (as 'oracle' user) 4. There is no need to configure JDK on OS manually separately. 5. Refer to readme file of the corresponding patch for other prerequisites. Installation steps A. Steps to apply on one of the nodes - for example, host1 1. Since the one-off patch is not large in size you can download and unzip it to /tmp/patch then generate a directory 16870214 under /tmp/patch by 'grid' user, else down to other place where free file system space is enough: [root@host1 16870214]# ls -l /tmp/patch/16870214 total 20 drwxr-xr-x 4 grid oinstall 4096 Oct 1 2014 etc drwxr-xr-x 3 grid oinstall 4096 Oct 1 2014 files -rw-rw-r-- 1 grid oinstall 10998 Oct 1 2014 README.txt 2. After the opatch tool upgrade you can verify the opatch version by command: # cat /u01/app/11.2.0/grid/OPatch/version.txt OPATCH_VERSION:11.2.0.3.17 3. Add OPatch directory of Grid home to PATH environmental variable for 'root' user /u01/app/11.2.0/grid/bin:/u01/app/11.2.0/grid/OPatch:$PATH 4. Confirm the path for database home that is needed to be applied from any node $ crsctl stat res -p -w "TYPE = ora.database.type" |egrep '^NAME|^ORACLE_HOME' NAME=ora.orcl.db ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1 ORACLE_HOME_OLD= NAME=ora.orcl.db ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1 ORACLE_HOME_OLD= 5. Optionally, check if database is running by executing srvctl as 'oracle' user from any node [oracle@host2 ~]$ srvctl status database -d orcl Instance orcl1 is running on node host1 Instance orcl2 is running on node host2 6. Before apply it on node 1, check whether CRS is running from the remaining node(s) as 'grid' user or 'root' user [grid@host2 tmp]$ crsctl stat res -t Cluster Resources -------------------------------------------------------------------------------- ora.LISTENER_SCAN1.lsnr 1 ONLINE ONLINE host2 ora.LISTENER_SCAN2.lsnr 1 ONLINE ONLINE host1 ora.LISTENER_SCAN3.lsnr 1 ONLINE ONLINE host1 ora.cvu 1 ONLINE ONLINE host1 ora.host1.vip 1 ONLINE ONLINE host1 ora.host2.vip 1 ONLINE ONLINE host2 ora.oc4j 1 ONLINE ONLINE host1 ora.orcl.db 1 ONLINE ONLINE host1 Open 2 ONLINE ONLINE host2 Open ora.scan1.vip 1 ONLINE ONLINE host2 ora.scan2.vip 1 ONLINE ONLINE host1 ora.scan3.vip 1 ONLINE ONLINE host1 7. Create an OCM response since this is required by 'opatch auto' Ensure to create an OCM response file, else the opatch auto process will stop at "OPatch is bundled with OCM, Enter the absolute OCM response file path:" then the process has to be broken. As 'grid' user: [grid@host1 bin]$ cd /u01/app/11.2.0/grid/OPatch/ocm/bin [grid@host1 bin]$ ./emocmrsp -no_banner Provide your email address to be informed of security issues, install and initiate Oracle Configuration Manager. Easier for you if you use your My Oracle Support Email address/User Name. Visit http://www.oracle.com/support/policies.html for details. Email address/User Name: <----- if you choose not to provide just press return here You have not provided an email address for notification of security issues. Do you wish to remain uninformed of security issues ([Y]es, [N]o) [N]: Y The OCM configuration response file (ocm.rsp) was successfully created. The generated ocm.rsp file will be used in later steps. 8. For rolling upgrade, you can run "srvctl start instance -d orcl -i orcl1" to stop the database instance on this node (host1) which is the applying node. Else if you let “opatch auto” to shutdown the database instance on behalf of you then by default it will shut down the database instance on the node with 'abort' option: (this can be seen later in alert log) Sat Nov 18 09:12:39 2017 Shutting down instance (abort) 9. (The first main change) Apply the one-off patch to GRID home, remember to run as 'root' user [root@host1 tmp]# opatch auto /tmp/patch -oh /u01/app/11.2.0/grid -ocmrf /u01/app/11.2.0/grid/OPatch/ocm/bin/ocm.rsp Executing /u01/app/11.2.0/grid/perl/bin/perl /u01/app/11.2.0/grid/OPatch/crs/patch11203.pl -patchdir /tmp -patchn patch -oh /u01/app/11.2.0/grid -ocmrf /u01/app/11.2.0/grid/OPatch/ocm/bin/ocm.rsp -paramfile /u01/app/11.2.0/grid/crs/install/crsconfig_params This is the main log file: /u01/app/11.2.0/grid/cfgtoollogs/opatchauto2017-11-18_09-11-50.log This file will show your detected configuration and all the steps that opatchauto attempted to do on your system: /u01/app/11.2.0/grid/cfgtoollogs/opatchauto2017-11-18_09-11-50.report.log 2017-11-18 09:11:50: Starting Clusterware Patch Setup Using configuration parameter file: /u01/app/11.2.0/grid/crs/install/crsconfig_params Enter 'yes' if you have unzipped this patch to an empty directory to proceed (yes/no):yes Enter 'yes' if you have unzipped this patch to an empty directory to proceed (yes/no):yes <--- just input 'yes' and return each time Stopping CRS... Stopped CRS successfully patch /tmp/patch/16870214 apply successful for home /u01/app/11.2.0/grid Starting CRS... Installing Trace File Analyzer CRS-4123: Oracle High Availability Services has been started. opatch auto succeeded. 10. See that step 9 succeeded and then check the cluster resources have been brought up by "opatch auto" except database instance Cluster Resources -------------------------------------------------------------------------------- ora.LISTENER_SCAN1.lsnr 1 ONLINE ONLINE host1 ora.LISTENER_SCAN2.lsnr 1 ONLINE ONLINE host2 ora.LISTENER_SCAN3.lsnr 1 ONLINE ONLINE host2 ora.cvu 1 ONLINE ONLINE host2 ora.host1.vip 1 ONLINE ONLINE host1 ora.host2.vip 1 ONLINE ONLINE host2 ora.oc4j 1 ONLINE ONLINE host2 ora.orcl.db 1 ONLINE OFFLINE Instance Shutdown 2 ONLINE ONLINE host2 Open ora.scan1.vip 1 ONLINE ONLINE host1 ora.scan2.vip 1 ONLINE ONLINE host2 ora.scan3.vip 1 ONLINE ONLINE host2 11. Optionally, If you would like, you can see Patch 16870214 has been applied to GRID home now by "opatch lsinventory". 12. (The second main change) Apply to rdbms home, remember to run as 'root' user as well as the step to Grid home: [root@host1 tmp]# /u01/app/11.2.0/grid/OPatch/opatch auto /tmp/patch -oh /u01/app/oracle/product/11.2.0/dbhome_1 -ocmrf /u01/app/11.2.0/grid/OPatch/ocm/bin/ocm.rsp Executing /u01/app/11.2.0/grid/perl/bin/perl /u01/app/11.2.0/grid/OPatch/crs/patch11203.pl -patchdir /tmp -patchn patch -oh /u01/app/oracle/product/11.2.0/dbhome_1 -ocmrf /u01/app/11.2.0/grid/OPatch/ocm/bin/ocm.rsp -paramfile /u01/app/11.2.0/grid/crs/install/crsconfig_params This is the main log file: /u01/app/11.2.0/grid/cfgtoollogs/opatchauto2017-11-18_09-32-10.log This file will show your detected configuration and all the steps that opatchauto attempted to do on your system: /u01/app/11.2.0/grid/cfgtoollogs/opatchauto2017-11-18_09-32-10.report.log 2017-11-18 09:32:10: Starting Clusterware Patch Setup Using configuration parameter file: /u01/app/11.2.0/grid/crs/install/crsconfig_params Enter 'yes' if you have unzipped this patch to an empty directory to proceed (yes/no):yes Enter 'yes' if you have unzipped this patch to an empty directory to proceed (yes/no):yes Stopping RAC /u01/app/oracle/product/11.2.0/dbhome_1 ... Stopped RAC /u01/app/oracle/product/11.2.0/dbhome_1 successfully patch /tmp/patch/16870214 apply successful for home /u01/app/oracle/product/11.2.0/dbhome_1 Starting RAC /u01/app/oracle/product/11.2.0/dbhome_1 ... Started RAC /u01/app/oracle/product/11.2.0/dbhome_1 successfully opatch auto succeeded. B. Perform the above steps on the remaining node(s) Only when Grid home has been successfully applied then proceed with RDBMS home. C. Verify the result by “opatch lsinventory” command on every applied Oracle home on every nodes. Example: [root@host1 ~]# su - oracle [oracle@host1 ~]$ opatch lsinventory ... Installed Top-level Products (1): Oracle Database 11g 11.2.0.4.0 There are 1 products installed in this Oracle Home. Interim patches (1) : Patch 16870214 : applied on Sat Nov 18 12:22:14 CST 2017 Unique Patch ID: 17739827 Created on 30 Sep 2014, 11:54:41 hrs PST8PDT Bugs fixed: 16870214 Rac system comprising of multiple nodes Local node = host1 Remote node = host2 Appendix I Content of applying logs The log for applying the Grid home: [grid@host1 cfgtoollogs]$ cat opatchauto2017-11-18_09-11-50.report.log *********** Configuration Data *********** * It shows only those targets that will be patched in this session * *********** Steps to be executed as owner unless specified as root *********** 1: /u01/app/11.2.0/grid/OPatch/opatch prereq CheckComponents -ph /tmp/patch/16870214 -oh /u01/app/11.2.0/grid 2: /u01/app/11.2.0/grid/OPatch/opatch prereq CheckConflictAgainstOH -ph /tmp/patch/16870214 -oh /u01/app/11.2.0/grid 3: /u01/app/11.2.0/grid/crs/install/rootcrs.pl -unlock : run as root 4: /sbin/fuser -k /u01/app/11.2.0/grid/bin/crsctl.bin : run as root 5: /u01/app/11.2.0/grid/OPatch/opatch prereq CheckApplicable -ph /tmp/patch/16870214 -oh /u01/app/11.2.0/grid 6: /u01/app/11.2.0/grid/OPatch/opatch napply /tmp/patch/16870214 -local -silent -ocmrf /u01/app/11.2.0/grid/OPatch/ocm/bin/ocm.rsp -oh /u01/app/11.2.0/grid -invPtrLoc /u01/app/11.2.0/grid/oraInst.loc 7: /u01/app/11.2.0/grid/bin/emctl start dbconsole 8: /u01/app/11.2.0/grid/rdbms/install/rootadd_rdbms.sh : run as root 9: /u01/app/11.2.0/grid/crs/install/rootcrs.pl -patch : run as root Note You can find what "opatch auto" did by reviewing the above two log files. Note that during the upgrade to Grid home there is a step "rootadd_rdbms.sh" executed by root user, this is usually not stated in readme file for such one-off patches. The log for applying RDBMS home: [grid@host1 cfgtoollogs]$ more opatchauto2017-11-18_09-32-10.report.log *********** Configuration Data *********** * It shows only those targets that will be patched in this session * rac_home=/u01/app/oracle/product/11.2.0/dbhome_1 owner=oracle opatch_ver=11.2.0.3.15 *********** Steps to be executed as owner unless specified as root *********** 1: /u01/app/oracle/product/11.2.0/dbhome_1/OPatch/opatch prereq CheckComponents -ph /tmp/patch/16870214 -oh /u01/app/oracle/product/11.2.0/dbhome_1 2: /u01/app/oracle/product/11.2.0/dbhome_1/OPatch/opatch prereq CheckConflictAgainstOH -ph /tmp/patch/16870214 -oh /u01/app/oracle/product/11.2.0/dbhome_1 3: /u01/app/oracle/product/11.2.0/dbhome_1/bin/emctl stop dbconsole 4: /u01/app/oracle/product/11.2.0/dbhome_1/bin/emctl stop agent 5: /u01/app/oracle/product/11.2.0/dbhome_1/OPatch/opatch prereq CheckApplicable -ph /tmp/patch/16 870214 -oh /u01/app/oracle/product/11.2.0/dbhome_1 6: /u01/app/oracle/product/11.2.0/dbhome_1/bin/srvctl stop home -o /u01/app/oracle/product/11.2.0/dbhome_1 -s /u01/app/oracle/product/11.2.0/dbhome_1/srvm/admin/stophome.txt -n host1 -f 7: /u01/app/oracle/product/11.2.0/dbhome_1/OPatch/opatch napply /tmp/patch/16870214 -local -silent -ocmrf /u01/app/11.2.0/grid/OPatch/ocm/bin/ocm.rsp -oh /u01/app/oracle/product/11.2.0/dbhome_1 -invPtrLoc /u01/app/oracle/product/11.2.0/dbhome_1/oraInst.loc 8: /u01/app/oracle/product/11.2.0/dbhome_1/bin/emctl start dbconsole 9: /u01/app/oracle/product/11.2.0/dbhome_1/bin/emctl start agent 10: /u01/app/oracle/product/11.2.0/dbhome_1/bin/srvctl start home -o /u01/app/oracle/product/11.2.0/dbhome_1 -s /u01/app/oracle/product/11.2.0/dbhome_1/srvm/admin/stophome.txt -n host1 Appendix II Rollback method /u01/app/11.2.0/grid/OPatch/opatch auto /tmp/patch -rollback -oh /u01/app/oracle/product/11.2.0/dbhome_1 -ocmrf /u01/app/11.2.0/grid/OPatch/ocm/bin/ocm.rsp /u01/app/11.2.0/grid/OPatch/opatch auto /tmp/patch -rollback -oh /u01/app/11.2.0/grid -ocmrf /u01/app/11.2.0/grid/OPatch/ocm/bin/ocm.rsp REFERENCES NOTE:1609742.1 - Cannot apply PSU in silent mode as fail to generate OCM response file NOTE:1363369.1 - Things to Consider Before Upgrading to 11.2.0.3/11.2.0.4 Grid Infrastructure/ASM NOTE:2159643.1 - Solaris: Process spins/ASM and DB Crash if RAC Instance Is Up For > 248 Days by LMHB with ORA-29770 NOTE:1479651.1 - Why "opatch auto" not patching database ORACLE_HOME?    

APPLIES TO: Oracle Database - Enterprise Edition - Version 11.2.0.4 and later Information in this document applies to any platform. GOAL Some bugs, especially ASM related, affect both GRID home and rdbms...

技术支持通讯

又有新的数据库中文文档添加到 My Oracle Support 中了! (2018年7月)

最新翻译的文档列表: Note 2403970.1 12c data guard 使用 sqlplus 主备切换最佳实践 Note 2404333.1 如何重建 Dataguard Broker 配置的步骤说明 Note 2403964.1 Data Guard 日志间隙检测及解决方案 Note 2404250.1 SRDC - 收集Data Guard 主库传输服务问题的诊断信息 Note 2404247.1 SRDC - 整个数据库损坏的数据收集 Note 2404271.1 SRDC - 数据库一般的损坏问题的诊断信息收集 Note 2403920.1 从 12.1 迁移到 12.2 后 SQL 语句执行缓慢等待在"PGA memory operation"和"Acknowledge over PGA limit" Note 2403919.1 在 12.1.0.2 中大量共享内存分配到 KGLH0 中的问题 Note 2406477.1 SRDC - Java和Streams Pool上的 - ORA-4031:证据提供 Note 2408404.1 SRDC - 用于降级问题的数据收集 Note 2408378.1 SRDC - 认证相关问题的数据收集 Note 2408421.1 SRDC - 数据库常规升级 Note 2403900.1 ORACLE 数据库 12C 标准版 (12.1.0.2) Note 2403921.1 Oracle Net 12c: DCD (Dead Connection Detection ) 功能的改变 Note 2406412.1 SRDC - Listener错误的数据收集 Note 2406413.1 SRDC - Listener Hang问题的数据收集 Note 2406414.1 SRDC - Listener Crash问题的数据收集 Note 2406415.1 SRDC - 远程连接缓慢,hang或者超时的数据收集 Note 2406417.1 SRDC - Listener Crash - (command=stop) 的数据收集 Note 2406418.1 SRDC - TNS-12516 / TNS-12518 / TNS-12519 / TNS-12520 的数据收集 Note 2406419.1 SRDC - ORA-12545 / ORA-12535 / ORA-12170 / ORA-12537的数据收集 Note 2406420.1 SRDC - ORA-12154 / ORA-12514 / ORA-12528的数据收集 Note 2406441.1 SRDC - ORA-3113 / ORA-3135的数据收集 Note 2406443.1 SRDC - 客户端通用连接问题的数据收集 Note 2406444.1 SRDC - DMU: Invalid Binary Representation - 需要提供的证据清单 Note 2406439.1 SRDC - 国家字符集:需要提供的证据清单 Note 2406440.1 SRDC - Database Link错误的数据收集 Note 2406471.1 SRDC - 通过DB Link 连接本地发生ORA-3113/Hanging/Slow Query 的数据收集 Note 2406473.1 SRDC - 通过DB Link远程访问发生ORA-12154错误的数据收集 Note 2406474.1 SRDC - 从源数据库通过DB Link连接发生ORA-12154错误的数据收集 Note 2406475.1 SRDC - ORA-2085的数据收集 Note 2406476.1 SRDC - 从远程客户端通过DB Link 访问发生ORA-3113/Hanging/Slow Query的数据收集 Note 2404865.1 SRDC –CTLB/CTF 数据收集 Note 2404866.1 SRDC – 没有 SCAN Listener 的 SLB(服务器端load balance)问题的数据收集 Note 2404867.1 SRDC – 使用SCAN Listener情况下的 SLB(服务器端load balance)问题的数据收集 Note 2404868.1 SRDC – 启动关闭问题:要提供的证据列表 Note 2405541.1 SRDC – 启动关闭 - Oracle 可执行程序以及 OS 资源问题: 提供的证据列表 Note 2405612.1 SRDC – TAF问题的数据收集 Note 2405709.1 SRDC - DBCA 问题: 要提供的证据清单 Note 2406343.1 SRDC - ORA-1555 bootstrap 错误 : 要提供的的证据列表 Note 2406308.1 SRDC - DBMS_SCHEDULER 里的邮件通知 : 要提供的证据列表 Note 2406309.1 SRDC - DBMS_JOB : 要提供的证据列表 Note 2406351.1 SRDC - SCN Issues问题: 要提供的证据列表 Note 2406342.1 SRDC - Unix上的DB- 过多的打开文件: 要提供的证据列表 Note 2405706.1 SRDC - Unix 上的DB- 资源:要提供的证据列表 Note 2405707.1 SRDC - Unix 上的DB- I/O 问题:要提供的证据列表 Note 2405713.1 SRDC – Unix 上的 DB - 配置:要提供的证据列表 Note 2406344.1 SRDC - Unix 上的DB-NUMA:要提供的证据列表 Note 2405710.1 SRDC - Windows平台资源使用高: 要提供的证据列表 Note 2405708.1 SRDC - DB Windows OracleService: 要提供的证据列表 Note 2405662.1 SRDC – 参数 CPU_COUNT - 配置和错误: 要提供的证据列表 Note 2405701.1 SRDC – 多租户下的数据库参数:提供的证据清单 Note 2404864.1 SRDC – ORA-18 或会话参数:提供的证据清单 Note 2405694.1 SRDC - 参数文件: 要提供的证据列表 Note 2405638.1 SRDC – 数据库参数:提供的证据清单 Note 2408452.1 应用 12.2.0.1.171017 RU(patch 26737266)补丁到 12.2 cluster 上导致 Oratab 条目被删除 Note 2404279.1 升级到 12c 之后'Global Cache Blocks Lost' 或 'gc blocks lost'的失败增长 Note 2404341.1 如何使用 gridSetup.sh 以静默模式安装/升级/克隆 12.2 GI Note 2403938.1 ocssd.bin 在 12c 中使用过高的内存和 CPU Note 2404320.1 12.2 打 GI Release Update 补丁时 ora.storage 资源启动失败 Note 2404853.1 SRDC - 集群(Grid Infrastructure和CRS)安装问题的诊断数据收集 Note 2405482.1 SRDC - 用于Windows Grid Infrastructure / Clusterware 管理相关问题的诊断数据收集 Note 2405682.1 SRDC - Grid Infrastructure和RAC安装升级补丁问题的诊断数据收集 Note 2405684.1 SRDC - RAC 数据库/实例 操作,管理和维护问题的诊断数据收集 Note 2405687.1 SRDC - Windows 10gR2和11gR1的Grid Infrastructure / Clusterware 管理相关问题的诊断数据收集 Note 2405685.1 SRDC - Grid Infrastructure / Clusterware管理相关问题的诊断数据收集 Note 2405483.1 SRDC - Windows 11gR1和10gR2的Grid Infrastructure / Clusterware 管理问题的诊断数据收集 Note 2405481.1 SRDC - Grid Infrastructure和RAC补丁问题的诊断数据收集 Note 2405460.1 SRDC - Grid Infrastructure / RAC认证和使用问题的诊断信息收集 Note 2404854.1 SRDC - RAC(RDBMS /Database Home)补丁问题的诊断数据收集 Note 2404855.1 SRDC - RACone问题的数据收集 Note 2404856.1 SRDC - 集群(GI/CRS)命令行工具(srvctl/crsctl)问题的数据收集 Note 2404248.1 SRDC - 集群(Grid Infrastructure 和 CRS)打补丁问题的诊断数据收集 Note 2404249.1 SRDC - RAC 数据库/实例 Hang 问题的数据收集 Note 2406310.1 SRDC - Oracle Multitenant问题的数据收集 Note 2406346.1 SRDC - 创建/维护 Partitioned/Subpartitioned Table/Index 问题的数据收集 Note 2406362.1 SRDC – 分区表/索引上执行 Create/Alter/Drop 命令慢问题的数据收集 Note 2406364.1 SRDC – 创建或刷新 Read Only Materialized View 遇到 ORA- 错误的数据收集 Note 2407812.1 SRDC - Materialized View 日志清除问题的数据收集 Note 2407813.1 SRDC - 物化视图 REFRESH 或 CREATE,DROP 语句慢的数据收集 Note 2407814.1 SRDC - 创建/维护物化视图和物化视图日志问题的数据收集 Note 2407816.1 SRDC - 分区表上执行 DML 或 Query 慢问题的数据收集 Note 2407817.1 SRDC - Compression 问题的数据收集(General, Unexpected Space Usage/Result, Compression Advisor) Note 2407818.1 SRDC - 传输表空间 Datapump 和原始 EXPORT,IMPORT 问题数据收集 Note 2407819.1 SRDC - Query Rewrite 问题的数据收集 Note 2407821.1 SRDC - Oracle Database In-Memory(DBIM)列存储问题的数据收集 Note 2407822.1 SRDC - 并行执行错误和 Set-up 问题的数据收集 Note 2407824.1 SRDC - 并行执行 Wrong Result 问题的数据收集 Note 2407825.1 SRDC - 并行执行性能问题的数据收集 Note 2404319.1 安装或升级到 12.2 Grid Infrastructure 后,意外的集群崩溃 Note 2404857.1 SRDC - 如何收集数据库捕获(Capture)问题的标准信息 完整的列表请点击这里   或登录 My Oracle Support  并查找: 中文文档列表 - Oracle Database (文档 ID 1533057.1)

最新翻译的文档列表: Note 2403970.1 12c data guard 使用 sqlplus 主备切换最佳实践 Note 2404333.1 如何重建 Dataguard Broker 配置的步骤说明 Note 2403964.1 Data Guard 日志间隙检测及解决方案 Note 2404250.1 SRDC - 收集Data Guard 主库传输服务问题的诊断信息Note...

技术支持通讯

又有新的数据库中文文档添加到 My Oracle Support 中了! (2018年3月)

最新翻译的文档列表: Note 2364820.1 使用 DBUA 升级数据库到 Database 12c 版本2(12.2)的完整核对清单 Note 2364834.1 datapatch -verbose 由于错误:" Patch xxxxxx: Archived Patch Directory Is Empty" 失败 Note 2364833.1 自动停止数据库(dbshut)在 OL 7 的 systemd 中不能运行 Note 2365616.1 SRDC - ORA-600 / ORA-7445: 10g 及以下版本的数据收集的检查清单 Note 2365571.1 SRDC - ORA-3137: 数据收集的检查清单 Note 2365615.1 SRDC - 数据泵导入(IMPDP)性能问题的诊断收集 Note 2365565.1 SRDC - SQL * Loader问题的诊断收集 Note 2365564.1 SRDC - DBVERIFY 问题的诊断收集 Note 2365576.1 SRDC - 其他内部错误:数据收集的检查清单 Note 2365568.1 SRDC - 数据泵导出性能问题的诊断收集 Note 2365573.1 SRDC - Large Pool 上的 ORA-4031: 数据收集的检查清单 Note 2365572.1 SRDC - ORA-4030:数据收集的检查清单 Note 2365569.1 SRDC - LogMiner 一般问题的诊断收集 Note 2365566.1 SRDC - 如何收集诊断导出(EXP)相关问题的信息 Note 2366178.1 SRDC - 自动任务及相关问题:提供的证据清单 Note 2365546.1 SRDC - CSSCAN:供应证据核对清单 Note 2365570.1 SRDC - DMU:提供的依据列表 Note 2366210.1 SRDC – 阻塞 Jobs 和 CJQ 相关问题:提供的证据清单 Note 2365291.1 SRDC - ORA-30036:数据收集的检查清单 Note 2365352.1 SRDC - ORA-1628:提供的证据清单 Note 2365306.1 SRDC – 导出数据时报错 ORA-1555:提供的证据清单 Note 2366155.1 SRDC - 错误的 SYSDATE 或服务器时区:证据清单 Note 2365308.1 SRDC – LOB 字段上发生 ORA-1555:需提供的证据列表 Note 2365355.1 SRDC – Undo 自动管理(AUM)问题:要提供的证据清单 Note 2365350.1 SRDC - ORA-1555:需要提供的证据列表 Note 2365712.1 SRDC - NLS setup:需要提供的证据清单 Note 2366185.1 SRDC - JOB 执行及相关错误:提供的证据清单 Note 2365354.1 SRDC - UNDO 配置信息检查列表 Note 2365304.1 SRDC - ORA-1555:Query Duration 0:数据收集的检查清单 Note 2365714.1 SRDC - 进程参数或者 ORA-20:数据收集的检查清单 Note 2366213.1 SRDC - 外部表和相关问题:提供的证据清单 Note 2365707.1 SRDC - Unix 上的数据库 - Huges Pages 以及 kernel 设置:提供的证据清单 Note 2365360.1 SRDC - 字符集转换:信息收集清单 Note 2366167.1 SRDC - DB Windows 操作系统配置:供应证据清单 Note 2364845.1 在 12.2 Alert.log 中"WARNING: too many parse errors" Note 2364832.1 如何显示 SPM 的 OUTLINE 中的 HINTS Note 2364837.1 关于 Oracle Database 12.1 的自适应特性的建议(自适应特性,自适应统计信息以及 12c SQL 性能 ) Note 2368297.1 SRDC – 如何收集数据库性能问题的标准信息(具有 Diagnostic Pack License) Note 2367668.1 SRDC - 如何收集 ‘Enq: TX - …’ 类型等待是数据库主要等待事件问题的标准信息 Note 2368307.1 SRDC - 如何收集"ORA-00054: resource busy and acquire with NOWAIT specified or timeout expired" 问题的标准信息 Note 2368325.1 SRDC – 如何收集 High CPU/Memory Usage 或 I/O 问题的标准信息 Note 2368363.1 SRDC – 如何收集"ORA-12751: cpu time or run time policy violation"问题的标准信息 Note 2368370.1 SRDC – 如何收集'library cache lock'等待是数据库主要等待事件问题的标准信息 Note 2368482.1 SRDC – 如何收集 alert 日志中'PMON failed to acquire latch, see PMON dump'问题的标准信息 Note 2367701.1 SRDC - 如何收集 ‘log file sync’ 等待是数据库主要等待事件问题的标准信息 Note 2367667.1 SRDC - 如何收集 “ORA-00060 Deadlock Detected” 问题的标准信息 Note 2367783.1 SRDC – 如何收集数据库性能相关的 Patch Request 问题的标准信息 Note 2367702.1 SRDC - 如何收集数据库 Replay 问题的标准信息 Note 2367669.1 SRDC - 如何对 ‘latch: cache buffers chains’ 是数据库主要的等待事件的性能问题收集基础的诊断信息 Note 2364225.1 ASMFD:在 GI 12.2 安装完成后,实施 ASM Filter Driver Note 2364214.1 12.2:如何创建 GI Management Repository Note 2364201.1 如何 relink Oracle Grid Infrastructure Standalone 或者 Oracle Grid Infrastructure RAC/Cluster 环境 Note 2364202.1 12.1.0.2 clssdadr_bucketThread线程导致ocssd.bin CPU使用率过高的问题 Note 2366811.1 SRDC - 如何收集 DBFS 问题的诊断信息(11.1,11.2 & 12c) Note 2366810.1 SRDC - 如何收集诊断 DNFS(Direct NFS)问题的诊断信息(11.1, 11.2 & 12c) Note 2366819.1 SRDC – Grid Infrastructure/集群管理 11gR1 和 10gR2 问题的诊断信息收集 Note 2365631.1 SRDC - 如何收集 ASM/ACFS 升级问题的诊断信息 Note 2365630.1 SRDC - ADVM/ACFS 问题的诊断数据收集 Note 2365618.1 SRDC - 如何收集 ASM 性能问题的诊断信息 Note 2365574.1 SRDC - 如何收集 ASM 空间和 ORA-15041 问题的诊断信息 Note 2365617.1 SRDC - 如何收集 ASM Hang 问题的诊断信息 Note 2365619.1 SRDC - 收集验证和诊断 ASM Diskgroup Corruptions 的诊断信息 Note 2365575.1 SRDC - 如何收集 ASM ORA-04031 和内存问题的诊断信息 Note 2365555.1 SRDC - 如何收集诊断 ASM/ASMLIB 问题所需的信息 Note 2365548.1 SRDC - 如何收集 ASM/ACFS 安装问题的诊断信息 Note 2366802.1 SRDC - 如何收集分析诊断 DBFS 问题的诊断信息(包含 TFA) Note 2366803.1 SRDC - 集群(Grid Infrastructure 和 CRS)启动问题的诊断信息收集 Note 2366844.1 SRDC - Grid Infrastructure 和 RAC 升级问题的诊断数据收集 Note 2366818.1 SRDC – 如何收集 ASM 问题的诊断信息(包括 TFA) Note 2366805.1 SRDC - RAC Database/Instance 相关问题的诊断信息收集 Note 2366832.1 SRDC - Grid Infrastructure 和 RAC 安装升级打补丁问题的诊断数据收集 Note 2366834.1 SRDC - Grid Infrastructure 和 RAC 的安装,升级以及打补丁问题的数据收集 Note 2366806.1 SRDC - RAC 数据库/实例性能问题(非 Hang 问题)的数据收集 Note 2366808.1 SRDC - Clusterware (GI/CRS) Agents 和 Resources (比如 Database,HAIP, CHM) 问题的数据收集 Note 2366331.1 SRDC - Clusterware(Grid Infrastructure 和 CRS)节点重启/驱逐的数据收集 Note 2364249.1 12.2 Rman 跨平台传输 PDB 到目的 CDB Note 2364266.1 12.2 在 PDB 级别执行 Flashback Note 2364217.1 从 12.1 到 12.2 运行 UPGRADE CATALOG 命令发生错误 RMAN-6004 和 ORA-1422 Note 2366186.1 SRDC - RMAN Maintenance 问题需要的诊断信息收集 Note 2367765.1 SRDC - 收集 logical standby 数据库问题的诊断信息 Note 2366187.1 SRDC - ORA-08103 错误的诊断信息收集 Note 2366190.1 SRDC – 非 RMAN 备份问题需要的诊断信息收集 Note 2367767.1 SRDC – 非 RMAN 恢复失败需要的诊断信息收集 Note 2366835.1 SRDC – RMAN-08137 或 RMAN-0812 错误需要的诊断信息收集 Note 2367683.1 SRDC – NOLOGGING的ORA-1578/ORA-26040 DBV-00201 错误的诊断信息收集 Note 2366188.1 SRDC - Redo Log 损坏的诊断信息收集 Note 2366954.1 SRDC – alert 日志信息“Corrupt block relative dba ”所需要的诊断信息收集 Note 2366952.1 SRDC - 错误 ORA-08102 需要的诊断信息收集 Note 2366189.1 SRDC - ORA-01578 的诊断信息收集 Note 2366836.1 SRDC – RMAN-00600 问题所需要诊断信息的收集 Note 2367673.1 SRDC – ORA-19566 问题所需要诊断信息的收集 Note 2367678.1 SRDC – 分析 ORA-00227 错误所需的诊断信息收集 Note 2366929.1 SRDC - 针对 Segment Corruption(表、索引、大对象等)的诊断信息收集 完整的列表请点击这里   或登录 My Oracle Support  并查找: 中文文档列表 - Oracle Database (文档 ID 1533057.1)  

最新翻译的文档列表: Note 2364820.1 使用 DBUA 升级数据库到 Database 12c 版本2(12.2)的完整核对清单 Note 2364834.1 datapatch -verbose 由于错误:" Patch xxxxxx: Archived Patch Directory Is Empty" 失败 Note 2364833.1 自动停止数据库(dbshut)在 OL 7...

测试案例

ora-119 错误的出现场景

本文测试一个不太常见的错误 ora-119. 错误解释是: "invalid specification for system parameter %s" 这个所谓的 ‘system parameter' 目前常见情况是指某种需要从DB外部获得解析的配置。 常见的如 域名解析 不存在,TNS name 解析不存在 等情况。 出现场景举例如下: (主机名/IP地址为隐藏替换值 ,非实际值,但是不影响结果) STEP 1. 确认名称解析初始配置。 这里没有DNS 服务干预,名称解析是通过/etc/hosts 文件。 [root@nascds10 etc]# cat hosts                   <<<<============= # Do not remove the following line, or various programs # that require network functionality will fail. 127.0.0.1       localhost.localdomain localhost ::1             localhost6.localdomain6 localhost6 #public 1.2.3.2   nascds10.test.com   nascds10 1.2.3.3   nascds11.test.com   nascds11 #VIP 1.2.3.4   nascds10-vip.test.com  nascds10-vip 1.2.3.5   nascds11-vip.test.com  nascds11-vip #private 10.1.1.1    nascds10-pvt 10.1.1.2    nascds11-pvt #scan 1.2.3.10   cluster-scan1                   <<<<============= it is available . STEP 2. 修改 hosts 文件,注销 scan 名称解析条目 [root@nascds10 etc]# vi hosts                   <<<<============= modify it . # Do not remove the following line, or various programs # that require network functionality will fail. 127.0.0.1       localhost.localdomain localhost ::1             localhost6.localdomain6 localhost6 #public 1.2.3.2   nascds10.test.com   nascds10 1.2.3.3   nascds11.test.com   nascds11 #VIP 1.2.3.4   nascds10-vip.test.com  nascds10-vip 1.2.3.5   nascds11-vip.test.com  nascds11-vip #private 10.1.1.1    nascds10-pvt 10.1.1.2    nascds11-pvt #scan #1.2.3.10   cluster-scan1                   <<<<============= disable this item. ~ ~ "hosts" 19L, 521C written STEP 3.  确认remote_listener 是指向修改的 scan resolution。并重启,测试重启过程中的初始化参数读取。 [root@nascds10 etc]# [root@nascds10 etc]# su - oracle [oracle@nascds10 ~]$ sqlplus / as sysdba SQL*Plus: Release 11.2.0.3.0 Production on Sat Nov 11 00:06:37 2017 Copyright (c) 1982, 2011, Oracle.  All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP, Data Mining and Real Application Testing options SQL> show parameter remote NAME                                 TYPE        VALUE ------------------------------------ ----------- ------------------------------ remote_dependencies_mode             string      TIMESTAMP remote_listener                      string      cluster-scan1:1521                   <<<<====== remote_listener is referred to /etc/hosts : "1.2.3.10   cluster-scan1" remote_login_passwordfile            string      EXCLUSIVE remote_os_authent                    boolean     FALSE remote_os_roles                      boolean     FALSE result_cache_remote_expiration       integer     0 SQL> SQL> SQL> SQL> shutdown immediate; Database closed. Database dismounted. ORACLE instance shut down.                   <<<<============= SQL>quit Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP, Data Mining and Real Application Testing options [oracle@nascds10 ~]$ sqlplus / as sysdba SQL*Plus: Release 11.2.0.3.0 Production on Sat Nov 11 00:07:16 2017 Copyright (c) 1982, 2011, Oracle.  All rights reserved. Connected to an idle instance. SQL> startup                   <<<<============= ORA-00119: invalid specification for system parameter REMOTE_LISTENER                   <<<<============= ORA-00132: syntax error or unresolved network name 'cluster-scan1:1521' SQL> ----------------------------------------- 再另开一个session ,观察 alert logs: [oracle@nascds10 trace]$ tail -f alert_ora11g1.log ...... Sat Nov 11 00:08:07 2017 Adjusting the requested value of parameter parallel_max_servers from 250 to 135 due to the value of parameter processes (150) Starting ORACLE instance (normal)                 <<<<============= ****************** Large Pages Information ***************** Total Shared Global Region in Large Pages = 0 KB (0%) Large Pages used by this instance: 0 (0 KB) Large Pages unused system wide = 0 (0 KB) (alloc incr 4096 KB) Large Pages configured system wide = 0 (0 KB) Large Page size = 4096 KB ......  remote_listener          = "cluster-scan1:1521"  parallel_min_servers     = 50  parallel_max_servers     = 135  audit_file_dest          = "/u01/app/oracle/admin/ora11g/adump"  audit_trail              = "DB"  db_name                  = "ora11g"  open_cursors             = 300  pga_aggregate_target     = 48M  parallel_force_local     = TRUE  diagnostic_dest          = "/u01/app/oracle" Cluster communication is configured to use the following interface(s) for this instance  169.254.33.67 cluster interconnect IPC version:Oracle UDP/IP (generic) IPC Vendor 1 proto 2 Sat Nov 11 00:08:17 2017 USER (ospid: 13857): terminating the instance due to error 119                 <<<<============= Instance terminated by USER, pid = 13857 Comments =================== 可见,以上是因为db启动需要解析参数remote_listener, 而无法从/etc/hosts 获得该对应解析 "cluster-scan1". ~~~~~~~~~~~~~~~~~~~~~~~ STEP 4. 恢复正确解析,并重启, 观察启动过程中读取参数并解析。 SQL> startup ORA-00119: invalid specification for system parameter REMOTE_LISTENER ORA-00132: syntax error or unresolved network name 'cluster-scan1:1521' SQL> quit                 <<<<============= Disconnected [oracle@nascds10 ~]$ [oracle@nascds10 ~]$ [oracle@nascds10 ~]$ su - root Password: [root@nascds10 ~]# [root@nascds10 ~]# cat /etc/hosts                 <<<<============= # Do not remove the following line, or various programs # that require network functionality will fail. 127.0.0.1       localhost.localdomain localhost ::1             localhost6.localdomain6 localhost6 #public 1.2.3.2   nascds10.test.com   nascds10 1.2.3.3   nascds11.test.com   nascds11 #VIP 1.2.3.4   nascds10-vip.test.com  nascds10-vip 1.2.3.5   nascds11-vip.test.com  nascds11-vip #private 10.1.1.1    nascds10-pvt 10.1.1.2    nascds11-pvt #scan #1.2.3.10   cluster-scan1                 <<<<============= [root@nascds10 ~]# [root@nascds10 ~]# [root@nascds10 ~]# vi /etc/hosts                 <<<<============= # Do not remove the following line, or various programs # that require network functionality will fail. 127.0.0.1       localhost.localdomain localhost ::1             localhost6.localdomain6 localhost6 #public 1.2.3.2   nascds10.test.com   nascds10 1.2.3.3   nascds11.test.com   nascds11 #VIP 1.2.3.4   nascds10-vip.test.com  nascds10-vip 1.2.3.5   nascds11-vip.test.com  nascds11-vip #private 10.1.1.1    nascds10-pvt 10.1.1.2    nascds11-pvt #scan 1.2.3.10   cluster-scan1                    <<<<============= modified hosts to re-enable the SCAN name resolution . ~ "/etc/hosts" 19L, 520C written [root@nascds10 ~]# [root@nascds10 ~]# exit logout [oracle@nascds10 ~]$ sqlplus / as sysdba                    <<<<============= SQL*Plus: Release 11.2.0.3.0 Production on Sat Nov 11 00:28:54 2017 Copyright (c) 1982, 2011, Oracle.  All rights reserved. Connected to an idle instance. linesize 130 SQL> startup                    <<<<============= ORACLE instance started. Total System Global Area  167387136 bytes Fixed Size                  1343668 bytes Variable Size             130027340 bytes Database Buffers           33554432 bytes Redo Buffers                2461696 bytes Database mounted. Database opened.                    <<<<=============   it is okay . SQL> =========================== 尝试删除TNSNAMES.ora中的 tns name 解析,然后在DB 中指定 local_listener 到这个不存在的 tns name,也会获得同样的错误。 即 ora-119 错误实际上是指无法从DB外部获得‘system'上的某种初始化参数值。

本文测试一个不太常见的错误 ora-119. 错误解释是: "invalid specification for system parameter %s" 这个所谓的 ‘system parameter' 目前常见情况是指某种需要从DB外部获得解析的配置。 常见的如 域名解析 不存在,TNS name 解析不存在 等情况。 出现场景举例如下:(主机名/IP地址为隐藏替换值...

新特性

12c新特性 在线操作数据文件

我们都知道,oracle pre-12c之前,若是想要把一个数据文件改名或者迁移,必须在归档模式下先把这个数据文件offline之后,然后进行OS上的copy或者rename 操作,最后在sqlplus里面进行alter database rename file x to Y;如果不是archivelog模式在offline数据文件的时候就会遇到ORA-01145   SQL> alter database datafile 8 offline; alter database datafile 8 offline * ERROR at line 1: ORA-01145: offline immediate disallowed unless media recovery enabled     12c oracle 增强了这个功能,我们可以在线进行数据文件的改名和迁移,而无需offline 数据文件,甚至都可以不打开归档的情况下进行操作,这无疑oracle在非停机运维的能力上又增强了。   下面是改名的一个操作输出,当然移动路径也可以用这个办法: SQL> archive log list; Database log mode        No Archive Mode   <<<<<非归档 Automatic archival        Disabled Archive destination        USE_DB_RECOVERY_FILE_DEST Oldest online log sequence     517 Current log sequence        519 SQL> SQL> SQL> ALTER DATABASE MOVE DATAFILE '/refresh/home/app/oracle/oradata/orcl/users01.dbf' to '/refresh/home/app/oracle/oradata/orcl/users02.dbf' ;   Database altered.     上述执行成功后,原有数据文件就直接被清理了,如果你想保留原有的数据文件,可以指定Keep 关键字来实现,注意此参数不适用原数据文件采用OFM的场景。   SQL> ALTER DATABASE MOVE DATAFILE '/refresh/home/app/oracle/oradata/orcl/users02.dbf' to '/refresh/home/app/oracle/oradata/orcl/users01.dbf' keep;  <<keep 原有数据文件   Database altered.   SQL> host ls -l /refresh/home/app/oracle/oradata/orcl/user* -rw-r----- 1 oracle oracle 352591872 Dec 17 07:19 /refresh/home/app/oracle/oradata/orcl/users01.dbf -rw-r----- 1 oracle oracle 352591872 Dec 17 07:19 /refresh/home/app/oracle/oradata/orcl/users02.dbf   可以看到原有数据文件并没有删除,若是目标文件已经存在,可以通过reuse 参数来覆盖,下面是没加reuse和使用reuse之后的输出   SQL> ALTER DATABASE MOVE DATAFILE '/refresh/home/app/oracle/oradata/orcl/users01.dbf' to '/refresh/home/app/oracle/oradata/orcl/users02.dbf'  ; ALTER DATABASE MOVE DATAFILE '/refresh/home/app/oracle/oradata/orcl/users01.dbf' to '/refresh/home/app/oracle/oradata/orcl/users02.dbf' * ERROR at line 1: ORA-01119: error in creating database file '/refresh/home/app/oracle/oradata/orcl/users02.dbf' ORA-27038: created file already exists Additional information: 1     SQL> ALTER DATABASE MOVE DATAFILE '/refresh/home/app/oracle/oradata/orcl/users01.dbf' to '/refresh/home/app/oracle/oradata/orcl/users02.dbf' reuse  ;   Database altered.   SQL> host ls -l /refresh/home/app/oracle/oradata/orcl/user* -rw-r----- 1 oracle oracle 352591872 Dec 17 07:23 /refresh/home/app/oracle/oradata/orcl/users02.dbf 没有使用keep ,user01.dbf已经删除了。   当然上述操作都是支持ASM的,参考语句如下: ALTER DATABASE MOVE DATAFILE '/u01/oracle/rbdb1/user1.dbf'  TO '+DG1/data/orcl/datafile/user1.dbf'; ALTER DATABASE MOVE DATAFILE '+DG1/data/orcl/datafile/user1.dbf' TO '+DG2/data/orcl/datafile/user1.dbf';

我们都知道,oracle pre-12c之前,若是想要把一个数据文件改名或者迁移,必须在归档模式下先把这个数据文件offline之后,然后进行OS上的copy或者rename 操作,最后在sqlplus里面进行alter database rename file x to Y;如果不是archivelog模式在offline数据文件的时候就会遇到ORA-01145   SQL> alter...

技术共享

segment header corruption的处理

  我们都知道,oracle从9iR2开始使用local managed tablespace来管理extent的分配情况,以替代原有用uet$/fet$表来管理的弊端,新特性是通过在 每个数据文件的file header block即block1后的1M的block中存放一个bitmap,每个bit代表一个extent,1 表示已经分配,0 表示未分配。 对于已经分配出去的extent,oracle都放在每个段内部进行自我管理,这个就是常说的ASSM,其中段的第一个extent的前三个block分别是一级块,二级块和三级块 我们称呼为L1,L2,L3,其中L3是最顶层管理块,有点类似索引的root block,L1是最底层块,类似索引的leaf block,直接管理datablock分配使用情况,L2是管理L1的使用情况,类似索引中的分支branch块,其中L3就是段头,segment header,那么一但这个segment header出现corruption会出现什么情况呢,如何处理呢? 下面我们来给您演示一下:     首先我们创建一个表 create table MAOB.MAOB_T tablespace user2 as select * from  TABS   查看一下extent分配情况 select  * from dba_extents where segment_name='MAOB_T' and owner='MAOB';   MAOB MAOB_T TABLE USER2 0 7 128 65536 8 7   分配了一个block id 176 起始的extents 查看segment header    select header_file,header_block from dba_SEGMENTS where segment_name='MAOB_T'  and owner='MAOB'; 7 130 segment header 是7,130   我们把segment header 弄成corruption,新shutdown db   SQL> shutdown immediate; Database closed. Database dismounted. ORACLE instance shut down.     -bash-4.1$ echo CORRUPT | dd of=/refresh/oracle/oradata/orcl/users02.dbf bs=8192 conv=notrunc seek=130 0+1 records in 0+1 records out 8 bytes (8 B) copied, 0.000588696 s, 13.6 kB/s   再次启动db SQL> startup ORACLE instance started.   Total System Global Area 6413680640 bytes Fixed Size     2265224 bytes Variable Size 6358568824 bytes Database Buffers    50331648 bytes Redo Buffers     2514944 bytes Database mounted. Database opened. SQL>     查看数据情况  select * from maob_t;               *  ERROR at line 1: ORA-01578: ORACLE data block corrupted (file # 7, block # 130) ORA-01110: data file 7: '/refresh/oracle/oradata/orcl/users02.dbf'   果然发现坏块了   查看extents分配情况 select  * from dba_extents where segment_name='MAOB_T' and owner='MAOB';    no rows selected   发现已经没有extents情况了,说明segment 损坏之后会影响extents显示     再次查看free 空间情况 select * from dba_free_space where file_id=7  TABLESPACE_NAME FILE_ID BLOCK_ID    BYTES    BLOCKS  RELATIVE_FNO USER2                7 136          208601088 25464 7  <<free 起始blockid是136,正是第二个extent   drop 对象 看看发生什么 SQL> drop table maob.maob_t; drop table maob.maob_t                 * ERROR at line 1: ORA-01578: ORACLE data block corrupted (file # 7, block # 130) ORA-01110: data file 7: '/refresh/oracle/oradata/orcl/users02.dbf'      仍然报错,说明这种情况已经不能处理这个对象了,这个时候若是有备份那么可以通过restore+recover来处理, 若是没有备份而且也不想恢复这个segment,只想释放出原有空间,那该如何处理呢?     首先需要 加purge 把表drop 掉,注意此处需要使用purge 语句,否则仍然会报错。 SQL> drop table maob_t purge;   Table dropped.     然后再次查看extent 是否释放 select * from dba_free_space where file_id=7  TABLESPACE_NAME FILE_ID BLOCK_ID    BYTES    BLOCKS  RELATIVE_FNO USER2        7 136    208601088    25464 7 <<free 起始blockid仍然是136说明并没有释放   继续对这个corruption segment执行如下步骤 exec dbms_space_admin.segment_corrupt('USER2',7,130);  exec dbms_space_admin.segment_drop_corrupt('USER2',7,130); exec DBMS_SPACE_ADMIN.TABLESPACE_REBUILD_BITMAPS ('USER2');     然后再次查看extent 是否释放 select * from dba_free_space where file_id=7  TABLESPACE_NAME FILE_ID BLOCK_ID    BYTES    BLOCKS  RELATIVE_FNO USER2             7       128      208666624 25472 7  <<已经和前面的8个block合并在起了     至此,我们成功处理掉了segment header corruption的segment对象。 注:上述测试基于11204 database。       

  我们都知道,oracle从9iR2开始使用local managed tablespace来管理extent的分配情况,以替代原有用uet$/fet$表来管理的弊端,新特性是通过在 每个数据文件的file header block即block1后的1M的block中存放一个bitmap,每个bit代表一个extent,1 表示已经分配,0 表示未分配。 对于已经分配出去的extent,oracle都放...

技术共享

几种常见重新硬解析的原因

       经常有客户提SR说某个SQL的执行计划变差了,导致出现了性能问题,进而就问为啥解析出了新的 执行计划。首先可以肯定突然出现了新的执行计划表明sql进行了重新硬解析(注意重新硬解析不一定 产生新的执行计划),那么为啥好好的sql需要重新硬解析呢?今天我们就列举几种常见的原因:   1.自动收集统计信息  为了保证sql的最佳执行性能,oracle需要找到一个最优的执行计划,基于CBO模式的优化器必须 要知道最新的统计信息,例如条数,block数量,某个字段的选择率等,所以oracle每天凌晨都会运行一 个自动收集统计信息的job,来收集那些变化超过10%的表的最新统计信息,收集完成之后,理所当然 要对新来的sql进行使用,所以就需要进行硬解析。oracle 收集某个表统计信息后默认是不会立即invalid 所有相关的cursor,因为这样做太暴力,会引发硬解析相关的性能问题,所以巧妙的设计了一下,当某个相关sql执行的时候发现一个依赖对象最近收集过统计信息,便随机的打个一个时间戳,这个时间戳是 5个小时内某个时间戳,等到下次sql解析的时候若是发现了这个时间戳就会和当前时间进行比较,若是超过就说明已经到期,立即进行硬解析,否则还继续进行软解析。   2.没有符合条件的child cursor 典型的如bind mismatch (其他原因可以参考v$sql_shared_cursor) 当某个sql使用了绑定变量的时候,ORACLE 会记录cursor第一次硬解析时候的绑定变量的相关metadata,  当后续解析的时候便会进行检查,若是发现绑定变量类型或长度不匹配就会进行重新解析,下面我们就用一个小例子验证一下:   CREATE TABLE MAOB_T AS SELECT * FROM DBA_TABlES ;  VAR  B1 char(20);  EXEC :B1 := 'MAOB';  SELECT COUNT(*) FROM MAOB_T WHERE TABLE_NAME=:B1;    查看cursor情况 Select sql_id,child_number,first_load_time from V$SQL WHERE SQL_TEXT LIKE '%COUNT%MAOB_T%' 4v22rgk83gjnc 0 2017-12-15/22:52:46 <<可以看到新cursor已经生成 把绑定变量类型变成varchar2,sql文本不变,再次执行: VAR  B1 VARCHAR2(20);  EXEC :B1 := 'MAOB';  SELECT COUNT(*) FROM MAOB_T WHERE TABLE_NAME=:B1;   执行上述语句后再次查看 Select sql_id,child_number,first_load_time from V$SQL WHERE SQL_TEXT LIKE '%COUNT%MAOB_T%' 4v22rgk83gjnc 0 2017-12-15/22:52:46 4v22rgk83gjnc 1 2017-12-15/22:52:46 可以看到已经有两个只cursor,进一步查看cursor不能share的原因:   Select sql_id,child_number,bind_mismatch from v$sql_shared_cursor WHERE ROWNUM<10 and sql_id='4v22rgk83gjnc' sql_id,child_number bind_mismatch 4v22rgk83gjnc 0 N 4v22rgk83gjnc 1 Y  <<<bind_mismatch  可以看到由于绑定变量的原因造成的mismatch,所以硬解析产生了第二个子cursor。   3.oracle11g 提供了自适应游标功能(Adaptive Cursor Sharing),如果表上的字段存在直方图并且数据存在倾斜的场景下,那么对于传入不同的数据就会造成oracle重新尝试硬解析。具体内容,可以参考另外一篇博客。 https://blogs.oracle.com/database4cn/oracle-11g-sql-adaptive-cursor-sharing   4.cursor 已经被ageout 内存  我们都知道,oracle 对于内存管理机制和很多OS管理内存机制一样,都采用了LRU(Least recently used,最近最少使用)算法, cursor作为一种library cache 中的对象也不例外,若是某个sql解析需要share pool内存时,发现free list 上并没有合适大小的内存块(chunk) 就会触发清理机制,那么之前cursor 申请的chunk就依据LRU算法规则被清理掉,这种就是age out,需要注意的是,这个是oracle的 机制,并不是OS上的swap机制,一旦某个cursor的被ageout出shared pool,那么下次执行这个sql的时候就是重新硬解析。   5.除了上述几种oracle自身的机制造成重新硬解析之外,也存在人为因素操作造成的可能 例如人为收集统计信息,人为执行了flush shared_pool 操作,手工调用dbms_shared_pool.purge 来清理某个cursor 执行了ddl 语句等。

       经常有客户提SR说某个SQL的执行计划变差了,导致出现了性能问题,进而就问为啥解析出了新的 执行计划。首先可以肯定突然出现了新的执行计划表明sql进行了重新硬解析(注意重新硬解析不一定 产生新的执行计划),那么为啥好好的sql需要重新硬解析呢?今天我们就列举几种常见的原因:   1.自动收集统计信息  ...

技术支持通讯

又有新的数据库中文文档添加到 My Oracle Support 中了! (2017年12月)

最新翻译的文档列表: Note 2331569.1    故障排除指南 ORA-3136:WARNING Inbound Connection Timed Out Note 2331135.1    升级到 12c 后出现 ORA-28040: No Matching Authentication Protocol Note 2331572.1    如何生成 AWR 报告和 AWR 基线 Note 2331567.1    如何收集 'SYS' 用户拥有的对象和 'Fixed' 对象的统计信息 Note 2331144.1    诊断 ’library cache: mutex X’ 等待 Note 2331566.1    SQL 自动调优以及 SQL Profile Note 2331575.1    故障排除:"enq: TX - index contention" Note 2331842.1    在物理 standby 数据库上如何解决 MRP 进程卡住的问题? Note 2331528.1    Opatch:从Opatch 12.2.0.1.5 和 11.2.0.3.14 版本开始的行为改变 Note 2331522.1    在 RHEL7 或者 OL7 上安装 64位 Oracle Database 12.1 的要求 Note 2331843.1    如何收集不同 OS 平台的 OS 日志来诊断存储(ACFS/ASM/DNFS/DBFS)相关问题 Note 2331776.1    Linux/Unix 平台,在CRS 磁盘组完全丢失后,如何恢复基于 ASM 的 OCR Note 2331856.1    重新配置或重建 11gR2/12cR1 Restart/OHAS/SIHA 堆栈配置(单机) Note 2322494.1    SRDC – Data Guard Broker 问题的诊断数据收集 Note 2322446.1    SRDC – RMAN duplicate 问题所需要诊断数据的收集 Note 2322503.1    SRDC – RAC 数据库/实例管理和维护问题的诊断数据收集 Note 2322464.1    SRDC - ASM/ACFS 一般问题的诊断数据收集 Note 2322465.1    SRDC – ASM/ACFS RAC/Cluster 问题的诊断数据收集 Note 2322520.1    SRDC – Unix 平台上的 Grid Infrastructure/Clusterware 问题的诊断数据收集 Note 2323083.1    SRDC - Shutdown Hang:提供的证据清单 Note 2323082.1    SRDC – 数据库启动问题:提供的证据清单 Note 2323579.1    SRDC – 在有 Diagnostic Pack License 时,如何对发生在 Unix/Linux 平台上的 11g和 更高版本的数据库性能问题收集基础的诊断信息 Note 2323567.1    SRDC - 如何对数据库性能问题收集基础的诊断信息(没有 Diagnostic Pack License 的情况下) Note 2323058.1    SRDC - 如何收集错误结果问题的标准信息 Note 2323655.1    SRDC - 如何收集 SQL 计划管理(SPM)Baseline 未被使用的问题的标准信息 Note 2323102.1    SRDC - 如何收集自动工作负载资源库(AWR)使用过多 SYSAUX 空间的问题的标准信息 Note 2323638.1    SRDC – 其他内部错误:11g 及更高版本数据收集的检查清单 Note 2323626.1    SRDC - Shared Pool 上的 ORA-4031: 11g 及更高版本数据收集的检查清单 Note 2323629.1    SRDC - ORA-4030:11g 及更高版本数据收集的检查清单 Note 2323055.1    SRDC - ORA-27300,ORA-27301,ORA-27302及其他内存问题:数据收集的检查清单 Note 2322967.1    SRDC - ORA-600 / ORA-700 / ORA-7445: 11g 及更高版本数据收集的检查清单 Note 2323106.1    SRDC - DataPump Import (IMPDP) 一般问题的诊断信息收集 Note 2323004.1    SRDC - Shared Pool上的ORA-4031:提供的证据清单 完整的列表请点击这里 或登录 My Oracle Support  并查找: 中文文档列表 - Oracle Database (文档 ID 1533057.1)

最新翻译的文档列表: Note 2331569.1    故障排除指南 ORA-3136:WARNING Inbound Connection Timed Out Note 2331135.1    升级到 12c 后出现 ORA-28040: No Matching Authentication Protocol Note 2331572.1    如何生成 AWR 报告和 AWR 基线Note...

如何手工运行Segment Advisor

针对特定的表、索引或表空间,可以手工的运行Segment Advisor,从而检查可以释放多少空间。 1.测试表定义如下: SQL> create table test.segtest (id char(800),id1 char(800),id2 char(800),id3 char(800),id4 char(800),id5 char(800),id6 char(800),id7 char(800),id8 char(800),id9 char(800),id10 char(800)) tablespace testsegment; 2. 表使用的空间情况如下: SQL>select owner,table_name,round((blocks*8),2)||' kb' "TABLE SIZE",round((num_rows*avg_row_len/1024),2)||' kb' "ACTUAL DATA"  from dba_tables where table_name='SEGTEST' and owner='SEGTEST'; OWNER           TABLE_NAME     TABLE SIZE   ACTUAL DATA   --------------- -------------- ------------ ------------- TEST            SEGTEST        203176 kb    17207.42 kb   --占用空间200M,实际仅仅使用了17MB. 3.进行分析 SQL> variable id number; begin declare name varchar2(100); descr varchar2(500); obj_id number; begin name:='Dagu_segment'; descr:='Segment Advisor Example'; dbms_advisor.create_task ( advisor_name => 'Segment Advisor', task_id => :id, task_name => name, task_desc => descr); dbms_advisor.create_object ( task_name => name, object_type => 'TABLE', attr1 => 'TEST', attr2 => 'SEGTEST', attr3 => NULL, attr4 => NULL, attr5 => NULL, object_id => obj_id); dbms_advisor.set_task_parameter( task_name => name, parameter => 'recommend_all', value => 'TRUE'); dbms_advisor.execute_task(name); end; end;  / 4.检查分析结果 SQL> select tablespace_name, segment_name, segment_type, recommendations, c1 from table(dbms_space.asa_recommendations('TRUE', 'TRUE', 'FALSE')) where tablespace_name = 'TESTSEGMENT'; TABLESPACE_NAME                SEGMENT_NAME                   SEGMENT_TYPE       RECOMMENDATIONS ------------------------------ ------------------------------ ------------------ ----------------------------------------------------------------------------------------------------------------------- TESTSEGMENT                    SEGTEST                        TABLE              Enable row movement of the table TEST.SEGTEST and perform shrink, estimated savings is 167224924 bytes. 5.进行整理操作 SQL> alter table SEGTEST enable row movement; Table altered. SQL> alter table SEGTEST Shrink Space cascade; Table altered. 6.整理完毕,再次检查空间使用情况: SQL>select owner,table_name,round((blocks*8),2)||' kb' "TABLE SIZE",round((num_rows*avg_row_len/1024),2)||' kb' "ACTUAL DATA"  from dba_tables where table_name='SEGTEST' and owner='SEGTEST'; OWNER           TABLE_NAME     TABLE SIZE   ACTUAL DATA   --------------- -------------- ------------ ------------- TEST            SEGTEST        22000 kb    17207.42 kb --当前仅仅使用21 MB。 7.删除对应的Task SQL> exec DBMS_ADVISOR.DELETE_TASK ('Dagu_segment');  相关参考: Is There a Way To Run The Segment Advisor Manually From SQL*Plus? (Doc ID 854234.1)

针对特定的表、索引或表空间,可以手工的运行Segment Advisor,从而检查可以释放多少空间。 1.测试表定义如下: SQL> create table test.segtest(id char(800),id1 char(800),id2 char(800),id3 char(800),id4 char(800),id5 char(800),id6 char(800),id7...

EXPDP如何导出两表关联后的数据

以SCOTT用户的EMP表为例,说明如何使用QUERY选项导出两个表关联后的数据 1. 检查EMP表的empno值 SQL> select empno from emp order by 1;      EMPNO ----------       7369       7499       7521       7566       7654       7698       7782       7788       7839       7844       7876       7900       7902       7934 14 rows selected. SQL> 2.创建测试表TEST01,并插入部分数据: SQL>create table test01 (name varchar2(30),empno number(8)); SQL> insert into test01 values ('test1',7788); insert into test01 values ('test2',7900); insert into test01 values ('test3',8999); commit; 3.需要导出下面SQL对应的EMP表的数据: select * from emp t1 where exists (select EMPNO from test01 t2 where t2.empno=t1.empno);      EMPNO ENAME      JOB              MGR HIREDATE         SAL       COMM     DEPTNO ---------- ---------- --------- ---------- --------- ---------- ---------- ----------       7788 SCOTT      ANALYST         7566 19-APR-87       3000                    20       7900 JAMES      CLERK           7698 03-DEC-81        950                    30 4. 使用EXPDP导出数据: $expdp scott/tiger directory=dump_dir dumpfile=emp.dmp tables=emp query='emp:" where exists (select EMPNO from test01 where ku$.EMPNO = test01.EMPNO)"' . . exported "SCOTT"."EMP"                               8.070 KB       2 rows Master table "SCOTT"."SYS_EXPORT_TABLE_01" successfully loaded/unloaded ****************************************************************************** 5.说明: 这里需要使用ku$作为表的别名,否则表的所有记录都会被导出。 相关参考: https://docs.oracle.com/database/121/SUTIL/GUID-CDA1477D-4710-452A-ABA5-D29A0F3E3852.htm#SUTIL860

以SCOTT用户的EMP表为例,说明如何使用QUERY选项导出两个表关联后的数据 1. 检查EMP表的empno值 SQL> select empno from emp order by 1;      EMPNO ----------       7369       7499       7521       7566       7654       7698       7782     ...

如何使用coe_load_sql_profile.sql来固定sql profile

SQLT工具包含一个脚本,名字是coe_load_sql_profile.sql,下面以用户SCOTT的EMP表为例,说明如何使用该脚本固定sql profile. 1. SQL> -- 对emp的列ename创建一个索引 SQL> create index i_emp_ename on scott.emp(ename); 索引已创建。 SQL> --收集统计信息 SQL> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'EMP') PL/SQL 过程已成功完成。 2.运行原始的SQL语句 SQL> select ename from scott.emp where ename='MILLER';  ENAME ---------- MILLER 执行计划如下: ------------------------------- SQL_ID  329d885bxvrcr           ------------------------------- Plan hash value: 4001599462 ------------------------------------------------- | Id  | Operation        | Name        | E-Rows | ------------------------------------------------- |   0 | SELECT STATEMENT |             |        | |*  1 |  INDEX RANGE SCAN| I_EMP_ENAME |      1 | ------------------------------------------------- --这是我们需要更改的plan 3. 运行带有hint的SQL SQL> select /*+ FULL (EMP) */ ename from scott.emp where ename='MILLER';  执行计划如下: ------------------------------- SQL_ID  4f74t4ab7rd5y ------------------------------- Plan hash value: 3956160932 ------------------------------------------- | Id  | Operation         | Name | E-Rows | ------------------------------------------- |   0 | SELECT STATEMENT  |      |        | |*  1 |  TABLE ACCESS FULL| EMP  |      1 | ------------------------------------------- --这是我们需要的plan 4: 可以通过下面的SQL获取这2个SQL的sql_id和plan_hash_value SQL> select sql_id ,plan_hash_value, sql_text from v$sql where sql_text like '%scott.emp%'; SQL_ID        PLAN_HASH_VALUE SQL_TEXT ------------- --------------- ---------------------------------------------------------------------------------------- 4f74t4ab7rd5y      3956160932 select /*+ FULL (EMP) */ ename from scott.emp where ename='MILLER' 329d885bxvrcr      4001599462 select ename from scott.emp where ename='MILLER' --329d885bxvrcr - 这是原始语句的SQL ID --4f74t4ab7rd5y - 这是使用hint的SQL ID --3956160932 - 这是需要替换的plan hash value. 5.进行plan的替换 --这两个计划都需要在缓存或AWR中 --需要以具有DBA权限的用户身份连接,例如SYSTEM SQL> conn system SQL> @coe_load_sql_profile.sql Parameter 1: ORIGINAL_SQL_ID (required) 输入 1 的值:  329d885bxvrcr Parameter 2: MODIFIED_SQL_ID (required) 输入 2 的值:  4f74t4ab7rd5y Parameter 3: PLAN_HASH_VALUE (required) 输入 3 的值:  3956160932 Values passed to coe_load_sql_profile: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ORIGINAL_SQL_ID: "329d885bxvrcr" MODIFIED_SQL_ID: "4f74t4ab7rd5y" PLAN_HASH_VALUE: "3956160932" ORIGINAL:329D885BXVRCR MODIFIED:4F74T4AB7RD5Y PHV:3956160932 SIGNATURE:15822026218863957422 CREATED BY COE_LOAD_SQL_PROFILE.SQL SQL>SET ECHO OFF; **************************************************************************** * Enter SYSTEM password to export staging table STGTAB_SQLPROF_329d885bxvrcr **************************************************************************** Export: Release 11.2.0.4.0 - Production on 星期二 12月 5 15:36:24 2017 Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved. 口令: coe_load_sql_profile completed. SQL>   6.运行原来的SQL语句 SQL>conn scott/tiger SQL> select ename from scott.emp where ename='MILLER'; PLAN_TABLE_OUTPUT ------------------------------- SQL_ID  329d885bxvrcr ------------------------------- Plan hash value: 3956160932 ------------------------------------------- | Id  | Operation         | Name | E-Rows | ------------------------------------------- |   0 | SELECT STATEMENT  |      |        | |*  1 |  TABLE ACCESS FULL| EMP  |      1 | ------------------------------------------- Predicate Information (identified by operation id): ---------------------------------------------------    1 - filter("ENAME"='MILLER') Note -----    - SQL profile 329D885BXVRCR_3956160932 used for this statement 我们可以看到,原始的SQL现在和使用hint的sql具有相同的plan_hash_value和plan。 此外,我们看到这个SQL启用了一个SQL配置文件。 相关参考: Directing Plans with Baselines/Profiles Using coe_load_sql_baseline.sql / coe_load_sql_profile.sql (shipped with SQLT) (Doc ID 1400903.1)

SQLT工具包含一个脚本,名字是coe_load_sql_profile.sql,下面以用户SCOTT的EMP表为例,说明如何使用该脚本固定sql profile. 1. SQL> -- 对emp的列ename创建一个索引 SQL> create index i_emp_ename on scott.emp(ename); 索引已创建。 SQL> --收集统计信息SQL>...

方博客 - 数据库产品技术支持

Scheduler job的日志记录时间与job运行时间不一致

最近遇到几个客户反映,Scheduler job的日志记录时间与job运行时间不一致,自动统计任务的window打开时间与job执行的时间不一致等问题。 例如下面的情况, SQL>select LOG_DATE, OWNER,JOB_NAME , STATUS , REQ_START_DATE,ACTUAL_START_DATE, RUN_DURATION from dba_scheduler_job_run_details; LOG_DATE OWNER JOB_NAME  STATUS REQ_START_DATE ACTUAL_START_DATE  RUN_DURATION 2017-09-26 20:01:07.156536 +08:00 HFMMS CW_UTIL_JOB SUCCEEDED 2017-09-26 05:01:01.300000 -07:00 2017-09-26 05:01:04.316769 -07:00 +000 00:00:03   从上述结果可以发现,日志记录的时间是2017-09-26 20:01:07.156536 +08:00。而job执行时间是2017-09-26 05:01:01.300000 -07:00。 根据计算,这两个时区+08 和 -07 正好相差15个小时。而 20:01 和 05:01 正好相差了15个小时。因此,这实际是同一个时间,只是时区不同,表示方式不一样。 发生该问题的原因是dbms_scheduler使用的默认timezone不是操作系统的时区。可以使用下面的语句检查: 1)检查 system timezone: SQL> select systimestamp, sessiontimezone from dual;  2)检查 Scheduler time zone: SQL> select DBMS_SCHEDULER.STIME from dual;   解决该问题的办法是执行下面的语句将scheduler job 的时区修改为与system一致的时区: SQL> exec DBMS_SCHEDULER.SET_SCHEDULER_ATTRIBUTE('default_timezone','');   可以参考下面的文档: How to Change the Scheduler Timezone to Match the System Timezone (Doc ID 1488157.1) DBMS_SCHEDULER or DBMS_JOB And DST / Timezones Explained (Doc ID 467722.1)          

最近遇到几个客户反映,Scheduler job的日志记录时间与job运行时间不一致,自动统计任务的window打开时间与job执行的时间不一致等问题。 例如下面的情况, SQL>select LOG_DATE, OWNER,JOB_NAME , STATUS , REQ_START_DATE,ACTUAL_START_DATE, RUN_DURATION from...

dbms_xplan.display_cursor的一点小问题分享

工具包dbms_xplan.display_cursor在诊断SQL性能方面是非常有用的,特别是与Statistics_level=all;一起使用同时制定Format为allstats last是会看到很多有用的信息,但是今天遇到一个问题,和大家分享一下。就是Statistics_level=all加dbms_xplan.display_cursor(null,null,'allstats last')显示的信息不完整。让我们看下如下的测试案例,问题与答案都一目了然了。 sqlplus / as sysdba SQL> create table test as select * from dba_objects; Table created. SQL>  alter session set Statistics_level=all; SQL> set linesize 500 SQL>  select count(*) from test;<<<<normal SQL      49981 SQL>  select * from table(dbms_xplan.display_cursor(null,null,'allstats last')); SQL_ID  2fxk53j4a5r6d, child number 0 -------------------------------------  select count(*) from test Plan hash value: 1950795681 ------------------------------------------------------------------------------------- | Id  | Operation          | Name | Starts | E-Rows | A-Rows |   A-Time   | Buffers |  <<<buffers information is displayed ------------------------------------------------------------------------------------- |   1 |  SORT AGGREGATE    |      |      1 |      1 |      1 |00:00:00.21 |     692 | |   2 |   TABLE ACCESS FULL| TEST |      1 |  53270 |  49981 |00:00:00.10 |     692 | ------------------------------------------------------------------------------------- SQL> select count(*) from test where object_id<100 and object_id>200;  <<<<<with illogical predicate          0 SQL>  select * from table(dbms_xplan.display_cursor(null,null,'allstats last')); SQL_ID  5xv7jfk3ryntq, child number 0 ------------------------------------- select count(*) from test where object_id<100 and object_id>200 Plan hash value: 1617223730 ---------------------------------------------------------------------------- | Id  | Operation           | Name | Starts | E-Rows | A-Rows |   A-Time   |  <<<<<<<<<no buffers information ---------------------------------------------------------------------------- |   1 |  SORT AGGREGATE     |      |      1 |      1 |      1 |00:00:00.01 | |*  2 |   FILTER            |      |      1 |        |      0 |00:00:00.01 | |*  3 |    TABLE ACCESS FULL| TEST |      0 |      8 |      0 |00:00:00.01 | ----------------------------------------------------------------------------  

工具包dbms_xplan.display_cursor在诊断SQL性能方面是非常有用的,特别是与Statistics_level=all;一起使用同时制定Format为allstats last是会看到很多有用的信息,但是今天遇到一个问题,和大家分享一下。就是Statistics_level=all加...

技术共享

12.2 如何单为PDB创建AWR报告

只有12.2才有这个功能。 http://docs.oracle.com/database/122/TGDBA/gathering-database-statistics.htm#TGDBA-GUID-D64AEB01-18FF-47EF-BB5C-A0611117D180 步骤如下: 1)设置PDB的awr_pdb_autoflush_enabled=true: alter session set container=PDB1; alter system set awr_pdb_autoflush_enabled=true; 2)设置AWR snpashot时间间隔为1小时: select * from cdb_hist_wr_control; DBID    SNAP_INTERVAL    RETENTION    TOPNSQL    CON_ID 2580889417    +40150 00:01:00.0    +00008 00:00:00.0    DEFAULT    3 execute dbms_workload_repository.modify_snapshot_settings(interval => 60); select * from cdb_hist_wr_control; DBID    SNAP_INTERVAL    RETENTION    TOPNSQL    CON_ID 2580889417    +00000 01:00:00.0    +00008 00:00:00.0    DEFAULT    3 3)同时注意AWR_SNAPSHOT_TIME_OFFSET这个参数建议设置成1000000 以防止过多PDB同时启动snapshot收集导致性能问题 http://docs.oracle.com/database/122/REFRN/AWR_SNAPSHOT_TIME_OFFSET.htm#REFRN10325 alter system set AWR_SNAPSHOT_TIME_OFFSET=1000000 scope=both; 4)等一段时间,等snapshot生成之后就可以生成AWR报告了: SQL> select * from awr_pdb_snapshot; 或者,您也可以手工创建snapshot: SQL> connect / as sysdba SQL> alter session set container=PDB1; SQL> exec dbms_workload_repository.create_snapshot(); 执行生成AWR报告: @?/rdbms/admin/awrrpt Specify the location of AWR Data ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ AWR_ROOT - Use AWR data from root (default) AWR_PDB - Use AWR data from PDB  <<<<<<<

只有12.2才有这个功能。 http://docs.oracle.com/database/122/TGDBA/gathering-database-statistics.htm#TGDBA-GUID-D64AEB01-18FF-47EF-BB5C-A0611117D180 步骤如下: 1)设置PDB的awr_pdb_autoflush_enabled=true: alter session set...

ORACLE数据库中如何插入生僻字

很多客户的数据库的字符集是ZHS16GBK ,但是有些特殊的生僻字在这个字符集里并不包括,下面就以䶮㼆为例,说明如何把这2个字符插入到数据库。 1.说明: 数据库的nls_characterset是ZHS16GBK, NLS_NCHAR_CHARACTERSET是AL16UTF16.  插入数据使用的工具是sqldeveloper,对应的版本是4.2.0.17.089 2.查询这2个字的Unicode编码 互联网上有很多Unicode相关的网站,通过相关网站可以查找到这2个字对应的Unicode编码: 䶮 Unicode编码:4DAE 㼆 Unicode编码:3F06 3.创建测试表 create table test(name nvarchar2(30)); 4.插入数据 SQL>insert into test values(N'䶮㼆'); --必须加字母"N"作为前缀,否则插入的数据依然乱码! SQL>commit; 5.验证数据 SQL> select name,dump(name,1016) b from test; NAME       B ---------- ----------------------------------------------------- 䶮㼆      Typ=1 Len=4 CharacterSet=AL16UTF16: 4d,ae,3f,6 䶮㼆这2个字已经成功的插入表中并能正确显示,对应的Unicode编码是4d,ae,3f,6,跟第一步查询的结果是一致的。 相关参考: The National Character Set ( NLS_NCHAR_CHARACTERSET ) in Oracle 9i, 10g , 11g and 12c (Doc ID 276914.1)

很多客户的数据库的字符集是ZHS16GBK ,但是有些特殊的生僻字在这个字符集里并不包括,下面就以䶮㼆为例,说明如何把这2个字符插入到数据库。 1.说明: 数据库的nls_characterset是ZHS16GBK, NLS_NCHAR_CHARACTERSET是AL16UTF16.  插入数据使用的工具是sqldeveloper,对应的版本是4.2.0.17.089 2.查询这2个字的Unicode编...

分区表增量搜集信息的引入摘要(synopses)的清理

1,首先分区表的增量统计信息搜集是11G引入的新特性,这样可以提高分区表搜集统计信息的效率。即:对于那些没有变化的分区,就不再进行扫描,而在实现该功能时引入摘要(synopses)来辅助完成(计算global信息)。 2,摘要(synopses)信息会逐渐增长从而占用大量的SYSAUX空间,这时最想的就是删除这些数据,但是往往没那么简单能删掉,这里的信息是否伴随统计信息删除而同时删除呢?请看如下测试案例,就会真相大白: 1,create test table create table t partition by list(x) ( partition p1 values (1) , partition p2 values (2) ) as select a.*, mod(rownum,2)+1 as x, (mod(rownum,2)+1)*5 as order_status from all_objects a; 2,set the incremental and gather table stats begin dbms_stats.set_table_prefs(user,'T','INCREMENTAL','TRUE'); dbms_stats.set_table_prefs(user,'T','GRANULARITY','AUTO'); dbms_stats.set_table_prefs(user,'T','PUBLISH','TRUE'); dbms_stats.set_table_prefs(user,'T','ESTIMATE_PERCENT','DBMS_STATS.AUTO_SAMPLE_SIZE'); dbms_stats.gather_table_stats(user,'T'); end; / 3,check the stats info SQL> select table_name, partition_name, to_char(last_analyzed, 'YYYY-MM-DD HH24:MI:SS') as last_analyzed from user_tab_partitions where table_name = 'T';  2    3 TABLE_NAME                     PARTITION_NAME                 LAST_ANALYZED ------------------------------ ------------------------------ ------------------- T                              P1                             2017-10-23 15:30:13 T                              P2                             2017-10-23 15:30:13 4,check the SYNOPSIS info SQL> SELECT tp.bo#,  do.object_id,  do.data_object_id,  object_type, object_name FROM sys.tabpart$ tp,  dba_objects do WHERE tp.bo# IN (SELECT DISTINCT(bo#) FROM sys.WRI$_OPTSTAT_SYNOPSIS$  ) AND tp.obj#     = do.object_id AND tp.DATAOBJ# = do.data_object_id;  2    3    4    5       BO#  OBJECT_ID DATA_OBJECT_ID OBJECT_TYPE         OBJECT_NAME ---------- ---------- -------------- ------------------- --------------------     22225      22227          22227 TABLE PARTITION     T     22225      22226          22226 TABLE PARTITION     T SQL> select count(* )from  wri$_optstat_synopsis_head$ where bo#='22225'  2  ;  COUNT(*) ----------        34  <<<<<<<<<<<<< select   count(* ) from SYS.WRI$_OPTSTAT_SYNOPSIS$  where bo#='22225' SQL>   2 SQL> /  COUNT(*) ----------     44285  <<<<<<<<<< 5, drop the statitics begin dbms_stats.purge_stats(sysdate); end; / 6,check the SYNOPSIS info SQL> select count(* )from  wri$_optstat_synopsis_head$ where bo#='22225'  2  ;  COUNT(*) ----------        34  <<<<<<<<<<<<< select   count(* ) from SYS.WRI$_OPTSTAT_SYNOPSIS$  where bo#='22225' SQL>   2 SQL> /  COUNT(*) ----------     44285  <<<<<<<<<< 很显然结论是不会被删除,那么这里的信息何时被删除呢? a,当对应的分区表取消增量搜集的时候会被删除。 b,当对应的分区变为stale,这是该分区对应的数据会被删除而从新搜集。 c,手工执行删除。参照:How to Delete Unwanted Incremental Partition Statistics Synopsis Information From WRI$_OPTSTAT_SYNOPSIS$ in the SYSAUX Tablespace (Doc ID 1953961.1) 当数据量很大时需要用如下方式删除: SQL> truncate table wri$_optstat_synopsis$; Table truncated. SQL> truncate table wri$_optstat_synopsis_head$; Table truncated. 3. do a rebuild index on the indexes of synopses tables SQL> alter index i_wri$_optstat_synopsis rebuild; Index altered. SQL> alter index i_wri$_optstat_synophead rebuild; 4. 运行rdbms/admin/utlrp.sql

1,首先分区表的增量统计信息搜集是11G引入的新特性,这样可以提高分区表搜集统计信息的效率。即:对于那些没有变化的分区,就不再进行扫描,而在实现该功能时引入摘要(synopses)来辅助完成(计算global信息)。 2,摘要(synopses)信息会逐渐增长从而占用大量的SYSAUX空间,这时最想的就是删除这些数据,但是往往没那么简单能删掉,这里的信息是否伴随统计信息删除而同时删...

v$session - 你看到的event真的是session当前的等待事件么?

当数据库出现性能问题的时候,几乎所有的DBA都会通过v$session来查询数据库的等待。但是,您可曾想过,您用于查询session等待的SQL是正确的么?您看到的event可能并不是session当前的等待,下面举例来说明: 如下的一段简单的PL/SQL Block代码是一个死循环,很显然,它会持续的ON CPU begin   while true loop     null;   end loop; end; / 下面我们用以上代码做一个测试。 --开启一个sqlplus,先确定当前sesison的sid和spid select s.sid,s.serial#,p.spid from v$session s, v$process p, (select * from v$mystat where rownum=1) ms where s.paddr=p.addr and s.sid=ms.sid;        SID    SERIAL# SPID ---------- ---------- ------------------------        283    55044 30176 --然后在这个sqlplus中执行以上PL/SQL代码: begin   while true loop     null;   end loop; end; / --再开启一个新的session,观察以上session 283的等待: set line 200 pages 1000 col username for a5 col event for a30 select sid,serial#,status,sql_id,event,seq# from v$session where sid=283;        SID    SERIAL# STATUS   SQL_ID         EVENT                  SEQ# ---------- ---------- -------- ------------- ------------------------------ ----------        283    55044 ACTIVE   1dn7nmztb2jaz SQL*Net message from client       247 --验证一下sql文本 col sql_text for a60 select sql_id,sql_text from v$sql where sql_id='1dn7nmztb2jaz'; SQL_ID          SQL_TEXT ------------- ------------------------------------------------------------ 1dn7nmztb2jaz begin   while true loop      null;   end loop; end; 您会发现以上这个session竟然会在 "等待" SQL*Net message from client,并且status为ACTIVE,大家都知道SQL*Net message from client是一个空闲等待,代表server process正在等待client发出下一个sql指令。 接下来观察以上以上进程的CPU消耗情况,会发现它在持续的ON CPU # top -p 30176   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                             30176 oracle    20   0 1470m  89m  80m R 47.0  1.1   2:38.91 oracle_30176_or 它几乎消耗了一半的CPU(本测试机为两个CPU),这符合代码的特点。 那么问题来了,这个如此烧CPU的死循环session怎么会是处于空闲等待?答案是我们忽略了v$session.state这个非常重要的列。 一个session的状态要么是在等待,要么是在ON CPU,v$session.state这个列可以判断这个状态。有且只有v$session.state='WAITING'的时候,才代表这个session当前正在等待这个event,否则代表这个session在ON CPU,并且观察到的event只是进程在ON CPU之前的最后一个等待。 接下来我们将以上用于查询session等待的SQL改一下,添加上v$session.state这个列: col state fro a15 select sid,serial#,status,state,sql_id,event,seq# from v$session where sid=283;        SID    SERIAL# STATUS   STATE           SQL_ID     EVENT                      SEQ# ---------- ---------- -------- ------------------- ------------- ------------------------------ ----------        283    55044 ACTIVE   WAITED KNOWN TIME   1dn7nmztb2jaz SQL*Net message from client           247 可见STATE的值为"WAITED KNOWN TIME",不是"WAITING",这表明这个session当前在ON CPU,"SQL*Net message from client"只是这个session在ON CPU之前的最后一个等待。因此当您查询v$session观察session的等待事件的时候,一定不要忘了v$session.state这个关键列。

当数据库出现性能问题的时候,几乎所有的DBA都会通过v$session来查询数据库的等待。但是,您可曾想过,您用于查询session等待的SQL是正确的么?您看到的event可能并不是session当前的等待,下面举例来说明: 如下的一段简单的PL/SQL Block代码是一个死循环,很显然,它会持续的ON CPU begin   while true loop     null;  end...

技术共享

如何使用SQLT创建一个testcase

开Bug必备,wrong result问题必备。不解释,直接贴action plan。 1)在以下文档中下载并安装最新的 SQLT: SQLT (SQLTXPLAIN) - Tool that helps to diagnose SQL statement  performing poorly (Doc ID 215187.1) Install SQLT: # cd sqlt/install # sqlplus / as sysdba SQL> START sqcreate.sql 2)生成SQLT report(包含不带数据的testcase,如果生成带数据的,请直接跳到第3步): cd sqlt/run sqlplus / as sysdba START sqltxtract.sql <SQL_ID> <======替换<SQL_ID>成你想要生成报告的SQL ID. 比如: START sqltxtract.sql bkvbqs9tjpufv 如果是12c以上版本,使用SYSDBA是无法正确生成报告的,必须赋权或者使用其他用户: sqlplus / as sysdba GRANT INHERIT PRIVILEGES ON USER SYS TO SQLTXADMIN; START sqltxtract.sql bkvbqs9tjpufv 或者使用其他用户 sqlplus oracle/oracle START sqltxtract.sql bkvbqs9tjpufv ... 中间过程忽略,在这一步输入SQLTXPLAIN用户的密码(希望你还记得安装时输入过的) Paremeter 2: SQLTXPLAIN password (required) Enter value for 2:  <====输入SQLTXPLAIN用户的密码(希望你还记得安装时输入过的) 其他一路回车 ... 在当前目录下生成以下文件: ls -l -rw-r--r--  1 oracle dba 2592472 Nov  9 14:18 sqlt_s48357_xtract_bkvbqs9tjpufv.zip -rw-r--r--  1 oracle dba     238 Nov  9 14:18 sqlt_s48357_purge.sql   如何使用这个报告呢? 在目标机器解压: unzip sqlt_s48357_xtract_bkvbqs9tjpufv.zip -d s48357 [oracle@nascds18 run]$ cd s48357 [oracle@nascds18 s48357]$ ls sqlt_s48357_10053_explain.trc        sqlt_s48357_readme.html sqlt_s48357_10053_i1_c0_extract.trc  sqlt_s48357_sql_detail_active.html sqlt_s48357_cell_state.zip           sqlt_s48357_sqldx.zip sqlt_s48357_driver.zip               sqlt_s48357_tc_script.sql sqlt_s48357_lite.html                sqlt_s48357_tc_sql.sql sqlt_s48357_log.zip                  sqlt_s48357_tcx.zip sqlt_s48357_main.html                sqlt_s48357_tc.zip sqlt_s48357_opatch.zip               sqlt_s48357_trc.zip unzip sqlt_s48357_tc.zip -d tc cd tc ./xpress.sh ... 3/7 Press ENTER to import SQLT repository for statement_id 48357. SQL> HOS imp SQLTXPLAIN FILE=sqlt_s48357_exp.dmp LOG=sqlt_s48357_imp.log TABLES=sqlt% IGNORE=Y Import: Release 12.2.0.1.0 - Production on Thu Nov 9 14:21:58 2017 Copyright (c) 1982, 2017, Oracle and/or its affiliates.  All rights reserved. Password: <====输入SQLTXPLAIN用户的密码(希望你还记得安装时输入过的) Export file created by EXPORT:V12.02.00 via conventional path import done in US7ASCII character set and AL16UTF16 NCHAR character set import server uses AL32UTF8 character set (possible charset conversion) . importing SQLTXPLAIN's objects into SQLTXPLAIN . importing SQLTXPLAIN's objects into SQLTXPLAIN . . importing table          "SQLT$_SQL_STATEMENT"          1 rows imported . . importing table             "SQLT$_AUX_STATS$"         13 rows imported . . importing table    "SQLT$_DBA_AUTOTASK_CLIENT"          1 rows imported . . importing table "SQLT$_DBA_AUTOTASK_CLIENT_HST"         20 rows imported . . importing table      "SQLT$_DBA_HIST_SNAPSHOT"        198 rows imported . . importing table            "SQLT$_DBA_OBJECTS"          1 rows imported . . importing table "SQLT$_DBA_OPTSTAT_OPERATIONS"       3054 rows imported . . importing table           "SQLT$_DBA_SEGMENTS"          1 rows imported . . importing table           "SQLT$_DBA_TAB_COLS"          1 rows imported . . importing table  "SQLT$_DBA_TAB_MODIFICATIONS"          1 rows imported . . importing table     "SQLT$_DBA_TAB_STATISTICS"          1 rows imported . . importing table             "SQLT$_DBA_TABLES"          1 rows imported . . importing table        "SQLT$_DBA_TABLESPACES"          5 rows imported . . importing table             "SQLT$_DBMS_XPLAN"         77 rows imported . . importing table      "SQLT$_GV$NLS_PARAMETERS"         19 rows imported . . importing table   "SQLT$_GV$OBJECT_DEPENDENCY"          2 rows imported . . importing table          "SQLT$_GV$PARAMETER2"        428 rows imported . . importing table       "SQLT$_GV$PARAMETER_CBO"        505 rows imported . . importing table            "SQLT$_GV$PQ_SLAVE"          8 rows imported . . importing table          "SQLT$_GV$PQ_SYSSTAT"         20 rows imported . . importing table          "SQLT$_GV$PX_PROCESS"          8 rows imported . . importing table  "SQLT$_GV$PX_PROCESS_SYSSTAT"         15 rows imported . . importing table                 "SQLT$_GV$SQL"          1 rows imported . . importing table   "SQLT$_GV$SQL_OPTIMIZER_ENV"          1 rows imported . . importing table            "SQLT$_GV$SQL_PLAN"          2 rows imported . . importing table   "SQLT$_GV$SQL_SHARED_CURSOR"          1 rows imported . . importing table             "SQLT$_GV$SQLAREA"          1 rows imported . . importing table   "SQLT$_GV$SQLAREA_PLAN_HASH"          1 rows imported . . importing table            "SQLT$_GV$SQLSTATS"          1 rows imported . . importing table  "SQLT$_GV$SQLSTATS_PLAN_HASH"          1 rows imported . . importing table "SQLT$_GV$SQLTEXT_WITH_NEWLINES"          1 rows imported . . importing table    "SQLT$_GV$SYSTEM_PARAMETER"        426 rows imported . . importing table                    "SQLT$_LOG"        922 rows imported . . importing table               "SQLT$_METADATA"          3 rows imported . . importing table "SQLT$_NLS_DATABASE_PARAMETERS"         20 rows imported . . importing table           "SQLT$_OUTLINE_DATA"         28 rows imported . . importing table         "SQLT$_PLAN_EXTENSION"          4 rows imported . . importing table              "SQLT$_PLAN_INFO"         16 rows imported . . importing table         "SQLT$_SQL_PLAN_TABLE"          2 rows imported . . importing table  "SQLT$_V$SESSION_FIX_CONTROL"       1301 rows imported . . importing table         "SQLT$_WRI$_ADV_TASKS"          1 rows imported . . importing table "SQLT$_WRI$_OPTSTAT_AUX_HISTORY"         36 rows imported Import terminated successfully with warnings. ... 最终会生成一个TCxxxxxx用户,就是你文件名里的这个号码sqlt_s48357_xtract_bkvbqs9tjpufv.zip,表在该用户下,但是没数据: SQL> select * from TC48357.test; no rows selected   3)生成包含数据的SQLT report(请注意原表中的数据不要太大,或者使用tcb_sampling_percent取百分比的数据): 主要增加了以下设置: EXEC sqltxadmin.sqlt$a.set_sess_param('tcb_export_data', 'TRUE'); EXEC sqltxadmin.sqlt$a.set_sess_param('tcb_export_pkg_body', 'TRUE'); EXEC sqltxadmin.sqlt$a.set_sess_param('tcb_sampling_percent', '10'); 请注意表中数据不要太大,清理数据的同时请保持能够重现问题。 请注意使用tcb_sampling_percent可能会导致无法重现问题。基于这个原因,以下步骤去掉了这个设置,您可以根据需要增加。 更早版本的设置请参考: How to Use SQLT (SQLTXPLAIN) to Create a Testcase Containing Application Data (Doc ID 1465741.1) 以下是具体步骤: cd sqlt/run sqlplus / as sysdba START sqltxtract.sql <SQL_ID> <======替换<SQL_ID>成你想要生成报告的SQL ID. 比如: EXEC sqltxadmin.sqlt$a.set_sess_param('tcb_export_data', 'TRUE'); EXEC sqltxadmin.sqlt$a.set_sess_param('tcb_export_pkg_body', 'TRUE'); START sqltxtract.sql bkvbqs9tjpufv 如果是12c以上版本,使用SYSDBA是无法正确生成报告的,必须赋权或者使用其他用户: sqlplus / as sysdba GRANT INHERIT PRIVILEGES ON USER SYS TO SQLTXADMIN; EXEC sqltxadmin.sqlt$a.set_sess_param('tcb_export_data', 'TRUE'); EXEC sqltxadmin.sqlt$a.set_sess_param('tcb_export_pkg_body', 'TRUE'); START sqltxtract.sql bkvbqs9tjpufv 或者使用其他用户 sqlplus oracle/oracle EXEC sqltxadmin.sqlt$a.set_sess_param('tcb_export_data', 'TRUE'); EXEC sqltxadmin.sqlt$a.set_sess_param('tcb_export_pkg_body', 'TRUE'); START sqltxtract.sql bkvbqs9tjpufv ... ... 中间过程忽略,在这一步输入SQLTXPLAIN用户的密码(希望你还记得安装时输入过的) Paremeter 2: SQLTXPLAIN password (required) Enter value for 2:  <====输入SQLTXPLAIN用户的密码(希望你还记得安装时输入过的) 其他一路回车 ... 在当前目录下生成以下文件: ls -l -rw-r--r--  1 oracle dba 2055250 Nov  9 15:17 sqlt_s48361_xtract_bkvbqs9tjpufv.zip -rw-r--r--  1 oracle dba     238 Nov  9 15:17 sqlt_s48361_purge.sql   如何使用这个报告呢? 在目标机器解压: unzip sqlt_s48361_xtract_bkvbqs9tjpufv.zip -d s48361 [oracle@nascds18 run]$ cd s48361 [oracle@nascds18 s48357]$ ls sqlt_s48361_10053_explain.trc        sqlt_s48361_readme.html sqlt_s48361_10053_i1_c0_extract.trc  sqlt_s48361_sql_detail_active.html sqlt_s48361_cell_state.zip           sqlt_s48361_sqldx.zip sqlt_s48361_driver.zip               sqlt_s48361_tcb.zip sqlt_s48361_lite.html                sqlt_s48361_tc_script.sql sqlt_s48361_log.zip                  sqlt_s48361_tc_sql.sql sqlt_s48361_main.html                sqlt_s48361_tcx.zip sqlt_s48361_opatch.zip               sqlt_s48361_tc.zip sqlt_s48361_perfhub_0001__.html      sqlt_s48361_trc.zip unzip sqlt_s48361_tc.zip -d tc cd tc ./xpress.sh ... 3/7 Press ENTER to import SQLT repository for statement_id 48357. SQL> HOS imp SQLTXPLAIN FILE=sqlt_s48357_exp.dmp LOG=sqlt_s48357_imp.log TABLES=sqlt% IGNORE=Y Import: Release 12.2.0.1.0 - Production on Thu Nov 9 14:21:58 2017 Copyright (c) 1982, 2017, Oracle and/or its affiliates.  All rights reserved. Password: <====输入SQLTXPLAIN用户的密码(希望你还记得安装时输入过的)   然后使用unzip sqlt_s48361_tcb.zip文件,tcb才会包含数据: unzip sqlt_s48361_tcb.zip -d tcb cd tcb [oracle@nascds18 tcb]$ ls sqlt_s48361_tcb_dpexp.dmp  sqlt_s48361_tcb_prmimp.sql  sqlt_s48361_tcb_ts.xml sqlt_s48361_tcb_dpexp.log  sqlt_s48361_tcb_README.txt  sqlt_s48361_tcb_xplf.sql sqlt_s48361_tcb_dpexp.sql  sqlt_s48361_tcb_smrpt.html  sqlt_s48361_tcb_xplo.sql sqlt_s48361_tcb_dpimp.sql  sqlt_s48361_tcb_sql.xml     sqlt_s48361_tcb_xpls.sql sqlt_s48361_tcb_main.xml   sqlt_s48361_tcb_ssimp.sql   sqlt_s48361_tcb_xpl.txt sqlt_s48361_tcb_ol.xml     sqlt_s48361_tcb_.trc 检查下这些文件所在的文件夹: pwd /home/oracle/sqlt/run/s48361/tcb sqlplus / as sysdba      create directory imp_tc as '/home/oracle/feng/sqlt/run/s48361/tcb';<====将这个文件夹建成目录      grant read on directory imp_tc to TC48361;      grant write on directory imp_tc to TC48361;      connect TC48361/TC48361      begin        dbms_sqldiag.import_sql_testcase(directory=>'IMP_TC', filename =>'sqlt_s48361_tcb_main.xml');      end;      / SQL> select * from TC48361.test;          A ----------          1 <===========数据被导入

开Bug必备,wrong result问题必备。不解释,直接贴action plan。 1)在以下文档中下载并安装最新的 SQLT: SQLT (SQLTXPLAIN) - Tool that helps to diagnose SQL statement  performing poorly (Doc ID 215187.1) Install SQLT: # cd sqlt/install#...

技术共享

安装ORACLE 12.2.0.1 GI 时遇到INS-44002错误

安装到Installation Location时遇到[INS-44002] The Oracle home location contains directories or files on following remote nodes 错误。 用户在环境变量中设置了ORACLE_HOME: ORACLE_HOME=/u01/oracle/app/grid/product/12.2.0 并且已经反复确认过/u01/oracle/app/grid/product/12.2.0目录下是空的,甚至把/u01/oracle/app/grid_base下的所有内容都删除了,也就是ORACLE_HOME和ORACLE_BASE都是空的,可是仍然遇到这个错误。   首先,Oracle软件在安装时不要设置任何oracle相关的环境变量,oracle默认用户什么都没有设置就开始安装,安装路径,ORACLE_BASE/ORACLE_HOME都是在安装时选择指定的。 其次,12.2的GI的安装有一个重大改变,不再有runInstaller了,而是直接解压到ORACLE_HOME下,运行gridSetup.sh进行配置,请一定要参考安装文档进行安装: Grid Infrastructure Installation and Upgrade Guide 9.3.3 Installing Oracle Member Clusters https://docs.oracle.com/database/122/CWLIN/installing-oracle-member-clusters.htm#CWLIN-GUID-E8B7F0FA-4781-4B28-AFCD-7934255F4A24 这一步的Software location,就是ORACLE_HOME,就是你运行gridSetup.sh的所在路径,所以是不能选的。而且你也不能再指定其他路径为ORACLE_HOME了。 解决方案: 1)从环境变量中取消ORACLE_HOME设置 2)将grid.zip解压到节点1的/u01/oracle/app/grid/product/12.2.0目录下(如果你希望这个目录是ORACLE_HOME的话,当然你也可以放到其他目录下),并运行gridSetup.sh 3)保证其他节点上的相同ORACLE_HOME(比如/u01/oracle/app/grid/product/12.2.0)目录是空的,并且GI安装用户有权限访问他们。

安装到Installation Location时遇到[INS-44002] The Oracle home location contains directories or files on following remote nodes 错误。 用户在环境变量中设置了ORACLE_HOME: ORACLE_HOME=/u01/oracle/app/grid/product/12.2.0 并且已经反复确认...

为什么数据库中大量的server process没有对应的session?

在什么情况下oracle server process没有对应的session?除了px进程以外,还有没有其他情况?下面的一个真实的案例中,有600个个server process没有session对应,并且这样的process越来越多,似乎永远也不自己释放,原因是什么呢? 首先查询一下v$process和v$session,观察差异,可见差异有600多个。 select * from v$process; 1674 rows selected. select * from v$session; 1051 rows selected. 比对了一下,v$process中除了32个px进程以外,还有大量的普通server process,并且它们已经存在了很多天了。 select * from v$process p where p.addr not in (select addr from v$process p,v$session s where s.creator_addr=p.addr) order by pid; SPID    PROGRAM 29674    oracle@mydb01 (P000) 29820    oracle@mydb01 (P001) 29822    oracle@mydb01 (P002) ...... 31415    oracle@mydb01 (P031) 31417    oracle@mydb01 (P032) 31419    oracle@mydb01 (P033) 7523    oracle@mydb01 27740    oracle@mydb01 3283    oracle@mydb01 29116    oracle@mydb01 20006    oracle@mydb01 12831    oracle@mydb01 15681    oracle@mydb01 2139    oracle@mydb01 8606    oracle@mydb01 3963    oracle@mydb01 31811    oracle@mydb01 1613    oracle@mydb01 ...... 先确认一下当前时间是2017年10月12日: # date Thu Oct 12 11:03:54 CST 2017 然后选取一个v$process中没有session的进程,比如以上输出中的最后一行的pid为1613的进程,通过ps来观察其状态: # ps -aeo user,pid,ppid,pri,pcpu,pmem,vsize,rssize,wchan:25,s,start,cputime,command USER       PID  PPID PRI %CPU %MEM    VSZ   RSS WCHAN                     S  STARTED     TIME COMMAND oracle 1613 1 19 0.0 0.0 365768 27636 sk_wait_data S Oct 04 00:00:00 oraclemydb01 (LOCAL=NO) 发现以上进程在10月4日就存在了,也就是已经过了8天了。同时做一次system state dump,找到这个进程1613 PROCESS 1560: ---------------------------------------- SO: 0x73a3d79790, type: 2, owner: (nil), flag: INIT/-/-/0x00 if: 0x3 c: 0x3 proc=0x73a3d79790, name=process, file=ksu.h LINE:13949, pg=0 conuid=0 (process) Oracle pid:1560, ser:174, calls cur/top: (nil)/0x71232cdd70 ...... Process Group: DEFAULT, pseudo proc: 0x7323de7370 O/S info: user: grid, term: UNKNOWN, ospid: 1613 <<<<<< 这里可见进程 1613 OSD pid info: Short stack dump: ksedsts <- ksdxfstk <- ksdxcb <- sspuser <- __sighandler <- read <- nttfprd <- nsbasic_brc <- nsbrecv <- nioqrc <- opikndf2 <- opitsk <- opiino <- opiodr <- opidrv <- sou2o <- opimai_real <- ssthrdmain <- main 可以看到以上进程的call stack都是一些网络相关的function call,既然与网络有关系,不妨取一下其打开的tcp连接: # lsof -p 1613 -Pnai TCP COMMAND     PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME oracle_16 1613 oracle 20u IPv4 1303337121 0t0 TCP 10.5.20.110:1521->10.5.70.234:23966 (ESTABLISHED) 可见server端(10.5.20.110)的确和一个client端(10.5.70.234)建立了连接,找到client端(10.5.70.234),在client上用如下命令观察是什么进程建立了连接: # lsof -Pni :5926 COMMAND   PID   USER   FD   TYPE DEVICE SIZE NODE NAME sqlplus 29544 oracle    9u  IPv4 739424       TCP 10.5.70.234:23966->10.5.20.110:1521 (ESTABLISHED) 原来客户端是一个sqlplus进程,进程号为29544,但是什么情况下sqlplus连接数据库后只有server process而没有session?最大的可能性是这个进程正处于密码验证阶段。 检查一下调用这个sqlplus的脚本,果然发现脚本中指定的登录数据库的密码是错误的! 接下来在12.2.0.1的测试机上模拟一下,sqlplus故意以错误密码登录,然后停住不动等1分钟,看能否重现这个现象。 sqlplus tony/a@server_r12201 SQL*Plus: Release 12.2.0.1.0 Production on Thu Nov 2 11:50:46 2017 Copyright (c) 1982, 2016, Oracle.  All rights reserved. ERROR: ORA-01017: invalid username/password; logon denied Enter user-name:   <<<<停在这里不要动 在server上通过两次ps定位是哪个进程被最新创建: # ps -ef | egrep "oracleR12201 \(LOCAL=NO\)|PID" | grep -v grep UID        PID  PPID  C STIME TTY          TIME CMD oracle     962     1  0 Oct31 ?        00:00:04 oracleR12201 (LOCAL=NO) # ps -ef | egrep "oracleR12201 \(LOCAL=NO\)|PID" | grep -v grep UID        PID  PPID  C STIME TTY          TIME CMD oracle     962     1  0 Oct31 ?        00:00:04 oracleR12201 (LOCAL=NO) oracle   28540     1  0 11:50 ?        00:00:00 oracleR12201 (LOCAL=NO) 两次ps对比可见新产生了进程28540,查询v$process v$session select * from v$process where spid=28540; ADDR    SPID    PROGRAM 000000006A576D48    28540    oracle@testsever select * from v$session where creator_addr='000000006A576D48'; no rows selected. 看来问题重现了,以上的进程28540在v$process中存在但是在v$session中不存在。 但是,在我们的测试中,进程28540会在大约1分钟后自行从server端退出,并且在alert log中打印如下信息 2017-11-02T11:51:02.509020+08:00 *********************************************************************** Fatal NI connect error 12170.   VERSION INFORMATION:     TNS for Linux: Version 12.2.0.1.0 - Production     Oracle Bequeath NT Protocol Adapter for Linux: Version 12.2.0.1.0 - Production     TCP/IP NT Protocol Adapter for Linux: Version 12.2.0.1.0 - Production   Time: 02-NOV-2017 11:51:02   Tracing not turned on.   Tns error struct:     ns main err code: 12535      TNS-12535: TNS:operation timed out     ns secondary err code: 12606     nt main err code: 0     nt secondary err code: 0     nt OS err code: 0   Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=10.182.211.94)(PORT=51681)) 2017-11-02T11:51:02.510302+08:00 WARNING: inbound connection timed out (ORA-3136) 看到这个错误可能大家马上想到了SQLNET.INBOUND_CONNECT_TIMEOUT这个Oracle*Net参数,的确,问题是这个参数引发的。在server端打开$ORACLE_HOME/network/admin/sqlnet.ora,发现如下设置: SQLNET.INBOUND_CONNECT_TIMEOUT=0 以上参数的含义是完成用户验证的最大时间,设置成0代表无限。也就是说,如果客户端输错了密码,只要客户端不关闭,那么对应的server process会永远等待client。 这个时候我们终于知道这个问题的原因了: 客户端输错了密码,停留在提示输入再次密码的界面上,并且数据库的server端的sqlnet.ora设置了SQLNET.INBOUND_CONNECT_TIMEOUT=0(无限时间),导致server process一直等待客户端输入密码验证,因此永远也不自动退出。 这个问题实际上还是比较严重的,它可能会导致ORA-00020错误发生,并且导致新的session无法连接。

在什么情况下oracle server process没有对应的session?除了px进程以外,还有没有其他情况?下面的一个真实的案例中,有600个个server process没有session对应,并且这样的process越来越多,似乎永远也不自己释放,原因是什么呢? 首先查询一下v$process和v$session,观察差异,可见差异有600多个。 select * from...

技术共享

12.2.0.1数据库alert log中的ORA-00933: SQL Command Not Properly Ended错误

12.2.0.1数据库alert log中经常报ORA-00933: SQL Command Not Properly Ended错误,是MMON的slave进程M000,M001,M002...报出来的: +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2017-08-30T22:18:49.533322+08:00 Errors in file /u01/app/oracle/diag/rdbms/hods/HODS1/trace/HODS1_m002_77817.trc: ORA-00933: SQL command not properly ended ★ 2017-08-30T22:18:52.591018+08:00 WARNING: too many parse errors, count=100 SQL hash=0x750004bb PARSE ERROR: ospid=77817, error=933 for statement: 2017-08-30T22:18:52.591247+08:00 DELETE FROM wri$_adv_sqlt_rtn_planWHERE task_id = :tid AND exec_name = :execution_name Additional information: hd=0x1ef6f9e2a0 phd=0x1ef6f9f6c8 flg=0x28 cisid=0 sid=0 ciuid=0 uid=0 2017-08-30T22:18:52.591466+08:00 ----- PL/SQL Call Stack -----  object line object  handle number name 0x2095465080 259 type body SYS.WRI$_ADV_SQLTUNE.SUB_DELETE_EXECUTION 0x219fa47d70 2134 package body SYS.PRVT_ADVISOR.COMMON_DELETE_TASK 0x219fa47d70 7342 package body SYS.PRVT_ADVISOR.DELETE_EXPIRED_TASKS 0x1f9f816918 1 anonymous block 2017-08-30T22:57:39.000273+08:00 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 大量的报错给用户造成困扰,这是一个Bug: Bug 26764561 ORA-00933 IN SYS.WRI$_ADV_SQLTUNE.SUB_DELETE_EXECUTION 是在删除过期的sql tuning task时,某个语句少了一个空格: “wri$_adv_sqlt_rtn_planWHERE”(错误)=》"wri$_adv_sqlt_rtn_plan WHERE"(正确)   该bug将在18.1版本上修复,如果有您平台的补丁请下载补丁,如果没有请开SR申请。 您也可以关闭sql tuning advisor计划任务来workaround该问题:   BEGIN dbms_auto_task_admin.DISABLE( client_name => 'sql tuning advisor', operation => '', window_name => ''); END; /

12.2.0.1数据库alert log中经常报ORA-00933: SQL Command Not Properly Ended错误,是MMON的slave进程M000,M001,M002...报出来的: +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2017-08-30T22:18:49.533322+08:00Err...

技术共享

RDA在远程节点上无法搜集日志的问题

在RAC环境中运行RDA,默认应该在一个节点上执行就可以搜集所有节点的数据并打包到当前目录下。 然而并没有(测试使用8.15版本,实际影响8.18之前的版本): 1. ./rda.pl -vXRda start CLOUD -p Rac_Assessment 2. ./rda.sh -v -e REMOTE_TRACE=1 Collecting diagnostic data ... ------------------------------------------------------------------------------ RDA Data Collection Started 22-May-2017 14:10:00 ------------------------------------------------------------------------------ Processing RDA.BEGIN module ... Inside BEGIN module, testing the RDA engine code build Inside BEGIN module, testing the report directory Inside BEGIN module, testing the module targets Inside BEGIN module, launching parallel executions Processing RDA.CONFIG module ... Inside CONFIG module, listing Oracle homes Inside CONFIG module, getting Oracle home inventory (can take time) Processing RDA.REMOTE module ... NOD001: Detecting storage type NOD001: Running RDA command NOD002: Detecting storage type NOD002: Installing RDA software <=============始终在节点2上安装software,然后不搜集日志 NOD001: Transfering report package Processing RDA.END module ... [oracle@nascds10 remote]$ ls -l total 9992 -rw-r----- 1 oracle oinstall 10214781 May 22 14:34 RDA_nod001_output.zip <======只有 node001的日志,没有node002的。 这是Bug 26544160 RDA is not collecting remote node information in RAC environment,因为文件’/home/oracle/rda/sdboot.pl‘没有成功拷贝,在远程安装完成后检查是否完成的操作失败了,导致每次执行都重新安装,安装都不成功,从而始终不在远程节点搜集日志。 该bug将在2017年12月12日发布的8.18版本中修复,您可以等待新版本发布后,重新从note 314422.1中去下载。 另外,对于数据库/RAC的问题,oracle推荐您使用TFA来搜集诊断日志,TFA将搜集更多更全的信息: TFA Collector - TFA with Database Support Tools Bundle (Doc ID 1513912.1)  

在RAC环境中运行RDA,默认应该在一个节点上执行就可以搜集所有节点的数据并打包到当前目录下。 然而并没有(测试使用8.15版本,实际影响8.18之前的版本): 1. ./rda.pl -vXRda start CLOUD -p Rac_Assessment 2. ./rda.sh -v -e REMOTE_TRACE=1 Collecting diagnostic data ...-----------...

诊断方法

一个ASMCA无法识别磁盘设备的问题。

在linux 环境下,我们一般通过udev或者asmlib来绑定磁盘分区作为ASM的候选存储单元。在使用udev的情况下,一般只要我们可以看到被绑定的磁盘的设备,并且这些设备的属主和权限没有问题,ASM就可以识别并使用这些设备了。 但是也有例外情况: 1. 首先观察到的现象:在ASMCA的“"show eligible" 页面,看不到udev绑定的设备/dev/data2 2. udev的rule,和设备的权限以及属主都没有问题 cat 99-oracle-asmdevices.rules ...... KERNEL=="sda1",BUS=="scsi",PROGRAM=="/sbin/scsi_id -g -u -d /dev/$parent",RESULT=="360a980004430753872244b6e4a376f70",NAME="data2",OWNER="grid", GROUP="asmadmin", MODE="0660" ls -l /dev |grep data ...... brw-rw---- 1 grid asmadmin 8, 1 Nov 1 09:36 data2 3. 通过kfed来读取这个设备,好像也没有问题: $ kfed read /dev/data2 kfbh.endian: 0 ; 0x000: 0x00 kfbh.hard: 0 ; 0x001: 0x00 kfbh.type: 0 ; 0x002: KFBTYP_INVALID kfbh.datfmt: 0 ; 0x003: 0x00 kfbh.block.blk: 0 ; 0x004: blk=0 kfbh.block.obj: 0 ; 0x008: file=0 kfbh.check: 0 ; 0x00c: 0x00000000 kfbh.fcn.base: 0 ; 0x010: 0x00000000 kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 kfbh.spare1: 0 ; 0x018: 0x00000000 kfbh.spare2: 0 ; 0x01c: 0x00000000 7FFCA34D0400 00000000 00000000 00000000 00000000 [................] Repeat 255 times KFED-00322: Invalid content encountered during block traversal: [kfbtTraverseBlock][Invalid OSM block type][][0] 那么这是什么鬼???看似权限,属主,盘的读取都没有问题啊。。。 后来经过确认,原来这个分区/dev/sda1是个扩展分区。。。 fdisk -l ...... Disk /dev/sda: 322.2 GB, 322163441664 bytes 255 heads, 63 sectors/track, 39167 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xc4ca7a41 Device Boot Start End Blocks Id System /dev/sda1 1 39167 314608896 5 Extended 总结,Oracle不能直接使用扩展分区作为ASM的首选存储设备,对于一块磁盘,或者把它分区成主分区,或者在扩展分区上创建逻辑分区。如果发现磁盘的权限,属主,读写都没有问题的话,ASM还是不识别设备,那就再确认一下这个分区是不是个扩展分区。

在linux 环境下,我们一般通过udev或者asmlib来绑定磁盘分区作为ASM的候选存储单元。在使用udev的情况下,一般只要我们可以看到被绑定的磁盘的设备,并且这些设备的属主和权限没有问题,ASM就可以识别并使用这些设备了。 但是也有例外情况: 1. 首先观察到的现象:在ASMCA的“"show eligible" 页面,看不到udev绑定的设备/dev/data2 2....

不要认为使用全局临时表,对于redo的产生量的控制就可以高枕无忧!

对于全局临时表,有一个非常闪耀的亮点就是可以避免大量的redo产生,这是我们都知道的。文档68098.1中也有说明。 其实在对全局临时表做DML操作时,还是会产生一些redo的,这部分主要来自于undo,文档848852.1中也有说明。 那么,写这篇文章的目的就是想通过一个测试提醒大家,使用全局临时表,有时也会产生大量的redo。特别是在delete操作的时候,所以,如果使用全局临时表的出发点在于减少redo,那么要引起注意,请参照如下的测试: ----------------------------------------------------------------------- 1,create global temporary table temp SQL>create global temporary table temp as select  * from dba_objects; 2,check there is no record SQL> select count(*) from temp;  COUNT(*) ----------         0 3,enable autotrace SQL>set autotrace on 4,insert into data SQL> insert into temp select * from dba_objects; 18181 rows created. Statistics ----------------------------------------------------------        733  recursive calls       1359  db block gets       1149  consistent gets        129  physical reads      99056  redo size   <<<<<<<<<99K redo        843  bytes sent via SQL*Net to client        799  bytes received via SQL*Net from client          3  SQL*Net roundtrips to/from client         91  sorts (memory)          0  sorts (disk)      18181  rows processed 5,delete data SQL> delete from temp; Statistics ----------------------------------------------------------         53  recursive calls      19629  db block gets        348  consistent gets          0  physical reads    5499048  redo size  <<<<<<<<<<5M redo size        844  bytes sent via SQL*Net to client        773  bytes received via SQL*Net from client          3  SQL*Net roundtrips to/from client          6  sorts (memory)          0  sorts (disk)      18181  rows processed

对于全局临时表,有一个非常闪耀的亮点就是可以避免大量的redo产生,这是我们都知道的。文档68098.1中也有说明。 其实在对全局临时表做DML操作时,还是会产生一些redo的,这部分主要来自于undo,文档848852.1中也有说明。 那么,写这篇文章...

其他

Oracle Database - Standard Edition - Version 12.2.0.1 客户端在Windows 10 Pro (1703)平台安装报PRVF-3919

Oracle Database - Standard Edition - Version 12.2.0.1 客户端在Windows 10 Pro (1703)平台安装报PRVF-3919 : Failed to retrieve value of environment variable "PATH"错误。首先检查PATH的设置,如果没有问题可以参考如下步骤进行解决。 1,Download the srvm.jar. 2,Confirm whether the java version "1.8.0_91" is available, if not available then download the java and install. 3,Unzip the following filegroup1.jar of the following folder. <Shiphome>/stage/Components/oracle.swd.oui.core/12.2.0.1.4/1/DataFiles <shiphome>/stage/Components/oracle.has.rsf/12.2.0.1.0/1/DataFiles <shiphome>/stage/Components/oracle.has.common.cvu/12.2.0.1.0/1/DataFiles <Shiphome>/stage/Components/oracle.has.deconfig/12.2.0.1.0/1/DataFiles 4,Replace the srvm.jar in the jlib sub-folder of filegroup1 with the downloaded one. 5,Re-Jar the filegroup1.jar with the following steps(one example): a,cd <Shiphome>/stage/Components/oracle.has.rsf/12.2.0.1.0/1/DataFiles/filegroup1 b,execute the command jar -cvf filegroup1.jar * 6,Clean up the Temp folder(Important). For example:C:\Users\<OS User>\AppData\Local\Temp\ 7,re-run the setup.exe 当然这只是临时的解决方法,安装介质更新后就不会有该问题了。

Oracle Database - Standard Edition - Version 12.2.0.1 客户端在Windows 10 Pro (1703)平台安装报PRVF-3919 : Failed to retrieve value of environment variable "PATH"错误。首先检查PATH的设置,如果没有问题可以参考如下步骤进行解决。 1,Download the...

log file switch (checkpoint incomplete) - 容易被误诊的event

首先来看如下的一份AWR,12分钟的采样,DB Time 105分钟。   DB Name DB Id Instance Inst num Startup Time Release RAC R11204 2114874159 R11204 1 23-Oct-17 10:10 11.2.0.4.0 NO   Host Name Platform CPUs Cores Sockets Memory (GB) nascds18 Linux x86 64-bit 2 2 1 11.64   Snap Id Snap Time Sessions Cursors/Session Begin Snap: 3 23-Oct-17 10:55:46 37 2.5 End Snap: 4 23-Oct-17 11:08:27 53 2.3 Elapsed: 12.67 (mins)   DB Time: 105.90 (mins)   Top event发现buffer busy waits和log file switch (checkpoint incomplete)几乎占用了所有的DB Time   Top 10 Foreground Events by Total Wait Time   Event Waits Total Wait Time (sec) Wait Avg(ms) % DB time Wait Class buffer busy waits 11 3310.6 300960 52.1 Concurrency log file switch (checkpoint incomplete) 10 3034.8 303479 47.8 Configuration DB CPU 5.5 .1   log file sync 28 2.3 82 .0 Commit log buffer space 24 .8 32 .0 Configuration   通过ASH不难发现buffer busy waits被log file switch (checkpoint incomplete)阻塞,而log file switch (checkpoint incomplete)又被LGWR的control file sequential read阻塞。   2017-10-23 11:05:31.563 1 37 perl@nascds18 (TNS V1-V3) buffer busy waits WAITING 1 150 2017-10-23 11:05:31.563 1 150 sqlplus@nascds18 (TNS V1-V3) buffer busy waits WAITING 1 141 2017-10-23 11:05:31.563 1 141 OMS log file switch (checkpoint incomplete) WAITING 1 130 2017-10-23 11:05:31.563 1 130 oracle@nascds18 (LGWR) control file sequential read WAITING NO HOLDER   接下来再看一眼AWR的iostat,很快发现LGWR有大量的读取,并且都是在读取控制控制文件,12分钟内的读取高达1.5G。   IOStat by Function summary   Function Name Reads: Data LGWR 1.5G Others 210M DBWR 0M Buffer Cache Reads 10M Direct Writes 0M TOTAL: 1.7G   IOStat by Filetype summary   Filetype Name Reads: Data Control File 1.5G Log File 185M Archive Log 0M Data File 10M Temp File 0M TOTAL: 1.7G   结合ASH中的LGWR是最终holder,并且LGWR等待control file sequential read的事实,我们可能很快将LGWR列为重点怀疑对象,如果真是这样,那就跑偏了。   此时不妨停下来思考一下,什么是log file switch (checkpoint incomplete)?   log file switch (checkpoint incomplete)指的是当redo需要向下一组redo group切换的时候,发现下组日志是active的,也就是说下组日志中对应的一些buffer cache中的脏块尚未写入到数据文件中,因此必须等待这些脏块被完毕后,才可以复用下一组redo group。   接下来再思考一下,哪个进程负责将脏块写入到数据文件?答案是DBWn,因此我们更需要关注的是DBWn。分析一下OSWatcher不难发现DBW0的状态是D,man一下ps命令: D指的是Uninterruptible sleep (usually IO),也就是说DBW0 hang在I/O上了,这才是问题的根本原因。   那么为什么LGWR会执行如此多的control file sequential read ?答案是DBWn出现问题导致 LGWR不断查询control 文件获取redo 状态(看它有没有切换成功)导致大量的control file sequential read 下面通过实验来演示这个现象:   Test on 12.1.0.2   Session 1:  创建一个表,并且update一下让其产生redo   Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options   SQL> select sid from v$mystat where rownum=1;         SID ----------        11   <<<< session 1的 sid 为11   SQL> create table t as select * from dba_objects;   Table created.   SQL> update t set object_name=object_name;   93841 rows updated.     Session 2:  用于查看redo的切换状态   SQL> set line 200 pages 1000 SQL> select group#,thread#,status from v$log;      GROUP#    THREAD# STATUS ---------- ---------- ----------------         1          1 INACTIVE         2          1 INACTIVE         3          1 CURRENT   SQL> alter system switch logfile;   System altered.   SQL> alter system switch logfile;   System altered.   SQL> select group#,thread#,status from v$log;      GROUP#    THREAD# STATUS ---------- ---------- ----------------         1          1 ACTIVE     <<<<<< 让下一组是active的         2          1 ACTIVE         3          1 CURRENT   Session 3: 确定DBWn以及LGWR的spid,并且通过oradebug将DBW0 suspend住让其不工作   SQL> set line 200 pages 1000 SQL> select spid,program from v$process where program like '%DBW%' or program like '%LG%';   SPID                     PROGRAM ------------------------ ---------------------------------------------------------------- 5768                     ORACLE.EXE (DBW0) 7248                     ORACLE.EXE (LGWR) 6384                     ORACLE.EXE (LG00) 6308                     ORACLE.EXE (LG01)   SQL> oradebug setospid 5768 Oracle pid: 11, Windows thread id: 5768, image: ORACLE.EXE (DBW0) SQL> oradebug suspend Statement processed.   接下来在Session 1中再执行几次update让其自动切换日志:   Session 1: SQL> update t set object_name=object_name;   93841 rows updated.   SQL> /   93841 rows updated.   SQL> /   93841 rows updated.   SQL> /   ---- 在这里hang住了   Session 4: 观察等待事件   SQL> set line 200 pages 1000 SQL> col program for a15 SQL> col event for a40 SQL> select sid,serial#,program,event,state from v$session where program like '%sqlplus%';         SID    SERIAL# PROGRAM         EVENT                                    STATE ---------- ---------- --------------- ---------------------------------------- -------------------        10      33682 sqlplus.exe     SQL*Net message from client              WAITING        11      48189 sqlplus.exe     log file switch (checkpoint incomplete)  WAITING       129      25471 sqlplus.exe     SQL*Net message to client                WAITED SHORT TIME       130      64963 sqlplus.exe     SQL*Net message from client              WAITING   接下来我们对LGWR做10046 trace,观察其等待: 可见反复的 control file sequential read   SQL> oradebug setospid 7248 Oracle pid: 12, Windows thread id: 7248, image: ORACLE.EXE (LGWR) SQL> oradebug event 10046 trace name context forever, level 8 Statement processed. SQL> oradebug tracefile_name D:\ORACLE\diag\rdbms\r12102\r12102\trace\r12102_lgwr_7248.trc   tail -f D:\ORACLE\diag\rdbms\r12102\r12102\trace\r12102_lgwr_7248.trc   WAIT #0: nam='LGWR all worker groups' ela= 72 p1=0 p2=0 p3=0 obj#=-1 tim=25178622234 WAIT #0: nam='control file sequential read' ela= 407 file#=0 block#=1 blocks=1 obj#=-1 tim=25178622880 WAIT #0: nam='control file sequential read' ela= 262 file#=1 block#=1 blocks=1 obj#=-1 tim=25178623344 WAIT #0: nam='control file sequential read' ela= 717 file#=0 block#=15 blocks=1 obj#=-1 tim=25178624315 WAIT #0: nam='control file sequential read' ela= 1774 file#=0 block#=17 blocks=1 obj#=-1 tim=25178626427 WAIT #0: nam='control file sequential read' ela= 311 file#=0 block#=19 blocks=1 obj#=-1 tim=25178627527 WAIT #0: nam='control file sequential read' ela= 269 file#=0 block#=284 blocks=1 obj#=-1 tim=25178627983 WAIT #0: nam='control file sequential read' ela= 238 file#=0 block#=22 blocks=1 obj#=-1 tim=25178628363 WAIT #0: nam='LGWR all worker groups' ela= 51 p1=0 p2=0 p3=0 obj#=-1 tim=25178628590 WAIT #0: nam='control file sequential read' ela= 503 file#=0 block#=1 blocks=1 obj#=-1 tim=25178629320 WAIT #0: nam='control file sequential read' ela= 322 file#=1 block#=1 blocks=1 obj#=-1 tim=25178630389 WAIT #0: nam='control file sequential read' ela= 276 file#=0 block#=15 blocks=1 obj#=-1 tim=25178630864 WAIT #0: nam='control file sequential read' ela= 253 file#=0 block#=17 blocks=1 obj#=-1 tim=25178631286 WAIT #0: nam='control file sequential read' ela= 250 file#=0 block#=19 blocks=1 obj#=-1 tim=25178631696 WAIT #0: nam='control file sequential read' ela= 658 file#=0 block#=284 blocks=1 obj#=-1 tim=25178632935 WAIT #0: nam='control file sequential read' ela= 303 file#=0 block#=22 blocks=1 obj#=-1 tim=25178633812 ......   最后我们将DBWn恢复,结束这个无限的control file sequential read等待。 回到Session 3,resume DBW0:   SQL> oradebug resume Statement processed.    只要理解了原理,这个问题本来不难诊断,但是ASH和AWR的信息会让DBA错误的认为是LGWR的等待control file sequential read导致的问题。

首先来看如下的一份AWR,12分钟的采样,DB Time 105分钟。   DB Name DB Id Instance Inst num Startup Time Release RAC R11204 2114874159 R11204 1 23-Oct-17 10:10 11.2.0.4.0 NO   Host Name Platform CPUs Cores Sockets Memory (GB) nas...

一个因为log/trace太多导致的ocssd.bin内存泄露问题

一个用户通过OSW观察到ocssd.bin 的内存以每小时4M的增长,而最终的原因竟然是因为目录下面log/trace文件太多了。下面是相关的分析: 1. 首先看到了每小时4M的增长: 以1小时top的数据来看 Line 78: 42 ? 4102 grid -11 20 275M 102M run 0:30 4.72 4.71 ocssd.bin <<<<<<<<<<<<<开始时是102M Line 170: 42 ? 4102 grid -11 20 275M 102M run 0:32 4.60 4.60 ocssd.bin Line 262: 42 ? 4102 grid -11 20 275M 102M run 0:33 4.61 4.61 ocssd.bin Line 354: 42 ? 4102 grid -11 20 275M 102M run 0:34 4.85 4.84 ocssd.bin Line 446: 42 ? 4102 grid -11 20 275M 102M run 0:37 4.84 4.83 ocssd.bin Line 538: 42 ? 4102 grid -11 20 275M 102M run 0:38 4.93 4.92 ocssd.bin Line 630: 42 ? 4102 grid -11 20 275M 102M run 0:39 4.97 4.96 ocssd.bin Line 722: 42 ? 4102 grid -11 20 275M 102M run 0:40 4.64 4.63 ocssd.bin Line 814: 42 ? 4102 grid -11 20 275M 102M run 0:42 4.67 4.66 ocssd.bin Line 906: 42 ? 4102 grid -11 20 275M 102M run 0:44 4.65 4.64 ocssd.bin Line 998: 42 ? 4102 grid -11 20 275M 102M run 0:45 4.69 4.69 ocssd.bin ...... ...... Line 4586: 42 ? 4102 grid -11 20 277M 103M run 1:41 4.49 4.48 ocssd.bin Line 4678: 42 ? 4102 grid -11 20 277M 103M run 1:42 4.44 4.43 ocssd.bin Line 4771: 42 ? 4102 grid -11 20 277M 104M run 1:43 4.58 4.58 ocssd.bin Line 4862: 42 ? 4102 grid -11 20 277M 104M run 1:46 4.63 4.63 ocssd.bin Line 4954: 42 ? 4102 grid -11 20 277M 104M run 1:47 4.59 4.58 ocssd.bin Line 5046: 42 ? 4102 grid -11 20 277M 104M run 1:48 4.35 4.34 ocssd.bin Line 5138: 42 ? 4102 grid -11 20 277M 104M run 1:49 4.69 4.68 ocssd.bin Line 5230: 42 ? 4102 grid -11 20 277M 104M run 1:51 4.73 4.72 ocssd.bin Line 5322: 42 ? 4102 grid -11 20 277M 104M run 1:53 4.76 4.75 ocssd.bin Line 5414: 42 ? 4102 grid -11 20 277M 104M run 1:54 4.66 4.65 ocssd.bin Line 5506: 42 ? 4102 grid -11 20 277M 104M run 1:55 4.46 4.46 ocssd.bin Line 5598: 42 ? 4102 grid -11 20 277M 104M run 1:57 4.72 4.71 ocssd.bin Line 5690: 42 ? 4102 grid -11 20 277M 104M run 1:58 4.68 4.67 ocssd.bin Line 5782: 42 ? 4102 grid -11 20 277M 104M run 2:00 4.93 4.92 ocssd.bin ...... ...... Line 10474: 42 ? 4102 grid -11 20 279M 106M run 3:11 4.58 4.57 ocssd.bin Line 10566: 42 ? 4102 grid -11 20 279M 106M run 3:13 4.69 4.69 ocssd.bin Line 10658: 42 ? 4102 grid -11 20 279M 106M run 3:14 4.88 4.87 ocssd.bin Line 10750: 42 ? 4102 grid -11 20 279M 106M run 3:15 4.82 4.81 ocssd.bin Line 10842: 42 ? 4102 grid -11 20 279M 106M run 3:18 4.55 4.54 ocssd.bin Line 10934: 42 ? 4102 grid -11 20 279M 106M run 3:19 4.60 4.59 ocssd.bin Line 11026: 42 ? 4102 grid -11 20 279M 106M run 3:20 4.65 4.64 ocssd.bin <<<<<<<<<<<<<<<<<<<结束时106M,所以增长是4M/H 2. 分析一下ocssd.bin的pmap (此时的ocssd.bin已经使用将近2G的内存): node1[/]#pmap 4102 4102: /oracle/app/12.1.0/grid/bin/ocssd.bin OFFSET VSZ RSZ TYPE PRM FILE 0 4K 4K SD(500) r-- [nullderef] c0001000 4K 4K SD(414) r-- /var/spool/pwgr/status 4000000000000000 2492K 2492K SC(1) r-x [text] 6000000000000000 1933M 1933M PD rw- [data] <<<<<<<<<<<<<<<<<< 9fffffff5ddcf000 72K 64K PD rw- [uarea] 9fffffff5deff000 72K 64K PD rw- [uarea] 9fffffff5e00f000 72K 64K PD rw- [uarea] 9fffffff5e02f000 72K 64K PD rw- [uarea] 3. 之前曾经有过一个bug,介绍过listener有可能会因为log、trace太多而导致在data段出现memory leak。所以就继续看看ocssd.bin写log的目录的文件数量: grid@node1:/oracle$ ls -ltr /oracle/app/grid/diag/crs/node1/crs/trace |wc -l 52710 <<<<<<<<<<<<  5万多个文件。 当然结局是:通过清除了部分老的trace以及log文件后,这个问题就没有发生了。 同时也可以看到,在12c以后,集群相关的trace、log文件迁移到ADR中进行管理了。但是如果retention设置的不合理,也有可能会造成文件过多或者过大的问题。作为DBA,在出现内存泄露的情况下,一方面应该分析是否遇到某些bug,同时在日常管理中,也要密切关注log以及trace的使用情况以避免类似的内存泄露或者是文件系统爆满的问题。  

一个用户通过OSW观察到ocssd.bin 的内存以每小时4M的增长,而最终的原因竟然是因为目录下面log/trace文件太多了。下面是相关的分析: 1. 首先看到了每小时4M的增长: 以1小时top的数据来看 Line 78: 42 ? 4102 grid -11 20 275M 102M run 0:30 4.72 4.71 ocssd.bin <<<<<<<<<<<<<开始时是102MLine...

诊断方法

一个因为外部authentication性能问题引起的实例终止。

一般来讲,RAC安装的grid、oracle用户都是本地(/etc/group, /etc/passwd)管理的方式。但是也有一些环境使用了外部管理的方式,比如ldap,或者vas。 下面介绍一个由于ldap性能问题导致的RAC实例终止的情况: 1. 首先现象是:LMHB因为错误29770 而终止实例: Wed Sep 20 23:08:34 2017 LMON (ospid: 5008) waits for event 'CSS operation: data query' for 8 secs. Wed Sep 20 23:08:38 2017 Thread 1 advanced to log sequence 66354 (LGWR switch) Current log# 4 seq# 66354 mem# 0: +LOG1/taorac09/onlinelog/group_4.260.864051729 Current log# 4 seq# 66354 mem# 1: +LOG2/taorac09/onlinelog/group_4.260.864051743 Errors in file /oracle/diag/rdbms/taorac09/r09ta1/trace/r09ta1_lmhb_5027.trc (incident=480165): ORA-29770: global enqueue process LMON (OSID 5008) is hung for more than 70 seconds Incident details in: /oracle/diag/rdbms/taorac09/r09ta1/incident/incdir_480165/r09ta1_lmhb_5027_i480165.trc ERROR: Some process(s) is not making progress. LMHB (ospid: 5027) is terminating the instance. Please check LMHB trace file for more details. Please also check the CPU load, I/O load and other system properties for anomalous behavior ERROR: Some process(s) is not making progress. Wed Sep 20 23:08:39 2017 System state dump requested by (instance=1, osid=5027 (LMHB)), summary=[abnormal instance termination]. System State dumped to trace file /oracle/diag/rdbms/taorac09/r09ta1/trace/r09ta1_diag_4996.trc LMHB (ospid: 5027): terminating the instance due to error 29770 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 2. 从systemstate dump中可以看到,LMON一直在等待"CSS operation: data query" 并且耗费了大量的时间: === LMON (ospid: 5008) Heartbeat Report ================================================== LMON (ospid: 5008) has no heartbeats for 99 sec. (threshold 70 sec) <<<<<<<<<<<<<<<<<< : waiting for event 'CSS operation: data query' for 13 secs with wait_id 173783400. ===[ Wait Chain ]=== Wait chain is empty. ============================== Dumping PROCESS LMON (ospid: 5008) States ============================== ===[ System Load State ]=== CPU Total 32 Core 16 Socket 2 Load normal: Cur 4881 Highmark 40960 (19.06 160.00) ===[ Latch State ]=== Not in Latch Get ===[ Session State Object ]=== ---------------------------------------- SO: 0x1fc1583260, type: 4, owner: 0x1fd125efe0, flag: INIT/-/-/0x00 if: 0x3 c: 0x3 proc=0x1fd125efe0, name=session, file=ksu.h LINE:12624, pg=0 (session) sid: 1046 ser: 1 trans: (nil), creator: 0x1fd125efe0 flags: (0x51) USR/- flags_idl: (0x1) BSY/-/-/-/-/- flags2: (0x409) -/-/INC DID: , short-term DID: txn branch: (nil) oct: 0, prv: 0, sql: (nil), psql: (nil), user: 0/SYS ksuxds FALSE at location: 0 service name: SYS$BACKGROUND Current Wait Stack: 0: waiting for 'CSS operation: data query' function_id=0x3, =0x0, =0x0 wait_id=173783400 seq_num=23067 snap_id=1 wait times: snap=13.550468 sec, exc=13.550468 sec, total=13.550468 sec <<<<<<<<<<<<<<<<<< wait times: max=infinite, heur=1 min 15 sec wait counts: calls=0 os=0 in_wait=1 iflags=0x5a0 Wait State: fixed_waits=0 flags=0x22 boundary=(nil)/-1 Session Wait History: elapsed time of 0.000004 sec since current wait 0: waited for 'CSS operation: data query' function_id=0x3, =0x0, =0x0 wait_id=173783399 seq_num=23066 snap_id=1 wait times: snap=15.610047 sec, exc=15.610047 sec, total=15.610047 sec <<<<<<<<<<<<< wait times: max=infinite wait counts: calls=0 os=0 occurred after 0.000005 sec of elapsed time 1: waited for 'CSS operation: data query' function_id=0x3, =0x0, =0x0 wait_id=173783398 seq_num=23065 snap_id=1 wait times: snap=15.606784 sec, exc=15.606784 sec, total=15.606784 sec <<<<<<<<<<<<<< wait times: max=infinite wait counts: calls=0 os=0 occurred after 0.000004 sec of elapsed time 2: waited for 'CSS operation: data query' function_id=0x3, =0x0, =0x0 wait_id=173783397 seq_num=23064 snap_id=1 wait times: snap=15.602135 sec, exc=15.602135 sec, total=15.602135 sec <<<<<<<<<<<<<<< wait times: max=infinite wait counts: calls=0 os=0 occurred after 0.000004 sec of elapsed time 3: waited for 'CSS operation: data query' function_id=0x3, =0x0, =0x0 wait_id=173783396 seq_num=23063 snap_id=1 wait times: snap=15.602871 sec, exc=15.602871 sec, total=15.602871 sec <<<<<<<<<<<<<<< wait times: max=infinite wait counts: calls=0 os=0 occurred after 0.000006 sec of elapsed time 3. 同时也观察到了一些其他进程的报错:"ORA-29701: unable to connect to Cluster Synchronization Service" Wed Sep 20 23:05:18 2017 Errors in file /oracle/diag/rdbms/taorac09/r09ta1/trace/r09ta1_ora_10843.trc: ORA-01114: IO error writing block to file (block # ) ORA-01114: IO error writing block to file 20001 (block # 722305) ORA-29701: unable to connect to Cluster Synchronization Service ORA-29701: unable to connect to Cluster Synchronization Service Wed Sep 20 23:05:30 2017 LMON (ospid: 5008) waits for event 'CSS operation: data query' for 11 secs. Wed Sep 20 23:05:34 2017 Errors in file /oracle/diag/rdbms/taorac09/r09ta1/trace/r09ta1_ora_846.trc: ORA-01114: IO error writing block to file (block # ) ORA-01114: IO error writing block to file 20002 (block # 78977) ORA-29701: unable to connect to Cluster Synchronization Service ORA-29701: unable to connect to Cluster Synchronization Service 4. 从这些进程的trace中,可以看到 2017-09-20 23:08:26.233: [ GIPCMUX] gipcmodMuxCallbackRecv: EXCEPTION[ ret gipcretAuthFail (22) ] error during recv on endp 0x196b5570 2017-09-20 23:08:26.233: [GIPCXCPT] gipcmodMuxCallbackRecv: internal receive request failed req 0x196d6f30 [0000000000000035] { gipcReceiveRequest : peerName '', data (nil), len 0, olen 0, off 0, parentEndp 0x196b73d0, ret gipcretAuthFail (22), objFlags 0x0, reqFlags 0x4 }, ret gipcretAuthFail (22) <<<<<<<<看起来好像是和Authentication有关系 5.CSSD Log也发现了同样的错误: 2017-09-20 22:55:35.755: [GIPCXCPT][3824294208] gipcmodClsaAuthStart: failuring during clsaauthmsg ret clsaretPROTERR (4), endp 0x2ac1e4392650 [000000001fa9c9f9] { gipcEndpoint : localAddr 'clsc://(ADDRESS=(PROTOCOL=ipc)(KEY=OCSSD_LL_talracsdw1a_)(GIPCID=fc049e15-66ed076f-28437))', remoteAddr 'clsc://(ADDRESS=(PROTOCOL=ipc)(KEY=OCSSD_LL_talracsdw1a_)(GIPCID=66ed076f-fc049e15-15531))', numPend 4, numReady 1, numDone 3, numDead 0, numTransfer 0, objFlags 0x0, pidPeer 15531, flags 0x603710, usrFlags 0x14000 } 2017-09-20 22:55:35.755: [GIPCXCPT][3824294208] gipcmodMuxTransferAccept: internal accept request failed endp 0x1af74a40, child 0x2ac1e4392650, ret gipcretAuthFail (22) 2017-09-20 22:55:35.755: [ GIPCMUX][3824294208] gipcmodMuxTransferAccept: EXCEPTION[ ret gipcretAuthFail (22) ] error during accept on endp 0x1af74a40 <<<<<<<<<<<< 6. 而从/etc/nsswitch.conf可以看到使用了ldap,同时在/etc/group, /etc/passwd中又没有grid、os用户的定义: group: files ldap <<<<<< passwd: compat shadow: compat 所以说,在用户或者组使用外部验证方式的时候(VAS、LDAP), 我们需要保证这些服务的性能。而如果性能不能达到要求,那么最好还是建议把这些用户或者组迁移到本地(/etc/group, /etc/passwd)

一般来讲,RAC安装的grid、oracle用户都是本地(/etc/group, /etc/passwd)管理的方式。但是也有一些环境使用了外部管理的方式,比如ldap,或者vas。 下面介绍一个由于ldap性能问题导致的RAC实例终止的情况: 1. 首先现象是:LMHB因为错误29770 而终止实例: Wed Sep 20 23:08:34 2017LMON (ospid: 5008) waits...

技术共享

12.2IMPDP创建索引不并行的问题

在12.2上,IMPDP已经设置了并行,但是在trace中发现索引创建始终使用串行,而不是并行。 SQL> conn test/test@PDB1 SQL> create table a(m number,n number) parallel 4; SQL> create index a_ind on a(m) parallel 3; SQL> !expdp test/test@PDB1 dumpfile=b.dmp directory=my_dir SQL> !impdp test/test@PDB1 directory=my_dir dumpfile=b.dmp parallel=2 TRACE=480301 DW trace显示index创建使用的是parallel=1,而不是parallel=2!(多么细心的客户)。   CDB2_dw00_6658.trc ===================== PARSING IN CURSOR #140037561274968 len=170 dep=2 uid=79 oct=1 lid=79 tim=841576694 hv=1135291776 ad='61d1c0b0' sqlid='apjngud1uqbc0' CREATE TABLE "TEST"."A" ("M" NUMBER, "N" NUMBER) SEGMENT CREATION DEFERRED PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING TABLESPACE "USERS" PARALLEL 4 END OF STMT ===================== PARSING IN CURSOR #140037558550112 len=114 dep=2 uid=79 oct=9 lid=79 tim=842113538 hv=68235534 ad='6374e7a8' sqlid='0u96wjh212c8f' CREATE INDEX "TEST"."A_IND" ON "TEST"."A" ("M") PCTFREE 10 INITRANS 2 MAXTRANS 255 TABLESPACE "USERS" PARALLEL 1 <=======PARALLEL 1, even if parallel=3 was set during index creation phase END OF STMT   但是在12.1.0.2却没有这个问题,该并行并行:   R1201_dw00_29326.trc : ===================== PARSING IN CURSOR #140427279060200 len=115 dep=2 uid=111 oct=9 lid=111 tim=8385394705 hv=1693801083 ad='77900cf8' sqlid='3t4ktqdkgaqmv' CREATE INDEX "TEST"."A_IND" ON "TEST"."A" ("M") PCTFREE 10 INITRANS 2 MAXTRANS 255 TABLESPACE "SYSTEM" PARALLEL 2 <========PARALLEL 2 END OF STMT 于是开了个bug,结果开发的解释是,这是期待的行为,因为,“我们发现这样更快”! BUG 26091146 - IMPDP CREATE INDEX WITH PARALLEL 1 IGNORING COMMAND LINE PARALLEL=2, Development explained that this is an expected behavior supplying the following explanation: "General support for parallel import of most object type, including indexes, is a 12.2 feature, which led to study of parallel creation of individual indexes. What was found was that using parallel index creation was generally slower than non-parallel. That led to a decision to backport the change to not use parallel index creation." 因为在12.2新feature的开发过程中,我们研究了一下impdp时的index的创建,发现“一般情况下”串行比并行建索引更快,所以我们决定把impdp时的索引都改成串行创建,并且在创建完成后,再使用'ALTER INDEX ... PARALLEL n' 设置索引的并行度,以实现查询时的并行效果。 好吧,开发永远都是(无)对(厘)的(头),如果您的测试表明“一般情况下”并行建索引更快,请告诉我们,我们将为您再开一个新bug,或者将这个bug重新打开。

在12.2上,IMPDP已经设置了并行,但是在trace中发现索引创建始终使用串行,而不是并行。 SQL> conn test/test@PDB1 SQL> create table a(m number,n number) parallel 4; SQL> create index a_ind on a(m) parallel 3;SQL> !expdp test/test@PDB1...

诊断方法

一个由于log/trace 目录文件太多导致的内存泄露。

最近处理了一个ocssd.bin内存泄露的问题,这个问题是由于ocssd.bin使用了过多内存达到系统设置的阀值,导致ocssd.bin无法分配内存并最终触发了系统重启。以下是诊断的过程: 1. 从cluster的alertlog中发现了在重启之前cssd失败的错误: 2017-07-11 23:23:01.817 [OCSSD(25291)]CRS-1656: The CSS daemon is terminating due to a fatal error; Details at (:CSSSC00012:) in /oracle/app/grid/diag/crs/node1/crs/trace/ocssd.trc <<<<<<<<<<< cssd failed. 2017-07-11 23:23:01.894 [OCSSD(25291)]CRS-1652: Starting clean up of CRSD resources. 2.进一步发掘cssd的log,发现错误的原因只是无法申请40k的内存。 2017-07-11 23:23:01.790310 :GIPCXCPT:16: gipclibMalloc: failed to allocate 40960 bytes, cowork 9ffffffffefcec70, ret gipcretOutOfMemory (28) <<<<<<<  Failed to allocate 40960 bytes 2017-07-11 23:23:01.790437 :GIPCXCPT:16: gipcWaitF [gipcInternalSendSync : gipcInternal.c : 1015]: EXCEPTION[ ret gipcretOutOfMemory (28) ] failed to wait on obj 6000 000000a7f3c0 [0000000000000466] { gipcEndpoint : localAddr 'udp://172.32.222.149:12041', remoteAddr '', numPend 5, numReady 1, numDone 0, numDead 0, numTransfer 0, obj Flags 0x0, pidPeer 0, readyRef 0000000000000000, ready 0, wobj 6000000001de9da0, sendp 6000000001e11110 status 13flags 0x20000003, flags-2 0x80, usrFlags 0x4000 }, req List 9ffffffffefcf6c0, nreq 1, creq 9ffffffffefcf6b0 timeout INFINITE, flags 0x100 3. 从OSW的历史记录中,可以看到,ocssd.bin使用了超过2G的内存: zzz ***Tue Jul 11 23:22:41 EAT 2017 Load averages: 0.01, 0.01, 0.01 701 processes: 615 sleeping, 86 running Cpu states: CPU LOAD USER NICE SYS IDLE BLOCK SWAIT INTR SSYS 0 0.01 1.6% 0.0% 1.4% 97.0% 0.0% 0.0% 0.0% 0.0% ...... 63 0.00 0.4% 0.0% 0.2% 99.4% 0.0% 0.0% 0.0% 0.0% --- ---- ----- ----- ----- ----- ----- ----- ----- ----- avg 0.01 1.6% 0.0% 0.4% 98.0% 0.0% 0.0% 0.0% 0.0% System Page Size: 4Kbytes Memory: 98497192K (85602260K) real, 100955548K (87689744K) virtual, 108259604K free Page# 1/44 CPU TTY PID USERNAME PRI NI SIZE RES STATE TIME %WCPU %CPU COMMAND 20 ? 25291 grid -11 20 2309M 2136M run 1511:23 5.50 5.49 ocssd.bin <<<<<<<<<<<<<  More than 2 GB 4. 而ocssd.bin以每小时4M的增长速度,缓慢增长:   Search "cssd" (120 hits in 1 file) from node1_top_17.07.12.0000.dat (120 hits): Line 78: 42 ? 4102 grid -11 20 275M 102M run 0:30 4.72 4.71 ocssd.bin Line 170: 42 ? 4102 grid -11 20 275M 102M run 0:32 4.60 4.60 ocssd.bin Line 262: 42 ? 4102 grid -11 20 275M 102M run 0:33 4.61 4.61 ocssd.bin Line 354: 42 ? 4102 grid -11 20 275M 102M run 0:34 4.85 4.84 ocssd.bin Line 446: 42 ? 4102 grid -11 20 275M 102M run 0:37 4.84 4.83 ocssd.bin Line 538: 42 ? 4102 grid -11 20 275M 102M run 0:38 4.93 4.92 ocssd.bin Line 630: 42 ? 4102 grid -11 20 275M 102M run 0:39 4.97 4.96 ocssd.bin Line 722: 42 ? 4102 grid -11 20 275M 102M run 0:40 4.64 4.63 ocssd.bin Line 814: 42 ? 4102 grid -11 20 275M 102M run 0:42 4.67 4.66 ocssd.bin Line 906: 42 ? 4102 grid -11 20 275M 102M run 0:44 4.65 4.64 ocssd.bin Line 998: 42 ? 4102 grid -11 20 275M 102M run 0:45 4.69 4.69 ocssd.bin ...... ...... Line 4586: 42 ? 4102 grid -11 20 277M 103M run 1:41 4.49 4.48 ocssd.bin Line 4678: 42 ? 4102 grid -11 20 277M 103M run 1:42 4.44 4.43 ocssd.bin Line 4771: 42 ? 4102 grid -11 20 277M 104M run 1:43 4.58 4.58 ocssd.bin Line 4862: 42 ? 4102 grid -11 20 277M 104M run 1:46 4.63 4.63 ocssd.bin Line 4954: 42 ? 4102 grid -11 20 277M 104M run 1:47 4.59 4.58 ocssd.bin Line 5046: 42 ? 4102 grid -11 20 277M 104M run 1:48 4.35 4.34 ocssd.bin Line 5138: 42 ? 4102 grid -11 20 277M 104M run 1:49 4.69 4.68 ocssd.bin Line 5230: 42 ? 4102 grid -11 20 277M 104M run 1:51 4.73 4.72 ocssd.bin Line 5322: 42 ? 4102 grid -11 20 277M 104M run 1:53 4.76 4.75 ocssd.bin Line 5414: 42 ? 4102 grid -11 20 277M 104M run 1:54 4.66 4.65 ocssd.bin Line 5506: 42 ? 4102 grid -11 20 277M 104M run 1:55 4.46 4.46 ocssd.bin Line 5598: 42 ? 4102 grid -11 20 277M 104M run 1:57 4.72 4.71 ocssd.bin Line 5690: 42 ? 4102 grid -11 20 277M 104M run 1:58 4.68 4.67 ocssd.bin Line 5782: 42 ? 4102 grid -11 20 277M 104M run 2:00 4.93 4.92 ocssd.bin ...... ...... Line 10474: 42 ? 4102 grid -11 20 279M 106M run 3:11 4.58 4.57 ocssd.bin Line 10566: 42 ? 4102 grid -11 20 279M 106M run 3:13 4.69 4.69 ocssd.bin Line 10658: 42 ? 4102 grid -11 20 279M 106M run 3:14 4.88 4.87 ocssd.bin Line 10750: 42 ? 4102 grid -11 20 279M 106M run 3:15 4.82 4.81 ocssd.bin Line 10842: 42 ? 4102 grid -11 20 279M 106M run 3:18 4.55 4.54 ocssd.bin Line 10934: 42 ? 4102 grid -11 20 279M 106M run 3:19 4.60 4.59 ocssd.bin Line 11026: 42 ? 4102 grid -11 20 279M 106M run 3:20 4.65 4.64 ocssd.bin <<<<<<<<<<<<<<<<<<< 4M increased for 1 hour 5. 从ocssd.bin的pmap输出来看,最大的部分是"PD rw- [data]" node1[/]#pmap 4102 4102: /oracle/app/12.1.0/grid/bin/ocssd.bin OFFSET VSZ RSZ TYPE PRM FILE 0 4K 4K SD(500) r-- [nullderef] c0001000 4K 4K SD(414) r-- /var/spool/pwgr/status 4000000000000000 2492K 2492K SC(1) r-x [text] 6000000000000000 1933M 1933M PD rw- [data] <<<<<<<<<<<<<<<<<< 9fffffff5ddcf000 72K 64K PD rw- [uarea] 9fffffff5deff000 72K 64K PD rw- [uarea] 9fffffff5e00f000 72K 64K PD rw- [uarea] 9fffffff5e02f000 72K 64K PD rw- [uarea] 6. 而在trace的目录里面发现了5万多个文件,之前就曾经遇到过类似的由于log文件太多导致listener内存泄露的bug: grid@node1:/oracle$ ls -ltr /oracle/app/grid/diag/crs/node1/crs/trace |wc -l 52710   7. 通过删除trace目录下面的文件,后续就没有再出现类似的使用内存增长情况。这个问题同时也提醒了DBA,DBA的职责不仅要管理数据库的主要文件,如:数据,日志,控制文件。而且也要留意一下log、trace等相关目录的情况以避免目录爆满或者相关内存泄露的问题。  

最近处理了一个ocssd.bin内存泄露的问题,这个问题是由于ocssd.bin使用了过多内存达到系统设置的阀值,导致ocssd.bin无法分配内存并最终触发了系统重启。以下是诊断的过程: 1. 从cluster的alertlog中发现了在重启之前cssd失败的错误: 2017-07-11 23:23:01.817 [OCSSD(25291)]CRS-1656: The CSS daemon is...

诊断方法

SLES12 SP2上遇到ORA-12518: TNS:listener could not hand off client connection错误

SLES12 SP2的linux上发生的问题,并不常见,但是给出了一些新的思路。 现象是数据库进程达到300个左右时,就无法继续连接数据库了,报以下错误。 ERROR: ORA-12518: TNS:listener could not hand off client connection 15-AUG-2017 01:40:01 * (CONNECT_DATA=(CID=(PROGRAM=myapp)(HOST=__jdbc__)(USER=admin))(SERVER=DEDICATED)(SERVICE_NAME=oracle)) * (ADDRESS=(PROTOCOL=tcp)(HOST=11.22.33.44)(PORT=1521)) * establish * oracle * 12518 TNS-12518: TNS:listener could not hand off client connection  TNS-12536: TNS:operation would block   TNS-12560: TNS:protocol adapter error   TNS-00506: Operation would block   Linux Error: 11: Resource temporarily unavailable 问题可以一直重现,但是用户无法找到限制在哪儿,ulimit -a显示没有明显限制: sa-server-0:grid:+ASM1 # ulimit -a core file size          (blocks, -c) 0 data seg size           (kbytes, -d) unlimited scheduling priority             (-e) 0 file size               (blocks, -f) unlimited pending signals                 (-i) 513378 max locked memory       (kbytes, -l) 64 max memory size         (kbytes, -m) unlimited open files                      (-n) 1000000 pipe size            (512 bytes, -p) 8 POSIX message queues     (bytes, -q) 819200 real-time priority              (-r) 0 stack size              (kbytes, -s) 8192 cpu time               (seconds, -t) unlimited max user processes              (-u) 1000000 virtual memory          (kbytes, -v) unlimited file locks                      (-x) unlimited 检查进程限制也没有异常: sa-server-0:~ # cat /proc/5497/limits Limit                     Soft Limit           Hard Limit           Units     Max cpu time              unlimited            unlimited            seconds   Max file size             unlimited            unlimited            bytes     Max data size             unlimited            unlimited            bytes     Max stack size            33554432             unlimited            bytes     Max core file size        unlimited            unlimited            bytes     Max resident set          unlimited            unlimited            bytes     Max processes             513378               513378               processes Max open files            65536                65536                files     Max locked memory         unlimited            unlimited            bytes     Max address space         unlimited            unlimited            bytes     Max file locks            unlimited            unlimited            locks     Max pending signals       513378               513378               signals   Max msgqueue size         819200               819200               bytes     Max nice priority         0                    0                     Max realtime priority     0                    0                     Max realtime timeout      unlimited            unlimited            us         让用户取了listener的strace,的确是clone函数失败,原因是资源不足(Resource temporarily unavailable): STRACE ------------------- filename=listener.strace 11404      0.000022 poll([{fd=8, events=POLLIN|POLLRDNORM}, {fd=11, events=POLLIN|POLLRDNORM}, {fd=13, events=POLLIN|POLLRDNORM}, {fd=14, events=POLLIN|POLLRDNORM}, {fd=15, events=POLLIN|POLLRDNORM}, {fd=16, events=POLLIN|POLLRDNORM}, {fd=17, events=POLLIN|POLLRDNORM}, {fd=3, events=POLLIN|POLLRDNORM}], 8, 60000) = 2 ([{fd=15, revents=POLLIN|POLLRDNORM}, {fd=3, revents=POLLIN|POLLRDNORM}]) <0.000012> 11404      0.000043 read(3, "\0\367\0\0\1\0\0\0\0016\1,\fA \0\177\377O\230\0\0\0\1\0\275\0:\0\0\0\0"..., 8208) = 247 <0.000010> 11404      0.000028 fcntl(3, F_GETFL)   = 0x802 (flags O_RDWR|O_NONBLOCK) <0.000008> 11404      0.000021 fcntl(3, F_SETFL, O_RDWR) = 0 <0.000008> 11404      0.000023 times({tms_utime=5483, tms_stime=2588, tms_cutime=440, tms_cstime=60}) = 1720115043 <0.000009> 11404      0.000096 fcntl(3, F_SETFD, 0) = 0 <0.000010> 11404      0.000027 pipe([18, 19])      = 0 <0.000012> 11404      0.000026 pipe([20, 21])      = 0 <0.000011> 11404      0.000024 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f4e29b769d0) = -1 EAGAIN (Resource temporarily unavailable) <0.000197>  《============ 11404      0.000219 close(18)           = 0 <0.000011> 11404      0.000022 close(19)           = 0 <0.000010> 11404      0.000023 close(20)           = 0 <0.000009> 11404      0.000021 close(21)           = 0 <0.000009> 检查OS log发现了一点端倪: 2017-08-16T02:36:55.560027+08:00 server-0 kernel: [ 165.619978] cgroup: fork rejected by pids controller in /system.slice/ohasd.service ' fork rejected by pids controller' 说明对进程数是有限制的。   最终的原因是因为在SUSE 12上增加了systemd的资源控制,其中默认参数: DefaultTasksMax was default value(512). systemd limited maximum number of tasks that may be created in the unit.  这个值会影响 OS上的maxpid,将该参数设为无限制后解决该问题: 修改 /etc/systemd/system.conf 设置 DefaultTasksMax 的值为'infinity',重启主机。

SLES12 SP2的linux上发生的问题,并不常见,但是给出了一些新的思路。 现象是数据库进程达到300个左右时,就无法继续连接数据库了,报以下错误。 ERROR: ORA-12518: TNS:listener could not hand off client connection15-AUG-2017 01:40:01...

技术共享

12c GI/RAC 日志目录路径的更改

12c的GI日志目录发生了改变,默认情况下,在 '$ORACLE_BASE/diag/crs/<node name>/crs/trace'目录下: [root@rac1 trace]# pwd /u01/app/oracle/grid/diag/crs/rac1/crs/trace [root@rac1 trace]# ls -l alert.log -rw-rw---- 1 grid oinstall 131004 Oct 11 21:41 alert.log [root@rac1 trace]# ls -l *cssd* -rw-rw---- 1 grid oinstall 52430990 Oct 9 21:31 ocssd_1.trc -rw-rw---- 1 grid oinstall 8064351 Oct 9 21:31 ocssd_1.trm -rw-rw---- 1 grid oinstall 52428999 Oct 11 02:39 ocssd_2.trc -rw-rw---- 1 grid oinstall 7515646 Oct 11 02:39 ocssd_2.trm -rw-rw---- 1 grid oinstall 30031491 Oct 11 22:41 ocssd.trc -rw-rw---- 1 grid oinstall 4441545 Oct 11 22:41 ocssd.trm -rw-rw---- 1 root oinstall 2615059 Oct 11 22:41 ohasd_cssdagent_root.trc -rw-rw---- 1 root oinstall 528863 Oct 11 22:41 ohasd_cssdagent_root.trm -rw-rw---- 1 root oinstall 2552595 Oct 11 22:41 ohasd_cssdmonitor_root.trc -rw-rw---- 1 root oinstall 508163 Oct 11 22:41 ohasd_cssdmonitor_root.trm [root@rac1 trace]# ls -l *crsd* -rw-rw---- 1 root oinstall 10486287 Oct 9 00:55 crsd_209.trc -rw-rw---- 1 root oinstall 1541500 Oct 9 00:55 crsd_209.trm -rw-rw---- 1 root oinstall 10486038 Oct 10 10:18 crsd_210.trc -rw-rw---- 1 root oinstall 1884924 Oct 10 10:18 crsd_210.trm -rw-rw---- 1 grid oinstall 10486071 Oct 10 15:02 crsd_oraagent_grid_1.trc -rw-rw---- 1 grid oinstall 1663426 Oct 10 15:02 crsd_oraagent_grid_1.trm -rw-rw---- 1 grid oinstall 4673388 Oct 11 22:42 crsd_oraagent_grid.trc -rw-rw---- 1 grid oinstall 855552 Oct 11 22:42 crsd_oraagent_grid.trm -rw-rw---- 1 oracle oinstall 4324992 Oct 11 22:41 crsd_oraagent_oracle.trc -rw-rw---- 1 oracle oinstall 753972 Oct 11 22:41 crsd_oraagent_oracle.trm -rw-rw---- 1 root oinstall 6551876 Oct 11 22:42 crsd_orarootagent_root.trc -rw-rw---- 1 root oinstall 1190635 Oct 11 22:42 crsd_orarootagent_root.trm -rw-rw---- 1 grid oinstall 6333986 Oct 11 22:42 crsd_scriptagent_grid.trc -rw-rw---- 1 grid oinstall 1195598 Oct 11 22:42 crsd_scriptagent_grid.trm -rw-rw---- 1 root oinstall 6845156 Oct 11 22:42 crsd.trc -rw-rw---- 1 root oinstall 1300678 Oct 11 22:42 crsd.trm   实际上,是在 '$ADR_BASE/diag/crs/'目录下,$ADR_BASE是由DIAGNOSTIC_DEST初始化参数控制的,如果用户没有设置,则DIAGNOSTIC_DEST指向$ORACLE_BASE,如果$ORACLE_BASE参数也没有设置,则指向$ORACLE_HOME/log目录。 关于12c的ADR架构,请参考在线文档: For more information, please may refer online document: http://docs.oracle.com/database/121/ADMIN/diag.htm#ADMIN11008 9.1.4 Structure, Contents, and Location of the Automatic Diagnostic Repository   -------------后记------------- 写这篇博客的初衷是因为发现到现在还有客户找不到12c的日志挪到哪儿去了,早在几年前12c刚出来时,‘12c trace new location’就成为了MOS的TOP热门搜索词汇。我以为这个问题早解决了,早应该有Note讲这个问题了,结果我自己搜了一下,发现根本搜不到。 于是我就写了一篇note:“Where can I find 12c GI trace file? (Doc ID 2316330.1)”,结果马上被删除了,说是和“12.1.0.2 Oracle Clusterware Diagnostic and Alert Log Moved to ADR (Doc ID 1915729.1)” 这篇重复了,看了这篇文档的标题,我瞬间明白了为何我和客户都搜不到这篇文档了,‘12c GI trace file new location',你会用来搜索的这些词当中,任何一个词都没有在这篇文档标题中出现过。。出现过。过。。。 “12.1.0.2 Oracle Clusterware Diagnostic and Alert Log Moved to ADR”完全是从一个编程者的角度出发主观写的说明文档,而没有考虑从一个使用者的角度会如何搜索这篇文档。 我已经给这篇文档加了comment,建议作者“整改”一下,也不知道他会不会搭理我。这就是单点信息失效的问题。Oracle虽然可以通过删除重复文档维护文档的高效性,但是适量的冗余可以帮助用户更有可能,更高效的找到想要的信息。 写这篇博客的目的,是为了帮助中文用户更好的找到这个信息。

12c的GI日志目录发生了改变,默认情况下,在 '$ORACLE_BASE/diag/crs/<node name>/crs/trace'目录下: [root@rac1 trace]# pwd /u01/app/oracle/grid/diag/crs/rac1/crs/trace [root@rac1 trace]# ls -l alert.log-rw-rw---- 1 grid...

技术共享

12.2 PDB插入CDB后报ORA-41401错误

在12.1时,还要求PDB必须和CDB字符集相同,或者是CDB的子集,12.2已经支持在CDB中插入不同字符集的PDB。 但是alert log中可能仍会出现ORA-41401错误: Errors in file /scratch/oradb/app/diag/rdbms/cdba/cdba1/trace/cdba1_q005_12770.trc: ORA-41401: Define character set (873) does not match database character set (852) 这是Advance Queue的bug,BUG 22331316     - FIX RECURSIVE HSTDEF NLS STATE DURING MEDIUM CONTAINER SWITCH 。AQ处理时,从PDB跨到CDB时对字符集处理不当造成的。该bug的修复最终被包含在12.2.0.2中。 尽管Oracle已经支持在CDB中插入不同字符集的PDB,但是最佳实践仍然建议用户先做PDB数据库字符集转换,再plug-in。除了以上bug的原因,还因为这种不同字符集的PDB在plug-in时,oracle会对PDB的元数据进行字符集转换(以插入数据到CDB的v$视图中)。 这种plug-in时的字符集转换存在一定限制,并且可能会失败。 请参考: Character Sets For CDB And PDB in 12.2 (Doc ID 2231602.1) Note, there are some restrictions: When a PDB character set is different from the CDB character set, there may be data truncation, if the column widths of CDB views and V$ views are not able to accommodate the PDB data that has expanded in length during the character set conversion. As UTF8 and AL32UTF8 have different maximum character widths (three versus four bytes per character), the automatic change of UTF8 to AL32UTF8 during plug-in operation will change implicit maximum byte lengths of columns with character length semantics. This change may fail, if there are functional indexes, virtual columns, bitmap join indexes, domain indexes, partitioning keys, sub-partitioning keys, or cluster keys defined on those columns. The plug-in operation may also fail, if a character length semantics column is part of an index key, and the index key exceeds the size limit (around 70% of the index block size) after the character set change. You must make sure that all the offending objects are removed from a database before it is plugged into a CDB. You can recreate those offending objects in the database after the database is plugged into a CDB.

在12.1时,还要求PDB必须和CDB字符集相同,或者是CDB的子集,12.2已经支持在CDB中插入不同字符集的PDB。 但是alert log中可能仍会出现ORA-41401错误: Errors in file /scratch/oradb/app/diag/rdbms/cdba/cdba1/trace/cdba1_q005_12770.trc: ORA-41401: Define character...

新特性

12.2Data Guard新特性--使用DBMS_DBCOMP.DBCOMP数据比较

      Oracle Data Guard会主动对Hot数据(数据正被读取或修改)执行验证, 无论是primary还是standby,但对于那些Cold数据不会做任何检查和校验。所以在12.2版本中,引入了dbms_comp来验证校验Hot 和 Cold数据, 其可以确保standby端没有任何corruption,switchover 或failover后变成primary角色后可以正常运行。 执行DBMS_DBCOMP可以检测primary和standby的所有数据块,并进行一致性比较和standby写丢失。   SQL> select * from scott.emp; select * from scott.emp * ERROR at line 1: ORA-65478: shadow lost write protection - found lost write   相应的alertlog消息: ERROR  - I/O type:buffered I/O found lost write in block with afn:4 rdba:1000086. Expected SCN:0x0000000000077d42 SCN in block:0x000000000007798b, approx current SCN:0x00000000000780d2, RAC instance:1         错误消息提到:其期望的scn:0x77d42即490818,而块读取却是scn 0x7798b即489867.    这意味着与上一次相比,Oracle收到了一个过时的版本 检查点(在SCN 490818)。这就表明写丢失。由于实际写入发生 在永久存储上,在Oracle RDBMS范围之外,我们需要进一步检查操作系统,卷管理或存储层,是导致丢失写入的实际原因。        当I / O子系统确认块写入完成时,发生数据块写丢失,但是写入并没有发生在永久存储器中。在随后的块中读取中,I / O子系统返回陈旧版本的数据块,可能用于更新数据库其他的块,从而造成corruption。   用法: 例如:我们有一个主数据库,它有一个或多个备数据库。当数据库挂载或打开时,在主数据库或备用数据库上执行DBMS_DBCOMP.DBCOMP   DBMS_DBCOMP.DBCOMP ( datafile IN varchar2, outputfile IN varchar2, block_dump IN布尔值 ); datafile -- 它可以是数据文件名或数据文件号。指定“ALL”来比较所有数据文件 其输出结果,可以帮助我们确定主备端是否存在潜在的block corruption。

      Oracle Data Guard会主动对Hot数据(数据正被读取或修改)执行验证, 无论是primary还是standby,但对于那些Cold数据不会做任何检查和校验。所以在12.2版本中,引入了dbms_comp来验证校验Hot 和 Cold数据, 其可以确保standby端没有任何corruption,switchover 或failover后变成primary角色后可以正常运行。 执...

新特性

12.2 dataguard 新特性--密码文件

 我们知道在dataguard12.2 以前的版本,如果修改primary SYS用户的口令时,不能只使用alter user 命令,同时还要手工将primary端的密码文件拷贝至standby端。否则,log传输会报下面错误:                 ORA-16191 Primary log shipping client not logged on standby      当我们使用SYS 用户以remote login方式认证登录数据库并传输redo日志时, primary和standby两端的SYS用户口令必须一致。 由于standby数据库始终处于mount或readonly状态,所以其不能执行primary传递过来的“grant sysdba to x" 命令,这就是为什么我们需要手工拷贝密码文件的原因。    一. 12.2以下版本 dataguard环境 a)  pirmary 端更改sys用户密码     SQL>alter user sys identified by oracle123;      b)  需要手工将primary端密码文件拷贝至standby端的Home目录下     $scp $ORACLE_HOME/dbs/orapw<primary_sid> oracle@<standby_host>:<$ORACLE_HOME>/dbs/      c)  拷贝所有(如果是RAC配置)standby端的密码文件后,按standby SID更改成对应的名字     mv $ORACLE_HOME/dbs/orapw<primary_sid> $ORACLE_HOME/dbs/orapw<standby_sid>      二. 12.2 版本dataguard环境   12.2版本由于有了这个新特性,当我们在primary更改 SYS,SYSDG等用户口令后,它会自动传递到所有的standby端database的配置信息里,自动同步到所有standby端的所有密码文件中。  

 我们知道在dataguard12.2 以前的版本,如果修改primary SYS用户的口令时,不能只使用alter user 命令,同时还要手工将primary端的密码文件拷贝至standby端。否则,log传输会报下面错误:                 ORA-16191 Primary log shipping client not logged on standby      当我们使用SYS...

技术支持通讯

又有新的数据库中文文档添加到 My Oracle Support 中了! (2017年9月)

最新翻译的文档列表: Note 2297528.1 Grid Infrastructure 12.2 安装不同类型集群的选择 Note 2297452.1 12.2 Grid Infrastructure 安装:新变化  Note 2297515.1 12.2 Flex 磁盘组配额管理 Note 2297494.1 12.2 Shadow Lost Write Protection -- 检测写丢失,无需配置备用数据库 Note 2297511.1 Oracle Sharding 12.2 完整参考 Note 2298002.1 闰秒(多出的1秒)以及对 Oracle 数据库的影响 Note 2297544.1 12.2 多租户数据库的 undo 模式 – 本地或者共享模式 Note 2297973.1 使用 12.2 中的 DBA_EXTERNAL_SCN_ACTIVITY 找出外部 SCN 跳变 Note 2298001.1 列 Collation 和大小写不敏感数据库 - 12.2 特性  Note 2297540.1 使用 COE XFR SQL Profile 脚本矫正优化器成本估算来获得好的执行计划 Note 2297986.1 关于 Oracle Database 12c 的自适应特性的建议(adaptive Statistics & 12c SQL Performance) Note 2297983.1 手动升级到 Non-CDB Oracle Database 12c Release 2(12.2)的完整核对清单  Note 2298396.1 手动升级 Oracle 多租户架构数据库从 12.1.x.x 到 12.2.x.x 的完整核对清单 Note 2298414.1 在 SLES 12 上安装 Oracle Database 12.2 64-bit(AMD64/EM64T)的要求 Note 2291982.1 SRDC – RMAN 还原恢复问题需要的诊断数据收集 Note 2292002.1 SRDC – RMAN 备份问题需要的诊断数据收集 Note 2292026.1 SRDC – RMAN 性能问题需要的诊断数据收集 Note 2292013.1 SRDC - RAC 实例驱逐问题的数据收集 Note 2292049.1 SRDC – RAC 实例重启问题的数据收集 Note 2292582.1 SRDC - 收集物理备库数据 Note 2292596.1 SRDC - 收集 RMAN Active Duplicate 数据 Note 2293024.1 SRDC - RAC 数据库/实例性能问题的数据收集(非 Hang 住的情况)(TFA) Note 2293025.1 SRDC - 对于 SQL 性能问题如何收集诊断信息 Note 2293066.1 SRDC – 对于数据库 Hang 的问题如何收集诊断信息 Note 2293085.1 SRDC - 对于数据库性能问题如何收集诊断信息 Note 2293114.1 SRDC - 安装问题的数据收集 Note 2293091.1 SRDC - 补丁安装问题的数据收集 Note 2293119.1 SRDC - RAC 数据库 ORA-7445 和 ORA-600 问题的数据收集 Note 2293129.1 SRDC - 对于 Listener 启动问题的数据收集 Note 2293415.1 SRDC – Undo 使用率高:提供的证据清单 Note 2293433.1 SRDC - DataPump Export 一般问题的诊断信息收集 Note 2293446.1 SRDC - Datapatch 问题的数据收集 Note 2293515.1 SRDC - Job 配置和执行:提供的证据清单 Note 2293531.1 SRDC - ORA-600 / ORA-700 / ORA-7445:11g 及更高版本数据收集的检查清单 完整的列表请点击这里 或登录 My Oracle Support  并查找: 中文文档列表 - Oracle Database (文档 ID 1533057.1)

最新翻译的文档列表: Note 2297528.1 Grid Infrastructure 12.2 安装不同类型集群的选择 Note 2297452.1 12.2 Grid Infrastructure 安装:新变化  Note 2297515.1 12.2 Flex 磁盘组配额管理 Note 2297494.1 12.2 Shadow Lost Write Protection...

一个connect by 应用的case

最近处理了一个connect by的case,分享给大家一下。 首先介绍一下connect by作用:对于数据有着严密的层级关系的表,我们有时候希望能够把有着 父子关系或者叫上下级关系的数据一次性展现出来,这个时候传统的sql 语法并不能就解决问题, 例如一个部门有一个总经理,多个副经理,每个下面又有多个总监,总监下面是员工, 我们设计表的时候,肯定只有一个字段来记录员工的上级,并不会记录他的上上级,那么我们 想把某个副经理的下面的所有员工都列出来的时候,就存在递归查找底层员工的情况,这种 就需要用到递归遍历,不同的DB给出了不同的解决办法,如DB2可以使用with+内嵌递归逻辑的 sql实现,oracle 提供了connect by的语法来实现。下面简单的看个例子: drop table emp; create table emp( emp_no number , manager_no number, name varchar2(100)); insert into emp values(1,,'总经理'); insert into emp values(2,1,'副经理1'); insert into emp values(3,1,'副经理2'); insert into emp values(4,2,'总监1'); insert into emp values(5,3,'总监2'); insert into emp values(6,4,'员工6'); insert into emp values(7,4,'员工7'); insert into emp values(8,5,'员工8'); insert into emp values(9,5,'员工9');  commit;   1个总经理两个副经理,每个副经理都有一个总监,每个总监都有两个员工。 下面列出副总1的所有员工情况: select * from emp   start with emp_no=2 connect by prior emp_no=manager_no   2 1 副经理1  <<起始行 4 2 总监1 6 4 员工6 7 4 员工7 这就sql的原理就是,start with标识递归遍历的起点,从emp_no=2这条记录开始遍历,prior 标识子节点和父节点关系, 可以理解成这个是一个函数,传入参数字段求值就可以得到他的父节点,根据emp_no父亲是在manager_no里面记录这种父子关系 向下遍历,那么就找第二条总监1,进而递归遍历找到员工6,7两条记录。 我们都知掉,任何编程语言递归遍历可能就存在死循环的情况,类似C语言中的goto滥用就会出现死循环一样,oracle在解决 这种递归的时候一旦发现死循环就会报错,例如下面的例子:   insert into emp values(2,7,'副经理1');  <<我们在插入一条让其副经理1是下面总监1的员工7的下属(这显然是矛盾的)   SQL>insert into emp values(2,7,'副经理1');   select * from emp   start with emp_no=2 connect by prior emp_no=manager_no 1 row created.   SQL> SQL>   2  ; ERROR: ORA-01436: CONNECT BY loop in user data  no rows selected   从上面看,的确发现了死循环,因为按照上面的逻辑,先列出前4条记录 2 1 副经理1  <<起始行 4 2 总监1 6 4 员工6 7 4 员工7   <<前4行记录 然后记录遍历:发现7的下级记录 2 7 副经理1' 然后在找2的下级记录,又发现 4 2 总监1  进而找到6,7,这样就无限的循环了。 那么若是因为突然插入这一条违背逻辑的数据就造成SQL报错,程序异常就没有办法补救了么,例如很显然, 我们就在死循环前停止,前面正常的数据正常输出即可,其实oracle的确已经帮我们想到了这个问题,我们可以 通过nocycle关键字来规避,这个参数的意思就是不要进入死循环,进入前停止。下面看看添加后的效果 select * from emp   start with emp_no=2 connect by nocycle prior emp_no=manager_no   2 1 副经理1   4 2 总监1 6 4 员工6 7 4 员工7  结果和我们期望的一致,显示正常的结果。   有了上述基础知识之后,我们再来看一下另外一个真实的case drop table t1; create table t1 (id int, fst_child int, snd_child int);   --base data insert into t1 values (1, 2, NULL); insert into t1 values (2, 3, 4); insert into t1 values (3, 5, NULL); insert into t1 values (4, 5, NULL); insert into t1 values (5, 6, NULL); insert into t1 values (6, 2, NULL);   SELECT id, fst_child, nvl(snd_child,99999) snd_child, connect_by_iscycle, SYS_CONNECT_BY_PATH(id, '/') "Path" from t1 start with id = 1 connect by nocycle ((id = prior fst_child) or (id = prior snd_child)); 这个结果返回如下:   id  fst_child   snd_child connect_by_iscycle   Path 1    2         99999     0        /1   2    3         4              0        /1/2   3    5         99999     0        /1/2/3   5    6         99999     1        /1/2/3/5  4    5         99999     0        /1/2/4   5    6         99999     1        /1/2/4/5     客户发现当然把最后一条记录 由2变成4 之后 insert into t1 values (6, 4, NULL); 数据变成如下: id  fst_child   snd_child connect_by_iscycle   Path 1    2   99999     0          /1  2    3       4     0              /1/2  3    5   99999     0          /1/2/3   5    6   99999     0          /1/2/3/5  6    4   99999     1          /1/2/3/5/6  <<新多出记录 4    5   99999     0          /1/2/4  5    6   99999     0          /1/2/4/5  6    4   99999     1          /1/2/4/5/6 <<新多出记录   结果多出两条记录出来,从上述知识来看最后一条无论是2还是4都是出现了死循环所以,造成了connect_by_iscycle返回1, 遍历停止,那么为啥后者能遍历出6,4这条记录,而前者不能遍历出6,2呢?因为2是6的祖先,4也是6的祖先,为啥 停止位置不同呢?难道是遇到了bug?经过在11204和12.2两个最稳定版本上测试,效果都是一样, 客户版本是11201,所以初步排除了bug的可能性,因为wrong result这种高优先级bug是不太可能跨越这两个版本仍然没有fix的。 那原因只能是一个,也就是这个结果是合理的。 再来重温一下connect_by_iscycle的解释: The CONNECT_BY_ISCYCLE pseudocolumn returns 1 if the current row has a child which is also its ancestor. Otherwise it returns 0. 如果当前行含有一个child,而且这个child又是他的祖先,那么就返回1,否则返回0.   我们来看一下第一个场景, insert into t1 values (1, 2, NULL); insert into t1 values (2, 3, 4); insert into t1 values (3, 5, NULL); insert into t1 values (4, 5, NULL); insert into t1 values (5, 6, NULL); insert into t1 values (6, 2, NULL); 当走到(5,6) 的时候 也就是child节点6的时候,发现有child 行(6,2),而这行表名2是6的子节点,但是根据 之前的遍历,2是3的祖先,3是5的祖先,5是6的祖先,自然2是6的祖先,所以connect_by_iscycle返回1,这个是合情合理。 再来看一下第二个场景 insert into t1 values (1, 2, NULL); insert into t1 values (2, 3, 4); insert into t1 values (3, 5, NULL); insert into t1 values (4, 5, NULL); insert into t1 values (5, 6, NULL); insert into t1 values (6, 4, NULL); 当走到(5,6) 的时候 也就是child节点6的时候,发现有child 行(6,4),而这行表名4是6的子节点,但是根据第四行(4,5) 5是4的子节点,6是5的子节点,显然6也是4的子节点,也违反逻辑,也应该connect_by_iscycle返回1才对,这个是为什么? 其实这里面存在一个误导,我们在考虑这个递归逻辑的时候是看到了所有数据,但是计算机是严格的一步一步递归的,也就是 当走到(5,6)的时候会,的确会进一步check下一行(6,4)情况,发现4是6的子节点,但是这个时候他是看不到(4,5)这一行的 所以他不知道5是4的子节点,所以他认为(6,4)是有效的,所以进行了输出,然后check他的子节点(4,5)发现5是4的子节点, 这个就有问题了,因为之前遍历的时候知道,5是6的祖先,6是4的祖先,所以5一定是4的祖先,所以进入时候死循环,那么本记录 标记成connect_by_iscycle=1,遍历停止,所以本场景会多遍历一层,这也就是为啥和场景1不同的原因。

最近处理了一个connect by的case,分享给大家一下。 首先介绍一下connect by作用:对于数据有着严密的层级关系的表,我们有时候希望能够把有着 父子关系或者叫上下级关系的数据一次性展现出来,这个时候传统的sql 语法并不能就解决问题, 例如一个部门有一个总经理,多个副经理,每个下面又有多个总监,总监下面是员工, 我们设计表的时候,肯定只有一个字段来记录员工的上级,并不会记录他的上上级,那么我...

技术共享

对于一个非空字段定义的表导出后,再imp时候报错ORA-01400: cannot insert NULL into xxx 为何呢?

最近有客户在11203环境上迁移一个大表的时候发现无法导入到新库,原因是imp时候报大量的ORA-01400: cannot insert NULL into xxx 但是通过查询这个表在原库上却没有null 数据,从表的定义上看也是not null的,而且有default值,这个是为什么呢?  下面的test case或许给您揭示原因: ==新建表并且插入几条记录 create table maob_t ( a number); insert into maob_t values(1); insert into maob_t values(2); insert into maob_t values(3); commit; ==对表新增字段并为非空+default 值 sqlplus>alter table maob_t add ( c number default 10 not null); ==第一次导出 exp maob/cdscds tables=maob_t file=maob_t.dmp About to export specified tables via Conventional Path ... . . exporting table                         MAOB_T          3 rows exported Export terminated successfully without warnings. 导出表之后drop表 sqlplus>drop table maob_t purge; 重新导入 imp maob/cdscds full=y   ignore=Y file=maob_t.dmp       Export file created by EXPORT:V11.02.00 via conventional path import done in US7ASCII character set and AL16UTF16 NCHAR character set import server uses AL32UTF8 character set (possible charset conversion) . importing MAOB's objects into MAOB . importing MAOB's objects into MAOB . . importing table                       "MAOB_T"          3 rows imported Import terminated successfully without warnings. 我们可以看到导出和导入都非常正常  我们采用exp maob/cdscds file=a_tab.dmp tables=a_tab direct=y 进行第二次导出 Export: Release 11.2.0.4.0 - Production on Thu Sep 14 06:06:26 2017  Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.  Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options Export done in US7ASCII character set and AL16UTF16 NCHAR character set server uses AL32UTF8 character set (possible charset conversion)  About to export specified tables via Direct Path ... . . exporting table                          A_TAB          2 rows exported Export terminated successfully without warnings. 再次对表进行清理: -bash-4.1$ sqlplus maob/cdscds   SQL> drop  table a_tab purge;  Table dropped. 在进行一次导入:  -bash-4.1$ imp maob/cdscds   ignore=Y file=a_tab.dmp tables=a_tab Import: Release 11.2.0.4.0 - Production on Thu Sep 14 06:06:37 2017  Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.   Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options  Export file created by EXPORT:V11.02.00 via direct path import done in US7ASCII character set and AL16UTF16 NCHAR character set import server uses AL32UTF8 character set (possible charset conversion) . importing MAOB's objects into MAOB . importing MAOB's objects into MAOB . . importing table                        "A_TAB" IMP-00019: row rejected due to ORACLE error 1400 IMP-00003: ORACLE error 1400 encountered ORA-01400: cannot insert NULL into ("MAOB"."A_TAB"."COL001") Column : 1 Column : IMP-00019: row rejected due to ORACLE error 1400 IMP-00003: ORACLE error 1400 encountered ORA-01400: cannot insert NULL into ("MAOB"."A_TAB"."COL001") Column : 2 Column :           0 rows imported Import terminated successfully with warnings. 问题再现了,从以上的测试来看,当对某一个已经存在数据的表进行了新增了非空+default字段之后,实际上11g因为避免把所有block都修改一遍,所以并没有真正的update底层数据,而是直接修改了数据字典。这样的好处显而易见,alter 表非常快,不会长时间持有library cache lock。执行sql查询这个新字段的时候,对于老的数据sql引擎会自动从数据字典里面把default读出来,对于新的数据就直接读取磁盘上的数据,但是当exp导出的时候,若是采用direct=y,因为跳过sql层,所以直接读取了block,所以老数据的block里面因为没有这个字段当然最终被处理成null插入新表,所以就出现了上述的问题。那么这个问题 解决的办法也很简单,就是采用常规形式导出,避免使用direct=y,另外oracle 在10g之后就推荐使用expdp+impdp,这套新工具也能避免 这个问题。

最近有客户在11203环境上迁移一个大表的时候发现无法导入到新库,原因是imp时候报大量的ORA-01400: cannot insert NULL into xxx 但是通过查询这个表在原库上却没有null 数据,从表的定义上看也是not null的,而且有default值,这个是为什么呢?  下面的test case或许给您揭示原因: ==新建表并且插入几条记录create table...

TimesTen

TimesTen 是关系型数据库还是 Oracle 11g/12c 的缓存?

许多客户都会问这样一个问题:TimesTen 是 Oracle 数据库的缓存,还是一套 关系型数据库系统?答案是,TimesTen 既可以配置为 Oracle 数据库的读/写缓存,也可以作为独立的关系型数据库系统。 TimesTen 作为关系型数据库系统 TimesTen 是低延迟的关系型内存数据库系统,它将数据持久化到磁盘并支持 ACID 事务。 检查点文件和事务日志用来持久化数据。在硬件或软件出现故障的情况下,可以使用检查点文件和事务日志来恢复数据库。TimesTen 使用事务日志文件来支持 ACID 事务的 COMMIT 和 ROLLBACK 操作。TimesTen 还支持多种方式来配置复制,以实现高可用性和在线升级。 TimesTen 使用 SQL 和 PLSQL,并支持丰富的运行环境: TimesTen 内存数据库是面向事务型的、可恢复的关系型数据库系统,为我们许多的客户提供 SQL 和 PLSQL 应用程序的关系型数据库服务。 TimesTen 用作 Oracle 数据库的缓存 TimesTen 内存数据库中的表,可以配置为 Oracle 数据库表的只读或读/写缓存。当 TimesTen 从 Oracle 缓存表时,数据仍然是持久化并且是可恢复的。缓存和非缓存[本地]表可以同时存在于 TimesTen 数据库中。应用程序可以将缓存表和非缓存表一起做关联查询: 连接到TimesTen(缓存)表的应用程序可以享有TimesTen提供的低延时服务。同时使用 Oracle 12c Exadata 和 TimesTen 应用层缓存,既可以获得 TimesTen 的低延迟,又可以受益于 Exadata 的可扩展性。白皮书提供了有关 TimesTen 缓存的更多信息。 该电信基准测试(TATP HLR)显示 Oracle 数据库使用 TimesTen Application Tier Database Cache 时,响应时间大幅减少。该测试具有以下特点: 两种场景下,使用完全相同的 HLR 工作负载。 该基准测试使用完全相同的 JDBC 代码,只有连接字符串不同。 两种场景下,使用完全相同的数据。 TimesTen 和 Oracle 使用完全相同的硬件和操作系统: Intel® Xeon CPU E5-2680 @2.7GHz 2 sockets 8 cores/socket 2 hyper-threads/core 32 vCPU Oracle Enterprise Linux 5 总而言之,TimesTen 既可以配置为 Oracle 数据库的读/写缓存,也可以作为独立的关系型数据库系统。  免责声明:这些都是我个人的观点,不代表 Oracle 的官方观点。 作者:Doug Hood | TimesTen Cloud Product Manager 原文出自:TimesTen Blog - Is TimesTen an RDBMS or a Cache for Oracle 11g/12c?

许多客户都会问这样一个问题:TimesTen 是 Oracle 数据库的缓存,还是一套 关系型数据库系统?答案是,TimesTen 既可以配置为 Oracle 数据库的读/写缓存,也可以作为独立的关系型数据库系统。 TimesTen 作为关系型数据库系统 TimesTen 是低延迟的关系型内存数据库系统,它将数据持久化到磁盘并支持 ACID 事务。 检查点文件和事务日志用来持久化数据。在硬件或软件出现故障的...

诊断方法

一次服务器时间调整引发的实例宕机。

问题描述: 1. 数据库实例突然crash,原因是ASMB有200多秒没有响应: Mon Sep 04 15:07:47 2017 WARNING: ASMB has not responded for 200 seconds <<<<<<<<<<<< ASMB has not responsed for 200 seconds. NOTE: ASM umbilicus running slower than expected, ASMB diagnostic requested after 200 seconds  NOTE: ASMB process state dumped to trace file /u01/app/oracle/diag/rdbms/iadw/iadw3/trace/iadw3_gen0_19179.trc Mon Sep 04 15:07:49 2017 NOTE: ASMB terminating Mon Sep 04 15:07:49 2017 Errors in file /u01/app/oracle/diag/rdbms/iadw/iadw3/trace/iadw3_asmb_19501.trc: ORA-15064: communication failure with ASM instance ORA-03113: end-of-file on communication channel Process ID: Session ID: 170 Serial number: 65161 Mon Sep 04 15:07:49 2017 Errors in file /u01/app/oracle/diag/rdbms/iadw/iadw3/trace/iadw3_asmb_19501.trc: ORA-15064: communication failure with ASM instance ORA-03113: end-of-file on communication channel Process ID: Session ID: 170 Serial number: 65161 USER (ospid: 19501): terminating the instance due to error 15064 2. 从system state dump上看,ASMB看起来没有什么问题: Current Wait Stack: Not in wait; last wait ended 3.321392 sec ago  <<<<<<<<<<<<<<< Not in wait. Wait State: fixed_waits=0 flags=0x21 boundary=(nil)/-1 Session Wait History: elapsed time of 3.321404 sec since last wait 0: waited for 'ASM background timer' =0x0, =0x0, =0x0 wait_id=37936676 seq_num=57511 snap_id=1 wait times: snap=2.682436 sec, exc=2.682436 sec, total=2.682436 sec wait times: max=infinite wait counts: calls=0 os=0 occurred after 0.000022 sec of elapsed time 1: waited for 'ASM file metadata operation' msgop=0xc, locn=0x3, =0x0 wait_id=37936675 seq_num=57510 snap_id=1 wait times: snap=0.000454 sec, exc=0.000454 sec, total=0.000454 sec wait times: max=infinite wait counts: calls=0 os=0 occurred after 0.000017 sec of elapsed time 3. 但是从OSW上看,没有发现明显的资源匮乏情况,但是中间却缺了三分多钟的断档: zzz ***Mon Sep 4 15:04:13 CST 2017 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 3 0 0 529160192 19412 31514216 0 0 82 48 0 0 1 0 99 0 0 0 0 0 529124032 19412 31514784 0 0 1545 23119 36620 37705 1 1 99 0 0 2 0 0 529126784 19412 31514712 0 0 1601 9056 28083 30263 1 0 99 0 0 zzz ***Mon Sep 4 15:04:23 CST 2017 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 5 0 0 529095360 19412 31514996 0 0 82 48 0 0 1 0 99 0 0 3 0 0 529118368 19412 31515228 0 0 1517 4540 20402 27856 1 1 98 0 0 52 0 0 529107936 19412 31515400 0 0 1206 3961 21105 31254 1 0 98 0 0 zzz ***Mon Sep 4 15:07:51 CST 2017 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<  15:04:23 到15:07:51之间没有任何记录 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 41 0 0 570421952 19412 31556616 0 0 82 48 0 0 1 0 99 0 0 16 0 0 578182976 19412 31575888 0 0 2129 35 25702 15760 1 8 91 0 0 5 0 0 582348800 19412 31607740 0 0 5209 40002 22122 19062 1 4 96 0 0 zzz ***Mon Sep 4 15:08:02 CST 2017 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 4 0 0 617279552 19412 31615300 0 0 82 48 0 0 1 0 99 0 0 2 0 0 624415168 19412 31617816 0 0 922 2 25322 20023 1 2 98 0 0 2 0 0 631768448 19412 31615728 0 0 1497 3 25405 22582 1 1 98 0 0 看到这里,一般的思考是OSW中间断档了3分多钟,是不是系统性能太差导致OSW没法生成?但是一般来讲,在断档之前一般都能看到一些先兆,比如block queue 剧增。但是这个案例里面没有此现象。 继续看OS log: 4. 在OSlog中看到关键性的一句话: Sep 4 15:04:01 hnpb05nc crond: /usr/sbin/postdrop: /lib64/libssl.so.10: no version information available (required by /usr/lib64/mysql/libmysqlclient.so.18) Sep 4 15:04:21 hnpb05nc init.tfa: Checking/Starting TFA.. Sep 4 15:07:47 hnpb05nc systemd: Time has been changed <<<<<<<<<<<<<<<<<<< 系统时间修改了。 5. 继续看看CTSSD 的trace: 2017-09-04 15:04:25.799241 : CTSS:3933169408: ctssslave_swm19: The offset is [2311562070 usec] and sync interval set to [4]<<< 偏移量为2311秒 2017-09-04 15:04:25.799251 : CTSS:3933169408: ctsselect_msm: Sync interval returned in [4] 2017-09-04 15:04:25.799260 : CTSS:3937371904: ctssslave_msg_handler4_3: slave_sync_with_master finished sync process. Exiting clsctssslave_msg_handler 2017-09-04 15:04:26.800845 : CTSS:3933169408: ctssslave_swm19: The offset is [2311562609 usec] and sync interval set to [4]<<< 偏移量为2311秒 2017-09-04 15:04:26.800856 : CTSS:3933169408: ctsselect_msm: Sync interval returned in [4] 2017-09-04 15:04:26.800864 : CTSS:3937371904: ctssslave_msg_handler4_3: slave_sync_with_master finished sync process. Exiting clsctssslave_msg_handler 2017-09-04 15:04:27.802328 : CTSS:3933169408: ctssslave_swm19: The offset is [2311563057 usec] and sync interval set to [4]<<< 偏移量为2311秒 2017-09-04 15:04:27.802337 : CTSS:3933169408: ctsselect_msm: Sync interval returned in [4] 2017-09-04 15:04:27.802346 : CTSS:3937371904: ctssslave_msg_handler4_3: slave_sync_with_master finished sync process. Exiting clsctssslave_msg_handler 2017-09-04 15:07:47.065051 : CTSS:3933169408: ctssslave_swm19: The offset is [2509824742 usec] and sync interval set to [4]<<< 偏移量剧增到2509秒 2017-09-04 15:07:47.065068 : CTSS:3933169408: ctsselect_msm: Sync interval returned in [4] 2017-09-04 15:07:47.065077 : CTSS:3937371904: ctssslave_msg_handler4_3: slave_sync_with_master finished sync process. Exiting 很明显,偏移量在问题期间发生了200秒左右的增长,而在之前,我们可以看到偏移量是相对稳定的!这个也间接说明了系统时间的调整。 这个故事: 事情是这样的,系统配置了ntp,由于一些问题ntp没有启动,但是由于已经配置了ntp,ctssd发现了ntp的配置文件所以ctssd只运行在观察者的角色。造成的结果就是系统时间不断出现偏差,直到系统管理员发现了这个问题并手工把系统时间往前调了200秒。。。 然后ASMB通过系统时间判断有200秒没有响应(当然情况不是这样了),然后就。。。 建议: 当然我们应该尽可能monitor系统并确保NTP的正常运行。如果我们确实需要手工大幅度调整系统时间,那么我们也应该先把RAC数据库关闭以后在做调整。  

问题描述: 1. 数据库实例突然crash,原因是ASMB有200多秒没有响应: Mon Sep 04 15:07:47 2017 WARNING: ASMB has not responded for 200 seconds <<<<<<<<<<<< ASMB has not responsed for 200 seconds.NOTE: ASM umbilicus running slower...

技术共享

如何在asm上定位数据块

我们都知道当db使用传统的文件系统时,定位block是就是通过dba_extents 中的blockid即可,然后 通过bbed或dd 直接操作对应数据文件的相应block即可,从10g开始,oracle使用ASM来管理磁盘, 因为所有数据文件都在ASM上,所以传统的bbed,dd都不能直接访问新型"文件系统"上的某个数据文件了 当我们需要在特殊场景下修改某个block的内存的时候该怎么办呢?下面给您演示一下: 首先我在这里先普及一下ASM的一点基础知识,需要知道的是ASM在磁盘上存储数据,分配的时候都是AU(allocation unit)为单位的,默认情况AU是1M,所以一个2G的数据文件 需要至少分配2×1024=2048个AU,当然存储这些AU的相关信息(如编号)也是需要存储空间的,这种元数据也是需要占用AU的,所以 实际上从ASM层面来看分配给某个数据文件的au数量要高于它的需求数量。对于ASM来讲,数据库的所有文件,如控制文件,spfile, 数据文件都是作为一种叫文件目录(file directory)类型的数据进行管理的。每一条这种类型的数据就是一个ASM管理的文件,其中 ASM为了管理方便会给每个文件目录分配一个唯一的编号,并且会在第一个文件目录的AU里面为其分配一个4k的block来 存放它分配的AU情况。而这个block编号就是分配给文件目录的编号。因为au默认是1M,所以一个au能分配出来256个block,也就是文件目录 编号前255(oracle 里面编号都是从0开始的)都在第一个AU里面,大于255小于512的都在第一个文件目录第二个au里面某个4kblock里面, 那么如何知道某个数据文件的编号呢,实际上oracle在创建文件的时候就已经告诉我们了。例如我们在往users表空间添加数据文件名为 user2.dbf的文件后,oracle在ASM上创建数据文件的名字类似如下:   user2.dbf => +DATA/R11204/DATAFILE/USERS.328.944473935   其中328就是表明这个数据文件的ASM 文件目录的编号。所以我们就通过它来入手。 介绍完如上的知识,我们看看如何定位一个数据文件的某个block: 首先创建一个表,为了好验证,我插入的数据都是a, create table test_t ( a number, b varchar2(100)); insert into test_t values(1,'abcdefg'); insert into test_t select * from test_t; insert into test_t select * from test_t; insert into test_t select * from test_t; commit; 查询这个表的block情况 select * from dba_extents where segment_name='TEST_T'; MAOB    TEST_T        TABLE    USERS    0    4    168    65536    8    4 select file_id,file_name from dba_data_files; 4 +DATA/r11204/datafile/users.300.908780493 <<file_number=300  我们可以看到这个表在file_id=4的数据文件里只分配了一个8个block的extent,第一个blockid是168, 根据oracle ASSM表空间的存储相关的知识,extent0 的前三个block分别是L1,L2,L3的metadata,所以第一个data block是171, 那么我们就找blockid=171这个block的ASM上存储位置: 首先我们根据file_id=4 blockid=171信息计算出这个数据文件在文件目录里面AU信息和block信息 AU信息:因为oracle数据块默认是8k的,所以171个block会占用多少个1M的au呢? select  171*8/1024 from dual 1.3359375 是1.3个Au,所以这个171的block一定放在第二个au里面的某个block上 au里的block信息: select (171*8-1*1024)/8 from dual 43 这个blockid=171的block放在第二个au里面的第43个block位置, 然后我们就需要找到这个数据文件的第二个au相对于磁盘的位置,根据之前介绍的知识, 下我们用kfed来读取磁盘头信息:我们要得到第一个文件目录的au信息 [grid@rac1 disks]$ kfed read /dev/oracleasm/disks/VOL1 |grep f1b1 kfdhdb.f1b1locn:                     10 ; 0x0d4: 0x0000000a  file1的第一个au 磁盘头里面的f1b1locn存放 就是目录文件1的第一个au,之前介绍了,第一个au里面 只能存放文件编号小于256的文件目录,我们的数据文件4的名字是 users.300.908780493 所以这个文件编号是300-256=44,也就是说会放在au=2的第44个block里面         查看文件目录1里面的au分配信息     [oracle@rac1 ~]$ kfed read /dev/oracleasm/disks/VOL1 aun=10 blkn=1 |grep au kfffde[0].xptr.au:                   10 ; 0x4a0: 0x0000000a kfffde[1].xptr.au:                   61 ; 0x4a8: 0x0000003d   <<第二个au的编号 kfffde[2].xptr.au:           4294967295 ; 0x4b0: 0xffffffff 查看文件目录44的au分配信息 [grid@rac1 ~]$ kfed read /dev/oracleasm/disks/VOL1 aun=61 blkn=44 | grep au kfffde[0].xptr.au:                 9931 ; 0x4a0: 0x000026cb kfffde[1].xptr.au:                 9932 ; 0x4a8: 0x000026cc <<file 300的第二个au编号 kfffde[2].xptr.au:                 9933 ; 0x4b0: 0x000026cd kfffde[3].xptr.au:                 9934 ; 0x4b8: 0x000026ce  。。。。。。。。。。。。。。 得到file 300的第二个au编号之后,我们就可以直接copy他的信息进行验证 dd if=/dev/oracleasm/disks/VOL1 skip=9932 of=/tmp/users.300 bs=1024k count=1 BBED> set blocksize 8192 BBED> set block 0 BBED-00309: out of range block number (0)  说明blockid是从1开始的,那么block43对应44 BBED> set block 44 BBED> p kcbh                 struct kcbh, 20 bytes       @0    ub1 type_kcbh            @0        0x06    ub1 frmt_kcbh            @1        0xa2    ub1 spare1_kcbh          @2        0x00    ub1 spare2_kcbh          @3        0x00    ub4 rdba_kcbh            @4        0x010000ab  <<file4 block 171    ub4 bas_kcbh             @8        0x0080737b    ub2 wrp_kcbh             @12       0x0000    ub1 seq_kcbh             @14       0x01    ub1 flg_kcbh             @15       0x04 (KCBHFCKV)    ub2 chkval_kcbh          @16       0xffc6    ub2 spare3_kcbh          @18       0x0000 BBED> set offset 8100     OFFSET             8100 BBED> dump /v  File: users.300 (1)  Block: 44      Offsets: 8100 to 8191  Dba:0x0040002C -------------------------------------------------------  64656667 2c010202 c1020761 62636465 l defg,......abcde  66672c01 0202c102 07616263 64656667 l fg,......abcdefg  2c010202 c1020761 62636465 66672c01 l ,......abcdefg,.  0202c102 07616263 64656667 2c010202 l .....abcdefg,...  c1020761 62636465 66672c01 0202c102 l ...abcdefg,..... 其中在定位文件目录300的au编号的时候也可以通过如下简单办法: select disk_kffxp, AU_kffxp, xnum_kffxp from x$kffxp where group_kffxp=1   and number_kffxp=300 ; DISK_KFFXP   AU_KFFXP XNUM_KFFXP ---------- ---------- ----------      0     9931           0      0     9932           1

我们都知道当db使用传统的文件系统时,定位block是就是通过dba_extents 中的blockid即可,然后 通过bbed或dd 直接操作对应数据文件的相应block即可,从10g开始,oracle使用ASM来管理磁盘, 因为所有数据文件都在ASM上,所以传统的bbed,dd都不能直接访问新型"文件系统"上的某个数据文件了当我们需要在特殊场景下修改某个block的内存的时候该怎么办呢?下面给...

诊断方法

ADG备库的DRCP连接报错OCI-21500解决一例

一、问题描述: 在只读备库adgstby上启动connection pool并通过easy naming method通过pool连接备库: SQL> startup ORACLE instance started. Total System Global Area 1369579520 bytes Fixed Size                  2253104 bytes Variable Size             419434192 bytes Database Buffers          939524096 bytes Redo Buffers                8368128 bytes Database mounted. Database opened. SQL> alter database recover managed standby database using current logfile disconnect from session; Database altered. SQL>  exec dbms_connection_pool.start_pool(); PL/SQL procedure successfully completed. SQL> exit [oracle@adg ~]$ sqlplus hr/hr@adg.fsm.com:1521/adgstby:POOLED   SQL*Plus: Release 11.2.0.4.0 Production on Thu Aug 10 08:00:50 2017   Copyright (c) 1982, 2013, Oracle.  All rights reserved.   ERROR: ORA-56600: DRCP: Illegal call [First call inconsistency] Errors in file : OCI-21500: internal error code, arguments: [kpplcSyncState:Error in sync], [56600], [], [], [], [], [], [] @@@33333333Errors in file : OCI-21500: internal error code, arguments: [kgepop: no error frame to pop to], [], [], [], [], [], [], [] OCI-21500: internal error code, arguments: [kpplcSyncState:Error in sync], [56600], [], [], [], [], [], [] 这个错误在11.2.0.4 ADG备库上可以重现。 在查了与此相关的bug发现都没有得到确认之后。进入了分析步骤。 二、分析过程: 1、起初只想到这是个连接问题,于是认为追踪的手段errorstack肯定不行,只能sqlnet client trace看看 (4198659808) [14-AUG-2017 01:20:31:440] nsbasic_bsd: packet dump (4198659808) [14-AUG-2017 01:20:31:440] nsbasic_bsd: 01 2A 00 00 06 00 00 00  |.*......| (4198659808) [14-AUG-2017 01:20:31:440] nsbasic_bsd: 00 00 03 5E 06 61 80 00  |...^.a..| (4198659808) [14-AUG-2017 01:20:31:440] nsbasic_bsd: 00 00 00 00 00 FE FF FF  |........| (4198659808) [14-AUG-2017 01:20:31:440] nsbasic_bsd: FF FF FF FF FF 50 00 00  |.....P..| (4198659808) [14-AUG-2017 01:20:31:440] nsbasic_bsd: 00 00 00 00 00 FE FF FF  |........| (4198659808) [14-AUG-2017 01:20:31:440] nsbasic_bsd: FF FF FF FF FF 0D 00 00  |........| (4198659808) [14-AUG-2017 01:20:31:440] nsbasic_bsd: 00 00 00 00 00 FE FF FF  |........| (4198659808) [14-AUG-2017 01:20:31:440] nsbasic_bsd: FF FF FF FF FF FE FF FF  |........| (4198659808) [14-AUG-2017 01:20:31:440] nsbasic_bsd: FF FF FF FF FF 00 00 00  |........| (4198659808) [14-AUG-2017 01:20:31:440] nsbasic_bsd: 00 01 00 00 00 00 00 00  |........| (4198659808) [14-AUG-2017 01:20:31:440] nsbasic_bsd: 00 00 00 00 00 00 00 00  |........| (4198659808) [14-AUG-2017 01:20:31:440] nsbasic_bsd: 00 00 00 00 00 00 00 00  |........| (4198659808) [14-AUG-2017 01:20:31:440] nsbasic_bsd: 00 00 00 00 00 00 00 00  |........| (4198659808) [14-AUG-2017 01:20:31:440] nsbasic_bsd: 00 00 00 00 00 FE FF FF  |........| (4198659808) [14-AUG-2017 01:20:31:440] nsbasic_bsd: FF FF FF FF FF 00 00 00  |........| (4198659808) [14-AUG-2017 01:20:31:440] nsbasic_bsd: 00 00 00 00 00 FE FF FF  |........| (4198659808) [14-AUG-2017 01:20:31:440] nsbasic_bsd: FF FF FF FF FF FE FF FF  |........| (4198659808) [14-AUG-2017 01:20:31:440] nsbasic_bsd: FF FF FF FF FF C8 31 5C  |......1\| (4198659808) [14-AUG-2017 01:20:31:441] nsbasic_bsd: 02 00 00 00 00 00 00 00  |........| (4198659808) [14-AUG-2017 01:20:31:441] nsbasic_bsd: 00 00 00 00 00 FE FF FF  |........| (4198659808) [14-AUG-2017 01:20:31:441] nsbasic_bsd: FF FF FF FF FF FE FF FF  |........| (4198659808) [14-AUG-2017 01:20:31:441] nsbasic_bsd: FF FF FF FF FF 00 00 00  |........| (4198659808) [14-AUG-2017 01:20:31:441] nsbasic_bsd: 00 00 00 00 00 00 00 00  |........| (4198659808) [14-AUG-2017 01:20:31:441] nsbasic_bsd: 00 00 00 00 00 00 00 00  |........| (4198659808) [14-AUG-2017 01:20:31:441] nsbasic_bsd: 00 00 00 00 00 00 00 00  |........| (4198659808) [14-AUG-2017 01:20:31:441] nsbasic_bsd: 00 00 00 00 00 28 53 45  |.....(SE| (4198659808) [14-AUG-2017 01:20:31:441] nsbasic_bsd: 4C 45 43 54 20 4E 55 4C  |LECT.NUL| (4198659808) [14-AUG-2017 01:20:31:441] nsbasic_bsd: 4C 20 46 52 4F 4D 20 44  |L.FROM.D| (4198659808) [14-AUG-2017 01:20:31:442] nsbasic_bsd: 55 41 4C 20 46 4F 52 20  |UAL.FOR.| (4198659808) [14-AUG-2017 01:20:31:443] nsbasic_bsd: 55 50 44 41 54 45 20 4E  |UPDATE.N|<====这里显示drcp执行了这个sql:select null from dual for update nowait (4198659808) [14-AUG-2017 01:20:31:443] nsbasic_bsd: 4F 57 41 49 54 00 01 00  |OWAIT...| (4198659808) [14-AUG-2017 01:20:31:443] nsbasic_bsd: 00 00 00 00 00 00 00 00  |........| (4198659808) [14-AUG-2017 01:20:31:443] nsbasic_bsd: 00 00 00 00 00 00 00 00  |........| (4198659808) [14-AUG-2017 01:20:31:443] nsbasic_bsd: 00 00 00 00 00 00 00 00  |........| (4198659808) [14-AUG-2017 01:20:31:443] nsbasic_bsd: 00 00 01 00 00 00 00 00  |........| (4198659808) [14-AUG-2017 01:20:31:443] nsbasic_bsd: 00 00 00 00 00 00 00 00  |........| (4198659808) [14-AUG-2017 01:20:31:443] nsbasic_bsd: 00 00 00 00 00 00 00 00  |........| (4198659808) [14-AUG-2017 01:20:31:443] nsbasic_bsd: 00 00                    |..      | ... (4198659808) [14-AUG-2017 01:20:31:445] nioqrc: entry (4198659808) [14-AUG-2017 01:20:31:445] nsbasic_brc: entry: oln/tot=0 (4198659808) [14-AUG-2017 01:20:31:445] nttfprd: entry (4198659808) [14-AUG-2017 01:20:31:445] nttfprd: socket 8 had bytes read=244 (4198659808) [14-AUG-2017 01:20:31:445] nttfprd: exit (4198659808) [14-AUG-2017 01:20:31:445] nsbasic_brc: type=6, plen=244 (4198659808) [14-AUG-2017 01:20:31:445] nsbasic_brc: what=1, tot =244 (4198659808) [14-AUG-2017 01:20:31:445] nsbasic_brc: packet dump (4198659808) [14-AUG-2017 01:20:31:445] nsbasic_brc: 00 F4 00 00 06 00 00 00  |........| (4198659808) [14-AUG-2017 01:20:31:445] nsbasic_brc: 00 00 04 01 00 00 00 00  |........| (4198659808) [14-AUG-2017 01:20:31:445] nsbasic_brc: 00 01 00 00 00 00 5C 02  |......\.| (4198659808) [14-AUG-2017 01:20:31:446] nsbasic_brc: 00 00 00 00 00 00 00 00  |........| (4198659808) [14-AUG-2017 01:20:31:446] nsbasic_brc: 00 00 00 00 00 00 00 00  |........| (4198659808) [14-AUG-2017 01:20:31:446] nsbasic_brc: 00 00 00 00 00 00 00 00  |........| (4198659808) [14-AUG-2017 01:20:31:446] nsbasic_brc: 00 00 00 00 00 00 00 00  |........| (4198659808) [14-AUG-2017 01:20:31:446] nsbasic_brc: 00 00 00 06 00 00 00 00  |........| (4198659808) [14-AUG-2017 01:20:31:446] nsbasic_brc: 00 00 00 00 00 00 00 00  |........| (4198659808) [14-AUG-2017 01:20:31:446] nsbasic_brc: 00 00 00 00 00 00 00 00  |........| (4198659808) [14-AUG-2017 01:20:31:446] nsbasic_brc: 00 00 20 3B 12 0C 00 00  |...;....| (4198659808) [14-AUG-2017 01:20:31:446] nsbasic_brc: 00 00 00 00 00 00 00 00  |........| (4198659808) [14-AUG-2017 01:20:31:446] nsbasic_brc: 00 00 00 00 00 00 00 00  |........| (4198659808) [14-AUG-2017 01:20:31:446] nsbasic_brc: 00 00 00 00 00 00 00 00  |........| (4198659808) [14-AUG-2017 01:20:31:446] nsbasic_brc: 00 00 00 00 00 00 00 00  |........| (4198659808) [14-AUG-2017 01:20:31:446] nsbasic_brc: 00 00 00 00 00 00 00 00  |........| (4198659808) [14-AUG-2017 01:20:31:446] nsbasic_brc: 00 00 00 00 00 00 00 00  |........| (4198659808) [14-AUG-2017 01:20:31:446] nsbasic_brc: 00 00 00 00 00 00 00 00  |........| (4198659808) [14-AUG-2017 01:20:31:446] nsbasic_brc: 00 00 61 4F 52 41 2D 30  |..aORA-0| (4198659808) [14-AUG-2017 01:20:31:446] nsbasic_brc: 30 36 30 34 3A 20 65 72  |0604:.er| (4198659808) [14-AUG-2017 01:20:31:446] nsbasic_brc: 72 6F 72 20 6F 63 63 75  |ror.occu| (4198659808) [14-AUG-2017 01:20:31:446] nsbasic_brc: 72 72 65 64 20 61 74 20  |rred.at.| (4198659808) [14-AUG-2017 01:20:31:446] nsbasic_brc: 72 65 63 75 72 73 69 76  |recursiv| (4198659808) [14-AUG-2017 01:20:31:446] nsbasic_brc: 65 20 53 51 4C 20 6C 65  |e.SQL.le| (4198659808) [14-AUG-2017 01:20:31:446] nsbasic_brc: 76 65 6C 20 31 0A 4F 52  |vel.1.OR| (4198659808) [14-AUG-2017 01:20:31:446] nsbasic_brc: 41 2D 31 36 30 30 30 3A  |A-16000:|<==== (4198659808) [14-AUG-2017 01:20:31:446] nsbasic_brc: 20 64 61 74 61 62 61 73  |.databas| (4198659808) [14-AUG-2017 01:20:31:446] nsbasic_brc: 65 20 6F 70 65 6E 20 66  |e.open.f| (4198659808) [14-AUG-2017 01:20:31:446] nsbasic_brc: 6F 72 20 72 65 61 64 2D  |or.read-| (4198659808) [14-AUG-2017 01:20:31:446] nsbasic_brc: 6F 6E 6C 79 20 61 63 63  |only.acc| (4198659808) [14-AUG-2017 01:20:31:446] nsbasic_brc: 65 73 73 0A              |ess.    | (4198659808) [14-AUG-2017 01:20:31:446] nsbasic_brc: exit: oln=0, dln=234, tot=244, rc=0 通过如上sqlnet client trace可以看到是递归sql: select null from dual for update在只读备库上执行,报了ORA-16000, 连续报错五次之后,连接断开。这是个DML语句,在只读备库上遇到ORA-16000是意料之中的事情。 2、跟drcp方面沟通后,确认drcp是有防止在只读备库上执行dml操作的功能的,即上述select null from dual for update并不是导致异常断开的原因。而sqlnet client trace看到的也只是客户端跟数据库服务器之间的交互,看不到更多的东西。 3、仔细想了之后,发现其实我们还可以通过对ORA-16000做errorstack追踪下,因为sqlnet trace已经说明它还是连上过备库的,只是触发了ORA-16000之后异常断开而已。 通过对备库设置alter system set events='16000 trace name errorstack forever,level 3'; 并重现连接问题之后,得到了如下trace: Unix process pid: 3311, image: oracle@adg.fsm.com (L001) *** 2017-08-16 06:54:49.441 *** SESSION ID:(30.65) 2017-08-16 06:54:49.441 *** CLIENT ID:() 2017-08-16 06:54:49.441 *** SERVICE NAME:() 2017-08-16 06:54:49.441 *** MODULE NAME:() 2017-08-16 06:54:49.441 *** ACTION NAME:() 2017-08-16 06:54:49.441   dbkedDefDump(): Starting a non-incident diagnostic dump (flags=0x0, level=4, mask=0x0) ----- Error Stack Dump ----- ORA-16000: database open for read-only access ----- Current SQL Statement for this session (sql_id=4m7m0t6fjcs5x) ----- update seq$ set increment$=:2,minvalue=:3,maxvalue=:4,cycle#=:5,order$=:6,cache=:7,highwater=:8,audit$=:9,flags=:10 where obj#=:1 ----- Call Stack Trace ----- skdstdst <- ksedst1 <- ksedst <- dbkedDefDump <- ksedmp         <- dbkdaKsdActDriver <- dbgdaExecuteAction <- dbgdaRunAction <- dbgdRunActions <- dbgdProcessEventAct          <- ions <- dbgdChkEventKgErr <- dbkdChkEventRdbmsEr <- ksfpec <- dbgePostErrorKGE           <- 1137 <- dbkePostKGE_kgsf <- kgeselv <- ksesecl0 <- opiexe            <- opiall0 <- opikpr <- opiodr <- rpidrus <- skgmstack             <- rpiswu2 <- kprball <- kqdsnu <- kqrcmt <- ktcCommitTxn              <- kdnwor <- kdnAllocN <- kdnnxt <- kkdlses <- kzaini               <- kpplsCreateSession <- kpplsFixUpSession <- kpplsSessGet <- opiodr <- ttcpip                <- opitsk <- opiino <- opiodr <- opirip <- opidrv                 <- sou2o <- opimai_real <- ssthrdmain <- main <- libc_start_main                  <- start 从中发现引起ORA-16000报错的实际上是这个递归sql: update seq$ set increment$=:2,minvalue=:3,maxvalue=:4,cycle#=:5,order$=:6,cache=:7,highwater=:8,audit$=:9,flags=:10 where obj#=:1 注意到其中的audit$=:9,这个sql像是db audit执行的,于是有了下面的解决方案。 三、解决方案 oracle@adg trace]$ sqlplus / as sysdba SQL*Plus: Release 11.2.0.4.0 Production on Wed Aug 16 07:05:24 2017 Copyright (c) 1982, 2013, Oracle.  All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL> alter system set audit_trail=none scope=spfile; System altered. SQL> shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. SQL> startup ORACLE instance started. Total System Global Area 1369579520 bytes Fixed Size                  2253104 bytes Variable Size             419434192 bytes Database Buffers          939524096 bytes Redo Buffers                8368128 bytes Database mounted. Database opened. SQL> alter database recover managed standby database using current logfile disconnect from session; Database altered. SQL>  exec dbms_connection_pool.start_pool(); PL/SQL procedure successfully completed. SQL> exit Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options [oracle@adg trace]$ sqlplus hr/hr@adg.fsm.com:1521/adgstby:POOLED SQL*Plus: Release 11.2.0.4.0 Production on Wed Aug 16 07:08:21 2017 Copyright (c) 1982, 2013, Oracle.  All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL> select * from tab; no rows selected SQL>

一、问题描述: 在只读备库adgstby上启动connection pool并通过easy naming method通过pool连接备库: SQL> startup ORACLE instance started. Total System Global Area 1369579520 bytes Fixed Size                  2253104 bytesVariable...

诊断方法

ADG switchover之后,数据库版本为何从11.2.0.4变成了11.2.0.2?

  最近接到了个比较奇怪的问题,switchover之后,新主库居然提示要以upgrade模式打开: alter database  open ORA-01092: ORACLE instance terminated. Disconnection forced ORA-00704: bootstrap process failure ORA-39700: database must be opened with UPGRADE option 我的第一反应是,客户的主库备库在switchover之前就是跨版本的。于是问客户要了下两边的alert log,发现确实是跨版本,新主库是11.2.0.2,而新备库是11.2.0.4。 于是建议客户: sqlplus / as sysdba startup upgrade       @?/rdbms/admin/catupgrd.sql   @?/rdbms/admin/utlrp.sql      shutdown immediate startup 然而客户说:我们升级是很久以前的事啦,早就都是11.2.0.4了,为什么switchover之后却变成11.2.0.2呢? 检查alert log历史启动记录,发现客户所言没错,的确是switchover时版本号变了,且新主库上有两个ORACLE HOME: /oracle/app/oracle/product/11.2.0.4/dbhome_1 /oracle/app/oracle/product/11.2.0/dbhome_1    《----11.2.0.2 <<<新主库alert log: Starting up: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production《====switchover之前还是在11.2.0.4 home下运行的 With the Partitioning, Real Application Clusters, OLAP, Data Mining and Real Application Testing options. ORACLE_HOME = /oracle/app/oracle/product/11.2.0.4/dbhome_1 System name: AIX Node name: oradb1 Release: 1 Version: 7 Machine: 00CBC6D54C00 Using parameter settings in server-side pfile /oracle/app/oracle/product/11.2.0.4/dbhome_1/dbs/initora1.ora ... Tue Aug 08 14:39:32 2017 ALTER SYSTEM SET log_archive_dest_state_2='ENABLE' SCOPE=BOTH; Tue Aug 08 14:40:24 2017 ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY [Process Id: 29098052] (ora1) ... Completed: ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN Reconfiguration complete Tue Aug 08 14:40:33 2017 ARC2: Becoming the active heartbeat ARCH ARC2: Becoming the active heartbeat ARCH Tue Aug 08 14:40:49 2017 Shutting down instance after CTL_SWITCH DMON (ospid: 23265382): terminating the instance Instance terminated by DMON, pid = 23265382 Tue Aug 08 14:40:52 2017 Starting ORACLE instance (normal) sskgpgetexecname failed to get name LICENSE_MAX_SESSION = 0 LICENSE_SESSIONS_WARNING = 0 2017-08-08 14:40:52.738 [USER(30343272)]CRS-2317:Fatal error: cannot get local GPnP security keys (wallet).  2017-08-08 14:40:52.739 [USER(30343272)]CRS-2316:Fatal error: cannot initialize GPnP, CLSGPNP_ERR (Generic GPnP error).  kggpnpInit: failed to init gpnp   WARNING: No cluster interconnect has been specified. Depending on            the communication driver configured Oracle cluster traffic             may be directed to the public interface of this machine.            Oracle recommends that RAC clustered databases be configured            with a private interconnect for enhanced security and            performance. Picked latch-free SCN scheme 3 WARNING: db_recovery_file_dest is same as db_create_file_dest Autotune of undo retention is turned on.  LICENSE_MAX_USERS = 0 SYS auditing is disabled Starting up: Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production With the Partitioning, Real Application Clusters, OLAP, Data Mining and Real Application Testing options. Using parameter settings in server-side pfile /oracle/app/oracle/product/11.2.0/dbhome_1/dbs/initora1.ora<===switchover之后,变成了11.2.0.2 home下打开 System parameters with non-default values: ... Tue Aug 08 14:41:04 2017 ARC2 started with pid=38, OS id=21364806  ARC1: Archival started Tue Aug 08 14:41:04 2017 ARC3 started with pid=39, OS id=22282270  ARC2: Archival started ARC1: Becoming the 'no FAL' ARCH ARC2: Becoming the heartbeat ARCH ARC2: Becoming the active heartbeat ARCH ARC2: Becoming the active heartbeat ARCH Completed: alter database  mount alter database  open Data Guard Broker initializing... Data Guard Broker initialization complete This instance was first to open Beginning standby crash recovery. Tue Aug 08 14:41:05 2017 SMON: enabling cache recovery Errors in file /oracle/app/oracle/diag/rdbms/oradg/ora1/trace/ora1_ora_22544618.trc: ORA-00704: ???????? ORA-39700: ??? UPGRADE ??????? Errors in file /oracle/app/oracle/diag/rdbms/oradg/ora1/trace/ora1_ora_22544618.trc: ORA-00704: ???????? ORA-39700: ??? UPGRADE ???????   分析过程: 由于这是RAC to RAC的data guard环境,首先怀疑是OCR里的ORACLE_HOME配错了,但检查了下确实是11.2.0.4没错。而环境变量里的ORACLE_HOME也是11.2.0.4的。/etc/oratab下也只写了11.2.0.4的ORACLE_HOME。 由于alert log中显示是用broker切换的,于是怀疑是broker配置错了,但检查了两个home下的启动的初始化参数,都是同样的configuration file。 于是跟客户要了下broker log看,发现broker的确是在switchover后选择了以11.2.0.2的ORACLE_HOME去启动实例,但看不出来原因。 在让客户用ps aeuxwww检查了进程环境变量ORACLE_HOME确认没问题之后,决定让客户对broker做debug(dgmgrl -debug)看下。 主库操作:(s切w) DGMGRL> switchover to oradg 立即执行切换, 请稍候... 操作要求连接实例 "ora1" (在数据库 "oradg" 上) 正在连接实例 "ora1"... [W000 08/09 17:51:21.18] Connecting to database using (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=xxxx)(PORT=2931))(ADDRESS=(PROTOCOL=TCP)(HOST=51.131.1.14)(PORT=2931))(ADDRESS=(PROTOCOL=TCP)(HOST=xxxx)(PORT=2932)))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=xxxx)(INSTANCE_NAME=ora1))). [W000 08/09 17:51:21.31] Checking broker version [BEGIN :version := dbms_drs.dg_broker_info('VERSION'); END;]. [W000 08/09 17:51:21.31] Broker version is '11.2.0.4.0' 已连接。 新的主数据库 "oradg" 正在打开...《===== 操作要求启动实例 "ora1" (在数据库 "ora" 上) 正在启动实例 "ora1"... [W000 08/09 17:51:51.23] Connecting to database using ora. [W000 08/09 17:51:51.31] Checking broker version [BEGIN :version := dbms_drs.dg_broker_info('VERSION'); END;]. ORA-01034: ORACLE not available 进程 ID: 0 会话 ID: 0 序列号: 0 ORACLE 例程已经启动。 [W000 08/09 17:51:56.84] Connecting to database using ora. [W000 08/09 17:51:56.93] Checking broker version [BEGIN :version := dbms_drs.dg_broker_info('VERSION'); END;]. [W000 08/09 17:51:56.94] Broker version is '11.2.0.4.0' alter database  mount 数据库装载完毕。 alter database  open 数据库已经打开。<==============这儿已经用11.2.0.4 open成功 [W000 08/09 17:52:09.52] Connecting to database using ora. [W000 08/09 17:52:09.65] Checking broker version [BEGIN :version := dbms_drs.dg_broker_info('VERSION'); END;]. [W000 08/09 17:52:09.71] Broker version is '11.2.0.4.0' 切换成功, 新的主数据库为 "oradg" 备库操作:(w切s) DGMGRL> switchover to ora               立即执行切换, 请稍候... 操作要求连接实例 "ora1" (在数据库 "ora" 上) 正在连接实例 "ora1"... [W000 08/09 17:55:28.24] Connecting to database using (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=51.131.1.11)(PORT=2931))(ADDRESS=(PROTOCOL=TCP)(HOST=51.131.1.12)(PORT=2931))(ADDRESS=(PROTOCOL=TCP)(HOST=51.131.1.15)(PORT=2932)))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=xxx)(INSTANCE_NAME=ora1))). [W000 08/09 17:55:28.33] Checking broker version [BEGIN :version := dbms_drs.dg_broker_info('VERSION'); END;]. [W000 08/09 17:55:28.33] Broker version is '11.2.0.4.0'《==========这儿还是11.2.0.4 已连接。 新的主数据库 "ora" 正在打开... 操作要求启动实例 "ora1" (在数据库 "oradg" 上) 正在启动实例 "ora1"... [W000 08/09 17:55:55.32] Connecting to database using oradg. [W000 08/09 17:55:56.20] Checking broker version [BEGIN :version := dbms_drs.dg_broker_info('VERSION'); END;]. ORA-01034: ORACLE not available 进程 ID: 0 会话 ID: 0 序列号: 0 ORACLE 例程已经启动。 [W000 08/09 17:56:02.65] Connecting to database using oradg.《==== [W000 08/09 17:56:02.80] Checking broker version [BEGIN :version := dbms_drs.dg_broker_info('VERSION'); END;]. [W000 08/09 17:56:02.96] Broker version is '11.2.0.2.0'<=========到这儿却变成了broker version 11.2.0.2 alter database  mount 数据库装载完毕。 alter database  open ORA-01092: ORACLE instance terminated. Disconnection forced ORA-00704: bootstrap process failure ORA-39700: database must be opened with UPGRADE option 进程 ID: 21168174 会话 ID: 1145 序列号: 1 请执行以下步骤以完成切换:        启动实例 "ora1" (属于数据库 "oradg") 从broker的debug输出,我发现了一个细节:切换前broker是使用连接串连到原备库的: Connecting to database using (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=xxxx)(PORT=2931))(ADDRESS=(PROTOCOL=TCP)(HOST=51.131.1.14)(PORT=2931))(ADDRESS=(PROTOCOL=TCP)(HOST=xxxx)(PORT=2932)))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=xxxx)(INSTANCE_NAME=ora1))) 而切换后,则是使用tns的alias连接到这个新主库的: ORACLE 例程已经启动。 [W000 08/09 17:56:02.65] Connecting to database using oradg.《==== [W000 08/09 17:56:02.80] Checking broker version [BEGIN :version := dbms_drs.dg_broker_info('VERSION'); END;]. [W000 08/09 17:56:02.96] Broker version is '11.2.0.2.0'<=========到这儿却变成了broker version 11.2.0.2 alter database  mount 数据库装载完毕。 alter database  open 于是我想到了下面这个可能性: 由于11.2版本RAC开始,监听配置在grid用户下,而在data guard创建时为了duplicate又必须配置静态监听,只有静态监听才会把ORACLE_HOME绑定在tns name alias上。估计是客户在升级后忘了改静态监听或者删掉它! 在跟客户要来了监听配置后发现果然如此: SID_LIST_LISTENER =  (SID_LIST =        (SID_DESC =          (ORACLE_HOME = /oracle/app/12.2.0/grid)          (SID_NAME = +ASM1)        )        (SID_DESC =          (GLOBAL_DBNAME=ORA)          (ORACLE_HOME = /oracle/app/oracle/product/11.2.0/dbhome_1)《====这里写的是11.2.0.2的ORACLE_HOME          (SID_NAME =  ORA1)        )  ) 那么原因就找到了,只要建议客户把监听的ORACLE_HOME = /oracle/app/oracle/product/11.2.0/dbhome_1改成/oracle/app/oracle/product/11.2.0.4/dbhome_1即可解决问题。 其实这里把静态监听删掉也可以,因为静态监听只在duplicate时实例没启动的情况下以sysdba身份连接备库实例时有用,之后就没用了,而broker这里也是先用连接串启动备库到nomount状态,然后连接tns alias去mount和open。        

  最近接到了个比较奇怪的问题,switchover之后,新主库居然提示要以upgrade模式打开: alter database  open ORA-01092: ORACLE instance terminated. Disconnection forced ORA-00704: bootstrap process failureORA-39700: database must be opened...

测试案例

从现有ADG备库创建新备库的可行性测试

有客户问,因主库业务负载较高,能否从ADG备库创建出一个新备库来。为此做了如下测试,证明确实可行。 步骤: 1、在主库上创建standby controlfile [oracle@adg ~]$ export ORACLE_SID=adgpri [oracle@adg ~]$ sqlplus / as sysdba   SQL*Plus: Release 11.2.0.4.0 Production on Thu Aug 10 12:12:25 2017   Copyright (c) 1982, 2013, Oracle. All rights reserved.     Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options   SQL> alter database create standby controlfile as '/home/oracle/app/oracle/oradata/adgnew/control01.ctl';   Database altered.   SQL> exit Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options [oracle@adg ~]$ export ORACLE_SID=adgnew   2、配置到新备库的静态监听和tnsnames $ cat $ORACLE_HOME/network/admin/listener.ora # listener.ora Network Configuration File: /home/oracle/app/oracle/product/11.2.0/dbhome_1/network/admin/listener.ora # Generated by Oracle configuration tools.   LISTENER = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = adg.fsm.com)(PORT = 1521)) (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521)) (UR=A) ) )   SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (SID_NAME = PLSExtProc) (ORACLE_HOME = /home/oracle/app/oracle/product/11.2.0/dbhome_1) (PROGRAM = extproc) )   (SID_DESC = (GLOBAL_DBNAME = adgstby) (ORACLE_HOME = /home/oracle/app/oracle/product/11.2.0/dbhome_1) (SID_NAME = adgstby) ) (SID_DESC = (GLOBAL_DBNAME = adgnew) (ORACLE_HOME = /home/oracle/app/oracle/product/11.2.0/dbhome_1) (SID_NAME = adgnew) )   ) ADR_BASE_LISTENER = /home/oracle/app/oracle   [oracle@adg ~]$ lsnrctl stop   LSNRCTL for Linux: Version 11.2.0.4.0 - Production on 10-AUG-2017 12:27:11   Copyright (c) 1991, 2013, Oracle. All rights reserved.   Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=adg.fsm.com)(PORT=1521))(UR=A)) The command completed successfully [oracle@adg ~]$ lsnrctl start   LSNRCTL for Linux: Version 11.2.0.4.0 - Production on 10-AUG-2017 12:27:16   Copyright (c) 1991, 2013, Oracle. All rights reserved.   Starting /home/oracle/app/oracle/product/11.2.0/dbhome_1/bin/tnslsnr: please wait...   TNSLSNR for Linux: Version 11.2.0.4.0 - Production System parameter file is /home/oracle/app/oracle/product/11.2.0/dbhome_1/network/admin/listener.ora Log messages written to /home/oracle/app/oracle/diag/tnslsnr/adg/listener/alert/log.xml Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=adg.fsm.com)(PORT=1521))(UR=A)) Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521))(UR=A))   Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=adg.fsm.com)(PORT=1521))(UR=A)) STATUS of the LISTENER ------------------------ Alias LISTENER Version TNSLSNR for Linux: Version 11.2.0.4.0 - Production Start Date 10-AUG-2017 12:27:16 Uptime 0 days 0 hr. 0 min. 0 sec Trace Level off Security ON: Local OS Authentication SNMP OFF Listener Parameter File /home/oracle/app/oracle/product/11.2.0/dbhome_1/network/admin/listener.ora Listener Log File /home/oracle/app/oracle/diag/tnslsnr/adg/listener/alert/log.xml Listening Endpoints Summary... (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=adg.fsm.com)(PORT=1521))(UR=A)) (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521))(UR=A)) Services Summary... Service "PLSExtProc" has 1 instance(s). Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service... Service "adgnew" has 1 instance(s). Instance "adgnew", status UNKNOWN, has 1 handler(s) for this service... Service "adgstby" has 1 instance(s). Instance "adgstby", status UNKNOWN, has 1 handler(s) for this service... The command completed successfully [oracle@adg ~]$ vi $ORACLE_HOME/network/admin/tnsnames.ora # tnsnames.ora Network Configuration File: /home/oracle/app/oracle/product/11.2.0/dbhome_1/network/admin/tnsnames.ora # Generated by Oracle configuration tools.   ADGSTBY = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.210.98)(PORT = 1521)) ) (SERVICE_NAME = adgstby) ) )   ADGPRI = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.210.98)(PORT = 1521)) ) (SERVICE_NAME = adgpri) ) )   ADGNEW = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.210.98)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = adgnew) ) ) ~ "app/oracle/product/11.2.0/dbhome_1/network/admin/tnsnames.ora" 32L, 715C written [oracle@adg ~]$ tnsping adgnew   TNS Ping Utility for Linux: Version 11.2.0.4.0 - Production on 10-AUG-2017 12:28:33   Copyright (c) 1997, 2013, Oracle. All rights reserved.   Used parameter files: /home/oracle/app/oracle/product/11.2.0/dbhome_1/network/admin/sqlnet.ora     Used TNSNAMES adapter to resolve the alias Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.210.98)(PORT = 1521))) (CONNECT_DATA = (SERVICE_NAME = adgnew))) OK (20 msec)   3、创建新备库的口令文件 [oracle@adg ~]$ cd $ORACLE_HOME/dbs [oracle@adg dbs]$ ls 0bsbab9d_1_1 arch1_10_919148645.dbf arch1_14_919148645.dbf arch1_18_919148645.dbf arch1_6_919148645.dbf hc_adgnew.dat lkADGPRI snapcf_adgpri.f 0csbab9h_1_1 arch1_11_919148645.dbf arch1_15_919148645.dbf arch1_19_919148645.dbf arch1_7_919148645.dbf hc_adgpri.dat lkADGSTBY spfileadgnew.ora 0dsbabcq_1_1 arch1_12_919148645.dbf arch1_16_919148645.dbf arch1_20_919148645.dbf arch1_8_919148645.dbf hc_adgstby.dat orapwadgpri spfileadgpri.ora 0esbabcu_1_1 arch1_13_919148645.dbf arch1_17_919148645.dbf arch1_5_919148645.dbf arch1_9_919148645.dbf init.ora orapwadgstby spfileadgstby.ora [oracle@adg dbs]$ cp orapwadgpri orapwadgnew   4、创建新备库的参数文件(特别注意db_file_name_convert不要写成主库的路径映射) [oracle@adg ~]$ vi pfilestby.txt *.audit_file_dest='/home/oracle/app/oracle/admin/adgnew/adump' *.audit_trail='db' *.compatible='11.2.0.4.0' *.control_files='/home/oracle/app/oracle/oradata/adgnew/control01.ctl' *.db_block_size=8192 *.db_domain='' *.db_file_name_convert='/home/oracle/app/oracle/oradata/adgstby','/home/oracle/app/oracle/oradata/adgnew' *.db_name='adgpri' *.db_unique_name='adgnew' *.diagnostic_dest='/home/oracle/app/oracle' *.dispatchers='(PROTOCOL=TCP) (SERVICE=adgnewXDB)' *.fal_client='ADGPRI' *.fal_server='ADGSTBY' *.log_archive_config='DG_CONFIG=(adgpri,adgnew)' *.log_archive_dest_2='SERVICE=adgpri LGWR SYNC VALID_FOR=(ONLINE_LOGFILES,primary_ROLE) DB_UNIQUE_NAME=adgpri' *.log_archive_dest_state_1='ENABLE' *.log_archive_dest_state_2='ENABLE' *.log_file_name_convert='/home/oracle/app/oracle/oradata/adgpri','/home/oracle/app/oracle/oradata/adgnew' *.open_cursors=300 *.pga_aggregate_target=456130560 *.processes=150 *.remote_login_passwordfile='EXCLUSIVE' *.sga_target=1368391680 *.standby_file_management='AUTO' *.undo_tablespace='UNDOTBS1' ~ ~ ~ "pfilestby.txt" 25L, 1038C written     5、创建备库spfile,之后重启备库到nomount状态 [oracle@adg ~]$ export ORACLE_SID=adgnew [oracle@adg ~]$ sqlplus / as sysdba   SQL*Plus: Release 11.2.0.4.0 Production on Thu Aug 10 12:35:33 2017   Copyright (c) 1982, 2013, Oracle. All rights reserved.     Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options   SQL> shutdown abort ORACLE instance shut down. SQL> create spfile from pfile='/home/oracle/pfilestby.txt';   File created.   SQL> exit Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options   [oracle@adg ~]$ export ORACLE_SID=adgnew [oracle@adg ~]$ sqlplus / as sysdba   SQL*Plus: Release 11.2.0.4.0 Production on Thu Aug 10 12:37:23 2017   Copyright (c) 1982, 2013, Oracle. All rights reserved.   Connected to an idle instance.   SQL> startup nomount ORACLE instance started.   Total System Global Area 1369579520 bytes Fixed Size 2253104 bytes Variable Size 419434192 bytes Database Buffers 939524096 bytes Redo Buffers 8368128 bytes SQL> exit Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options   6、从现有备库duplicate新备库 [oracle@adg ~]$ export ORACLE_SID=adgstby [oracle@adg ~]$ rman target / auxiliary sys/huiming@adgnew   Recovery Manager: Release 11.2.0.4.0 - Production on Thu Aug 10 12:37:38 2017   Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.   connected to target database: ADGPRI (DBID=1362425892) connected to auxiliary database: ADGPRI (not mounted)   RMAN> duplicate target database for standby from active database nofilenamecheck dorecover;   Starting Duplicate Db at 10-AUG-17 using target database control file instead of recovery catalog allocated channel: ORA_AUX_DISK_1 channel ORA_AUX_DISK_1: SID=19 device type=DISK   contents of Memory Script: { backup as copy reuse targetfile '/home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/orapwadgstby' auxiliary format '/home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/orapwadgnew' ; } executing Memory Script   Starting backup at 10-AUG-17 allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=1 device type=DISK Finished backup at 10-AUG-17   contents of Memory Script: { backup as copy current controlfile for standby auxiliary format '/home/oracle/app/oracle/oradata/adgnew/control01.ctl'; } executing Memory Script   Starting backup at 10-AUG-17 using channel ORA_DISK_1 channel ORA_DISK_1: starting datafile copy copying standby control file output file name=/home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/snapcf_adgstby.f tag=TAG20170810T123746 RECID=7 STAMP=951655066 channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:03 Finished backup at 10-AUG-17   contents of Memory Script: { sql clone 'alter database mount standby database'; } executing Memory Script   sql statement: alter database mount standby database   contents of Memory Script: { set newname for tempfile 1 to "/home/oracle/app/oracle/oradata/adgnew/temp01.dbf"; switch clone tempfile all; set newname for datafile 1 to "/home/oracle/app/oracle/oradata/adgnew/system01.dbf"; set newname for datafile 2 to "/home/oracle/app/oracle/oradata/adgnew/sysaux01.dbf"; set newname for datafile 3 to "/home/oracle/app/oracle/oradata/adgnew/undotbs01.dbf"; set newname for datafile 4 to "/home/oracle/app/oracle/oradata/adgnew/users01.dbf"; backup as copy reuse datafile 1 auxiliary format "/home/oracle/app/oracle/oradata/adgnew/system01.dbf" datafile 2 auxiliary format "/home/oracle/app/oracle/oradata/adgnew/sysaux01.dbf" datafile 3 auxiliary format "/home/oracle/app/oracle/oradata/adgnew/undotbs01.dbf" datafile 4 auxiliary format "/home/oracle/app/oracle/oradata/adgnew/users01.dbf" ; } executing Memory Script   executing command: SET NEWNAME   renamed tempfile 1 to /home/oracle/app/oracle/oradata/adgnew/temp01.dbf in control file   executing command: SET NEWNAME   executing command: SET NEWNAME   executing command: SET NEWNAME   executing command: SET NEWNAME   Starting backup at 10-AUG-17 using channel ORA_DISK_1 channel ORA_DISK_1: starting datafile copy input datafile file number=00001 name=/home/oracle/app/oracle/oradata/adgstby/system01.dbf output file name=/home/oracle/app/oracle/oradata/adgnew/system01.dbf tag=TAG20170810T123757 channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:45 channel ORA_DISK_1: starting datafile copy input datafile file number=00002 name=/home/oracle/app/oracle/oradata/adgstby/sysaux01.dbf output file name=/home/oracle/app/oracle/oradata/adgnew/sysaux01.dbf tag=TAG20170810T123757 channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:35 channel ORA_DISK_1: starting datafile copy input datafile file number=00003 name=/home/oracle/app/oracle/oradata/adgstby/undotbs01.dbf output file name=/home/oracle/app/oracle/oradata/adgnew/undotbs01.dbf tag=TAG20170810T123757 channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:07 channel ORA_DISK_1: starting datafile copy input datafile file number=00004 name=/home/oracle/app/oracle/oradata/adgstby/users01.dbf output file name=/home/oracle/app/oracle/oradata/adgnew/users01.dbf tag=TAG20170810T123757 channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01 Finished backup at 10-AUG-17   contents of Memory Script: { switch clone datafile all; } executing Memory Script   datafile 1 switched to datafile copy input datafile copy RECID=7 STAMP=951655166 file name=/home/oracle/app/oracle/oradata/adgnew/system01.dbf datafile 2 switched to datafile copy input datafile copy RECID=8 STAMP=951655166 file name=/home/oracle/app/oracle/oradata/adgnew/sysaux01.dbf datafile 3 switched to datafile copy input datafile copy RECID=9 STAMP=951655166 file name=/home/oracle/app/oracle/oradata/adgnew/undotbs01.dbf datafile 4 switched to datafile copy input datafile copy RECID=10 STAMP=951655166 file name=/home/oracle/app/oracle/oradata/adgnew/users01.dbf   contents of Memory Script: { set until scn 1015629; recover standby clone database noredo delete archivelog ; } executing Memory Script   executing command: SET until clause   Starting recover at 10-AUG-17 using channel ORA_AUX_DISK_1   Finished recover at 10-AUG-17 Finished Duplicate Db at 10-AUG-17   RMAN> exit     Recovery Manager complete.   7、配置主库的新参数 [oracle@adg ~]$ export ORACLE_SID=adgpri [oracle@adg ~]$ sqlplus / as sysdba   SQL*Plus: Release 11.2.0.4.0 Production on Thu Aug 10 12:42:43 2017   Copyright (c) 1982, 2013, Oracle. All rights reserved.     Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options   SQL> select open_mode,database_role from v$database;   OPEN_MODE DATABASE_ROLE -------------------- ---------------- READ WRITE PRIMARY     SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_3='SERVICE=adgnew NOAFFIRM ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=adgnew';   System altered.   SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_3=ENABLE;   System altered.   SQL> ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(adgpri,adgstby,adgnew)';   System altered.   SQL> show parameter log_archive_dest   NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ log_archive_dest string log_archive_dest_1 string log_archive_dest_10 string log_archive_dest_11 string log_archive_dest_12 string log_archive_dest_13 string log_archive_dest_14 string log_archive_dest_15 string log_archive_dest_16 string log_archive_dest_17 string log_archive_dest_18 string   NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ log_archive_dest_19 string log_archive_dest_2 string SERVICE=adgstby LGWR SYNC VALI D_FOR=(ONLINE_LOGFILES,primary _ROLE) DB_UNIQUE_NAME=adgstby log_archive_dest_20 string log_archive_dest_21 string log_archive_dest_22 string log_archive_dest_23 string log_archive_dest_24 string log_archive_dest_25 string log_archive_dest_26 string   NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ log_archive_dest_27 string log_archive_dest_28 string log_archive_dest_29 string log_archive_dest_3 string SERVICE=adgnew NOAFFIRM ASYNC VALID_FOR=(ONLINE_LOGFILES,PRI MARY_ROLE) DB_UNIQUE_NAME=adgn ew log_archive_dest_30 string log_archive_dest_31 string log_archive_dest_4 string log_archive_dest_5 string   NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ log_archive_dest_6 string log_archive_dest_7 string log_archive_dest_8 string log_archive_dest_9 string ... SQL> exit Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options   8、启动备库,并开始实时日志应用 [oracle@adg ~]$ export ORACLE_SID=adgnew [oracle@adg ~]$ sqlplus / as sysdba   SQL*Plus: Release 11.2.0.4.0 Production on Thu Aug 10 12:44:44 2017   Copyright (c) 1982, 2013, Oracle. All rights reserved.     Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options   SQL> shutdown immediate   ORA-01109: database not open     Database dismounted. ORACLE instance shut down. SQL> SQL> startup ORACLE instance started.   Total System Global Area 1369579520 bytes Fixed Size 2253104 bytes Variable Size 419434192 bytes Database Buffers 939524096 bytes Redo Buffers 8368128 bytes Database mounted. Database opened. SQL> alter database recover managed standby database using current logfile disconnect from session;   Database altered.    

有客户问,因主库业务负载较高,能否从ADG备库创建出一个新备库来。为此做了如下测试,证明确实可行。 步骤: 1、在主库上创建standby controlfile [oracle@adg ~]$ export ORACLE_SID=adgpri [oracle@adg ~]$ sqlplus / as sysdba   SQL*Plus: Release 11.2.0.4.0 Production on...

TimesTen

TimesTen 内存数据库的速度有多快?

TimesTen 内存数据库在商业硬件领域上表现出极佳的性能。 衡量RDBMS 性能有两个重要因素:延迟和吞吐量。延迟是关于 SQL 即: Select、Insert、Update、Delete 或 Merge 等操作完成的速度。 TimesTen 以实现低延迟的 SQL 事务而闻名。 我们以微秒为单位衡量 TimesTen 延迟,而不是毫秒: 上图的延迟基准测试在商用 Linux / Intel 硬件上运行: •    2 CPU sockets,22 cores/socket,Intel Xeon E5-2699 v4 @ 2.20GHz •    基准测试使用 TPTBM 执行读取和更新操作 •    TimesTen 11.2.2.8.0(100M 行数据,数据库大小为17 GB) 真正的低延迟也有助于提高吞吐量。 RDBMS 吞吐量以每秒事务(ACID)量来定义。 该吞吐量基准测试在相同的商业硬件上运行: •    2 CPU sockets,22 cores/socket,Intel Xeon E5-2699 v4 @ 2.20GHz •    基准测试是基于 TPTBM 的混合事务负载(80% 读取,10% 更新,5% 插入和 5% 删除) •    TimesTen 11.2.2.8.0(100M 行数据,数据库大小为17 GB) TimesTen 的性能取决于工作负载、硬件和优化的 SQL 语句。 这些 TPTBM 基准测试使用主键查询,每个事务中的 SQL 语句只影响几行。如果您的 SQL 事务涉及许多表的复杂关联或返回大量行,这些操作将需要更长时间。运行 SQL 事务的硬件也会影响性能。高性能的以 GHz 为单位的 CPU、L3 缓存的大小以及 CPU 的核数往往会提供更好的 TimesTen 内存数据库性能。 下载并测试 TimesTen 内存数据库。TimesTen Quickstart Guide 可以帮助您快速入门。 免责声明:这些都是我个人的观点,不代表 Oracle 的官方观点。 作者:Doug Hood | TimesTen Cloud Product Manager 原文出自:TimesTen Blog - Just how fast is TimesTen In-Memory Database?

TimesTen 内存数据库在商业硬件领域上表现出极佳的性能。 衡量RDBMS 性能有两个重要因素:延迟和吞吐量。延迟是关于 SQL 即: Select、Insert、Update、Delete 或 Merge 等操作完成的速度。 TimesTen 以实现低延迟的 SQL 事务而闻名。 我们以微秒为单位衡量 TimesTen 延迟,而不是毫秒: 上图的延迟基准测试在商用 Linux / Intel...

技术共享

statspack 数据维护清理问题

我们都知道oracle从10g开始提供了Automatic Workload Repository (AWR)来完成对系统性能数据的自动收集和存储,甚至利用ADDM能够进一步完成自我诊断。但是这个工具包是企业版才提供的, 对于标准版并不是免费的,不过购买标准版license的客户仍然能够使用9i开始提供的Statspack功能包。但是AWR因为有完善的自我管理功能,如自动收集,自动清理, 所以是使用上非常便捷,相比免费的Statspack就没有任何自动维护功能,需要客户自行手动运行性能数据的收集和历史数据的清理。 对于statspack历史数据的清理问题,官方自带的@?/rdbms/admin/spdoc.txt文档是有所描述的:以11204版本为例 8.  Managing and Sharing performance data      8.2. Purging/removing unnecessary data        8.2.1. Input Parameters for the PURGE procedure and function               which accept Begin Snap Id and End Snap Id               8.2.2. Input Parameters for the PURGE procedure and function               which accept Begin Date and End Date        8.2.3. Input Parameters for the PURGE procedure and function               which accept a single Purge Before Date        8.2.4. Input Parameters for the PURGE procedure and function               which accept the Number of Days of data to keep        8.2.5. Using sppurge.sql 可以看到官方purge方法提供了4种形式: 1.输入起始snapshot和终止snapshot        SQL> variable num_snaps number;        SQL> begin        SQL>   :num_snaps := statspack.purge(i_begin_snap=>1237, i_end_snap=>1241, i_extended_purge=>TRUE);        SQL> end;        SQL> / 2.输入起始日期和终止日期         SQL> exec statspack.purge -                (i_begin_date=>to_date('01-JAN-2003', 'DD-MON-YYYY'), -                 i_end_date  =>to_date('02-JAN-2003', 'DD-MON-YYYY'), -                 i_extended_purge=>TRUE); 3.输入单一日期,        SQL> exec statspack.purge(to_date('31-OCT-2002','DD-MON-YYYY')); 4.输入保留天数:        SQL> exec statspack.purge(31); 除了清理部分数据的方法,还有整体清理的手段:  sqlplus>conn PERFSTAT/paswd    <<需要在PERFSTAT用户下执行  sqlplus>@?/rdbms/admin/sptrunc     Enter value for begin_or_exit:      Entered at the 'begin_or_exit' prompt  <<exit 可以中止执行     ... Starting truncate operation     Table truncated.     Table truncated.     <etc...>     Commit complete.      Package altered.      ... Truncate operation complete 除了上述官方的清理办法之外,还有一种简单办法就是直接删除STATS$SNAPSHOT,如 delete from STATS$SNAPSHOT where SNAP_ID<100; 因为oracle 在设计statspack的时候,其他表都是通过外键约束关联到这个 核心表的,并且约束上是有on delete cascade 语句 ,当删除核心表STATS$SNAPSHOT 数据时,这些关联表都会随之删除。 下面是通过对 delete from STATS$SNAPSHOT where SNAP_ID<100; 进行10046 trace的情况,可以看到所有表 都会进行清理。  delete from "PERFSTAT"."STATS$DB_CACHE_ADVICE" where "SNAP_ID" = :1 and "DBID" = :2 and "INSTANCE_NUMBER" = :3 delete from "PERFSTAT"."STATS$FILESTATXS" where "SNAP_ID" = :1 and "DBID" = :2 and "INSTANCE_NUMBER" = :3 delete from "PERFSTAT"."STATS$TEMPSTATXS" where "SNAP_ID" = :1 and "DBID" = :2 and "INSTANCE_NUMBER" = :3 delete from "PERFSTAT"."STATS$LATCH" where "SNAP_ID" = :1 and "DBID" = :2 and "INSTANCE_NUMBER" = :3 delete from "PERFSTAT"."STATS$LATCH_CHILDREN" where "SNAP_ID" = :1 and "DBID" = :2 and "INSTANCE_NUMBER" = :3 delete from "PERFSTAT"."STATS$LATCH_PARENT" where "SNAP_ID" = :1 and "DBID" = :2 and "INSTANCE_NUMBER" = :3 delete from "PERFSTAT"."STATS$LATCH_MISSES_SUMMARY" where "SNAP_ID" = :1 and "DBID" = :2 and "INSTANCE_NUMBER" = :3 delete from "PERFSTAT"."STATS$LIBRARYCACHE" where "SNAP_ID" = :1 and "DBID" = :2 and "INSTANCE_NUMBER" = :3 delete from "PERFSTAT"."STATS$BUFFER_POOL_STATISTICS" where "SNAP_ID" = :1 and "DBID" = :2 and "INSTANCE_NUMBER" = :3 delete from "PERFSTAT"."STATS$ROLLSTAT" where "SNAP_ID" = :1 and "DBID" = :2 and "INSTANCE_NUMBER" = :3 delete from "PERFSTAT"."STATS$ROWCACHE_SUMMARY" where "SNAP_ID" = :1 and "DBID" = :2 and "INSTANCE_NUMBER" = :3 delete from "PERFSTAT"."STATS$SGA" where "SNAP_ID" = :1 and "DBID" = :2 and "INSTANCE_NUMBER" = :3 delete from "PERFSTAT"."STATS$SGASTAT" where "SNAP_ID" = :1 and "DBID" = :2 and "INSTANCE_NUMBER" = :3 delete from "PERFSTAT"."STATS$SYSSTAT" where "SNAP_ID" = :1 and "DBID" = :2 and "INSTANCE_NUMBER" = :3 delete from "PERFSTAT"."STATS$SESSTAT" where "SNAP_ID" = :1 and "DBID" = :2 and "INSTANCE_NUMBER" = :3  。。。。。。省略 综上所述,虽然statspack虽然没有提供自动维护的机制,但是对于数据的维护清理还是提供了很多方便的手段,客户只要自己编写一个job或者后台shell就可以 实现自动化。

我们都知道oracle从10g开始提供了Automatic Workload Repository (AWR)来完成对系统性能数据的自动收集和存储,甚至利用ADDM能够进一步完成自我诊断。但是这个工具包是企业版才提供的, 对于标准版并不是免费的,不过购买标准版license的客户仍然能够使用9i开始提供的Statspack功能包。但是AWR因为有完善的自我管理功能,如自动收集,自动清理,所以是使用上...

测试案例

为什么控制文件的时间点恢复不使用controlfile backup而使用snapshot controlfile?

近日有客户提到了这个有趣的问题,为此做了个Test Case研究了下: 测试控制文件的时间点恢复。 1、恢复到控制文件备份时间点之前 2、恢复到控制文件备份时间点之后 3、恢复到控制文件备份时间点的sequence# 步骤1:环境准备 [oracle@adg ~]$ sqlplus / as sysdba SQL*Plus: Release 11.2.0.4.0 Production on Mon Aug 7 13:07:33 2017 Copyright (c) 1982, 2013, Oracle.  All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL> archive log list;   Database log mode              Archive Mode Automatic archival             Enabled Archive destination            /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/arch Oldest online log sequence     13 Next log sequence to archive   15 Current log sequence           15 SQL> exit Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options [oracle@adg ~]$ rman target / Recovery Manager: Release 11.2.0.4.0 - Production on Mon Aug 7 13:07:48 2017 Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved. connected to target database: ADGPRI (DBID=1362425892) RMAN> backup database plus archivelog; Starting backup at 07-AUG-17 current log archived using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=55 device type=DISK channel ORA_DISK_1: starting archived log backup set channel ORA_DISK_1: specifying archived log(s) in backup set input archived log thread=1 sequence=5 RECID=1 STAMP=919155285 input archived log thread=1 sequence=6 RECID=2 STAMP=919155719 input archived log thread=1 sequence=7 RECID=3 STAMP=919155989 input archived log thread=1 sequence=8 RECID=4 STAMP=919156172 input archived log thread=1 sequence=9 RECID=5 STAMP=919156175 input archived log thread=1 sequence=10 RECID=6 STAMP=919156178 input archived log thread=1 sequence=11 RECID=7 STAMP=919156515 input archived log thread=1 sequence=12 RECID=9 STAMP=919156518 input archived log thread=1 sequence=13 RECID=17 STAMP=919156585 input archived log thread=1 sequence=14 RECID=18 STAMP=951396680 input archived log thread=1 sequence=15 RECID=19 STAMP=951397676 channel ORA_DISK_1: starting piece 1 at 07-AUG-17 channel ORA_DISK_1: finished piece 1 at 07-AUG-17 piece handle=/home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/0bsbab9d_1_1 tag=TAG20170807T130757 comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:00:04 Finished backup at 07-AUG-17 Starting backup at 07-AUG-17 using channel ORA_DISK_1 channel ORA_DISK_1: starting full datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup set input datafile file number=00001 name=/home/oracle/app/oracle/oradata/adgpri/system01.dbf input datafile file number=00002 name=/home/oracle/app/oracle/oradata/adgpri/sysaux01.dbf input datafile file number=00003 name=/home/oracle/app/oracle/oradata/adgpri/undotbs01.dbf input datafile file number=00004 name=/home/oracle/app/oracle/oradata/adgpri/users01.dbf channel ORA_DISK_1: starting piece 1 at 07-AUG-17 channel ORA_DISK_1: finished piece 1 at 07-AUG-17 piece handle=/home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/0csbab9h_1_1 tag=TAG20170807T130801 comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:01:45 channel ORA_DISK_1: starting full datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup set including current control file in backup set including current SPFILE in backup set channel ORA_DISK_1: starting piece 1 at 07-AUG-17 channel ORA_DISK_1: finished piece 1 at 07-AUG-17 piece handle=/home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/0dsbabcq_1_1 tag=TAG20170807T130801 comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01 Finished backup at 07-AUG-17 Starting backup at 07-AUG-17 current log archived using channel ORA_DISK_1 channel ORA_DISK_1: starting archived log backup set channel ORA_DISK_1: specifying archived log(s) in backup set input archived log thread=1 sequence=16 RECID=20 STAMP=951397790 channel ORA_DISK_1: starting piece 1 at 07-AUG-17 channel ORA_DISK_1: finished piece 1 at 07-AUG-17 piece handle=/home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/0esbabcu_1_1 tag=TAG20170807T130950 comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01 Finished backup at 07-AUG-17 RMAN> list backup of controlfile; using target database control file instead of recovery catalog List of Backup Sets =================== BS Key  Type LV Size       Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 3       Full    9.36M      DISK        00:00:04     07-AUG-17      《===========================这里看不出控制文件备份的准确时间点,稍后通过v$backup_set查看backupset 3的创建时间点可得到         BP Key: 3   Status: AVAILABLE  Compressed: NO  Tag: TAG20170807T130801         Piece Name: /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/0dsbabcq_1_1   Control File Included: Ckp SCN: 992988       Ckp time: 07-AUG-17 RMAN> exit Recovery Manager complete. [oracle@adg ~]$ sqlplus / as sysdba SQL*Plus: Release 11.2.0.4.0 Production on Mon Aug 7 13:11:38 2017 Copyright (c) 1982, 2013, Oracle.  All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL> archive log list; Database log mode              Archive Mode Automatic archival             Enabled Archive destination            /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/arch Oldest online log sequence     15 Next log sequence to archive   17 Current log sequence           17 SQL>  SQL> select sequence#,to_char(first_time,'yyyy-mm-dd hh24:mi:ss'), to_char(next_time,'yyyy-mm-dd hh24:mi:ss') from v$archived_log;  SEQUENCE# TO_CHAR(FIRST_TIME, TO_CHAR(NEXT_TIME,' ---------- ------------------- -------------------          5 2016-08-06 07:05:28 2016-08-06 08:54:45          6 2016-08-06 08:54:45 2016-08-06 09:01:59          7 2016-08-06 09:01:59 2016-08-06 09:06:29          8 2016-08-06 09:06:29 2016-08-06 09:09:32          9 2016-08-06 09:09:32 2016-08-06 09:09:35         10 2016-08-06 09:09:35 2016-08-06 09:09:38         11 2016-08-06 09:09:38 2016-08-06 09:15:14          6 2016-08-06 08:54:45 2016-08-06 09:01:59         12 2016-08-06 09:15:14 2016-08-06 09:15:18         12 2016-08-06 09:15:14 2016-08-06 09:15:18          7 2016-08-06 09:01:59 2016-08-06 09:06:29  SEQUENCE# TO_CHAR(FIRST_TIME, TO_CHAR(NEXT_TIME,' ---------- ------------------- -------------------          9 2016-08-06 09:09:32 2016-08-06 09:09:35         10 2016-08-06 09:09:35 2016-08-06 09:09:38         11 2016-08-06 09:09:38 2016-08-06 09:15:14          8 2016-08-06 09:06:29 2016-08-06 09:09:32         13 2016-08-06 09:15:18 2016-08-06 09:16:24         13 2016-08-06 09:15:18 2016-08-06 09:16:24         14 2016-08-06 09:16:24 2017-08-07 12:51:19         15 2017-08-07 12:51:19 2017-08-07 13:07:56         16 2017-08-07 13:07:56 2017-08-07 13:09:50 20 rows selected. SQL> select recid,to_char(start_time,'yyyy-mm-dd hh24:mi:ss') from v$backup_set;      RECID TO_CHAR(START_TIME, ---------- -------------------          1 2017-08-07 13:07:57          2 2017-08-07 13:08:01          3 2017-08-07 13:09:46《=============控制文件备份创建时间点,显然是在16号归档日志范围内.          4 2017-08-07 13:09:50 步骤2:恢复到控制文件备份时间点之前 由于恢复过程只能前滚不能回滚(回滚是闪回的功能),所以无法使用控制文件备份,而根据ASk Tom的帖子,snapshot controlfile是个“精简版”的控制文件,只能用于无备份可恢复的情况,且完全恢复需要用snapshot controlfile创建之后的所有归档: ASM tom的帖子: 3)In case of failure can we make use of snapshot controlfile to restore database from past backup?  3) Yes. For example, from MOS note 372996.1, we describe an example where "everything" is lost - one of the options is  "If no controlfile backup available it may be also an option to restore CONTROLFILE from a SNAPSHOT CONTROLFILE if available"  测试过程: [oracle@adg ~]$ rman target / Recovery Manager: Release 11.2.0.4.0 - Production on Mon Aug 7 13:12:31 2017 Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved. connected to target database: ADGPRI (DBID=1362425892) RMAN> run{ 2> set until sequence 14; 3> restore controlfile preview; 4> } executing command: SET until clause Starting restore at 07-AUG-17 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=48 device type=DISK List of Control File Copies =========================== Key     S Completion Time Ckp SCN    Ckp Time        ------- - --------------- ---------- --------------- 2       A 06-AUG-16       969402     06-AUG-16               Name: /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/snapcf_adgpri.f         Tag: TAG20160806T090132 using channel ORA_DISK_1 List of Archived Log Copies for database with db_unique_name ADGPRI ===================================================================== Key     Thrd Seq     S Low Time  ------- ---- ------- - --------- 2       1    6       A 06-AUG-16         Name: /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_6_919148645.dbf 3       1    7       A 06-AUG-16         Name: /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_7_919148645.dbf 4       1    8       A 06-AUG-16         Name: /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_8_919148645.dbf 5       1    9       A 06-AUG-16         Name: /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_9_919148645.dbf 6       1    10      A 06-AUG-16         Name: /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_10_919148645.dbf 7       1    11      A 06-AUG-16         Name: /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_11_919148645.dbf 9       1    12      A 06-AUG-16         Name: /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_12_919148645.dbf 17      1    13      A 06-AUG-16         Name: /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_13_919148645.dbf Media recovery start SCN is 969402 Recovery must be done beyond SCN 969402 to clear datafile fuzziness Finished restore at 07-AUG-17 RMAN>  步骤3:恢复到备份控制文件之后的时间点 这种情况可以利用控制文件备份 RMAN> run{ 2> set until sequence 17; 3> restore controlfile preview; 4> } executing command: SET until clause Starting restore at 07-AUG-17 using channel ORA_DISK_1 List of Backup Sets =================== BS Key  Type LV Size       Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 3       Full    9.36M      DISK        00:00:04     07-AUG-17               BP Key: 3   Status: AVAILABLE  Compressed: NO  Tag: TAG20170807T130801         Piece Name: /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/0dsbabcq_1_1   Control File Included: Ckp SCN: 992988       Ckp time: 07-AUG-17 List of Archived Log Copies for database with db_unique_name ADGPRI ===================================================================== Key     Thrd Seq     S Low Time  ------- ---- ------- - --------- 20      1    16      A 07-AUG-17         Name: /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_16_919148645.dbf Media recovery start SCN is 992988 Recovery must be done beyond SCN 992988 to clear datafile fuzziness Finished restore at 07-AUG-17 步骤4:恢复到备份控制文件时间点的sequence# 这种情况比较特殊,但可以想明白为什么没走控制文件备份:因为archivelog sequence# 16对于控制文件备份来讲是当前redo而不是归档日志,其信息注册进了controlfile backup里却又不完整(没有END_OF_REDO,v$archived_log.END_OF_REDO),用它recover会导致后续的archivelog无法接续应用。 RMAN> run{ 2> set until sequence 16; 3>  restore controlfile preview; 4> } executing command: SET until clause Starting restore at 07-AUG-17 using channel ORA_DISK_1 List of Control File Copies =========================== Key     S Completion Time Ckp SCN    Ckp Time        ------- - --------------- ---------- --------------- 2       A 06-AUG-16       969402     06-AUG-16               Name: /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/snapcf_adgpri.f         Tag: TAG20160806T090132 List of Archived Log Copies for database with db_unique_name ADGPRI ===================================================================== Key     Thrd Seq     S Low Time  ------- ---- ------- - --------- 2       1    6       A 06-AUG-16         Name: /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_6_919148645.dbf 3       1    7       A 06-AUG-16         Name: /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_7_919148645.dbf 4       1    8       A 06-AUG-16         Name: /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_8_919148645.dbf 5       1    9       A 06-AUG-16         Name: /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_9_919148645.dbf 6       1    10      A 06-AUG-16         Name: /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_10_919148645.dbf 7       1    11      A 06-AUG-16         Name: /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_11_919148645.dbf 9       1    12      A 06-AUG-16         Name: /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_12_919148645.dbf 17      1    13      A 06-AUG-16         Name: /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_13_919148645.dbf 18      1    14      A 06-AUG-16         Name: /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_14_919148645.dbf 19      1    15      A 07-AUG-17         Name: /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_15_919148645.dbf Media recovery start SCN is 969402 Recovery must be done beyond SCN 969402 to clear datafile fuzziness Finished restore at 07-AUG-17 RMAN> exit 

近日有客户提到了这个有趣的问题,为此做了个Test Case研究了下: 测试控制文件的时间点恢复。 1、恢复到控制文件备份时间点之前 2、恢复到控制文件备份时间点之后 3、恢复到控制文件备份时间点的sequence# 步骤1:环境准备 [oracle@adg ~]$ sqlplus / as sysdba SQL*Plus: Release 11.2.0.4.0 Production on Mon Aug...

关于NUMBER(p,s) 精度P的相关解释

最近有客户问关于NUMBER(p,s) 其中 精度P如何理解。 下面是官方在线文档的解释: p is the precision, or the maximum number of significant decimal digits, where the most significant digit is the left-most nonzero digit, and the least significant digit is the right-most known digit. Oracle guarantees the portability of numbers with precision of up to 20 base-100 digits, which is equivalent to 39 or 40 decimal digits depending on the position of the decimal point. 1.怎么理解 20 base-100 digits  ? oracle 内部使用21个字节来存储number类型的数据,其中第一个字节存放 sign/offset/exponent. 符号/偏移量/指数的组合:具体介绍如下 -sign bit (0=negative 128 positive) -offset always 65 -exponent (range from -65 to 62) in base 100 关于base 100的概念,这只是一种技术方式而已,我们都知道计算机世界使用0,1 二进制来操作,这个就是base 2,而我们经常使用的阿拉伯数字就是10进制的,那么就是base 10 。例如 10进制下345的表示方式为: 345=3*10^2+4*10^1+5*10^0,同样道理,用100进制来表示计数方式就是 base 100 , for example 12,34,56=12*100^2+34*100^1+56*100^0。 就像10进制下任何一位只能存放0~9以内数字一样,100进制下的任何“1”位数能存放0~99,oracle使用1个字节来存放100进制的每“1”位,共计有20个,所以oracle能存放的最大数字是(这里暂不考虑指数部分)99,99,99,99,99,99,99,99,99,99,99,99,99,99,99,99,99,99,99,99,为了内部实现,oracle实际上在存储每“1”位的时候都+1,也就是存在磁盘上就是 100,100,100,100,100,100,100,100,100,100,100,100,100,100,100,100,100,100,100,100. 2、如何理解精度的概念 如上所述,不考虑指数位的情况最大数字是20个99,也就是40位。那么超过这个数字,oracle就会丢失精度,如 若是存储41位的两个数字99,99,99,99,99,99,99,99,99,99,99,99,99,99,99,99,99,99,99,99,1 99,99,99,99,99,99,99,99,99,99,99,99,99,99,99,99,99,99,99,99,2,因为有效精度是40位,最后新增1位会被忽略掉,作为指数增加1。所以oracle是无法区分这两个数字的,会 认为这两个数字相等,相减也不会等于1,而是0, 下面分别是41位数和40位数相减情况   SQL> select 9999999999999999999999999999999999999999-9999999999999999999999999999999999999998  delta_40bit from dual; delta_40bit --------------------------------------------------------------------------------                                            1 SQL> select 99999999999999999999999999999999999999993-99999999999999999999999999999999999999992  delta_41bit from dual; delta_41bit --------------------------------------------------------------------------------                                            0 虽然精度存在40位的问题,但是并不代表oracle只能保存小于41位的数字,因为还存在指数位,所以只要超过40位, 那么指数位就加1,(因为100进制的四舍五入的原因,0-49指数不变,50-99才加1), 所以指数位最大是62,那么表示62个100进制位,即10进制的124位,加上第一个2位,oracle最大能存放1.0 x 10126(注意,因为100进制最大是99,所以是不包含1.0 x 10126   )  所以:NUMBER(p,s)  精度P是用来指定到底能存放多大精度的数字,若是p=5,那么最大数字就是99999, 这个参数可以指定0-38,若是想存储39,甚至最大40位精度,那么就不指定,默认最高就是40位精度了。

最近有客户问关于NUMBER(p,s) 其中 精度P如何理解。 下面是官方在线文档的解释: p is the precision, or the maximum number of significant decimal digits, where the most significant digit is the left-most nonzero digit, and the...

技术共享

记一次 sqlplus无法连接到实例 故障诊断

客户抱怨实例明明在启动状态,sqlplus 却无法登录db,一直提示 Connected to an idle instance 刚接到这个case,首先怀疑是不是客户搞错了SID大小写,因为没有指定正确的SID就会提示连接空实例的错误, 根据这个先检查一下客户提供的信息: $ ps -ef|grep noctest  oracle 27181     1  0  Jul  1  ?        1083:02 ora_mmnl_noctest  oracle 27155     1  0  Jul  1  ?        1122:34 ora_vktm_noctest  oracle 25941     1  0  Jul 25  ?         0:20 oraclenoctest (LOCAL=NO)  oracle 16621     1  0 18:03:19 ?         0:00 ora_w001_noctest  oracle 25947     1  0  Jul 25  ?         0:21 oraclenoctest (LOCAL=NO)  oracle 27175     1  0  Jul  1  ?        832:41 ora_smon_noctest  oracle 25945     1  0  Jul 25  ?         0:23 oraclenoctest (LOCAL=NO)  oracle 27157     1  0  Jul  1  ?        70:18 ora_gen0_noctest  oracle 28309     1  0  Jul  1  ?        138:37 ora_smco_noctest  oracle 25924     1  0  Jul 25  ?         0:20 oraclenoctest (LOCAL=NO)  oracle 27169     1  0  Jul  1  ?        134:47 ora_dbw1_noctest  oracle 25953     1  0  Jul 25  ?         0:22 oraclenoctest (LOCAL=NO)  oracle 25951     1  0  Jul 25  ?         0:21 oraclenoctest (LOCAL=NO)  oracle 27159     1  0  Jul  1  ?        69:47 ora_diag_noctest  oracle 27167     1  0  Jul  1  ?        143:05 ora_dbw0_noctest  oracle 27177     1  0  Jul  1  ?        18:26 ora_reco_noctest  oracle 27179     1  0  Jul  1  ?        480:08 ora_mmon_noctest  oracle 27173     1  0  Jul  1  ?        784:26 ora_ckpt_noctest  oracle 25949     1  0  Jul 25  ?         0:20 oraclenoctest (LOCAL=NO)  oracle 27163     1  0  Jul  1  ?        3156:38 ora_dia0_noctest  oracle 27152     1  0  Jul  1  ?        273:40 ora_psp0_noctest  oracle 27039     1  0  Jul  1  ?        649:27 ora_pmon_noctest  oracle 25943     1  0  Jul 25  ?         0:21 oraclenoctest (LOCAL=NO)  oracle 27161     1  0  Jul  1  ?        70:04 ora_dbrm_noctest  oracle 27171     1  0  Jul  1  ?        111:56 ora_lgwr_noctest  oracle 27165     1  0  Jul  1  ?        120:01 ora_mman_noctest  oracle 19773 19349  0 18:33:19 pts/0     0:00 grep noctest $ $ export ORACLE_SID=noctest $   $ sqlplus / as sysdba SQL*Plus: Release 11.2.0.3.0 Production on Wed May 17 18:32:19 2017 Copyright (c) 1982, 2011, Oracle.  All rights reserved. Connected to an idle instance.               <<<<<<< 可以看到,的确实例noctest在运行状态,而且ORACLE_SID也没有大小写问题,结果和客户描述一致。 根据这个信息,我们还无法判断DB是不是在正常状态,于是让客户通过其他客户端sqlplus连接db,发现 的确是成功的,这样就排除了db实例存在问题的可能性,还应该是这个客户端配置问题,于是让客户能重现问题 的情况下提供oracle_home 环境变量和dbs信息: $ ps -ef|grep smon  oracle 15400     1  0  Jun 25  ?        207:54 ora_smon_cdb    grid 15163     1  0  Jun 25  ?        56:01 asm_smon_+ASM  oracle 27175     1  0  Jul  1  ?        833:44 ora_smon_noctest  oracle  6275  6186  0 12:22:11 pts/1     0:00 grep smon    root  6197  1893  0 12:22:00 ?         0:00 sh -c   sleep 15;/etc/opt/resmon/lbin/mon_EMSHAProvider_state.sh $ export ORACLE_SID=noctest $ $ sqlplus / as sysdba SQL*Plus: Release 11.2.0.3.0 Production on Thu May 18 12:22:25 2017 Copyright (c) 1982, 2011, Oracle.  All rights reserved. Connected to an idle instance.         <<<重现问题 SQL> exit Disconnected $ $ env|grep ORACLE_HOME ORACLE_HOME=/opt/app/oracle/product/11.2.0/dbhome_1 $ ls -l $ORACLE_HOME/dbs total 44960 -rw-rw----   1 oracle     asmadmin      1544 Jul  5  2014 hc_cdb.dat -rw-r--r--   1 oracle     oinstall      2851 May 15  2009 init.ora -rw-r-----   1 oracle     oinstall       887 Nov  7  2016 initcdb.ora -rw-r-----   1 oracle     asmadmin        24 Mar 21  2012 lkCDB -rw-r-----   1 oracle     asmadmin      3072 Jun  3  2014 orapwcdb drwx------   2 oracle     asmadmin        96 Mar 21  2012 peshm_DBUA0428007_0 drwx------   2 oracle     asmadmin        96 Mar 21  2012 peshm_DBUA1414357_0 drwx------   2 oracle     asmadmin        96 Mar 21  2012 peshm_DBUA1652091_0 drwx------   2 oracle     asmadmin        96 Mar 21  2012 peshm_DBUA1728950_0 drwx------   2 oracle     asmadmin        96 Mar 21  2012 peshm_DBUA2104902_0 drwx------   2 oracle     asmadmin        96 Mar 21  2012 peshm_DBUA2450035_0 drwx------   2 oracle     oinstall        96 Mar 21  2012 peshm_DBUA2840091_0 drwx------   2 oracle     asmadmin        96 Mar 21  2012 peshm_DBUA4330530_0 drwx------   2 oracle     oinstall        96 Mar 20  2012 peshm_DBUA4544048_0 drwx------   2 oracle     asmadmin        96 Mar 23  2012 peshm_DBUA4711672_0 drwx------   2 oracle     asmadmin        96 Mar 21  2012 peshm_DBUA5842860_0 drwx------   2 oracle     asmadmin     32768 Mar 21  2012 peshm_cdb_0 -rw-r-----   1 oracle     asmadmin   22921216 May 18 07:29 snapcf_cdb.f -rw-r-----   1 oracle     asmadmin      3072 Nov  6  2016 spfilecdb.ora -rw-r-----   1 oracle     asmadmin      3072 Apr  1  2014 spfilecdb.orabak $ 果然发现疑点,当前ORACLE_HOME下的dbs里面并没有noctest实例的spfile文件和init文件。 说明该实例并不是当前ORACLE_HOME下的,那么一定是还有其他home目录,于是让客户提供 如下sqlplus输出: # find / -name sqlplus /opt/grid/app/grid/product/11.2.0/grid/bin/sqlplus /opt/grid/app/grid/product/11.2.0/grid/sqlplus /opt/app/oracle/product/11.2.0/dbhome_1/bin/sqlplus /opt/app/oracle/product/11.2.0/dbhome_1/sqlplus /oracle/u01.bak/app/oracle/product/11.2.0/dbhome_1/bin/sqlplus /oracle/u01.bak/app/oracle/product/11.2.0/dbhome_1/sqlplus /oracle/product/11.2.0/dbhome_1/bin/sqlplus /oracle/product/11.2.0/dbhome_1/sqlplus 果然看到还有其他ORACLE_HOME目录 /oracle/product/11.2.0/dbhome_1 /oracle/u01.bak/app/oracle/product/11.2.0/dbhome_1 于是让客户重新指定对应的ORACLE_HOME再次尝试,问题解决。

客户抱怨实例明明在启动状态,sqlplus 却无法登录db,一直提示 Connected to an idle instance 刚接到这个case,首先怀疑是不是客户搞错了SID大小写,因为没有指定正确的SID就会提示连接空实例的错误, 根据这个先检查一下客户提供的信息: $ ps -ef|grep noctest oracle 27181     1  0  Jul  1  ?       ...

新特性

数据库12.2.0.1新变化Release Updates (Updates)和 Release Update Revisions (Revisions)

从2017年7月开始,Oracle 对数据库和 GI(Grid Infrastructure) 12.2及之后版本的主动修补程序进行了更改。传统的 “Patchset Update” 和“Database Proactive Bundle Patch” 对于12.2数据库将不再发布。将采用新的发布方式 Release Updates (Updates)和 Release Update Revisions (Revisions)。 这个战略的主要目标是双重的: 1. 拥抱一个更加简单的软件发布流程 a. Oracle每年都可以发布一些新特性,而不是像以前一样等很多年 b. Oracle通过减少每次发布的软件的修改来提升数据库的质量 2.可以提供给客户一个更灵活的方式来: a. 在需要时有效的提供 bug 修复(就像 12.1.0.2的DB Proactive BP 目前所提供的) b. 当客户环境稳定时,有效的提供季度安全更新(就像11.2.0.4以及12.1.0.2上的 PSU 目前所提供的) 请注意,本文所述的更改只适用于数据库和 GI(Grid Infrastructure) 12.2及之后版本。数据库12.1和11.2版本仍然使用传统的 PSU/BP 流程以及版本编号系统。 补丁系统的改变 - Release Updates (Updates)和 Release Update Revisions (Revisions) 从计划的2018年的下一个数据库发布(本来预计是12.2.0.2)开始,数据库产品的新版本发布改为每年一次,并且不再发布补丁集。   为了支持与安全相关的修复以及高优先级的非安全修复,将在每年的1月,4月,7月和10月每个季度发布一个 Release Updates (Updates)。 Oracle的季度发布的Updates包含客户最有可能遇到的错误的修复:     查询优化器错误修复,在之前版本的PSU以及BP中并不包含的这些修复被加入到Updates中,但是默认是禁用的。     Updates包含安全相关的补丁。     Updates会经过 广泛的测试,包括功能测试,压力测试,性能测试以及破坏性测试。     及时应用Updates可以降低碰到已知问题的可能性。     Updates在RAC环境下可以使用rolling的方式不停机安装。 除了季度性发布的 Updates, Release Update Revisions (Revisions) 也会每个季度发行,包含对 Updates 的回退修复以及包含最新的安全方面的修复。     在每个Update发布后的六个月内,会有2个针对这个 Update 的 Revisions 。比如, Release.Update.1 和 Release.Update.2,这里"1" 和 "2"代表的是Revision。 图1: 12.2.0.1 数据库版本 - Update/Revision 的命名规则 Release Update - Database <Quarter> Release Update 12.2.0.1.<build-date> Release Update Revision - Database <Quarter> Release Update Revision 12.2.0.1.<build-date>   版本编号的变化 从2018年开始,开始使用一个新的数据库软件版本编号系统。和以往的编号系统(比如12.2.0.2)不同,会使用3个数字编码格式:年.更新.发布 (Year.Update.Revision),比如18.1.0。这样可以清楚的表示:     软件是哪年发布的 (第一个部分)     哪个季节发布的Update (第二个部分)     哪个季节发布的Revision (第三个部分) Figure 2: Release and Update Timeline   在没有先应用对应的Update的情况下,也可以安装这个Update对应的Revision。Revision 包含对 Update 的安全性和回退修复,将 Update 的生命周期延长两个季度,可以让数据库保持最新的安全修复。 客户可以在 Updates 和 Revisions 之间切换。一个简单的公式就是在相同的年度发布的情况下,把目标以及源库的版本号的后两个部分相加。如果目标版本号的后两个部分相加大于源库版本号的后两个部分相加,那么就可以应用目标版本;否则安装会失败。 例 1:     源版本 - 18.2.2     <<<<< 第二部分和第三部分的和是 "4"     目标版本 - 18.5.0     <<<<< 第二部分和第三部分的和是 "5"     结论: 目标版本 "5" 比源版本 "4" 大,所以可以应用目标版本 例 2:     源版本 - 18.2.2     <<<<< 第二部分和第三部分的和是 "4"     目标版本 - 18.3.0     <<<<< 第二部分和第三部分的和是"3"     结论: 目标版本 "3" 比源版本 "4" 小所以不能安装目标版本,会出错   更多常见问题,请参考文档: Release Update Introduction and FAQ  (Doc ID 2285040.1) 关于本文如有问题,可以点击链接到社区进行提问。

从2017年7月开始,Oracle 对数据库和 GI(Grid Infrastructure) 12.2及之后版本的主动修补程序进行了更改。传统的 “Patchset Update” 和“Database Proactive Bundle Patch” 对于12.2数据库将不再发布。将采用新的发布方式 Release Updates (Updates)和 Release Update...

诊断方法

记一次监听异常处理

客户抱怨最近监听经常异常并无法注册服务,导致前台进程连接失败。 根据客户的提到最后一次的大致时间,我们来看一下监听日志情况: [.......] 21-JUN-2017 15:35:14 * (CONNECT_DATA=(CID=(PROGRAM=)(HOST=__jdbc__)(USER=))(SERVER=DEDICATED)(SERVICE_NAME=app2012)) * (ADDRESS=(PROTOCOL=tcp) 21-JUN-2017 15:35:14 * (CONNECT_DATA=(CID=(PROGRAM=)(HOST=__jdbc__)(USER=))(SERVER=DEDICATED)(SERVICE_NAME=app2012)) * (ADDRESS=(PROTOCOL=tcp)(HOST=10.231.3.85)(PORT=57408)) * establish * app2012 * 0 No longer listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=10.231.3.22)(PORT=1521)))      <<<<<< No longer listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=10.231.3.21)(PORT=1521)))      <<<<<< Listener completed notification to CRS on stop                    <<<<< 21-JUN-2017 15:35:14 * (CONNECT_DATA=(CID=(PROGRAM=)(HOST=TRFFAPP2)(USER=oracle))(COMMAND=stop)(ARGUMENTS=64)(SERVICE=LISTENER_TRFFAPP2)(VERSION=169870592)) * stop * 0 21-JUN-2017 15:35:14 * (CONNECT_DATA=(SID=app20122)(CID=(PROGRAM=)(HOST=__jdbc__)(USER=))) * (ADDRESS=(PROTOCOL=tcp)(HOST=10.231.3.58)(PORT=64878)) * establish * app20122 * 0 TNSLSNR for HPUX: Version 10.2.0.5.0 - Production on 21-JUN-2017 15:35:17 Copyright (c) 1991, 2010, Oracle.  All rights reserved. System parameter file is /oracle/app/oracle/product/10.2.0/dbhome_1/network/admin/listener.ora Log messages written to /oracle/app/oracle/product/10.2.0/dbhome_1/network/log/listener_trffapp2.log Trace information written to /oracle/app/oracle/product/10.2.0/dbhome_1/network/trace/listener_trffapp2.trc Trace level is currently 0 Started with pid=2260 Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=10.231.3.22)(PORT=1521))) Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=10.231.3.21)(PORT=1521))) Listener completed notification to CRS on start                  <<<<<< TIMESTAMP * CONNECT DATA [* PROTOCOL INFO] * EVENT [* SID] * RETURN CODE 21-JUN-2017 15:35:17 * (CONNECT_DATA=(CID=(PROGRAM=)(HOST=__jdbc__)(USER=))(SERVER=DEDICATED)(SERVICE_NAME=app2012)) * (ADDRESS=(PROTOCOL=tcp)(HOST=10.231.3.94)(PORT=56715)) * establish * app2012 * 12514 TNS-12514: TNS:listener does not currently know of service requested in connect descriptor    <<<<<<<<< 21-JUN-2017 15:35:17 * (CONNECT_DATA=(CID=(PROGRAM=)(HOST=__jdbc__)(USER=))(SERVER=DEDICATED)(SERVICE_NAME=app2012)) * (ADDRESS=(PROTOCOL=tcp)(HOST=10.231.3.109)(PORT=60547)) * establish * app2012 * 12514   从上面可以看到,21-JUN-2017 15:35:14之前监听一直正常,但是突然日志记录监听不再了No longer listening on:....., 然后是监听通知CRS stop的消息:  Listener completed notification to CRS on stop。 接下来是监听重启的信息:Started with pid=2260 最后是 TNS-12514报错信息,说监听无法处理请求的服务,这也印证了说客户说前台连接不上的说法。 但是这里并没有给出原因为啥监听突然不再了,之前没有任何报错,alert 日志里面也没有任何信息, 那我们就先看一下监听报错时段的请求情况,  147 21-JUN-2017 15:27   127 21-JUN-2017 15:31    95 21-JUN-2017 15:32  1217 21-JUN-2017 15:33   <<<high  1443 21-JUN-2017 15:34   <<<high 12265 21-JUN-2017 15:35   <<issue time  very high 10607 21-JUN-2017 15:36 可以看到出现问题前监听请求量先降低,然后突然升高,出现问题时间点达到最高。 这个看起来更像是前台进程引发了连接风暴,既然新连接这么高,我们在看一下os 层面的情况: 但是因为当时客户并没有部署oswatcher,并且问题已经人为处理完毕,所以让其尽快部署。 过几天之后,问题再次发生,我们看一下这次情况:    608 27-JUN-2017 09:23    333 27-JUN-2017 09:24    809 27-JUN-2017 09:25  <<<<   1306 27-JUN-2017 09:26   <<<<<   1965 27-JUN-2017 09:27   <<<<      4 27-JUN-2017 09:28   1070 27-JUN-2017 09:29   <<<<   1055 27-JUN-2017 09:30   <<< 发生问题前后仍然出现大量新请求,我们看一下os watcher 输出情况: zzz ***Tue Jun 27 09:27:12 EAT 2017         procs           memory                   page                              faults       cpu    r     b     w      avm    free   re   at    pi   po    fr   de    sr     in     sy    cs  us sy id   95    39     0  64868005  88012273    0    0     2    0     0    0     0  94556 519483 34750   8  3 89           <<<<RunQ 95, blockQ 39   95    39     0  64868005  88000105    0    0     0    0     0    0     0  149539 1720220 79082  45  7 48   95    39     0  64868005  87979642    0    0     0    0     0    0     0  147551 1853425 77468  47  5 47 zzz ***Tue Jun 27 09:27:29 EAT 2017         procs           memory                   page                              faults       cpu    r     b     w      avm    free   re   at    pi   po    fr   de    sr     in     sy    cs  us sy id   86    61     0  66285766  87435149    0    0     2    0     0    0     0  94556 519489 34750   8  3 89   86    61     0  66285766  87354916    0    0     0    0     0    0     0  141514 2691511 78742  33  8 59   86    61     0  66285766  87287447    0    0     0    0     0    0     0  142313 2680929 80039  32  9 59 zzz ***Tue Jun 27 09:27:46 EAT 2017         procs           memory                   page                              faults       cpu    r     b     w      avm    free   re   at    pi   po    fr   de    sr     in     sy    cs  us sy id  171    61     0  80397655  86770380    0    0     2    0     0    0     0  94556 519494 34750   8  3 89        <<<RunQ 171, blockQ 61  171    61     0  80397655  86733359    0    0     0    0     0    0     0  153462 2252976 99530  62  8 30  171    61     0  80397655  86709517    0    0     0    0     0    0     0  153881 2250919 97705  59  8 33   当时OS 层面出现大量的RunQ和BlockQ,远超过cpu数量,CRS层面日志也在不断的报警,cpu 使用率过高 ++++++++++++++++engine_A.log 2017/06/27 09:00:30 VCS WARNING V-16-1-50086 CPU usage on trffapp2 is 83% 2017/06/27 09:12:00 VCS INFO V-16-1-50086 CPU usage on trffapp2 is 66% 2017/06/27 09:17:36 VCS INFO V-16-1-50086 CPU usage on trffapp2 is 62% 2017/06/27 09:18:06 VCS WARNING V-16-1-50086 CPU usage on trffapp2 is 80% 2017/06/27 09:20:36 VCS NOTICE V-16-1-50086 CPU usage on trffapp2 is 74% 2017/06/27 09:21:06 VCS CRITICAL V-16-1-50086 CPU usage on trffapp2 is 91% 2017/06/27 09:22:01 VCS ERROR V-16-2-13027 (trffapp2) Resource(CSSD_trapp) - monitor procedure did not complete within the expected time. 显然是OS系统资源利用率突然过高引发了监听异常问题,接下来我们分析一下awr 报告 SQL ordered by Gets 947,020,215 43 22,023,725.93 14.71 33793.03 107433.92 7sgm3npmzvwvj JDBC Thin Client  SELECT * FROM (SELECT pagetabl... 946,702,135 74 12,793,272.09 14.70 37181.04 122613.98 5aqranh8b8hkf JDBC Thin Client  SELECT * FROM (SELECT pagetabl... 475,885,893 33 14,420,784.64 7.39 18047.45 54492.09 50uhrdj7uant0 JDBC Thin Client  SELECT * FROM (SELECT pagetabl... 371,382,132 24 15,474,255.50 5.77 15852.55 48278.23 863b3ba2bx6h2 JDBC Thin Client  SELECT * FROM (SELECT pagetabl... 317,142,383 24 13,214,265.96 4.93 13056.82 43185.59 f4q2kfd3q1uh6 JDBC Thin Client  SELECT * FROM (SELECT pagetabl...   看到排名靠前的sql基本都是一个逻辑,而且前两个SQL的buffer gets异常高,单个进程达到7225GB的读取,ash 显示也有大量的on cpu进程,所以需要优化cpu top排名 靠前的sql可以缓解问题,经过限制这个sql的调用,问题得到缓解,问题没有再次发生。    

客户抱怨最近监听经常异常并无法注册服务,导致前台进程连接失败。 根据客户的提到最后一次的大致时间,我们来看一下监听日志情况: [.......]21-JUN-2017 15:35:14 * (CONNECT_DATA=(CID=(PROGRAM=)(HOST=__jdbc__)(USER=))(SERVER=DEDICATED)(SERVICE_NAME=app2012)) *...

测试案例

关于ORA-01536 报错的几种场景:

我们都知道unix 或linux下都可以限制某个用户使用磁盘空间,避免造成空间占用100%引发系统事故, oracle也可以实现该功能,就是通过指定用户对某些表空间的配额quota来实现的。一旦超过配额上限, 就会报ORA-01536,下面的几个场景就来介绍一下。 场景1:用户quota不足 sqlplus / as sysdba drop user test cascade; create user test identified by abcdefg; alter user test quota 1m on users ; grant create session to test; grant create table to test; 查看配额情况:  select username, tablespace_name,bytes, max_bytes from dba_ts_quotas where username = 'TEST';    USERNAME                 TABLESPACE_NAME                  BYTES  MAX_BYTES ------------------------------------------------------------   TEST                         USERS                                 1048576    1048576  <<1M 插入数据: create table test.test_t as select * from dba_objects ;   * ERROR at line 1: ORA-01536: space quota exceeded for tablespace 'USERS'   上述结果可以看到,因为我们只给了test用户使用users表空间1m的配额, 所以插入大量数据就会报错,因为错误明显,检查dba_ts_quotas就可以解决。 场景2:递归cursor sqlplus / as sysdba grant dba to maob; SQL> select username, tablespace_name,bytes, max_bytes from dba_ts_quotas where username = 'MAOB'; no rows selected 上述可以看到这个视图只能查询到显式赋予配额的用户和大小,我们给maob用户赋予dba之后,在配额表里面是没有任何记录的,这是因为dba的role在起作用, SQL> select * from session_privs WHERE PRIVILEGE LIKE '%UNLIMIT%' ; PRIVILEGE -------------------------------------------------------------------------------- UNLIMITED TABLESPACE 查看当前session 的确是有UNLIMITED的quota的权限的 sqlplus maob/abcdefg create table maob.test_t2  as select * from dba_objects where 1=2; create table test.test_t2  as select * from dba_objects where 1=2; grant all on test.test_t2 to public ; CREATE OR REPLACE TRIGGER maob.test_trg    BEFORE INSERT OR DELETE OR UPDATE    ON maob.test_t2  FOR EACH ROW BEGIN      INSERT INTO test.test_t2(object_id,object_name) values(:new.object_id,:new.object_name);   END; / SQL> insert into maob.test_T2 select * from dba_objects; insert into maob.test_T2 select * from dba_objects                  * ERROR at line 1: ORA-01536: space quota exceeded for tablespace 'USERS' ORA-06512: at "MAOB.TEST_TRG", line 3 ORA-04088: error during execution of trigger 'MAOB.TEST_TRG' 上述可以看到,虽然maob用户是对任何表空间不限制quota的,但是因为trigger的原因, 导致操作了test用户下的表,而test用户是有quota限制的,所以会报错,不过这个根据报错 信息trigger也很容易定位原因。 场景3:错误的使用索引,在其他用户下创建索引   sqlplus maob/abcdefg create table  test_t3  as select * from dba_objects where 1=2; ==在用户test下的索引却指向本用户的表 sqlplus test/abcdefg create index test.i3 on maob.test_t3( object_name,owner,OBJECT_ID,DATA_OBJECT_ID,OBJECT_TYPE,CREATED ) tablespace users; sql>insert into maob.test_T3 select * from dba_objects; SQL> SQL> insert into maob.test_T3 select * from dba_objects; insert into maob.test_T3 select * from dba_objects                  * ERROR at line 1: ORA-01536: space quota exceeded for tablespace 'USERS' 这个报错就会让人很奇怪,因为通常情况下在生产系统上类似test_t3业务表,owner是不会被限制quota的,而且 dba通常进一步检查dba_ts_quotas和系统权限就能很快排除可能性,但是却很容易忽略对象上的索引造成问题, 因为的确很少有人在B用户下建索引却指向A用户的表,往往都是有人错误操作造成的。

我们都知道unix 或linux下都可以限制某个用户使用磁盘空间,避免造成空间占用100%引发系统事故, oracle也可以实现该功能,就是通过指定用户对某些表空间的配额quota来实现的。一旦超过配额上限, 就会报ORA-01536,下面的几个场景就来介绍一下。 场景1:用户quota不足 sqlplus / as sysdba drop user test cascade;create user...

技术共享

奇怪的等待事件“enq: ss - contention”

数据库有时会遇到大量的进程发生'enq: ss - contention'等待,持续5到10分钟,然后自动消失。从字面上看,'SS'是Sort Segment: select * from v$lock_type where type='SS' TYPE       NAME   ID1_TAG     ID2_TAG   IS_USER DESCRIPTION --------------------------- ---------------------------------- -------------------------- -------------------- SS    Sort Segment   tablespace #   dba    NO  Ensures that sort segments created during parallel DML operations aren't prematurely cleaned up 为何大量的进程需要等待Sort Segment enqueue呢? 从ASH的信息看,Sort Segment enqueue的持有者1581也是一个用户进程,他在等待'DFS lock handle' 5931 1 WAITING 1581 2 JDBC Thin Client dfcdxr0v3hn6n DFS lock handle 1128857605 14 2 26522266 147 1370406 N N   1674 1 WAITING 5931 1 JDBC Thin Client dfcdxr0v3hn6n enq: SS - contention 1397948422 6 2 142364 25 147677 N N 1772 1 WAITING 5931 1 JDBC Thin Client dfcdxr0v3hn6n enq: SS - contention 1397948422 6 2 140883 131 3809055 N N 1852 1 WAITING 5931 1 JDBC Thin Client dfcdxr0v3hn6n enq: SS - contention 1397948422 6 2 19434636 102 1265728 N N <=========session 5931 是阻塞者,在等 'DFS lock handle','DFS lock handle'的持有者是节点2上的session 1581 . 从DFS lock handle的P1和P2可以看出他为何申请DFS lock handle, <========DFS lock handle P1=1128857605 P2=14 P3=2 P1 DEC1128857605 =>HEX 43490005 <======CI enqueue P2=14 <===========Release unused space of the sort segments. Handled by SMON 这是一个Cross Instance(CI)请求,请求的目的是释放未使用的sort segments,也就是清理TEMP表空间。 节点2上的session 1581 是DBW0: 2016-12-07 16:27:27 db file parallel write 1581 2 WAITING oracle@gx-db02-p780 (DBW0)   所以,节点1上的应用进程在等节点2上的DBW0清理TEMP表空间。 wait a minute,为何节点1的进程要等节点2的DBW0,他们为什么不请求本地的DBW0? 在RAC中,TEMP表空间是在各个节点间共享的(当然,其他所有的表空间都一样),但是TEMP表空间会在各个节点有缓存,可以通过以下视图查询到TEMP在各个节点的使用情况: select inst_id, tablespace_name, blocks_cached, blocks_used from gv$temp_extent_pool;   如果一个节点缓存的TEMP blocks耗尽,会请求另一个节点释放一些未使用的TEMP给他用,释放的过程中会较长时间等待enq: ss - contention,这是一个正常的行为。 为了避免申请临时空间时较长的等待,可以通过手工方式释放各个节点的cached block。 ALTER SESSION SET events 'immediate trace name drop_segments level tablespace_number+1';  

数据库有时会遇到大量的进程发生'enq: ss - contention'等待,持续5到10分钟,然后自动消失。从字面上看,'SS'是Sort Segment: select * from v$lock_type where type='SS' TYPE       NAME   ID1_TAG     ID2_TAG   IS_USER DESCRIPTION ---------------------...

新特性

自Oracle 12.2始, 可以限制pdb的IO了

从12.2版本开始,Oracle引入了两个参数来限制PDB的磁盘IO量,分别是MAX_IOPS以及MAX_MBPS。 在CDB中存在多个PDB时,如果某一个PDB产生了大量的磁盘IO,那么很可能会影响到其它的PDB。现在可以通过设置MAX_IOPS来限制PDB每秒钟产生的IO请求次数,通过设置MAX_MBPS来限制PDB每秒钟产生多少兆的IO请求。如果同时设置了两个参数,那么两个参数就同时生效。 在不同的级别设置这两个参数会产生不同的效果: 1.    如果只在CDB root里设置这两个参数,那么设置的值就会在所有的PDB中生效。 2.    如果只在application root(这是12.2中的新特性)中设置了这两个参数,那么设置的值就会在所有的application PDB中生效。 3.    如果在CDB root或者PDB level中都设置了这两个参数,那么PDB level设置的值会有更高的优先级。 4.    这两个参数的默认值都是0,也就是默认不限制IO产生的数量。 注意:这两个参数不能设置在non-CDB中;并且只能限制PDB的磁盘IO量,不能限制CDB root的磁盘IO量。 对于PDB的critical IO,比如读写控制文件, 密码文件,重做日志以及DBWR写脏数据,是不受限制的。就算已经达到了上限,这些IO仍能够成功。虽然这些IO操作不受限制,这些IO也会被计算进PDB产生的IO次数及请求中。 在PDB的IO操作超过限制后,相应的Server Process会等待“resmgr: I/O rate limit”等待事件。 注意:虽然等待事件的名字是以resmgr开头的,很类似于resource manager的“resmgr: cpu quantum”等待事件;但是MAX_IOPS和MAX_MBPS并不需要启用resource manager plan。 另外,可以通过查询V$RSRCPDBMETRIC ,V$RSRCPDBMETRIC_HISTORY,DBA_HIST_RSRC_PDB_METRIC相关视图的IOPS, IOMBPS, IOPS_THROTTLE_EXEMPT, IOMBPS_THROTTLE_EXEMPT列来获知PDB的IO指标。 以下是一个真实的测试案列,为了更容易重现场景,我们设置了一个非常小的限制: 1、创建一个包含两个PDB的CDB,PDB的名字分别是PDB1和PDB2: SQL> select con_id, name from v$pdbs;     CON_ID NAME ---------- ----------------------------------------      2 PDB$SEED      3 PDB1      4 PDB2 2、对pdb1限制每秒钟只可以做3次IO SQL> alter session set container = pdb1; Session altered. SQL> alter system set max_iops = 3; System altered. SQL> alter pluggable database pdb1 open; Pluggable database altered. 3、创建一个新用户,并且登录到pdb1上并创建一个大表来产生大量磁盘IO SQL> grant dba to feng identified by feng; Grant succeeded. SQL> conn feng/feng@127.0.0.1/pdb1 Connected. SQL> create table feng.test as select * from dba_source; <…此时HUNG住了…> 4、另外开启一个窗口连入到CDB root中 SQL> select username,state,con_id,event from v$session where con_id=3 and username='FENG'; USER STATE             CON_ID EVENT ---- ------------------- ---------- -------------------------------------------------- FENG WAITING              3 resmgr: I/O rate limit 可以看到那个session正在等待resmgr: I/O rate limit,这就说明了对PDB的IO限制成功生效了。

从12.2版本开始,Oracle引入了两个参数来限制PDB的磁盘IO量,分别是MAX_IOPS以及MAX_MBPS。 在CDB中存在多个PDB时,如果某一个PDB产生了大量的磁盘IO,那么很可能会影响到其它的PDB。现在可以通过设置MAX_IOPS来限制PDB每秒钟产生的IO请求次数,通过设置MAX_MBPS来限制PDB每秒钟产生多少兆的IO请求。如果同时设置了两个参数,那么两个参数就同时生效。 在不...

新特性

自Oracle 12.2始,Active Dataguard也可以支持AWR功能了

自Oracle 12.2始,Active Dataguard也开始支持AWR功能了 在之前的版本里,Active Dataguard不支持AWR report。只能安装standby statspack来监控ADG数据库的性能,而且statspack不支持自动收集;需要手工收集statspack快照,或者自己定义脚本/Job来收集statspack的快照。 从Oracle 12.2开始,通过dblink以及RMF(Remote Management Framework,远程管理架构)技术,ADG也开始支持AWR功能了。 就像上面的示意图所示,主库通过dblink连接到ADG数据库并发起收集AWR快照的动作,之后ADG数据库把AWR快照通过dblink发送到主库存储。主库和ADG库在这里组成一个RMF拓扑结构,ADG库是拓扑结构中的source,而主库则是拓扑结构中的destination。存储在主库中的ADG库的AWR快照被称为remote snapshot。 这是RMF结构的最简单的方式。实际上RMF拓扑可以更复杂;比如存储remote snapshot的destination可以不是主库,而是不相关的另外一个数据库;比如可以有多个source;比如除了destination库之外还可以有candidate destination库,candidate destination库是一个source类型的数据库,但可以在destination库宕掉后替代destination库。 在配置好整个环境后,ADG库就会和主库一样,定期自动生成AWR snapshot并存储到主库中(收集snapshot的指令实际上是从主库发出的)。当然也可以在主库调用DBMS_WORKLOAD_REPOSITORY.CREATE_REMOTE_SNAPSHOT API手工收集。需要生成ADG的AWR report时,在主库上执行@$ORACLE_HOME/rdbms/admin/awrrpti.sql并指定ADG的dbid即可。 不过当Dataguard环境中各个数据库的角色发生改变时(比如发生了switchover),RMF拓扑也需要额外的配置才能让AWR在ADG库上继续工作。 下面我们大概讲一下在ADG环境中部署AWR的过程: 假设我们有两个数据库,R12201是主库,而DG1是对应的ADG库。Dataguard的配置已经完成并且可以正常工作。 1.    在主库上配置sys$umf用户。因为RMF功能需要使用sys$umf用户,而这个用户默认是被锁住的,所以需要先解锁这个用户并且设置密码: SQL> alter user sys$umf account unlock identified by oracle; 2.    创建两个dblink,一个是从主库到ADG库(R12201_TO_DG1),另一个是从ADG库到主库(DG1_TO_R12201)。但因为ADG库是只读的,所以创建dblink的操作都需要在主库运行: SQL> create database link R12201_TO_DG1 connect to sys$umf identified by oracle using 'dg1';  SQL> create database link DG1_TO_R12201 connect to sys$umf identified by oracle using 'r12201'; 3.    等待一段时间,直到前两个步骤的改动都已经同步到ADG库上。 4.    在主库上使用DBMS_UMF配置节点名: SQL> exec dbms_umf.configure_node('R12201'); 5.    在ADG库上使用DBMS_UMF配置节点名: SQL> exec dbms_umf.configure_node('DG1', 'DG1_TO_R12201'); 6.    在主库上配置RMF拓扑TOPOLOGY_ADG并且把ADG库注册到RMF拓扑中: SQL> exec dbms_umf.create_topology('TOPOLOGY_ADG');     SQL> exec dbms_umf.register_node('TOPOLOGY_ADG', 'DG1', 'R12201_TO_DG1', 'DG1_TO_R12201','TRUE','FALSE'); 7.    在主库上执行下面的操作把拓扑的ADG库DG1的AWR service开启: SQL> exec DBMS_WORKLOAD_REPOSITORY.register_remote_database(node_name=>'DG1'); 8.    配置ADG的AWR功能就做完了,可以检查相关视图来验证这个拓扑配置: col topology_name for a20  col node_name for a20  SQL> select * from DBA_UMF_TOPOLOGY; TOPOLOGY_NAME         TARGET_ID TOPOLOGY_VERSION TOPOLOGY -------------------- ---------- ---------------- -------- TOPOLOGY_ADG         3211929203                4 ACTIVE SQL> select * from dba_umf_registration;       TOPOLOGY_NAME        NODE_NAME               NODE_ID  NODE_TYPE AS_SO AS_CA STATE -------------------- -------------------- ---------- ---------- ----- ----- -------------------- TOPOLOGY_ADG         R12201               3211929203          0 FALSE FALSE OK TOPOLOGY_ADG         DG1                  3472153111          0 TRUE  FALSE OK SQL> select * from DBA_UMF_LINK; TOPOLOGY_NAME        FROM_NODE_ID TO_NODE_ID LINK_NAME -------------------- ------------ ------------------------------------------------------------------------------------ TOPOLOGY_ADG           3211929203 3472153111 R12201_TO_DG1 TOPOLOGY_ADG           3472153111 3211929203 DG1_TO_R12201 SQL> select * from DBA_UMF_SERVICE; TOPOLOGY_NAME           NODE_ID SERVICE -------------------- ---------- ------- TOPOLOGY_ADG         3472153111 AWR 9.    这时候每当默认生成AWR snapshot时,主库与ADG库会同时生成。如果要手工生成ADG的AWR快照,可以执行下面的命令(参数值为ADG库的node_id) SQL> exec DBMS_WORKLOAD_REPOSITORY.CREATE_REMOTE_SNAPSHOT(3472153111);  10.    如果要生成ADG库的AWR report,可以执行下面的操作: SQL> @?/rdbms/admin/awrrpti.sql Instances in this Workload Repository schema ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~   DB Id      Inst Num   DB Name      Instance     Host ------------ ---------- ---------    ----------   ------   3472153111     1      R12201       DG1          ol65 * 1154541834     1      R12201       R12201       ol65 Enter value for dbid: Enter value for dbid: 3472153111    <<<此处需要指定DG1的dbid     下面是一个ADG库的AWR report的例子,可以看到数据库的Role为PHYSICAL STANDBY。       结语:Oracle 12.2在Active Dataguard上引入AWR功能,可以让Active dataguard的数据库性能诊断更加轻松可控。

自Oracle 12.2始,Active Dataguard也开始支持AWR功能了 在之前的版本里,Active Dataguard不支持AWR report。只能安装standby statspack来监控ADG数据库的性能,而且statspack不支持自动收集;需要手工收集statspack快照,或者自己定义脚本/Job来收集statspack的快照。从Oracle...

技术共享

RAC ASM到单机ASM的dataguard创建步骤

有客户需要RAC ASM环境到单机ASM环境的创建步骤,由于MOS上的英文note中没有提及对这个过程中可能遇到的问题如何解决,故这里讲全部创建步骤和问题解决记录如下以供参考。  一、环境: 1、Primary 11204两节点rac [oracle@rac11g1 ~]$ cat /etc/hosts # Do not remove the following line, or various programs # that require network functionality will fail. 127.0.0.1       localhost.localdomain localhost ::1             localhost6.localdomain6 localhost6 192.168.56.18   rac11g1.fsm.com rac11g1 192.168.56.19   rac11g2.fsm.com rac11g2 192.168.210.18  rac11g1-priv.fsm.com    rac11g1-priv 192.168.210.19  rac11g2-priv.fsm.com    rac11g2-priv 192.168.56.28   rac11g1-vip.fsm.com     rac11g1-vip 192.168.56.29   rac11g2-vip.fsm.com     rac11g2-vip 192.168.56.8    rac11g-cluster.fsm.com  rac11g-cluster 192.168.56.118  restart.oracle.com      restart [oracle@rac11g1 ~]$ [grid@rac11g1 ~]$ crsctl stat res -t -------------------------------------------------------------------------------- NAME           TARGET  STATE        SERVER                   STATE_DETAILS        -------------------------------------------------------------------------------- Local Resources -------------------------------------------------------------------------------- ora.CRS.dg                ONLINE  ONLINE       rac11g1                                                     ONLINE  ONLINE       rac11g2                                      ora.DATA.dg                ONLINE  ONLINE       rac11g1                                                     ONLINE  ONLINE       rac11g2                                      ora.LISTENER.lsnr                ONLINE  ONLINE       rac11g1                                                     ONLINE  ONLINE       rac11g2                                      ora.asm                ONLINE  ONLINE       rac11g1                  Started                             ONLINE  ONLINE       rac11g2                  Started              ora.gsd                OFFLINE OFFLINE      rac11g1                                                     OFFLINE OFFLINE      rac11g2                                      ora.net1.network                ONLINE  ONLINE       rac11g1                                                     ONLINE  ONLINE       rac11g2                                      ora.ons                ONLINE  ONLINE       rac11g1                                                     ONLINE  ONLINE       rac11g2                                      ora.registry.acfs                ONLINE  ONLINE       rac11g1                                                     ONLINE  ONLINE       rac11g2                                      -------------------------------------------------------------------------------- Cluster Resources -------------------------------------------------------------------------------- ora.LISTENER_SCAN1.lsnr       1        ONLINE  ONLINE       rac11g1                                      ora.cvu       1        ONLINE  ONLINE       rac11g1                                      ora.db11g.db       1        ONLINE  ONLINE       rac11g1                  Open                      2        ONLINE  ONLINE       rac11g2                  Open                ora.oc4j       1        ONLINE  ONLINE       rac11g1                                      ora.rac11g1.vip       1        ONLINE  ONLINE       rac11g1                                      ora.rac11g2.vip       1        ONLINE  ONLINE       rac11g2                                      ora.scan1.vip       1        ONLINE  ONLINE       rac11g1       2、Standby 单节点Oracle Restart环境  -bash-3.2$ cat /etc/hosts # Do not remove the following line, or various programs # that require network functionality will fail. 127.0.0.1               localhost.localdomain localhost ::1             localhost6.localdomain6 localhost6 192.168.56.118  restart.oracle.com      restart 192.168.56.8    rac11g-cluster.fsm.com  rac11g-cluster 192.168.56.28   rac11g1-vip.fsm.com     rac11g1-vip 192.168.56.29   rac11g2-vip.fsm.com     rac11g2-vip   二、配置步骤 1、配置tnsnames,三个主机保持一致: DB11G =   (DESCRIPTION =     (ADDRESS = (PROTOCOL = TCP)(HOST = rac11g-cluster)(PORT = 1521))     (CONNECT_DATA =       (SERVER = DEDICATED)       (SERVICE_NAME = db11g)     )   )   DB11G1 =   (DESCRIPTION =     (ADDRESS = (PROTOCOL = TCP)(HOST = rac11g1-vip)(PORT = 1521))     (CONNECT_DATA =       (SERVER = DEDICATED)       (SERVICE_NAME = db11g)       (instance_name=db11g1)     )   )   DB11G2 =   (DESCRIPTION =     (ADDRESS = (PROTOCOL = TCP)(HOST = rac11g2-vip)(PORT = 1521))     (CONNECT_DATA =       (SERVER = DEDICATED)       (SERVICE_NAME = db11g)       (instance_name=db11g2)     )   )   DB11G_stby =   (DESCRIPTION =     (ADDRESS = (PROTOCOL = TCP)(HOST = restart)(PORT = 1521))     (CONNECT_DATA =       (SERVER = DEDICATED)       (SERVICE_NAME = db11g_stby)     )   ) 2、配置备库静态监听 -bash-3.2$ su - grid Password: -bash-3.2$ which crsctl /u01/app/11.2.0/grid/bin/crsctl -bash-3.2$ vi /u01/app/11.2.0/grid/network/admin/listener.ora # listener.ora Network Configuration File: /u01/app/11.2.0/grid/network/admin/listener.ora # Generated by Oracle configuration tools.   LISTENER =   (DESCRIPTION_LIST =     (DESCRIPTION =       (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))       (ADDRESS = (PROTOCOL = TCP)(HOST = restart.oracle.com)(PORT = 1521))     )   )   SID_LIST_LISTENER=    (SID_LIST=         (SID_DESC=           (GLOBAL_DBNAME=db11g_stby)           (SID_NAME=db11g_stby)           (ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1)         )       )   ADR_BASE_LISTENER = /u01/app/grid   ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER=ON              # line added by Agent <=============注:ORACLE_HOME=一定要写RDBMS home的路径,否则会造成备库sqlplus sys/oracle@db11g_stby as sysdba报错ORA-01017 -bash-3.2$ srvctl stop listener -bash-3.2$ srvctl status listener Listener LISTENER is enabled Listener LISTENER is not running -bash-3.2$ srvctl start listener -bash-3.2$ lsnrctl status   LSNRCTL for Linux: Version 11.2.0.3.0 - Production on 10-JUN-2017 08:34:47   Copyright (c) 1991, 2011, Oracle.  All rights reserved.   Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1521))) STATUS of the LISTENER ------------------------ Alias                     LISTENER Version                   TNSLSNR for Linux: Version 11.2.0.3.0 - Production Start Date                10-JUN-2017 08:34:41 Uptime                    0 days 0 hr. 0 min. 6 sec Trace Level               off Security                  ON: Local OS Authentication SNMP                      OFF Listener Parameter File   /u01/app/11.2.0/grid/network/admin/listener.ora Listener Log File         /u01/app/grid/diag/tnslsnr/restart/listener/alert/log.xml Listening Endpoints Summary...   (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))   (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=restart.oracle.com)(PORT=1521))) Services Summary... Service "db11g_stby" has 1 instance(s).   Instance "db11g_stby", status UNKNOWN, has 1 handler(s) for this service... The command completed successfully -bash-3.2$   3、同步密码文件 [oracle@rac11g1 ~]$ scp /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/orapwdb11g1 restart:/u01/app/oracle/product/11.2.0/dbhome_1/dbs/orapwdb11g_stby oracle@restart's password: orapwdb11g1                                                                                                                                                       100% 1536     1.5KB/s   00:00    [oracle@rac11g1 ~]$   使用密码文件登录主库两节点,发现1成功,2失败: <<<备库 -bash-3.2$ sqlplus sys/oracle@db11g1 as sysdba   SQL*Plus: Release 11.2.0.3.0 Production on Sat Jun 10 08:38:05 2017   Copyright (c) 1982, 2011, Oracle.  All rights reserved.     Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, Real Application Clusters, Automatic Storage Management and OLAP options   SQL> exit Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, Real Application Clusters, Automatic Storage Management and OLAP options -bash-3.2$ sqlplus sys/oracle@db11g2 as sysdba   SQL*Plus: Release 11.2.0.3.0 Production on Sat Jun 10 08:38:10 2017   Copyright (c) 1982, 2011, Oracle.  All rights reserved.   ERROR: ORA-12537: TNS:connection closed     Enter user-name: ^C^[[A <<<主库节点1 [oracle@rac11g1 admin]$ sqlplus sys/oracle@db11g2 as sysdba   SQL*Plus: Release 11.2.0.4.0 Production on Sat Jun 10 08:42:09 2017   Copyright (c) 1982, 2013, Oracle.  All rights reserved.   ERROR: ORA-12537: TNS:connection closed     Enter user-name: ERROR: ORA-01017: invalid username/password; logon denied     Enter user-name: ERROR: ORA-01017: invalid username/password; logon denied     SP2-0157: unable to CONNECT to ORACLE after 3 attempts, exiting SQL*Plus   在节点2使用grid用户访问rdbms的oracle binary文件,发现无权限: [oracle@rac11g2 ~]$ su - grid Password: [grid@rac11g2 ~]$ ls -l /home/oracle/app/oracle/product/11.2.0/dbhome_1/bin/oracle ls: /home/oracle/app/oracle/product/11.2.0/dbhome_1/bin/oracle: Permission denied 但该文件权限没问题: [oracle@rac11g2 ~]$ ls -l $ORACLE_HOME/bin/oracle -rwsr-s--x 1 oracle oinstall 239626943 Mar 19  2016 /home/oracle/app/oracle/product/11.2.0/dbhome_1/bin/oracle 进一步检查发现问题出自底层目录缺少组权限: <<<节点2 [grid@rac11g2 ~]$ ll /home total 16 drwxr-xr-x 3 root   oinstall 4096 Mar 19  2016 11.2.0 drwxr-xr-x 7 grid   oinstall 4096 Mar 19  2016 grid drwx------ 4 oracle oinstall 4096 Jun 10 08:27 oracle 《---- [grid@rac11g2 ~]$ su - oracle <<<节点1 [grid@rac11g1 ~]$ ll /home total 16 drwxr-xr-x 3 root   oinstall 4096 Mar 19  2016 11.2.0 drwxr-xr-x 7 grid   oinstall 4096 Mar 19  2016 grid drwxr-xr-x 5 oracle oinstall 4096 Mar 19  2016 oracle [grid@rac11g1 ~]$   参照节点1权限进行授权后,问题解决: [oracle@rac11g2 ~]$ chmod 755 /home/oracle [oracle@rac11g2 ~]$ ll /home total 16 drwxr-xr-x 3 root   oinstall 4096 Mar 19  2016 11.2.0 drwxr-xr-x 7 grid   oinstall 4096 Mar 19  2016 grid drwxr-xr-x 4 oracle oinstall 4096 Jun 10 08:27 oracle [oracle@rac11g2 ~]$ exit logout [grid@rac11g2 ~]$ ls -l /home/oracle/app/oracle/product/11.2.0/dbhome_1/bin/oracle -rwsr-s--x 1 oracle oinstall 239626943 Mar 19  2016 /home/oracle/app/oracle/product/11.2.0/dbhome_1/bin/oracle [grid@rac11g2 ~]$ <<<备库 -bash-3.2$ sqlplus sys/oracle@db11g as sysdba   SQL*Plus: Release 11.2.0.3.0 Production on Sat Jun 10 09:04:10 2017   Copyright (c) 1982, 2011, Oracle.  All rights reserved.     Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, Real Application Clusters, Automatic Storage Management and OLAP options   SQL> -bash-3.2$ sqlplus sys/oracle@db11g1 as sysdba   SQL*Plus: Release 11.2.0.3.0 Production on Sat Jun 10 09:04:40 2017   Copyright (c) 1982, 2011, Oracle.  All rights reserved.     Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, Real Application Clusters, Automatic Storage Management and OLAP options   SQL> exit Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, Real Application Clusters, Automatic Storage Management and OLAP options -bash-3.2$ sqlplus sys/oracle@db11g2 as sysdba   SQL*Plus: Release 11.2.0.3.0 Production on Sat Jun 10 09:04:45 2017   Copyright (c) 1982, 2011, Oracle.  All rights reserved.     Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, Real Application Clusters, Automatic Storage Management and OLAP options   SQL> exit Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, Real Application Clusters, Automatic Storage Management and OLAP options [oracle@rac11g1 ~]$ sqlplus sys/oracle@db11g_stby as sysdba   SQL*Plus: Release 11.2.0.4.0 Production on Sat Jun 10 11:28:39 2017   Copyright (c) 1982, 2013, Oracle.  All rights reserved.     Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production With the Partitioning, Automatic Storage Management, OLAP, Data Mining and Real Application Testing options   SQL>      4、创建standby controlfile,并拷贝到备库 [oracle@rac11g1 admin]$ sqlplus / as sysdba   SQL*Plus: Release 11.2.0.4.0 Production on Sat Jun 10 09:08:09 2017   Copyright (c) 1982, 2013, Oracle.  All rights reserved.     Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, Real Application Clusters, Automatic Storage Management and OLAP options   SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/standbyctl.ctl';   Database altered.   SQL> exit Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, Real Application Clusters, Automatic Storage Management and OLAP options [oracle@rac11g1 admin]$ scp /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/standbyctl.ctl restart:/u01/app/oracle/product/11.2.0/dbhome_1/dbs oracle@restart's password: standbyctl.ctl                                                                                                                                                    100%   18MB  17.6MB/s   00:01    [oracle@rac11g1 admin]$   5、创建备库的pfile 在主库spfile的基础上修改出备库的pfile: SQL> create pfile='/home/oracle/pfile.txt' from spfile;   File created. vi /home/oracle/pfile.txt *.audit_file_dest='/home/oracle/app/oracle/admin/db11g_stby/adump' *.audit_trail='db' *.cluster_database=false *.control_files='/u01/app/oracle/product/11.2.0/dbhome_1/dbs/standbyctl.ctl ' *.db_block_size=8192 *.db_create_file_dest='+DATA' *.db_domain='' *.db_name='db11g' *.db_unique_name='db11g_stby' *.diagnostic_dest='/u01/app/oracle' *.log_archive_dest_1='LOCATION=+DATA' *.memory_target=838860800 *.open_cursors=300 *.processes=150 *.remote_login_passwordfile='exclusive' *.thread=1 *.undo_tablespace='UNDOTBS1' *.standby_file_management='AUTO' *.fal_server='db11g1','db11g2' *.log_archive_config='DG_CONFIG=(db11g,db11g_stby)' *.log_archive_dest_2='SERVICE=db11g NOAFFIRM ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=db11g' *.log_archive_dest_state_2='ENABLE' *.fal_client='dg_stby' *.db_file_name_convert='+DATA/db11g','+DATA/db11g_stby' *.log_file_name_convert='+DATA/db11g','+DATA/db11g_stby'   保存pfile到备库,并使用它创建备库的spfile,创建audit目录并启动实例到nomount状态: -bash-3.2$ export ORACLE_SID=db11g_stby -bash-3.2$ sqlplus / as sysdba   SQL*Plus: Release 11.2.0.3.0 Production on Sat Jun 10 10:20:35 2017   Copyright (c) 1982, 2011, Oracle.  All rights reserved.   Connected to an idle instance.   SQL> create spfile from pfile='/u01/app/oracle/pfile.txt';   File created.   SQL> !mkdir -p /home/oracle/app/oracle/admin/db11g_stby/adump SQL> startup nomount; ORACLE instance started.   Total System Global Area  835104768 bytes Fixed Size                  2232960 bytes Variable Size             490737024 bytes Database Buffers          339738624 bytes Redo Buffers                2396160 bytes SQL>   6、duplicate备库 在主库上: [oracle@rac11g1 ~]$ export ORACLE_SID=db11g1 [oracle@rac11g1 ~]$ rman target / auxiliary sys/oracle@db11g_stby   Recovery Manager: Release 11.2.0.4.0 - Production on Sat Jun 10 11:31:45 2017   Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.   connected to target database: DB11G (DBID=376554982) PL/SQL package SYS.DBMS_BACKUP_RESTORE version 11.02.00.03 in AUXILIARY database is not current PL/SQL package SYS.DBMS_RCVMAN version 11.02.00.03 in AUXILIARY database is not current connected to auxiliary database: DB11G (not mounted)   RMAN> duplicate target database for standby from active database nofilenamecheck dorecover;   Starting Duplicate Db at 10-JUN-17 using target database control file instead of recovery catalog allocated channel: ORA_AUX_DISK_1 channel ORA_AUX_DISK_1: SID=24 device type=DISK   contents of Memory Script: {    backup as copy reuse    targetfile  '/home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/orapwdb11g1' auxiliary format  '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/orapwdb11g_stby'   ; } executing Memory Script   Starting backup at 10-JUN-17 allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=34 instance=db11g1 device type=DISK Finished backup at 10-JUN-17   contents of Memory Script: {    backup as copy current controlfile for standby auxiliary format  '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/standbyctl.ctl '; } executing Memory Script   Starting backup at 10-JUN-17 using channel ORA_DISK_1 channel ORA_DISK_1: starting datafile copy copying standby control file output file name=/home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/snapcf_db11g1.f tag=TAG20170610T113324 RECID=2 STAMP=946294405 channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:03 Finished backup at 10-JUN-17   contents of Memory Script: {    sql clone 'alter database mount standby database'; } executing Memory Script   sql statement: alter database mount standby database RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of Duplicate Db command at 06/10/2017 11:33:29 RMAN-05501: aborting duplication of target database RMAN-03015: error occurred in stored script Memory Script RMAN-03009: failure of sql command on clone_default channel at 06/10/2017 11:33:29 RMAN-11003: failure during parse/execution of SQL statement: alter database mount standby database ORA-00201: control file version 11.2.0.4.0 incompatible with ORACLE version 11.2.0.0.0 ORA-00202: control file: '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/standbyctl.ctl '   RMAN> <===========这里证明了11204对11203无法做dataguard,data guard是不能跨版本的(物理备库转成逻辑备库后可用于滚动升级) 。 升级备库的GI和rdbms到11204版本后,上述问题消失: <<<备库 SQL> alter system set compatible='11.2.0.4.0' scope=spfile;   System altered.   SQL> shutdown immediate startup noORA-01507: database not mounted     mount ORACLE instance shut down. SQL> ORACLE instance started.   Total System Global Area  835104768 bytes Fixed Size                  2257840 bytes Variable Size             490736720 bytes Database Buffers          339738624 bytes Redo Buffers                2371584 bytes SQL>   <<<主库 [oracle@rac11g1 ~]$ rman target / auxiliary sys/oracle@db11g_stby   Recovery Manager: Release 11.2.0.4.0 - Production on Sat Jun 10 14:09:15 2017   Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.   connected to target database: DB11G (DBID=376554982) connected to auxiliary database: DB11G (not mounted)   RMAN> duplicate target database for standby from active database nofilenamecheck dorecover;   Starting Duplicate Db at 10-JUN-17 using target database control file instead of recovery catalog allocated channel: ORA_AUX_DISK_1 channel ORA_AUX_DISK_1: SID=25 device type=DISK   contents of Memory Script: {    backup as copy reuse    targetfile  '/home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/orapwdb11g1' auxiliary format  '/u01/app/oracle/product/11.2.0/dbhome_2/dbs/orapwdb11g_stby'   ; } executing Memory Script   Starting backup at 10-JUN-17 allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=34 instance=db11g1 device type=DISK Finished backup at 10-JUN-17   contents of Memory Script: {    backup as copy current controlfile for standby auxiliary format  '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/standbyctl.ctl '; } executing Memory Script   Starting backup at 10-JUN-17 using channel ORA_DISK_1 channel ORA_DISK_1: starting datafile copy copying standby control file output file name=/home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/snapcf_db11g1.f tag=TAG20170610T140924 RECID=4 STAMP=946303765 channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:03 Finished backup at 10-JUN-17   contents of Memory Script: {    sql clone 'alter database mount standby database'; } executing Memory Script   sql statement: alter database mount standby database RMAN-05529: WARNING: DB_FILE_NAME_CONVERT resulted in invalid ASM names; names changed to disk group only.   contents of Memory Script: {    set newname for tempfile  1 to  "+data";    switch clone tempfile all;    set newname for datafile  1 to  "+data";    set newname for datafile  2 to  "+data";    set newname for datafile  3 to  "+data";    set newname for datafile  4 to  "+data";    set newname for datafile  5 to  "+data";    backup as copy reuse    datafile  1 auxiliary format  "+data"   datafile  2 auxiliary format  "+data"   datafile  3 auxiliary format  "+data"   datafile  4 auxiliary format  "+data"   datafile  5 auxiliary format  "+data"   ;    sql 'alter system archive log current'; } executing Memory Script   executing command: SET NEWNAME   renamed tempfile 1 to +data in control file   executing command: SET NEWNAME   executing command: SET NEWNAME   executing command: SET NEWNAME   executing command: SET NEWNAME   executing command: SET NEWNAME   Starting backup at 10-JUN-17 using channel ORA_DISK_1 channel ORA_DISK_1: starting datafile copy input datafile file number=00001 name=+DATA/db11g/datafile/system.256.906885291 output file name=+DATA/db11g_stby/datafile/system.260.946303775 tag=TAG20170610T140935 channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:25 channel ORA_DISK_1: starting datafile copy input datafile file number=00002 name=+DATA/db11g/datafile/sysaux.257.906885293 output file name=+DATA/db11g_stby/datafile/sysaux.265.946303801 tag=TAG20170610T140935 channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:15 channel ORA_DISK_1: starting datafile copy input datafile file number=00003 name=+DATA/db11g/datafile/undotbs1.258.906885293 output file name=+DATA/db11g_stby/datafile/undotbs1.264.946303817 tag=TAG20170610T140935 channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:03 channel ORA_DISK_1: starting datafile copy input datafile file number=00005 name=+DATA/db11g/datafile/undotbs2.264.906885597 output file name=+DATA/db11g_stby/datafile/undotbs2.263.946303819 tag=TAG20170610T140935 channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01 channel ORA_DISK_1: starting datafile copy input datafile file number=00004 name=+DATA/db11g/datafile/users.259.906885293 output file name=+DATA/db11g_stby/datafile/users.262.946303821 tag=TAG20170610T140935 channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01 Finished backup at 10-JUN-17   sql statement: alter system archive log current   contents of Memory Script: {    backup as copy reuse    archivelog like  "+DATA/db11g/archivelog/2017_06_10/thread_1_seq_9.273.946303823" auxiliary format  "+DATA"   archivelog like  "+DATA/db11g/archivelog/2017_06_10/thread_1_seq_7.270.946297317" auxiliary format  "+DATA"   archivelog like  "+DATA/db11g/archivelog/2017_06_10/thread_1_seq_8.272.946302773" auxiliary format  "+DATA"   archivelog like  "+DATA/db11g/archivelog/2017_06_10/thread_2_seq_5.274.946303823" auxiliary format  "+DATA"   ;    catalog clone start with  "+DATA";    switch clone datafile all; } executing Memory Script   Starting backup at 10-JUN-17 using channel ORA_DISK_1 channel ORA_DISK_1: starting archived log copy input archived log thread=1 sequence=9 RECID=7 STAMP=946303824 output file name=+DATA/db11g_stby/archivelog/2017_06_10/thread_1_seq_9.261.946303825 RECID=0 STAMP=0 channel ORA_DISK_1: archived log copy complete, elapsed time: 00:00:01 channel ORA_DISK_1: starting archived log copy input archived log thread=1 sequence=7 RECID=4 STAMP=946297316 output file name=+DATA/db11g_stby/archivelog/2017_06_10/thread_1_seq_7.259.946303827 RECID=0 STAMP=0 channel ORA_DISK_1: archived log copy complete, elapsed time: 00:00:01 channel ORA_DISK_1: starting archived log copy input archived log thread=1 sequence=8 RECID=6 STAMP=946302773 output file name=+DATA/db11g_stby/archivelog/2017_06_10/thread_1_seq_8.258.946303827 RECID=0 STAMP=0 channel ORA_DISK_1: archived log copy complete, elapsed time: 00:00:01 channel ORA_DISK_1: starting archived log copy input archived log thread=2 sequence=5 RECID=8 STAMP=946303824 output file name=+DATA/db11g_stby/archivelog/2017_06_10/thread_2_seq_5.257.946303829 RECID=0 STAMP=0 channel ORA_DISK_1: archived log copy complete, elapsed time: 00:00:01 Finished backup at 10-JUN-17   searching for all files that match the pattern +DATA   List of Files Unknown to the Database ===================================== File Name: +data/DB11G_STBY/ARCHIVELOG/2017_06_10/thread_1_seq_9.261.946303825 File Name: +data/DB11G_STBY/ARCHIVELOG/2017_06_10/thread_1_seq_7.259.946303827 File Name: +data/DB11G_STBY/ARCHIVELOG/2017_06_10/thread_1_seq_8.258.946303827 File Name: +data/DB11G_STBY/ARCHIVELOG/2017_06_10/thread_2_seq_5.257.946303829 File Name: +data/DB11G_STBY/DATAFILE/SYSTEM.260.946303775 File Name: +data/DB11G_STBY/DATAFILE/SYSAUX.265.946303801 File Name: +data/DB11G_STBY/DATAFILE/UNDOTBS1.264.946303817 File Name: +data/DB11G_STBY/DATAFILE/UNDOTBS2.263.946303819 File Name: +data/DB11G_STBY/DATAFILE/USERS.262.946303821 File Name: +data/ASM/ASMPARAMETERFILE/REGISTRY.253.904020973 cataloging files... cataloging done   List of Cataloged Files ======================= File Name: +data/DB11G_STBY/ARCHIVELOG/2017_06_10/thread_1_seq_9.261.946303825 File Name: +data/DB11G_STBY/ARCHIVELOG/2017_06_10/thread_1_seq_7.259.946303827 File Name: +data/DB11G_STBY/ARCHIVELOG/2017_06_10/thread_1_seq_8.258.946303827 File Name: +data/DB11G_STBY/ARCHIVELOG/2017_06_10/thread_2_seq_5.257.946303829 File Name: +data/DB11G_STBY/DATAFILE/SYSTEM.260.946303775 File Name: +data/DB11G_STBY/DATAFILE/SYSAUX.265.946303801 File Name: +data/DB11G_STBY/DATAFILE/UNDOTBS1.264.946303817 File Name: +data/DB11G_STBY/DATAFILE/UNDOTBS2.263.946303819 File Name: +data/DB11G_STBY/DATAFILE/USERS.262.946303821   List of Files Which Where Not Cataloged ======================================= File Name: +data/ASM/ASMPARAMETERFILE/REGISTRY.253.904020973   RMAN-07518: Reason: Foreign database file DBID: 0  Database Name:   datafile 1 switched to datafile copy input datafile copy RECID=9 STAMP=946303830 file name=+DATA/db11g_stby/datafile/system.260.946303775 datafile 2 switched to datafile copy input datafile copy RECID=10 STAMP=946303830 file name=+DATA/db11g_stby/datafile/sysaux.265.946303801 datafile 3 switched to datafile copy input datafile copy RECID=11 STAMP=946303830 file name=+DATA/db11g_stby/datafile/undotbs1.264.946303817 datafile 4 switched to datafile copy input datafile copy RECID=12 STAMP=946303830 file name=+DATA/db11g_stby/datafile/users.262.946303821 datafile 5 switched to datafile copy input datafile copy RECID=13 STAMP=946303830 file name=+DATA/db11g_stby/datafile/undotbs2.263.946303819   contents of Memory Script: {    set until scn  1105997;    recover    standby    clone database     delete archivelog    ; } executing Memory Script   executing command: SET until clause   Starting recover at 10-JUN-17 using channel ORA_AUX_DISK_1   starting media recovery   archived log for thread 1 with sequence 9 is already on disk as file +DATA/db11g_stby/archivelog/2017_06_10/thread_1_seq_9.261.946303825 archived log for thread 2 with sequence 5 is already on disk as file +DATA/db11g_stby/archivelog/2017_06_10/thread_2_seq_5.257.946303829 archived log file name=+DATA/db11g_stby/archivelog/2017_06_10/thread_1_seq_9.261.946303825 thread=1 sequence=9 archived log file name=+DATA/db11g_stby/archivelog/2017_06_10/thread_2_seq_5.257.946303829 thread=2 sequence=5 media recovery complete, elapsed time: 00:00:00 Finished recover at 10-JUN-17 Finished Duplicate Db at 10-JUN-17   RMAN>   7、恢复备库控制文件到ASM <<<备库 SQL> show parameter control   NAME                                 TYPE        VALUE ------------------------------------ ----------- ------------------------------ control_file_record_keep_time        integer     7 control_files                        string      /u01/app/oracle/product/11.2.0                                                  /dbhome_1/dbs/standbyctl.ctl control_management_pack_access       string      DIAGNOSTIC+TUNING SQL> alter system set control_files='+DATA' scope=spfile;   System altered.   SQL> shutdown immediate ORA-01109: database not open     Database dismounted. ORACLE instance shut down. SQL> startup nomount; ORACLE instance started.   Total System Global Area  835104768 bytes Fixed Size                  2257840 bytes Variable Size             490736720 bytes Database Buffers          339738624 bytes Redo Buffers                2371584 bytes SQL> exit Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options -bash-3.2$ rman target /   Recovery Manager: Release 11.2.0.4.0 - Production on Sat Jun 10 14:23:17 2017   Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.   connected to target database: DB11G (not mounted)   RMAN> restore controlfile from '/u01/app/oracle/product/11.2.0/dbhome_2/dbs/standbyctl.ctl';   Starting restore at 10-JUN-2017 14:23:40 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=24 device type=DISK   channel ORA_DISK_1: copied control file copy output file name=+DATA/db11g_stby/controlfile/current.269.946304621 Finished restore at 10-JUN-2017 14:23:42   RMAN>   8、配置主库参数 [oracle@rac11g1 ~]$ sqlplus / as sysdba   SQL*Plus: Release 11.2.0.4.0 Production on Sat Jun 10 14:31:22 2017   Copyright (c) 1982, 2013, Oracle.  All rights reserved.     Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, Real Application Clusters, Automatic Storage Management and OLAP options   SQL> ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(db11g,db11g_stby)'; ALTER DATABASE FORCE LOGGING; ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=db11g_stby NOAFFIRM ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=db11g_stby'; ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE; ALTER SYSTEM SET FAL_SERVER=db11g_stby; alter system set STANDBY_FILE_MANAGEMENT=auto;   ALTER SYSTEM SET FAL_CLIENT=db11g1 sid='db11g1'; ALTER SYSTEM SET FAL_CLIENT=db11g2 sid='db11g2'; System altered.   SQL> Database altered.   SQL>       System altered.   SQL> System altered.   SQL> System altered.   SQL> System altered.   SQL> SQL> System altered.   SQL> System altered. SQL> select  FORCE_LOGGING from gv$database;   FOR --- YES YES   9、在主备库创建standby log file <<<主库 SQL> alter database add standby logfile thread 1 group 5 '+DATA' size 50m; alter database add standby logfile thread 2 group 6 '+DATA' size 50m; alter database add standby logfile thread 1 group 7 '+DATA' size 50m; alter database add standby logfile thread 2 group 8 '+DATA' size 50m; Database altered.   SQL> Database altered.   SQL> Database altered.   SQL>   Database altered.   SQL> <<<备库  SQL> alter database add standby logfile thread 1 group 5 '+DATA' size 50m; alter database add standby logfile thread 2 group 5 '+DATA' size 50m; Database altered. SQL> alter database add standby logfile thread 2 group 6 '+DATA' size 50m; alter database add standby logfile thread 1 group 7 '+DATA' size 50m; alter database add standby logfile thread 2 group 8 '+DATA' size 50m; Database altered.   SQL> Database altered.   SQL>   Database altered.   SQL>   10、将备库置于active dataguard模式下 <<<备库 SQL> alter database recover managed standby database using current logfile disconnect from session;   Database altered.   SQL>   11、添加备库资源到OCR -bash-3.2$ srvctl add database -d db11g_stby -o /u01/app/oracle/product/11.2.0/dbhome_2 -p /u01/app/oracle/product/11.2.0/dbhome_2/dbs/spfiledb11g_stby.ora -bash-3.2$   12、检查主备库状态 <<<备库 SQL>  select process,status,sequence#,thread# from v$managed_standby; PROCESS   STATUS        SEQUENCE#    THREAD# --------- ------------ ---------- ---------- ARCH      CONNECTED             0          0 ARCH      CONNECTED             0          0 ARCH      CLOSING              30          1 ARCH      CONNECTED             0          0 RFS       IDLE                  0          0 RFS       IDLE                 31          1 RFS       IDLE                  0          0 MRP0      APPLYING_LOG         31          1 8 rows selected. SQL> SELECT 'Last Applied : ' Logs,   2  TO_CHAR(next_time,'DD-MON-YY:HH24:MI:SS') TIME,thread#,sequence#   3  FROM v$archived_log   4  WHERE sequence# =   5  (SELECT MAX(sequence#) FROM v$archived_log WHERE applied='YES'   6  )   7  UNION   8  SELECT 'Last Received : ' Logs,   9  TO_CHAR(next_time,'DD-MON-YY:HH24:MI:SS') TIME,thread#,sequence#  10  FROM v$archived_log  11  WHERE sequence# =  12  (SELECT MAX(sequence#) FROM v$archived_log ); LOGS             TIME                     THREAD#  SEQUENCE# ---------------- --------------------- ---------- ---------- Last Applied :   12-JUN-17:13:55:06             1         29 Last Received :  12-JUN-17:14:00:18             1         30 <<<主库 SQL> SELECT   2   (SELECT name FROM V$DATABASE   3   ) name,   4   (SELECT MAX (sequence#) FROM v$archived_log WHERE dest_id = 1   5   ) Current_primary_seq,   6   (SELECT MAX (sequence#)   7   FROM v$archived_log   8   WHERE TRUNC(next_time) > SYSDATE - 1   9   AND dest_id = 2  10   ) max_stby,  11   (SELECT NVL (  12   (SELECT MAX (sequence#) - MIN (sequence#)  13   FROM v$archived_log  14   WHERE TRUNC(next_time) > SYSDATE - 1  15   AND dest_id = 2  16   AND applied = 'NO'  17   ), 0)  18   FROM DUAL  19   ) "To be applied",  20   (  21   (SELECT MAX (sequence#) FROM v$archived_log WHERE dest_id = 1  22   ) -  23   (SELECT MAX (sequence#) FROM v$archived_log WHERE dest_id = 2  24   )) "To be Shipped"  25  FROM DUAL; NAME      CURRENT_PRIMARY_SEQ   MAX_STBY To be applied To be Shipped --------- ------------------- ---------- ------------- ------------- DB11G                      30         30             0             0

有客户需要RAC ASM环境到单机ASM环境的创建步骤,由于MOS上的英文note中没有提及对这个过程中可能遇到的问题如何解决,故这里讲全部创建步骤和问题解决记录如下以供参考。  一、环境: 1、Primary 11204两节点rac [oracle@rac11g1 ~]$ cat /etc/hosts # Do not remove the following line, or various...

其他

如何将文件上传到Oracle MOS系统

下面的方法可以根据文件大小,将文件上传到Oracle MOS系统。 MY ORACLE SUPPORT (MOS)方式 - 最大2GB FTPS和HTTPS方式上传文件到MOS - 最大200 GB 下面举例演示一下如何在Linux服务器通过FTPS命令上传比较大的文件到MOS的SR。 FTPS上传文件到SR的命令: $curl -k -T <path_to_file> -u "<user>" ftps://transport.oracle.com/issue/<sr_number>/ 注意: 这里的“<path_to_file>”,是文件的绝对路径和文件名称,如果文件在当前路径,可以直接使用文件名称。 比如: /home/temp/test.zip 或 test.zip都是可以的 这里的“<user>”,是MOS用户账号,比如:a.b@c.com 这里的“<sr_number>”,只包括SR号码,而不包括“<>”,并确保包含最后的“/” FTPS上传文件到SR的示例: $ ls -lt FTPS_test.zip -rw-r----- 1 oracle dba 5001715712 Mar 13 00:03 FTPS_test.zip $curl -k -T FTPS_test.zip -u "a.b@c.com" ftps://transport.oracle.com/issue/3-25888888888/ Enter host password for user 'a.b@c.com': 输入正确的MOS用户的密码,就开始传输文件了。 文件传输完毕,会在对应的SR显示文件上传成功。例如: "Upload to TDS successful for the fileFTPS_test.zip." 如果SR号码错误,会提示下面的错误信息: curl: (9) Couldn't cd to 3-25888888888 更多详情,可以参阅下面2个MOS文档: How to Upload Files to Oracle Support (Doc ID 1547088.2) How to Send a File to Oracle Support Using FTPS (Doc ID 464666.1)

下面的方法可以根据文件大小,将文件上传到Oracle MOS系统。 MY ORACLE SUPPORT (MOS)方式 - 最大2GB FTPS和HTTPS方式上传文件到MOS - 最大200 GB 下面举例演示一下如何在Linux服务器通过FTPS命令上传比较大的文件到MOS的SR。 FTPS上传文件到SR的命令: $curl -k -T <path_to_file>...

新特性

GI 中新的基础架构 --MDNS, gipc 和 gpnp 是如何协同工作的

  最近一直有朋友来询问oracle 的集群管理软件从11.2 这个版本开始开始出现的新的组件mdns, gpic, 和gpnp 是做什么的,以及他们是如何协调工作的。所以就花了时间写了这篇文章来解释一下这些新组件的基本功能和它们之间是如何协同工作的。   首先来回顾一下历史。对于10g版本的oracle 集群管理软件(CRS),当集群启动的时候,集群节点的列表和每个节点的公网地址,私网地址是可以从OCR当中获得的,而且如果集群包含多块私有网卡的话,是需要依赖于OS层面的网卡绑定软件(例如:linux 的bonding)的,也就是说集群的私网网卡数量是对CRS透明的,集群只需要知道经过聚合之后的网卡名称就可以了。   但是,在11.2 这个版本开始,oracle的集群管理软件(GI)开始需要自己来管理集的网卡,也就是说GI要能够管理多块私网网卡;另外,由于集群启动的流程发生了改变,OLR的出现改变了11.2 集群启动的行为,OCR在集群最初启动时不再被使用了,而完全变成了集群应用资源层的一个注册表(registry)。所以,就需要一些组件来完成节点发现,集群节点列表构建的工作(这部分信息在10.2中都是在OCR中写好的)。所以,就出现了: 1. mdns:这个组件以mdmsd.bin 的方式出现,他负责在集群启动时找到本地节点集群需要使用的所有网卡,以便为节点发现提供基本的网络通信功能。 2. gpnpd:这个组件以gpnpd.bin 的方式出现,它通过维护gpnpd profile 的方式把构建集群所需要的核心信息在节点之间进行同步。当然,这种信息同步的过程是需要借助mdns来实现的。具体说,gpnpd再启动之后会: 步骤1:读取本地的gpnp profile得到构建集群的核心信息。 步骤2:和mdns进行通行,通过mdns发现的网卡向网络中发送消息,找到集群中的其他节点。 步骤3:和其他的节点建立链接,同步彼此的gpnp profile 文件。     注意:详细的gpnpd 的功能,请参考之前的文章 “11gR2新特性---Gpnp守护进程“。当gpnp 正常启动成功之后,实际上节点发现,集群节点列表构建的工作就结束了。    3.gipc:这部分功能是以gipcd.bin 的方式出现的,它负责管理集群中节点的私网网卡。并建立节点和节点之间通过私网的点对点通信。它相当于gpnp 的一个重要客户,因为集群的核心信息是要通过gpnp来提供的。关于gipc的详细功能,请参考我之前的文章“11gR2新特性---gipc守护进程”。   通过上面的三个组件,就可以完成节点发现,集群节点列表构建的工作,以及管理节点私有网络的工作。而这种设计的另外一个好处在于,它能够使集群的结构更加的灵活和有弹性。如果简单的解释着三个组件的关系的话,可以认为,mdns 为gpnp 提供了网络通信服务, gpnp相当于mdns的客户;gpnp相当于集群的其他上层资源的一个服务组件,它能够向集群的其它组件提供集群的基本核心信息。gipc相当于gpnpd的一个重要客户,它负责管理集群节点的私有网络。   望这篇文章对于大家理解这三个11.2新出现的组件有所帮助。

  最近一直有朋友来询问oracle 的集群管理软件从11.2 这个版本开始开始出现的新的组件mdns, gpic, 和gpnp 是做什么的,以及他们是如何协调工作的。所以就花了时间写了这篇文章来解释一下这些新组件的基本功能和它们之间是如何协同工作的。   首先来回顾一下历史。对于10g版本的oracle 集群管理软件(CRS),当集群启动的时候,集群节点的列表和每个节点的公网地址,私网地址是可以从O...

诊断方法

回收站对象过多造成查询dba_free_space缓慢

日常监控免不了监控表空间空闲信息,但是有时发现查询他非常缓慢,这是因为dba_free_space 里面条目过多,所以查询起来非常缓慢,为啥这个view里面条目如此 之多呢,有时候会发现里面的extent居然还是连续的, 其实这是因为drop 对象造成的,下面的例子可以展示一下这个场景: create table t1 as select * from dba_tables where rownum<1000; create table t2 as select * from dba_tables where rownum<1000;  分别新建两个表,然后查询他们的extent情况 select * from dba_extents where segment_NAME IN ('T1','T2') MAOB T1  TABLE USERS 0 4 520 65536 8 4 MAOB T1  TABLE USERS 1 4 528 65536 8 4 MAOB T1  TABLE USERS 2 4 536 65536 8 4 MAOB T1  TABLE USERS 3 4 7184 65536 8 4 MAOB T1  TABLE USERS 4 4 7192 65536 8 4 MAOB T1  TABLE USERS 5 4 7200 65536 8 4 MAOB T2  TABLE USERS 0 4 7208 65536 8 4   <<T2 是接着T1的最后一个extent分配的 MAOB T2  TABLE USERS 1 4 7216 65536 8 4 MAOB T2  TABLE USERS 2 4 7224 65536 8 4 MAOB T2  TABLE USERS 3 4 7232 65536 8 4 MAOB T2  TABLE USERS 4 4 7240 65536 8 4 MAOB T2  TABLE USERS 5 4 7248 65536 8 4 对两个表进行drop 之后,我们查询  dba_free_space情况 select * from dba_free_space where file_id=4 order by block_id USERS 4 520 65536 8 4 USERS 4 528 65536 8 4 USERS 4 536 65536 8 4  <<<以上3个是T1的前三个extent 都是连续的,并没有进行合并 USERS 4 640 41943040 5120 4  USERS 4 7184 65536 8 4 USERS 4 7192 65536 8 4 USERS 4 7200 65536 8 4 <<<以上3个是T1的后三个extent 都是连续的,并没有进行合并 USERS 4 7208 65536 8 4 USERS 4 7216 65536 8 4 USERS 4 7224 65536 8 4 USERS 4 7232 65536 8 4 USERS 4 7240 65536 8 4 USERS 4 7248 65536 8 4      <<以上6个是T2的extent,都是连续的,并没有进行合并 USERS 4 7256 524288 64 4   <<这个和T2的extents是连续的,但是也没有合并  这些extents都是保持原样的出现在了dba_free_space,所以造成条目增多,我们接下来进行purge   purge recyclebin;  我们再次查询  dba_free_space情况 select * from dba_free_space where file_id=4 order by block_id USERS 4 520 196608 24 4           <<3个extent 已经合并成一个24blocks的新extent USERS 4 640 41943040 5120 4 USERS 4 7184 1114112 136 4    <<6个extent 共计72个block连同原有的相邻extent 里面的64 个block合并成为了一个新的136block的extent dba_free_space条目也大幅减少,所以对于recyclebin里面有着大量drop的表,尤其是这些表曾经分配了大量的extent,就会出现此类问题。

日常监控免不了监控表空间空闲信息,但是有时发现查询他非常缓慢,这是因为dba_free_space 里面条目过多,所以查询起来非常缓慢,为啥这个view里面条目如此 之多呢,有时候会发现里面的extent居然还是连续的, 其实这是因为drop 对象造成的,下面的例子可以展示一下这个场景:create table t1 as select * from dba_tables...

技术共享

Advisor Webcast 2017年03月28日: Oracle Clusterware 节点重启问题的诊断

主题:  Oracle Clusterware 节点重启问题的诊断摘要: 本次网上研讨会大约1小时, 关于如何诊断及避免Oracle CRS集群节点重启问题。适用于有一定系统管理经验的DBA和系统管理员参加。时间: 2017年3月28日14:00 ~15:00 (北京时间) 包括:1.我们将着重介绍Oracle为什么会发起CRS或者主机的重启,以及为什么Oracle会做这样的重启。2.我们会介绍重启的几个组件以及如何诊断重启的原因。3.我们通过以上的讲述,让客户知道如何避免这样的故障发生。 欢迎有经验的DBA以及系统管理员参加这次Webcast的培训。 参考文档:所有webcast的时间安排和过去的演讲pdf文稿和录像,可以在文档 Note 740966.1 中找到。WebEx 会议详细内容:Topic: Oracle Clusterware 节点重启问题的诊断(Mandarin Only)Event Number: 595 859 256Event Passcode: 123456注册地址:https://oracleaw.webex.com/oracleaw/onstage/g.php?d=595859256&t=a主持人确认您的请求后,您会收到参加会议具体步骤的确认邮件。InterCall 电话接入的方法:中国地区免费接入号码: 108007441329 中国地区免费接入号码: 108004411182台湾地区免费接入号码: 00801044259香港地区免费接入号码: 800966155Conference ID: 72594840WebEx Conference  会议也提供直接的音频流 (即可以通过 webex 页面直接获得声音,不必须通过电话拨入)

主题:  Oracle Clusterware 节点重启问题的诊断摘要: 本次网上研讨会大约1小时, 关于如何诊断及避免Oracle CRS集群节点重启问题。适用于有一定系统管理经验的DBA和系统管理员参加。 时间: 2017年3月28日14:00 ~15:00 (北京时间)包括: 1.我们将着重介绍Oracle为什么会发起CRS或者主机的重启,以及为什么Oracle会做这样的重启。2.我们会介绍重启...

新特性

12c新特性-Oracle Sharding简介

Oracle Sharding简介 ================ Oracle Sharding是Oracle 12.2版本推出的新功能,也称为数据分片,适用于online transaction processing (OLTP). Oracle Sharding基于表分区技术,是一种在数据层将数据水平分区存储到不同的数据库的技术. Sharding可以实现将一个分区表的不同分区存储在不同的数据库中,每个数据库位于不同的服务器,每一个数据库都称为shard, 这些shard组成一个逻辑数据库,称为sharded database (SDB).  这个table也称为sharded table, 每个shard数据库中保存该表的不同数据集(按照sharding key分区), 但是他们有相同的列(columns)。 Shard是一种shared-nothing技术,每个shard数据库使用独立的服务器硬件(CPU,内存等)。Shard可以运行在单机数据库或者DATAGUARD/ADG数据库。 Oracle Sharding优势 ================ Oracle Sharding技术提供线性扩展和失败隔离的优点: 线性扩展: 因为每个shard是一个独立的数据库,通过增加新的Shard节点,来线性扩展性能。自动rebalance数据。 失败隔离: 由于Shard是一种shared-nothing技术,每个shard使用独立的硬件,因此一个shard节点出现故障,只会影响到这个shard存放的数据,而不会影响到其他shard。 按照地理位置分布数据:可以选择根据地理位置不同,将数据存储在不同的shard。 滚动升级:选择不同时间升级不同的shard。比如同一时间只升级一个或一部分shard,那么只有这些升级的shard中存储的数据受到影响,其他的shard不受到影响,可以继续提供服务。 云部署:Shard非常适合部署在cloud。 Oracle Sharding组成 ================= Oracle Sharding 主要包括下面组件: Sharded database (SDB): 逻辑上SDB是一个数据库,但是物理上SDB包括多个物理独立的数据库,SDB类似一个数据库池(pool),数据库池(pool)中包括多个数据库(Shard). 目前版本最大支持1000个shard。 Shards: SDB包括多个物理独立的数据库,每一个数据库都称为shard, 每个shard数据库位于不同的服务器,他们不共享CPU,内存,存储等资源。每个shard数据库中保存表的不同数据集, 但是每个shard中都有相同的列(columns). Shard数据库可以是Dataguard/ADG,提供高可用性, Shard数据库(单机或者ADG)可以通过GSM deploy来自动创建,也可以将一个已经通过dbca创建好的数据库add到SDB。 Shard catalog:是一个Oracle数据库,用于集中存储管理SDB配置信息,是SDB的核心。SDB配置变化,比如添加/删除shard,Global service等等,都记录在Shard catalog。如果应用查询多个shard中的数据,那么由Shard catalog统一协调分配。我们推荐将Shard catalog配置为dataguard环境,这样可以提供HA高可用。如果Shard catalog无法访问,那么只会影响一些维护操作和跨shard访问,而不会影响单独的shard操作(通过sharding key的查询/DML)。 Shard directors: Global Data Service (GDS)实现对Sharding的集中部署和管理。GSM是GDS的核心组件。GSM作为Shard director. GSM类似于监听器,将客户端对SDB的请求路由到对应的shard。负载均衡客户端的访问。 Global service: 数据库的服务(service), 用于访问SDB中的数据 管理接口:通过GDSCTL (command-line utility) 接口部署管理监控Sharding。 Oracle Sharding方法 ================ Oracle Sharding支持3种方法shard/分片方法: System-Managed Sharding:这种方法用户不用指定数据存放在哪个shard中。Sharding通过一致性哈希(CONSISTENT HASH)方法将数据分区(partitioning),并自动分布在不同的Shard。System-managed sharding只能有一个shardspace. Composite Sharding: 这种方法用户创建多个shardspaces ,每个shardspaces 中存放一定范围(range)或者列表(list)的数据。一般情况下,Shardspace按照区域来划分,比如美国区域的shard属于shardspace cust_america,欧洲的shard属于shardspace cust_europe。 Subpartitions with Sharding: Sharding基于表分区,因此子分区(Subpartitions)技术同样适用于Sharding Oracle Sharding 对象 ================= 被Shard/分片的表我们成为sharded table,这些sharded table的集合称为表家族(Table Family)。所谓表家族(Table Family)就是指sharded table之间是父-子关系,一个表家族(Table Family)中没有任何父表的表叫做根表(root table),每个表家族中只能有一个根表。在12.2,在一个SDB中只支持一个表家族。在表家族(Table Family)中的所有sharded table都按照相同的sharding key(主键)来分片,主要是由root table的sharding key决定的。表家族(Table Family)中有相同sharding key的数据存储在同一个Chunk中,这样方便以后的数据移动。 比如: 用户表 – 订单表 – 订单明细表 就是一个表家族,其中用户表是root table,订单表 和 订单明细表分别是子表,他们都按照sharding key (CustNo )分区。 具体请参考后面的测试-安装配置system managed sharding  用户表: CustNo    Name       Address        Location  Class --------- ---------- -------------- --------- ------ 123       Brown      100 Main St    us3       Gold 456       Jones      300 Pine Ave   us1       Silver 999       Smith      453 Cherry St  us2       Bronze 订单表: OrderNo   CustNo   OrderDate --------- -------- ----------- 4001      123      14-FEB-2013 4002      456      09-MAR-2013 4003      456      05-APR-2013 4004      123      27-MAY-2013 4005      999      01-SEP-2013 订单明细表 LineNo  OrderNo  CustNo  StockNo    Quantity ------  -------  ------  -------    -------- 40011   4001     123     05683022   1 40012   4001     123     45423609   4 40013   4001     123     68584904   1 40021   4002     456     05683022   1 40022   4002     456     45423509   3 40022   4003     456     80345330   16 40041   4004     123     45423509   1 40042   4004     123     68584904   2 40051   4005     999     80345330   12 Oracle Sharding 路由选择(Routing) ========================== --直接路由应用程序初始化时,在应用层/中间件层建立连接池,连接池获取所有shard节点的sharding key范围,并且保存在连接池中,形成shard topology cache(拓扑缓存),Cache提供了一个快速的方法直接将请求路由到具体的shard。客户端请求时指定shard key,直接从连接池获取连接,这种情况下不经过shard director/catalog数据库,直接连接到对应的shard。--代理路由如果客户端执行select或者DML时不指定shard key或者执行聚合操作(比如 group by),那么请求发送到Catalog数据库,根据matadata信息,SQL编译器决定访问哪些shards。 为了实现sharding,oracle在连接池和驱动方面都做了增强,提供了新的API(UCP, JDBC, OCI等等)在连接创建时来传递sharding keys.  比如: Sharding APIs for Oracle UCP PoolDataSource pds =                                      PoolDataSourceFactory.getPoolDataSource();   // Set Connection Pool properties pds.setURL(DB_URL); pds.setUser("hr" );   pds.setPassword("****" ); pds.setInitialPoolSize(10); pds.setMinPoolSize(20); pds.setMaxPoolSize(30); // build the sharding key object OracleShardingKey shardingKey =      pds.createShardingKeyBuilder()        .subkey("mary.smith@example.com", OracleType.VARCHAR2)       .build();    // Get an UCP connection for a shard Connection conn =      pds.createConnectionBuilder()      .shardingKey(shardingKey)      .build(); 比如:SQLPLUS连接串中指定sharding key: $ sqlplus app_schema/oracle @ ' (description=(address=(protocol=tcp)(host=gsm1)(port=1522)) (connect_data=(service_name=oltp_rw_srvc.shdb.oradbcloud)(region=region1)(SHARDING_KEY=james.parker@x-DOT-bogus)))' 安装配置system managed sharding(shard节点为单机) ================================================== 系统环境概述 -------------- 这是一个测试环境,因此shard均为单机数据库,没有配置ADG. 生产环境下,建议配置为ADG,提供高可用性。 主机名 角色 系统配置 gsm1 - GSM/shard Director和Shard catalog 都安装在gsm1服务器。 4GB内存,1颗CPU,30GB ssd磁盘 sd1 - shard服务器1。 4GB内存,1颗CPU,30GB ssd磁盘 sd2 - shard服务器2。 4GB内存,1颗CPU,30GB ssd磁盘 安装12.2 RDBMS软件 ------------------- 在所有服务器安装12.2 ORACLE RDBMS软件,包括Shard catalog 服务器和所有shard服务器。只安装软件,不用dbca创建数据库。 安装GDS/GSM软件 ------------------- 在shard Director服务器gsm1安装12.2 GDS/GSM软件。GSM安装过程比较简单,按照默认配置安装即可。 创建Shard Catalog database ---------------------------- 在Shard catalog  服务器gsm1  创建 non-cdb数据库。创建过程与普通数据库相同。 配置GSM/Shard director ------------------------ 1. 在gsm1服务器(catalog 数据库/shard director),连接到Sharding catalog数据库, 解锁 GSMCATUSER 用户,shard director 通过GSMCATUSER 用户连接到shard catalog database。 $ export ORACLE_BASE=/u01/app/oracle $ export ORACLE_HOME=/u01/app/oracle/products/12.2.0.1 $ export ORACLE_SID=catadb $ sqlplus / as sysdba SQL> alter user gsmcatuser identified by oracle account unlock; 2. 在 catalog数据库,创建管理用户mygds,用户mygds用于存储Sharding管理信息,GDSCTL接口通过用户mygds连接到catalog数据库。 SQL> create user mygds identified by oracle; SQL> grant connect, create session, gsmadmin_role to mygds; SQL> grant inherit privileges on user SYS to GSMADMIN_INTERNAL; 3. 在gsm1服务器(catalog 数据库/shard director),启动listener 4. 在gsm1服务器(catalog 数据库/shard director),创建shard catalog,在shard catalog中配置remote scheduler agent. 参数含义: -user : 指定管理用户,在前面步骤中创建的catalog database管理用户mygds -database : 指定catalog database 信息,catalog 数据库的主机名:监听器port: catalog 数据库db_name -sdb : 指定sharded database name -agent_port: 设置端口,用于shard节点agent连接到GSM -agent_password: 设置密码,用于shard节点agent连接到GSM 如果没有指定- sharding参数,默认是创建system-managed (default)类型 $ su – oracle $ export ORACLE_BASE=/u01/app/oracle $ export ORACLE_HOME=/u01/app/oracle/products/12.2.0/gsmhome_1 $ export PATH=/u01/app/oracle/products/12.2.0/gsmhome_11/bin:$PATH:$HOME/bin $ gdsctl GDSCTL>create shardcatalog -database gsm1:1521:catadb -chunks 12 -user mygds/oracle -sdb shdb -region region1, region2 -agent_port 8080 -agent_password oracle Catalog is created 5. 创建和启动shard director. 参数含义: -gsm: 指定shard director名称 -listener: 指定shard director的监听端口,注意不能与数据库的listener端口冲突 -catalog: 指定catalog database 信息,catalog数据库的主机名:监听器port: catalog 数据库db_name GDSCTL>add gsm -gsm sharddirector3 -listener 1522 -pwd oracle -catalog gsm1:1521:catadb -region region1 GSM successfully added GDSCTL>start gsm -gsm sharddirector3 GSM is started successfully 6. 添加操作系统认证. GDSCTL> add credential -credential cre_reg1 -osaccount oracle -ospassword oracle The operation completed successfully 7. 在所有的shard节点分别执行Agent���册 --在sd1节点执行 [oracle@sd1 ~]$ schagent -start Scheduler agent started using port 21620 [oracle@sd1 ~]$ schagent -status Agent running with PID 1814 Agent_version:12.2.0.1.2 Running_time:00:00:08 Total_jobs_run:0 Running_jobs:0 Platform:Linux ORACLE_HOME:/u01/app/oracle/products/12.2.0.1 ORACLE_BASE:/u01/app/oracle Port:21620 Host:sd1 --密码oracle和端口8080是在第4步创建shardcatalog时设置的: $ echo oracle | schagent -registerdatabase 192.168.56.230 8080 Agent Registration Password ?   Oracle Scheduler Agent Registration for 12.2.0.1.2 Agent Agent Registration Successful! --创建shard 数据库的数据文件存储路径 $ mkdir /u01/app/oracle/oradata --在sd2节点执行 [oracle@sd2 oradata]$ schagent -start Scheduler agent started using port 24240 [oracle@sd2 oradata]$ schagent -status Agent running with PID 1887 Agent_version:12.2.0.1.2 Running_time:00:01:10 Total_jobs_run:0 Running_jobs:0 Platform:Linux ORACLE_HOME:/u01/app/oracle/products/12.2.0.1 ORACLE_BASE:/u01/app/oracle Port:24240 Host:sd2 $ echo oracle | schagent -registerdatabase 192.168.56.230 8080 Agent Registration Password ?   Oracle Scheduler Agent Registration for 12.2.0.1.2 Agent Agent Registration Successful! $ mkdir /u01/app/oracle/oradata 创建System-Managed SDB ------------------------- 部署system-managed SDB 1. 在Shard服务器 sd1 连接到shard director/GSM服务器(gsm1) $ ssh oracle@gsm1 2. 设置当前session为sharddirector3 shard director. $ export ORACLE_BASE=/u01/app/oracle $ export ORACLE_HOME=/u01/app/oracle/products/gsm_home1 $ export PATH=/u01/app/oracle/products/gsm_home1/bin:$PATH:$HOME/bin $ gdsctl GDSCTL>set gsm -gsm sharddirector3 GDSCTL>connect mygds/oracle Catalog connection is established 3. 添加shardgroup, shardgroup是一组shard的集合,shardgroup名称为primary_shardgroup,-deploy_as primary表示这个group中的shard都是主库。 GDSCTL>add shardgroup -shardgroup primary_shardgroup -deploy_as primary -region region1 The operation completed successfully 4. 将每个shard地址添加到catalog的valid node checking for registration (VNCR)列表,并且创建shard GDSCTL> add invitednode sd1  GDSCTL>create shard -shardgroup primary_shardgroup -destination sd1 -credential cre_reg1 -sys_password oracle The operation completed successfully DB Unique Name: sh1 GDSCTL> add invitednode sd2 GDSCTL>create shard -shardgroup primary_shardgroup -destination sd2 -credential cre_reg1 -sys_password oracle The operation completed successfully DB Unique Name: sh21 5. 检查配置 GDSCTL>config Regions ------------------------ region1                        region2                        GSMs ------------------------           sharddirector3                 Sharded Database ------------------------ shdb                           Databases ------------------------ sh1                            sh21                           Shard Groups ------------------------ primary_shardgroup             Shard spaces ------------------------ shardspaceora                  Services ------------------------ GDSCTL pending requests ------------------------ Command                       Object                        Status                         -------                       ------                        ------                         Global properties ------------------------ Name: oradbcloud Master GSM: sharddirector3 DDL sequence #: 0 GDSCTL>config shardspace Shard space                   Chunks                         -----------                   ------                         shardspaceora                 12                             GDSCTL> GDSCTL>config shardgroup Shard Group         Chunks Region              Shard space          -----------         ------ ------              -----------          primary_shardgroup  12     region1             shardspaceora        GDSCTL> GDSCTL>config vncr Name                          Group ID                       ----                          --------                       192.168.56.230                                               sd1                                                          sd2                                                          GDSCTL> GDSCTL>config shard Name                Shard Group         Status    State       Region    Availability  ----                -----------         ------    -----       ------    ------------  sh1                 primary_shardgroup  U         none        region1   -             sh21                primary_shardgroup  U         none        region1   -       6. 部署/deploy Shard数据库部署过程采用静默安装方式。 GDSCTL>deploy deploy: examining configuration... deploy: deploying primary shard 'sh1' ... deploy: network listener configuration successful at destination 'sd1' deploy: starting DBCA at destination 'sd1' to create primary shard 'sh1' ... deploy: deploying primary shard 'sh21' ... deploy: network listener configuration successful at destination 'sd2' deploy: starting DBCA at destination 'sd2' to create primary shard 'sh21' ... deploy: waiting for 2 DBCA primary creation job(s) to complete... deploy: waiting for 2 DBCA primary creation job(s) to complete... deploy: waiting for 2 DBCA primary creation job(s) to complete... deploy: waiting for 2 DBCA primary creation job(s) to complete... deploy: waiting for 2 DBCA primary creation job(s) to complete... deploy: waiting for 2 DBCA primary creation job(s) to complete... deploy: waiting for 2 DBCA primary creation job(s) to complete... deploy: waiting for 2 DBCA primary creation job(s) to complete... deploy: waiting for 2 DBCA primary creation job(s) to complete... deploy: DBCA primary creation job succeeded at destination 'sd1' for shard 'sh1' deploy: DBCA primary creation job succeeded at destination 'sd2' for shard 'sh21' deploy: requesting Data Guard configuration on shards via GSM deploy: shards configured successfully The operation completed successfully 7. 检查配置信息 GDSCTL>config shard Name                Shard Group         Status    State       Region    Availability  ----                -----------         ------    -----       ------    ------------  sh1                 primary_shardgroup  Ok        Deployed    region1   ONLINE        sh21                primary_shardgroup  Ok        Deployed    region1   ONLINE       GDSCTL>databases Database: "sh1" Registered: Y State: Ok ONS: N. Role: PRIMARY Instances: 1 Region: region1    Registered instances:      shdb%1 Database: "sh21" Registered: Y State: Ok ONS: N. Role: PRIMARY Instances: 1 Region: region1    Registered instances:      shdb%11 GDSCTL>config shard -shard sh1 Conversion = ':'Name: sh1 Shard Group: primary_shardgroup Status: Ok State: Deployed Region: region1 Connection string: sd1:1521/sh1:dedicated SCAN address:  ONS remote port: 0 Disk Threshold, ms: 20 CPU Threshold, %: 75 Version: 12.2.0.0 Last Failed DDL:  DDL Error: --- Failed DDL id:  Availability: ONLINE Supported services ------------------------ Name                                                            Preferred Status     ----                                                            --------- ------     GDSCTL>config shard -shard sh21 Conversion = ':'Name: sh21 Shard Group: primary_shardgroup Status: Ok State: Deployed Region: region1 Connection string: sd2:1521/sh21:dedicated SCAN address:  ONS remote port: 0 Disk Threshold, ms: 20 CPU Threshold, %: 75 Version: 12.2.0.0 Last Failed DDL:  DDL Error: --- Failed DDL id:  Availability: ONLINE Supported services ------------------------ Name                                                            Preferred Status     ----                                                            --------- ------     8. 创建service GDSCTL>add service -service oltp_rw_srvc -role primary The operation completed successfully GDSCTL>start service -service oltp_rw_srvc The operation completed successfully GDSCTL>status service Service "oltp_rw_srvc.shdb.oradbcloud" has 2 instance(s). Affinity: ANYWHERE   Instance "shdb%1", name: "sh1", db: "sh1", region: "region1", status: ready.   Instance "shdb%11", name: "sh21", db: "sh21", region: "region1", status: ready. 创建用户和对象 1. 在catalog数据库中创建业务用户 SQL> alter session enable shard ddl; SQL> create user app_schema identified by oracle; SQL> grant all privileges to app_schema; SQL> grant gsmadmin_role to app_schema; SQL> grant select_catalog_role to app_schema; SQL> grant connect, resource to app_schema; SQL> grant dba to app_schema; SQL> grant execute on dbms_crypto to app_schema; 2. 创建表空间集合 SQL> CREATE TABLESPACE SET TSP_SET_1 using template (datafile size 100m autoextend on next 10M maxsize unlimited extent management local segment space management auto); 3. 为duplicated tables创建表空间,这个测试中duplicated table是Products table. SQL> CREATE TABLESPACE products_tsp datafile size 100m autoextend on next 10M maxsize unlimited extent management local uniform size 1m; 4. 创建root 表Customers SQL> CONNECT app_schema/oracle SQL> ALTER SESSION ENABLE SHARD DDL; SQL> CREATE SHARDED TABLE Customers   (     CustId      VARCHAR2(60) NOT NULL,     FirstName   VARCHAR2(60),     LastName    VARCHAR2(60),     Class       VARCHAR2(10),     Geo         VARCHAR2(8),     CustProfile VARCHAR2(4000),     Passwd      RAW(60),     CONSTRAINT pk_customers PRIMARY KEY (CustId),     CONSTRAINT json_customers CHECK (CustProfile IS JSON)   ) TABLESPACE SET TSP_SET_1 PARTITION BY CONSISTENT HASH (CustId) PARTITIONS AUTO; 5. 创建其他sharded table Orders. SQL> CREATE SHARDED TABLE Orders   (     OrderId     INTEGER NOT NULL,     CustId      VARCHAR2(60) NOT NULL,     OrderDate   TIMESTAMP NOT NULL,     SumTotal    NUMBER(19,4),     Status      CHAR(4),     CONSTRAINT  pk_orders PRIMARY KEY (CustId, OrderId),     CONSTRAINT  fk_orders_parent FOREIGN KEY (CustId)      REFERENCES Customers ON DELETE CASCADE   ) PARTITION BY REFERENCE (fk_orders_parent);   6. 为OrderId�������创建序列 SQL> CREATE SEQUENCE Orders_Seq;   7. 创建SHARDED TABLE LineItems SQL> CREATE SHARDED TABLE LineItems   (     OrderId     INTEGER NOT NULL,     CustId      VARCHAR2(60) NOT NULL,     ProductId   INTEGER NOT NULL,     Price       NUMBER(19,4),     Qty         NUMBER,     CONSTRAINT  pk_items PRIMARY KEY (CustId, OrderId, ProductId),     CONSTRAINT  fk_items_parent FOREIGN KEY (CustId, OrderId)     REFERENCES Orders ON DELETE CASCADE   ) PARTITION BY REFERENCE (fk_items_parent); 8. 创建duplicated tables. In this example, the Products table is a duplicated object. SQL> CREATE DUPLICATED TABLE Products   (     ProductId  INTEGER GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,     Name       VARCHAR2(128),     DescrUri   VARCHAR2(128),     LastPrice  NUMBER(19,4)   ) TABLESPACE products_tsp;   9. 创建function,目的是为了后面的DEMO: CREATE OR REPLACE FUNCTION PasswCreate(PASSW IN RAW) RETURN RAW IS Salt RAW(8); BEGIN Salt := DBMS_CRYPTO.RANDOMBYTES(8); RETURN UTL_RAW.CONCAT(Salt, DBMS_CRYPTO.HASH(UTL_RAW.CONCAT(Salt, PASSW), DBMS_CRYPTO.HASH_SH256)); END; / CREATE OR REPLACE FUNCTION PasswCheck(PASSW IN RAW, PHASH IN RAW) RETURN INTEGER IS BEGIN RETURN UTL_RAW.COMPARE( DBMS_CRYPTO.HASH(UTL_RAW.CONCAT(UTL_RAW.SUBSTR(PHASH, 1, 8), PASSW), DBMS_CRYPTO.HASH_SH256), UTL_RAW.SUBSTR(PHASH, 9)); END; / 10. 检查是否有错误: GDSCTL>connect mygds/oracle GDSCTL>show ddl id      DDL Text                                 Failed shards  --      --------                                 -------------  5       grant connect, resource to appuser1                     6       grant dba to appuser1                                   7       grant execute on dbms_crypto to appuser1                8       CREATE TABLESPACE SET TSP_SET_1 using...                9       CREATE TABLESPACE products_tsp datafi...                10      CREATE SHARDED TABLE Customers   (   ...                11      CREATE SHARDED TABLE Orders   (     O...                12      CREATE SEQUENCE Orders_Seq                              13      CREATE SHARDED TABLE LineItems   (   ...                14      CREATE MATERIALIZED VIEW "APPUSER1"."...                11. 检查每个shard是否有DDL错误 GDSCTL>config shard -shard sh1 Conversion = ':'Name: sh1 Shard Group: primary_shardgroup Status: Ok State: Deployed Region: region1 Connection string: sd1:1521/sh1:dedicated SCAN address:  ONS remote port: 0 Disk Threshold, ms: 20 CPU Threshold, %: 75 Version: 12.2.0.0 Last Failed DDL:  DDL Error: ---      <<<<<<<<<<<<没有DDL错误 Failed DDL id:  Availability: - Supported services ------------------------ Name                                                            Preferred Status     ----                                                            --------- ------     验证环境-表空间/chunks 1. 在gsm节点,检查chunks信息 前面创建shardcatalog时指定chunks为12,因此后续创建shard table分配12个chunks GDSCTL>config chunks Chunks ------------------------ Database                      From      To         --------                      ----      --         sh1                           1         6          sh21                          7         12     2. 在sd1节点检查表空间和chunks信息 --表空间 SQL> select TABLESPACE_NAME, BYTES/1024/1024 MB from sys.dba_data_files order by tablespace_name; TABLESPACE_NAME                        MB ------------------------------ ---------- C001TSP_SET_1                         100 C002TSP_SET_1                         100 C003TSP_SET_1                         100 C004TSP_SET_1                         100 C005TSP_SET_1                         100 C006TSP_SET_1                         100 PRODUCTS_TSP                          100 SYSAUX                                460 SYSTEM                                800 TSP_SET_1                             100 UNDOTBS1                               70 USERS                                   5 创建了6个表空间,分别是C001TSP_SET_1 ~ 表空间C006TSP_SET_1,因为设置chunks=12,每个shard有6个chunks。 每个表空间有一个datafile,大小是100M,这个是在创建tablespace set时设置的datafile 100M。 --检查chunks SQL> set linesize 140 SQL> column table_name format a20 SQL> column tablespace_name format a20 SQL> column partition_name format a20 SQL> show parameter db_unique_name SQL> select table_name, partition_name, tablespace_name from dba_tab_partitions where tablespace_name like 'C%TSP_SET_1' order by tablespace_name; TABLE_NAME           PARTITION_NAME       TABLESPACE_NAME -------------------- -------------------- -------------------- ORDERS               CUSTOMERS_P1         C001TSP_SET_1 CUSTOMERS            CUSTOMERS_P1         C001TSP_SET_1 LINEITEMS            CUSTOMERS_P1         C001TSP_SET_1 CUSTOMERS            CUSTOMERS_P2         C002TSP_SET_1 LINEITEMS            CUSTOMERS_P2         C002TSP_SET_1 ORDERS               CUSTOMERS_P2         C002TSP_SET_1 CUSTOMERS            CUSTOMERS_P3         C003TSP_SET_1 ORDERS               CUSTOMERS_P3         C003TSP_SET_1 LINEITEMS            CUSTOMERS_P3         C003TSP_SET_1 ORDERS               CUSTOMERS_P4         C004TSP_SET_1 CUSTOMERS            CUSTOMERS_P4         C004TSP_SET_1 LINEITEMS            CUSTOMERS_P4         C004TSP_SET_1 CUSTOMERS            CUSTOMERS_P5         C005TSP_SET_1 LINEITEMS            CUSTOMERS_P5         C005TSP_SET_1 ORDERS               CUSTOMERS_P5         C005TSP_SET_1 CUSTOMERS            CUSTOMERS_P6         C006TSP_SET_1 LINEITEMS            CUSTOMERS_P6         C006TSP_SET_1 ORDERS               CUSTOMERS_P6         C006TSP_SET_1 18 rows selected. 3. 在sd2节点检查表空间和chunks信息 --表空间 SQL> select TABLESPACE_NAME, BYTES/1024/1024 MB from sys.dba_data_files order by tablespace_name; TABLESPACE_NAME              MB -------------------- ---------- C007TSP_SET_1               100 C008TSP_SET_1               100 C009TSP_SET_1               100 C00ATSP_SET_1               100 C00BTSP_SET_1               100 C00CTSP_SET_1               100 PRODUCTS_TSP                100 SYSAUX                      470 SYSTEM                      800 TSP_SET_1                   100 UNDOTBS1                     70 USERS                         5 12 rows selected. 创建了6个表空间,分别是C007TSP_SET_1 ~ 表空间C00CTSP_SET_1,因为设置chunks=12,每个shard有6个chunks。 每个表空间有一个datafile,大小是100M,这个是在创建tablespace set时设置的datafile 100M。 --检查chunks SQL> set linesize 140 SQL> column table_name format a20 SQL> column tablespace_name format a20 SQL> column partition_name format a20 SQL> show parameter db_unique_name SQL> select table_name, partition_name, tablespace_name from dba_tab_partitions where tablespace_name like 'C%TSP_SET_1' order by tablespace_name; TABLE_NAME           PARTITION_NAME       TABLESPACE_NAME -------------------- -------------------- -------------------- ORDERS               CUSTOMERS_P7         C007TSP_SET_1 CUSTOMERS            CUSTOMERS_P7         C007TSP_SET_1 LINEITEMS            CUSTOMERS_P7         C007TSP_SET_1 CUSTOMERS            CUSTOMERS_P8         C008TSP_SET_1 LINEITEMS            CUSTOMERS_P8         C008TSP_SET_1 ORDERS               CUSTOMERS_P8         C008TSP_SET_1 CUSTOMERS            CUSTOMERS_P9         C009TSP_SET_1 ORDERS               CUSTOMERS_P9         C009TSP_SET_1 LINEITEMS            CUSTOMERS_P9         C009TSP_SET_1 ORDERS               CUSTOMERS_P10        C00ATSP_SET_1 CUSTOMERS            CUSTOMERS_P10        C00ATSP_SET_1 LINEITEMS            CUSTOMERS_P10        C00ATSP_SET_1 CUSTOMERS            CUSTOMERS_P11        C00BTSP_SET_1 LINEITEMS            CUSTOMERS_P11        C00BTSP_SET_1 ORDERS               CUSTOMERS_P11        C00BTSP_SET_1 CUSTOMERS            CUSTOMERS_P12        C00CTSP_SET_1 LINEITEMS            CUSTOMERS_P12        C00CTSP_SET_1 ORDERS               CUSTOMERS_P12        C00CTSP_SET_1 18 rows selected. 4. 在catalog数据库检查chunks信息 SQL> set echo off SQL> select a.name Shard, count( b.chunk_number) Number_of_Chunks from   2  gsmadmin_internal.database a, gsmadmin_internal.chunk_loc b where   3  a.database_num=b.database_num group by a.name; SHARD                          NUMBER_OF_CHUNKS ------------------------------ ---------------- sh1                                           6 sh21                                          6 6.6.4 验证环境-tables --catalog数据库 SQL> conn app_schema/oracle Connected. SQL> select table_name from user_tables; TABLE_NAME -------------------------------------------------------------------------------- PRODUCTS MLOG$_PRODUCTS CUSTOMERS ORDERS LINEITEMS RUPD$_PRODUCTS 6 rows selected. --shard节点sd1和sd2 SQL> conn app_schema/oracle Connected. SQL> select table_name from user_tables; TABLE_NAME -------------------- PRODUCTS CUSTOMERS ORDERS LINEITEMS 访问单独一个shard --------------------------- 在连接串中指定sharding key,那么GSM/shard director将请求连接到对应的一个shard 参数含义: app_schema – 是业务用户, (host=gsm1)(port=1522) – 是GSM/shard director 监听地址 service_name=oltp_rw_srvc.shdb.oradbcloud – 是前面创建的全局service $ sqlplus app_schema/oracle@'(description=(address=(protocol=tcp)(host=gsm1)(port=1522)) (connect_data=(service_name=oltp_rw_srvc.shdb.oradbcloud)(region=region1)(SHARDING_KEY=james.parker@x.bogus)))' SQL> select db_unique_name from v$database; DB_UNIQUE_NAME ------------------------------ sh1 --插入数据 SQL> INSERT INTO Customers (CustId, FirstName, LastName, CustProfile,     Class, Geo, Passwd) VALUES ('james.parker@x.bogus', 'James', 'Parker',     NULL, 'Gold', 'east', hextoraw('8d1c00e')); 1 row created. SQL> commit; Commit complete. SQL> exit Disconnected from Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production [oracle@gsm1 ~]$ sqlplus app_schema/oracle@'(description=(address=(protocol=tcp)(host=gsm1)(port=1522)) (connect_data=(service_name=oltp_rw_srvc.shdb.oradbcloud)(region=region1)(SHARDING_KEY=james.parker@x.bogus)))' SQL> select db_unique_name from v$database; DB_UNIQUE_NAME ------------------------------ sh1 SQL> column custid format a20 SQL> column firstname format a15 SQL> column lastname format a15 SQL> select custid, FirstName, LastName, class, geo from customers     where custid = 'james.parker@x.bogus'; CUSTID               FIRSTNAME       LASTNAME        CLASS      GEO -------------------- --------------- --------------- ---------- -------- james.parker@x.bogus James           Parker          Gold       east SQL> SELECT sys_context('USERENV', 'INSTANCE_NAME') FROM DUAL; SYS_CONTEXT('USERENV','INSTANCE_NAME') -------------------------------------------------------------------------------- shdb%1 --查询SHARDING_KEY=tom.david,连接到sd2: sqlplus app_schema/oracle@'(description=(address=(protocol=tcp)(host=gsm1)(port=1522)) (connect_data=(service_name=oltp_rw_srvc.shdb.oradbcloud)(region=region1)(SHARDING_KEY=tom.david)))' 访问多个shard ---------------------- 如果在连接串中指定sharding key,那么GSM/shard director将请求连接到对应的一个shard。 如果没有指定sharding key,那么session和coordinator database (shard catalog)建立连接,然后再分别到需要(prund)的shard中查询,最后再整合。 优化器判断访问一个shard还是访问多个shard。 --链接到catalog数据库查询 $ sqlplus app_schema/oracle@gsm1:1521/GDS\$CATALOG.oradbcloud set termout on set linesize 120 set echo on column firstname format a20 column lastname format a20 explain plan for SELECT FirstName,LastName, geo, class FROM Customers WHERE CustId in ('Scott.Tiger@x.bogus', 'Mary.Parker@x.bogus') AND class != 'free' ORDER BY geo, class; select plan_table_output from table(DBMS_XPLAN.DISPLAY()); PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------------------------------------- Plan hash value: 1622328711 ------------------------------------------------------------------------------------------------------- | Id  | Operation         | Name              | Rows  | Bytes | Cost (%CPU)| Time     | Inst   |IN-OUT| ------------------------------------------------------------------------------------------------------- |   0 | SELECT STATEMENT  |                   |   100 |  7700 |     1 (100)| 00:00:01 |        |      | |   1 |  SORT ORDER BY    |                   |   100 |  7700 |     1 (100)| 00:00:01 |        |      | |   2 |   VIEW            | VW_SHARD_5B3ACD5D |   100 |  7700 |     5 (100)| 00:00:01 |        |      | |   3 |    SHARD ITERATOR |                   |       |       |            |          |        |      | |   4 |     REMOTE        |                   |       |       |            |          | ORA_S~ | R->S | ------------------------------------------------------------------------------------------------------- PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------------------------------------- Remote SQL Information (identified by operation id): ----------------------------------------------------    4 - EXPLAIN PLAN INTO PLAN_TABLE@! FOR SELECT        "A1"."FIRSTNAME","A1"."LASTNAME","A1"."GEO","A1"."CLASS" FROM "CUSTOMERS" "A1" WHERE        ("A1"."CUSTID"='Mary.Parker@x.bogus' OR "A1"."CUSTID"='Scott.Tiger@x.bogus') AND        "A1"."CLASS"<>'free' /* coord_sql_id=462qrk7rf02kq */  (accessing        'ORA_SHARD_POOL@ORA_MULTI_TARGET' ) 21 rows selected. DEMO --------------- 1. 下载demo,Doc ID 2184500.1 2. 在gsm节点解压缩 3. 创建额外一些对象,运行下面脚本,可能需要手动修改demo_app_ext.sql中app_schema的密码 $ cd sdb_demo_app/sql  $ sqlplus / as sysdba  SQL>@demo_app_ext.sql 4. 修改配置文件 name=demo connect_string=(ADDRESS_LIST=(LOAD_BALANCE=off)(FAILOVER=on)(ADDRESS=(HOST=gsm1)(PORT=1522)(PROTOCOL=tcp))) monitor.user=dbmonuser monitor.pass=TEZiPP4MsLLL app.service.write=oltp_rw_srvc.shdb.oradbcloud #app.service.write=oltp_rw_srvc.orasdb.oradbcloud app.service.readonly= oltp_rw_srvc.shdb.oradbcloud  #app.service.readonly=oltp_ro_srvc.orasdb.oradbcloud app.user=app_schema app.pass=oracle app.threads=7 5. 运行demo ./run.sh demo 6. 运行monitor ./run.sh monitor 7. 访问web,监控性能。性能与测试环境有关系,这篇文章只是提供一个实验环境,非生产环境。 参考文档 ======== http://docs.oracle.com/database/122/ADMIN/sharding-overview.htm#ADMIN-GUID-0F39B1FB-DCF9-4C8A-A2EA-88705B90C5BF http://www.oracle.com/technetwork/database/availability/sharding-adg-createshard-cookbook-3610619.pdf

Oracle Sharding简介 ================ Oracle Sharding是Oracle 12.2版本推出的新功能,也称为数据分片,适用于online transaction processing (OLTP)....

技术共享

一条SQL语句究竟会产生多少个并行进程?

有一些数据库性能问题可能是因为同时启动的并行进程过多造成的,特别常见于RAC节点重启,很多时候是因为瞬间启动了几百个并行进程,导致OS各项指标“彪高”,后台进程失去响应。最近遇到的一个,是因为SQL语句中写了/*+ parallel a,8*/  ,但是在RAC的两个节点上各启动了512个并行进程,一共启动了1024个并行进程,导致网络心跳丢失。因为问题可以通过执行这个语句重现,而使用parallel_force_local=true可以workaround这个问题,所以基本可以确定是跨节点并行导致的。抛开这个问题背后的其他因素不谈,我们单来讨论一下:一条SQL语句究竟会产生多少个并行进程?一条SQL语句使用的并行度受3个层面的数值影响:1)hint中指定的并行度select /*+ parallel(a,8) */ * from scott.emp a order by ename;2)表的并行度,也就是表的degree:select owner,table_name,degree from dba_tables where table_name='EMP';OWNER                          TABLE_NAME                     DEGREE   ------------------------------ ------------------------------ ----------SCOTT                          EMP                                     2 3)auto DOP单节点:auto DOP = PARALLEL_THREADS_PER_CPU x CPU_COUNTRAC:auto DOP = PARALLEL_THREADS_PER_CPU x CPU_COUNT x INSTANCE_COUNT他们的优先级是hint>degree>auto DOP,也就是说:1)如果hint指定了并行度,会忽略表的degree。2)如果hint只指定parallel,不写具体的数字,或者表上DEGREE显示为DEFAULT,没有具体数值(alter table scott.emp parallel不指定具体degree数值),则会使用auto DOP。除此之外,还有以下一些规则:1)如果表中有group by或者其他排序操作,以上并行度×2。2)RAC中,并行度会自动平均分配到各个节点上,比如并行度256,2个节点,则每个节点上各起128个并行进程。“并行度>parallel_max_servers”的判断在各个节点上进行。3)在PARALLEL_ADAPTIVE_MULTI_USER = TRUE 的情况下,会根据系统load(当前正在使用并行的用户数),将并行度乘以一个衰减因子。4)如果以上并行度>parallel_max_servers能够提供的空闲并行进程数,则最终并行度=0,也就是不并行(不使用Pnnn的进程)。举一些例子来更详细的说明它:1)如果SQL中没有使用hint,而表上degree=1则并行度=0;2)如果SQL中没有使用hint,而表上degree=DEFAULT 则并行度=PARALLEL_THREADS_PER_CPU x CPU_COUNT x INSTANCE_COUNT;3)如果SQL中没有使用hint,而表上degree>1 则并行度=表上degree;4)如果SQL中使用没有数值的hint(/*+ parallel */ ),无论表上degree的值是多少,并行度= PARALLEL_THREADS_PER_CPU x CPU_COUNT x INSTANCE_COUNT;5)如果SQL中使用带数值的hint(/*+ parallel (a,8)*/ or /*+ parallel (a 8)*/ ),无论表上degree的值是多少,并行度= hint中的数值(8);6)如果有排序操作,以上并行度×2;7)并行度分配到各个RAC节点,乘以衰减因子,如果最终并行度>parallel_max_servers能够提供的空闲并行进程数,则并行度=0;这个用户的问题是,hint的写法写错了,没有使用括号,写成了/*+ parallel a,8*/,系统认为就是/*+ parallel a*/,而忽略了后面的数字8,结果使用了自动并行度= PARALLEL_THREADS_PER_CPU x CPU_COUNT x INSTANCE_COUNT;而语句中又有group by,于是最终并行度= PARALLEL_THREADS_PER_CPU x CPU_COUNT x INSTANCE_COUNT × 2。在现在的多CPU主机上,auto DOP是比较危险的,一般都会产生较多的并行进程。

有一些数据库性能问题可能是因为同时启动的并行进程过多造成的,特别常见于RAC节点重启,很多时候是因为瞬间启动了几百个并行进程,导致OS各项指标“彪高”,后台进程失去响应。最近遇到的一个,是因为SQL语句中写了/*+ parallel a,8*/  ,但是在RAC的两个节点上各启动了512个并行进程,一共启动了1024个并行进程,导致网络心跳丢失。因...

TimesTen

双向多主复制环境下的timesten升级测试

背景 =========== 客户升级应用,但应用打包了timesten,所以升级应用过程中涉及timesten的重装,所以如何避免升级过程中因升级而写入升级库的数据不被复制到另一边的未升级环境就成了问题。本测试步骤用升级过程中插入数据 application upgrade来模拟应用升级的数据插入。 环境 ============= 两个虚拟机,ADG和ADG2,重装(升级)ADG的timesten,升级过程中(恢复ADG2到ADG复制之前)的数据不复制到ADG。 配置(双向多主复制) =================== ADG1: create replication REP.REPSCHEME1 element "COMPLETE1" datastore master "ACTIVE" on "ADG2" subscriber "ACTIVE" on "ADG" element "COMPLETE2" datastore master "ACTIVE" on "ADG" subscriber "ACTIVE" on "ADG2" store "ACTIVE" on "ADG2" port 16090 store "ACTIVE" on "ADG" port 16093 ; CALL ttRepStart; ttAdmin -repPolicy always active ADG2: ttRepAdmin -duplicate -from active -host adg -uid repl -pwd repl "dsn=active" ttAdmin -repPolicy always active <<<<adg: Command> call ttrepstop; Command> drop replication REP.REPSCHEME1; Command> drop replication REP.REPSCHEME2; Command> create replication REP.REPSCHEME1 > element "COMPLETE1" datastore > master "ACTIVE" on "ADG2" > subscriber "ACTIVE" on "ADG" > element "COMPLETE2" datastore > master "ACTIVE" on "ADG" > subscriber "ACTIVE" on "ADG2" > store "ACTIVE" on "ADG2" > port 16090 > store "ACTIVE" on "ADG" > port 16093 > ; Command> CALL ttRepStart; Command> create user repl identified by 'repl'; 15004: User REPL already exists The command failed. Command> exit Disconnecting... Done. [oracle@adg bin]$ ./ttAdmin -repPolicy always active RAM Residence Policy : inUse Replication Agent Policy : always Cache Agent Policy : manual Cache Agent Manually Started : False [oracle@adg bin]$ ./ttisql active Copyright (c) 1996, 2016, Oracle and/or its affiliates. All rights reserved. Type ? or "help" for help, type "exit" to quit ttIsql. connect "DSN=active"; Connection successful: DSN=active;UID=oracle;DataStore=/home/oracle/TimesTen/tt1122/info/active;DatabaseCharacterSet=WE8MSWIN1252;ConnectionCharacterSet=US7ASCII;DRIVER=/home/oracle/TimesTen /tt1122/lib/libtten.so;PermSize=64;TypeMode=0; (Default setting AutoCommit=1) Command> insert into rep.t1 values(1,'test2'); 907: Unique constraint (T1 on REP.T1) violated at Rowid <BMUFVUAAACZAAAAKDR> The command failed. Command> insert into rep.t1 values(3,'test3'); 1 row inserted. Command> commit; Command> select * from rep.t1; < 1, test > < 2, test > < 3, test3 > < 4, test4 > 4 rows found. Command> <<<<adg2 [oracle@adg2 bin]$ ./ttdestroy active [oracle@adg2 bin]$ ./ttRepAdmin -duplicate -from active -host adg -localhost adg2 -uid repl -pwd repl "dsn=active" [oracle@adg2 bin]$ ttIsql -e "call ttrepstart;exit;" active -bash: ttIsql: command not found [oracle@adg2 bin]$ ./ttIsql -e "call ttrepstart;exit;" active Copyright (c) 1996, 2016, Oracle and/or its affiliates. All rights reserved. Type ? or "help" for help, type "exit" to quit ttIsql. connect "DSN=active"; Connection successful: DSN=active;UID=oracle;DataStore=/home/oracle/TimesTen/tt1122/info/active;DatabaseCharacterSet=WE8MSWIN1252;ConnectionCharacterSet=US7ASCII;DRIVER=/home/oracle/TimesTen /tt1122/lib/libtten.so;PermSize=64;TypeMode=0; (Default setting AutoCommit=1) call ttrepstart; exit; Disconnecting... Done. [oracle@adg2 bin]$ ./ttAdmin -repPolicy always active RAM Residence Policy : inUse Replication Agent Policy : always Cache Agent Policy : manual Cache Agent Manually Started : False [oracle@adg2 bin]$ ./ttisql active Copyright (c) 1996, 2016, Oracle and/or its affiliates. All rights reserved. Type ? or "help" for help, type "exit" to quit ttIsql. connect "DSN=active"; Connection successful: DSN=active;UID=oracle;DataStore=/home/oracle/TimesTen/tt1122/info/active;DatabaseCharacterSet=WE8MSWIN1252;ConnectionCharacterSet=US7ASCII;DRIVER=/home/oracle/TimesTen /tt1122/lib/libtten.so;PermSize=64;TypeMode=0; (Default setting AutoCommit=1) Command> select * from rep.t1; < 1, test > < 2, test > < 3, test3 > 3 rows found. Command> insert into rep.t1 values(4,'test4'); 1 row inserted. Command> commit; ========== 升级过程 ================= <<<Step 1 配置静态复制端口,跳过,因为已经使用了静态端口复制 <<<Step 2&3,停止待升级的adg上的应用连接,并在adg2上pause adg2到adg的复制,不是直接停掉复制,这样可以等待transaction log上的事务在停复制前复制到adg上而不是丢失(因为升级后第10步是reset receiver,会清掉bookmark)。 <--adg [oracle@adg2 bin]$ ./ttRepAdmin -receiver -name active -state pause active [oracle@adg2 bin]$ ./ttisql active Copyright (c) 1996, 2016, Oracle and/or its affiliates. All rights reserved. Type ? or "help" for help, type "exit" to quit ttIsql. connect "DSN=active"; Connection successful: DSN=active;UID=oracle;DataStore=/home/oracle/TimesTen/tt1122/info/active;DatabaseCharacterSet=WE8MSWIN1252;ConnectionCharacterSet=US7ASCII;DRIVER=/home/oracle/TimesTen /tt1122/lib/libtten.so;PermSize=64;TypeMode=0; (Default setting AutoCommit=1) Command> select * from rep.t1; < 1, test > < 2, test > < 3, test3 > < 4, test4 > < 5, upgrade_step3 > 5 rows found. Command> insert into rep.t1 values(6,'upgrade_step3_adg2');<===pause复制后,在adg2插入一条数据 1 row inserted. Command> commit; Command> select * from rep.t1; < 1, test > < 2, test > < 3, test3 > < 4, test4 > < 5, upgrade_step3 > < 6, upgrade_step3_adg2 > 6 rows found. [oracle@adg bin]$ ./ttisql active Copyright (c) 1996, 2016, Oracle and/or its affiliates. All rights reserved. Type ? or "help" for help, type "exit" to quit ttIsql. connect "DSN=active"; Connection successful: DSN=active;UID=oracle;DataStore=/home/oracle/TimesTen/tt1122/info/active;DatabaseCharacterSet=WE8MSWIN1252;ConnectionCharacterSet=US7ASCII;DRIVER=/home/oracle/TimesTen /tt1122/lib/libtten.so;PermSize=64;TypeMode=0; (Default setting AutoCommit=1) Command> insert into rep.t1 values(5,'upgrade_step3'); 1 row inserted. Command> commit; Command> select * from rep.t1; < 1, test > < 2, test > < 3, test3 > < 4, test4 > < 5, upgrade_step3 ><====在adg2 pause receiver之后,adg2新插入的记录没有传播到adg 5 rows found. <<<Step4 停止两边的rep agent,从此没有更新发送到对方 <---adg [oracle@adg bin]$ ./ttAdmin -repStop active *** [TimesTen][TimesTen 11.2.2.8.18 ODBC Driver][TimesTen]TT10016: Replication Agent was not stopped due to repPolicy setting. *** ODBC Error = S1000, TimesTen Error = 10016 [oracle@adg bin]$ ./ttAdmin -repPolicy manual active RAM Residence Policy : inUse Replication Agent Policy : manual Replication Manually Started : True Cache Agent Policy : manual Cache Agent Manually Started : False [oracle@adg bin]$ ./ttAdmin -repStop active RAM Residence Policy : inUse Replication Agent Policy : manual Replication Manually Started : False Cache Agent Policy : manual Cache Agent Manually Started : False <---adg2 [oracle@adg2 bin]$ ./ttAdmin -repPolicy manual active RAM Residence Policy : inUse Replication Agent Policy : manual Replication Manually Started : True Cache Agent Policy : manual Cache Agent Manually Started : False [oracle@adg2 bin]$ ./ttAdmin -repStop active RAM Residence Policy : inUse Replication Agent Policy : manual Replication Manually Started : False Cache Agent Policy : manual Cache Agent Manually Started : False <<<Step5<===防止adg2上有积压的更新发送到adg [oracle@adg bin]$ ./ttRepAdmin -receiver -name active -state stop active [oracle@adg bin]$ <<<Step6<==备份 [oracle@adg bin]$ ./ttMigrate -c active /home/oracle/backup.dat Saving user PUBLIC User successfully saved. Saving user REP User successfully saved. Saving user REPL User successfully saved. Saving table REP.T1 Saving rows... 5/5 rows saved. Table successfully saved. Saving table REP.T2 Saving rows... 0/0 rows saved. Table successfully saved. <<<Step7<===adg删库;adg2重启repagent <--adg删库 [oracle@adg bin]$ ./ttdestroy active [oracle@adg bin]$ <--adg2 重启repagent [oracle@adg2 bin]$ ./ttAdmin -repStart active RAM Residence Policy : inUse Replication Agent Policy : manual Replication Manually Started : True Cache Agent Policy : manual Cache Agent Manually Started : False [oracle@adg2 bin]$ <<<Step8 <--adg,重装(或升级) [oracle@adg bin]$ ./ttdaemonadmin -stop TimesTen Daemon stopped. [oracle@adg ~]$ cd [oracle@adg ~]$ rm -rf TimesTen [oracle@adg linux8664]$ rm -rf /etc/TimesTen/instance_info [oracle@adg ~]$ cd install/linux8664/ [oracle@adg linux8664]$ ./setup.sh There is 1 TimesTen instance installed locally : 1) tt1122 (TimesTen11.2.2.8) Of the following options : [1] Install a new instance [2] Upgrade an existing instance [3] Display information about an existing instance [q] Quit the installation Which would you like to perform? [ 1 ] 1 * The default instance name 'tt1122' is in use. ... The 11.2.2.8 Release Notes are located here : '/home/oracle/TimesTen/tt1122/README.html' Starting the daemon ... TimesTen Daemon startup OK. End of TimesTen installation. <--adg2,恢复从adg2到adg的replication,并插入一条测试数据 [oracle@adg2 bin]$ ./ttRepAdmin -receiver -name active -state start active [oracle@adg2 bin]$ ./ttisql active Copyright (c) 1996, 2016, Oracle and/or its affiliates. All rights reserved. Type ? or "help" for help, type "exit" to quit ttIsql. connect "DSN=active"; Connection successful: DSN=active;UID=oracle;DataStore=/home/oracle/TimesTen/tt1122/info/active;DatabaseCharacterSet=WE8MSWIN1252;ConnectionCharacterSet=US7ASCII;DRIVER=/home/oracle/TimesTen/tt1122/lib/libtten.so;PermSize=64;TypeMode=0; (Default setting AutoCommit=1) Command> insert into rep.t1 values(8,'during upgrade'); 1 row inserted. Command> commit; <<<Step9,adg导回备份 将active的dsn加回info/sys.odbc.ini: [active] Driver=/home/oracle/TimesTen/tt1122/lib/libtten.so DataStore=/home/oracle/TimesTen/tt1122/info/active PermSize=64 DatabaseCharacterSet=WE8MSWIN1252 然后还原备份: [oracle@adg bin]$ ./ttmigrate -r active /home/oracle/backup.dat Restoring user REP Restoring privileges... Privileges restored. User successfully restored. Restoring user REPL Restoring privileges... Privileges restored. User successfully restored. Restoring table REP.T1 Restoring rows... 5/5 rows restored. Table successfully restored. Restoring table REP.T2 Restoring rows... 0/0 rows restored. Table successfully restored. Restoring replication schema (supports replicated sequences) REP.REPSCHEME1 Replication schema (supports replicated sequences) successfully restored. [oracle@adg bin]$ ./ttisql active Copyright (c) 1996, 2016, Oracle and/or its affiliates. All rights reserved. Type ? or "help" for help, type "exit" to quit ttIsql. connect "DSN=active"; Connection successful: DSN=active;UID=oracle;DataStore=/home/oracle/TimesTen/tt1122/info/active;DatabaseCharacterSet=WE8MSWIN1252;ConnectionCharacterSet=US7ASCII;DRIVER=/home/oracle/TimesTen/tt1122/lib/libtten.so;PermSize=64;TypeMode=0; (Default setting AutoCommit=1) Command> insert into rep.t1 values(9,'application upgrade');《----插入数据模拟应用升级过程中的数据写入,这条数据不应该被复制到adg2 1 row inserted. Command> commit; <<<Step10, 通过把adg2的receiver state重置来清空adg的replication bookmark和txn logs,并重启replication [oracle@adg bin]$ ./ttRepAdmin -receiver -name active -reset active [oracle@adg bin]$ ./ttRepAdmin -receiver -name active -state stop active [oracle@adg bin]$ ./sleep 10 [oracle@adg bin]$ ./ttRepAdmin -receiver -name active -state start active <<<Step11 启动adg到adg2的复制 [oracle@adg bin]$ ./ttAdmin -repStart active RAM Residence Policy : inUse Replication Agent Policy : manual Replication Manually Started : True Cache Agent Policy : manual Cache Agent Manually Started : False <<<Step12 两节点插入数据并检查 <--adg [oracle@adg bin]$ ./ttisql active Copyright (c) 1996, 2016, Oracle and/or its affiliates. All rights reserved. Type ? or "help" for help, type "exit" to quit ttIsql. connect "DSN=active"; Connection successful: DSN=active;UID=oracle;DataStore=/home/oracle/TimesTen/tt1122/info/active;DatabaseCharacterSet=WE8MSWIN1252;ConnectionCharacterSet=US7ASCII;DRIVER=/home/oracle/TimesTen/tt1122/lib/libtten.so;PermSize=64;TypeMode=0; (Default setting AutoCommit=1) Command> select * from rep.t1; < 1, test > < 2, test > < 3, test3 > < 4, test4 > < 5, upgrade_step3 > < 8, during upgrade > < 9, application upgrade > 7 rows found. Command> insert into rep.t1 values(11,'after upgrade'); 1 row inserted. Command> commit; Command> select * from rep.t1; < 1, test > < 2, test > < 3, test3 > < 4, test4 > < 5, upgrade_step3 > < 8, during upgrade > < 9, application upgrade > < 10, after upgrade > < 11, after upgrade > 9 rows found. Command> <--adg2 [oracle@adg2 bin]$ ./ttisql active Copyright (c) 1996, 2016, Oracle and/or its affiliates. All rights reserved. Type ? or "help" for help, type "exit" to quit ttIsql. connect "DSN=active"; Connection successful: DSN=active;UID=oracle;DataStore=/home/oracle/TimesTen/tt1122/info/active;DatabaseCharacterSet=WE8MSWIN1252;ConnectionCharacterSet=US7ASCII;DRIVER=/home/oracle/TimesTen/tt1122/lib/libtten.so;PermSize=64;TypeMode=0; (Default setting AutoCommit=1) Command> insert into rep.t1 values(10,'after upgrade'); 1 row inserted. Command> commit; Command> select * from rep.t1; < 1, test > < 2, test > < 3, test3 > < 4, test4 > < 5, upgrade_step3 > < 6, upgrade_step3_adg2 > < 8, during upgrade ><===可以看到第9条数据“application upgrade”没有写入adg2节点 < 10, after upgrade > < 11, after upgrade > 9 rows found. Command> 结论 ====== 这个步骤虽然是用于双向多主复制的timesten升级的,但同样适用于Application升级。 通过如上测试记录可见,第9步导回数据库后插入的记录,在第10步重置adg到adg2的replication bookmark&txn log并启动复制后,是没有被复制到adg2的。 注:我这里将两边的datastore名称都设置为active了,所以执行ttRepAdmin -receiver的时候容易弄错节点,这个命令应该在它所修改的复制方向的主库上运行(例如adg到adg2就在adg上跑)。

背景 =========== 客户升级应用,但应用打包了timesten,所以升级应用过程中涉及timesten的重装,所以如何避免升级过程中因升级而写入升级库的数据不被复制到另一边的未升级环境就成了问题。本测试步骤用升级过程中插入数据 application upgrade来模拟应用升级的数据插入。 环境 =============两个虚拟机,ADG和ADG2,重装(升级)ADG的timesten...

测试案例

在VirtualBox环境中安装Solaris 10(x86-64)上的Oracle 11.2.0.4双节点RAC

概述 本文来自Oracle数据库产品技术支持官方博客: https://blogs.oracle.com/Database4CN/   本文包含截图,如果需要下载完整的版本,请下载附件。   //cdn.app.compendium.com/uploads/user/e7c690e8-6ff9-102a-ac6d-e4aebca50425/f4a5b21d-66fa-4885-92bf-c4e81c06d916/File/002e5704435631113d7b8a222305f5a1/virtualbox_solaris_oracle_11_2_0_4_rac.001 //cdn.app.compendium.com/uploads/user/e7c690e8-6ff9-102a-ac6d-e4aebca50425/f4a5b21d-66fa-4885-92bf-c4e81c06d916/File/b54322ebb581571019bff633a9d38893/virtualbox_solaris_oracle_11_2_0_4_rac.002 //cdn.app.compendium.com/uploads/user/e7c690e8-6ff9-102a-ac6d-e4aebca50425/f4a5b21d-66fa-4885-92bf-c4e81c06d916/File/e9d9d191ad9804a832f36a263d9568dc/virtualbox_solaris_oracle_11_2_0_4_rac.003 //cdn.app.compendium.com/uploads/user/e7c690e8-6ff9-102a-ac6d-e4aebca50425/f4a5b21d-66fa-4885-92bf-c4e81c06d916/File/a98719dbec02ca06da04446d09c317de/virtualbox_solaris_oracle_11_2_0_4_rac.004 //cdn.app.compendium.com/uploads/user/e7c690e8-6ff9-102a-ac6d-e4aebca50425/f4a5b21d-66fa-4885-92bf-c4e81c06d916/File/a078a7143173d32dcceaaf7431390ffb/virtualbox_solaris_oracle_11_2_0_4_rac.005   本文的目的是以VirtualBox实现在Solaris 10(x86-64)操作系统上两节点的Oracle11.2.0.4 RAC,本实验会先创建一个虚拟机host1,然后用VirtualBox复制的功能创建host2, 这样我们就能得到两台对称的主机用作RAC的两个节点。   本文主要参考: http://docs.oracle.com/cd/E11882_01/install.112/e47805/toc.htm   Solaris操作系统的安装以及配置并不是本文的重点,不过在本文附录中介绍了安装RAC可能会用到的Solaris命令。 环境准备 VirtualBox: https://www.virtualbox.org/ Host: Windows 10 x86-64; 70G Disk; 8G Memory; Intel(R) Core(TM) i3-6100 CPU @ 3.70GHz Guest: Solaris 10 x86-64; 20G Disk; 3G Memory; 2 CPU Solaris安装介质: [sol-10-u11-ga-x86-dvd.iso] http://www.oracle.com/technetwork/server-storage/solaris10/downloads/index.html Oracle安装介质: [选择Solaris x86-64] https://updates.oracle.com/download/13390677.html 目录结构 vm   |   |--- sol10        |        |---host1        |    |--------disk1.vdi(20g)        |        |---host2        |    |--------disk1.vdi(20g)        |        |--- shared-disk                |--------disk1.vdi(1g)                |--------disk2.vdi(1g)                |--------disk3.vdi(1g)                |--------disk4.vdi(10g)                |--------disk5.vdi(10g) 虚拟机配置清单   虚拟磁盘规划 磁盘 分区 挂载点 文件系统 大小 host1/disk1 c0t0d0s0 / ufs 14g c0t0d0s1 swap 6g host2/disk1 c0t0d0s0 / ufs 14g c0t0d0s1 swap 6g shared-disk/disk[1-3] 用做normal redundancy的ocr和voting files 1g*3 shared-disk/disk[4-5] 用做normal redundancy的disk group存放数据文件 10g*2 ip规划 将宿主机中的VirtualBox Host-Only Network这个虚拟网卡的ip设置为10.4.120.1以便能与虚拟机通讯, 如下是规划的虚拟机ip信息 host1 e1000g0 e1000g1 ip 10.4.120.15 192.168.1.15 netmask 255.255.255.0 255.255.255.0 gateway 10.4.120.1 host2 e1000g0 e1000g1 ip 10.4.120.16 192.168.1.16 netmask 255.255.255.0 255.255.255.0 gateway 10.4.120.1 安装Solaris 10系统 安装host1的时候,先不用在VirtualBox挂上shared-disk,可以等host1完全安装完毕,并且成功复制出host2后,再挂shared-disk。 Solaris选择最小化安装Core System Support Software Group(Core Group)即可,安装时注意给swap分配6G,剩余磁盘全部给/,创建文件系统时选择ufs文件系统。 设置主机和IP # cat /etc/nodename   host1   # cat /etc/hosts   ::1 localhost 127.0.0.1 localhost 10.4.120.15     host1   loghost 10.4.120.16     host2 192.168.1.15    host1-priv 192.168.1.16    host2-priv 10.4.120.115    host1-vip 10.4.120.116    host2-vip   # cat /etc/hostname.e1000g0   host1   # cat /etc/hostname.e1000g1   host1-priv   # cat /etc/netmasks   10.4.120.0      255.255.255.0 192.168.1.0     255.255.255.0 关掉不用的服务 # svcadm disable svc:network/ftp # svcadm disable svc:network/telnet # svcadm disable svc:network/smtp:sendmail 添加安装RAC所必须的package 在添加安装手册中提到的package之前,建议先安装如下package,这些都不是安装RAC所必需的,不过安装后可以大大提高安装RAC的效率。 # pkginfo -i SUNWxcu4 SUNWbash SUNWman SUNWsshcu SUNWsshdu SUNWbind   如下是一个安装package的示例, 注意如果提示依赖关系, 那么需要先安装依赖的package # mount -F hsfs -o ro /dev/dsk/c1t0d0s2 /mnt/cdrom # pkgadd -d /mnt/cdrom/Solaris_10/Product/ SUNWbash   安装完以上package后就可以使用比sh更友好的bash了,如下:   # vi /etc/passwd   root:x:0:0:Super-User:/root:/usr/bin/bash   然后开启ssh, 这样我们可以远程ssh上来, 方便复制粘贴 # ssh-keygen -b 1024 -t rsa1 -f /etc/ssh/ssh_host_key -N "" # ssh-keygen -b 1024 -t rsa -f /etc/ssh/ssh_host_rsa_key -N "" # ssh-keygen -b 1024 -t dsa -f /etc/ssh/ssh_host_dsa_key -N "" # svcadm enable /network/ssh   允许root远程登录 # vi /etc/default/login   CONSOLE=/dev/console ---用#注释掉这一行   允许root ssh远程登录 # vi /etc/ssh/sshd_config   PermitRootLogin yes   重启后我们应当可以通过工具远程ssh到这个系统了,当可以远程ssh后,我们就可以按照文档要求的安装Oracle 11.2 GI & database 所需的package了:   # pkginfo -i SUNWarc SUNWbtool SUNWhea SUNWlibC SUNWlibm SUNWlibms SUNWsprot SUNWtoo SUNWi1of SUNWi1cs SUNWi15cs SUNWxwfnt SUNWcsl 安装VirtualBox增强功能 接下来建议安装VirtualBox增强功能, 有了VirtualBox增强功能,我们就可以挂载VirtualBox共享文件夹了, 这样就不需要把安装介质上传到虚拟机里面了, 参考 https://www.virtualbox.org/manual/ch04.html#idm2003   在虚拟机的存储中添加一个IDE控制器,然后添加光盘,将光盘放入如下iso文件 C:\Program Files\Oracle\VirtualBox\VBoxGuestAdditions.iso   然后启动虚拟机, 在虚拟机中mount光盘, 安装增强功能 # mount -F hsfs -o ro /dev/dsk/c1t0d0s2 /mnt/cdrom # pkgadd -G -d /mnt/cdrom/VBoxSolarisAdditions.pkg   如果今后想卸载VirtualBox增强功能, 可用如下命令 # pkgrm SUNWvboxguest 创建用户和组 执行如下命令以创建grid和oracle用户以及相关的组: # groupadd -g 1000 oinstall # groupadd -g 1100 asmadmin # groupadd -g 1101 asmdba # groupadd -g 1102 asmoper # groupadd -g 1200 dba # groupadd -g 1201 oper # useradd -u 1000 -g oinstall -G asmadmin,asmdba,asmoper,dba -d /export/home/grid -m -s /usr/bin/bash -c "Grid Infrastructure Owner" grid # useradd -u 1001 -g oinstall -G asmdba,dba,oper -d /export/home/oracle -m -s /usr/bin/bash -c "Oracle Software Owner" oracle   # passwd grid grid123   # passwd oracle oracle123   # id -a grid uid=1000(grid) gid=1000(oinstall) groups=1100(asmadmin),1101(asmdba),1102(asmoper),1200(dba)   # id -a oracle uid=1001(oracle) gid=1000(oinstall) groups=1101(asmdba),1200(dba),1201(oper) 建立grid & Oracle软件安装目录 用如下命令创建grid和oracle software的安装目录 # mkdir -p /u01/app/grid # mkdir -p /u01/app/11.2.0/grid # chown -R grid:oinstall /u01 # mkdir -p /u01/app/oracle/product/11.2.0/dbhome_1 # chown -R oracle:oinstall /u01/app/oracle # chmod -R 775 /u01   根据文档要求创建与ssh相关的软连接 http://docs.oracle.com/cd/E11882_01/install.112/e47805/presolar.htm#CWSOL227   # ln -s /etc/ssh /usr/local/etc # ln -s /usr/bin /usr/local/bin 配置内核参数 查看udp 和 tcp port范围 # /usr/sbin/ndd /dev/tcp tcp_smallest_anon_port tcp_largest_anon_port   根据安装文档, 需要将以上参数设置成如下   # /usr/sbin/ndd -set /dev/tcp tcp_smallest_anon_port 9000 # /usr/sbin/ndd -set /dev/tcp tcp_largest_anon_port 65500 # /usr/sbin/ndd -set /dev/udp udp_smallest_anon_port 9000 # /usr/sbin/ndd -set /dev/udp udp_largest_anon_port 65500   不过以上设置会在重启后丢失, 无法永久保存, 创建如下启动脚本让Solaris启动的时候, 自动修改udp和tcp的参数   # cat /etc/init.d/rac_udp_tcp   #!/sbin/sh   case "$1" in 'start')         /usr/sbin/ndd -set /dev/tcp tcp_smallest_anon_port 9000         /usr/sbin/ndd -set /dev/tcp tcp_largest_anon_port 65500         /usr/sbin/ndd -set /dev/udp udp_smallest_anon_port 9000         /usr/sbin/ndd -set /dev/udp udp_largest_anon_port 65500         ;;       *)         echo "Usage: $0 start"         exit 1         ;; esac exit 0   # chmod +x /etc/init.d/rac_udp_tcp # ln -s /etc/init.d/rac_udp_tcp /etc/rc3.d/S30rac_udp_tcp   配置kernel参数(default) # projmod -sK "project.max-shm-memory=(priv,4GB,deny)" default # projmod -sK "project.max-sem-nsems=(priv,256,deny)" default # projmod -sK "project.max-sem-ids=(priv,100,deny)" default # projmod -sK "project.max-shm-ids=(priv,100,deny)" default # projmod -sK "process.max-file-descriptor=(basic,65536,deny),(privileged,65536,deny)" default # projmod -sK "process.max-stack-size=(basic,33554432,deny),(privileged,33554432,deny)" default   下面把root的也配了, 因为crs是root启动的, crs启动时会继承root的project配置, 如果不配root的话, 在通过root用户配置gi(运行root.sh)或者启动asm资源时可能会发生如下错误:   ORA-27102: out of memory Solaris-AMD64 Error: 22: Invalid argument   配置kernel参数(root) # projmod -sK "project.max-shm-memory=(priv,4GB,deny)" user.root # projmod -sK "project.max-sem-nsems=(priv,256,deny)" user.root # projmod -sK "project.max-sem-ids=(priv,100,deny)" user.root # projmod -sK "project.max-shm-ids=(priv,100,deny)" user.root # projmod -sK "process.max-file-descriptor=(basic,65536,deny),(privileged,65536,deny)" user.root # projmod -sK "process.max-stack-size=(basic,33554432,deny),(privileged,33554432,deny)" user.root   查看poeject配置, 多种方法 # cat /etc/project # projects -l # prctl -n project.max-shm-memory -i project user.root   如果今后需要将project的配置还原, 只需要将以上的-sK 换成 -rK即可, 例如   # projmod -rK "project.max-shm-memory=(priv,4GB,deny)" default ...... # projmod -rK "project.max-shm-memory=(priv,4GB,deny)" user.root ...... 配置bash环境变量 root用户(非必须, 只是为了今后执行crsctl等命令方便) # vi .bash_profile   PATH=/usr/sbin:/usr/bin:/usr/sfw/bin   ORACLE_SID=+ASM1 ORACLE_BASE=/u01/app/grid ORACLE_HOME=/u01/app/11.2.0/grid PATH=$PATH:$ORACLE_HOME/bin:$ORACLE_HOME/OPatch   export ORACLE_SID ORACLE_BASE ORACLE_HOME PATH   grid用户 # su - grid $ vi .bash_profile   if [ -t 0 ]; then    stty intr ^C fi   # User specific environment and startup programs   ORACLE_SID=+ASM1 ORACLE_BASE=/u01/app/grid ORACLE_HOME=/u01/app/11.2.0/grid PATH=$PATH:$ORACLE_HOME/bin:$ORACLE_HOME/OPatch   export ORACLE_SID ORACLE_BASE ORACLE_HOME PATH umask 022   oracle用户 # su - oracle $ vi .bash_profile   if [ -t 0 ]; then    stty intr ^C fi   ORACLE_SID=orcl1 ORACLE_BASE=/u01/app/oracle ORACLE_HOME=$ORACLE_BASE/product/11.2.0/dbhome_1 PATH=$PATH:$ORACLE_HOME/bin:$ORACLE_HOME/OPatch   export ORACLE_SID ORACLE_BASE ORACLE_HOME PATH umask 022 配置DNS server以提供对scan ip的解析 注意DNS server端可在宿主机中安装bind来实现, 本例宿主机为windows, 可以选择ISC BIND, 它的配置与Linux上的bind相同 https://www.isc.org/downloads/   默认isc-bind会安装在C:\Program Files\ISC BIND 9\目录中, 在这个目录中创建子目录etc, 然后在etc中创建如下3个文件:   named.conf myrac.com.zone 120.4.10.in-addr.arpa   文件内容参考目录isc-bind,本文也把这些文件内容贴出来了供参考:   文件named.conf内容 options { directory "C:\Program Files\ISC BIND 9\etc"; };   zone "myrac.com" in { type master; file "myrac.com.zone"; };   zone "120.4.10.in-addr.arpa" in { type master; file "120.4.10.in-addr.arpa"; };   文件myrac.com.zone内容 $TTL 6h @ IN SOA ns1.myrac.com. hostmaster.myrac.com. ( 2017010100 10800 3600 604800 86400 )   @ NS ns1.myrac.com.   ns1 IN A 10.4.120.1   host1 IN A 10.4.120.15 host2 IN A 10.4.120.16 host1-vip IN A 10.4.120.115 host2-vip IN A 10.4.120.116 my-rac-scan IN A 10.4.120.110 my-rac-scan IN A 10.4.120.111 my-rac-scan IN A 10.4.120.112   文件120.4.10.in-addr.arpa内容 $TTL 6h @ IN SOA ns1.myrac.com. hostmaster.myrac.com. ( 2017010100 10800 3600 604800 86400 )   @ NS ns1.myrac.com.   1 IN PTR ns1.myrac.com.   15 IN PTR host1.myrac.com. 16 IN PTR host2.myrac.com. 115 IN PTR host1-vip.myrac.com. 116 IN PTR host2-vip.myrac.com. 110 IN PTR my-rac-scan.myrac.com. 111 IN PTR my-rac-scan.myrac.com. 112 IN PTR my-rac-scan.myrac.com.   以上配置文件完毕后, 在windows的服务中启动ISC BIND服务   在guest host中配置DNS客户端以解析scan ip # vi /etc/resolv.conf   domain myrac.com nameserver 10.4.120.1   # vi /etc/nsswitch.conf   hosts:      dns files   在guest host中测试DNS是否工作正常   # nslookup ns1 # nslookup my-rac-scan # nslookup 10.4.120.1 # nslookup 10.4.120.110 复制生成另一个节点host2 shutdown当前host1后, 在VirtualBox主界面: 控制->复制, 注意勾选 "重新初始化所有网卡的 MAC 地址" 配置另一个节点host2 复制完毕后, 适当修改host2.vbox里的相关信息, 主要是将MAC地址信息调整成上下文一致。然后启动新节点, 修改新节点的ip(参考本文开始的ip规划) # vi /etc/nodename # vi /etc/hosts # vi /etc/hostname.e1000g0 # vi /etc/hostname.e1000g1 # vi /etc/netmasks   修改新节点的root/grid/oracle用户的.bash_profile中的$ORACLE_SID 为 +ASM2/orcl2(略), 重启新创建的节点使修改生效 挂载共享磁盘 关闭host1和host2,然后按照之前规划的目录结构创建shared-disk目录,然后在VirtualBox的host1中,添加shared-disk的磁盘1-5,然后回到VirtualBox主界面: 管理->虚拟介质管理,选中shared-disk的磁盘,点击[修改],弹出的界面中选择[可共享]; 将shared-disk的disk[1-5]都改成[可共享] 然后在host2的VirtualBox界面中添加磁盘,选择[使用现有的虚拟盘],浏览到shared-disk文件夹,按顺序将将shared-disk目录里的disk[1-5]添加到host2的SATA存储中。 分别启动host1, host2,分别执行如下命令 # touch /reconfigure 然后再重启观察新磁盘是否能在所有host中看到,并且设备名称统一。 配置节点互信 启动所有节点, 先对grid用户配置互信, 如下命令需要在host1和host2中都执行 # su - grid $ mkdir -p ~/.ssh $ chmod 700 ~/.ssh $ ssh-keygen -t rsa   如下命令只需要在host1中执行执行 $ touch ~/.ssh/authorized_keys $ ssh host1 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys $ ssh host2 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys $ scp ~/.ssh/authorized_keys host2:.ssh/authorized_keys   如下命令需要在host1和host2中都执行 $ chmod 600 ~/.ssh/authorized_keys   测试互信, 所有节点grid用户执行如下命令直到不需要再输入密码为止   $ ssh host1 date $ ssh host2 date $ ssh host1-priv date $ ssh host2-priv date   然后以同样的方法, 对oracle用户配置互信(过程与grid完全一样,略) 执行安装检查 保持host1和host2都启动的状态, host1通过共享文件夹挂载安装介质, 在宿主机中, 将p13390677_112040_Solaris86-64_3of6.zip当前路径解压, 会解压出一个grid目录, 然后在VirtualBox运行界面临时分配一个共享文件夹, 路径选择解压出来的grid这个目录. 最后在虚拟机中挂载这个共享文件夹(注意grid是宿主机中的共享文件夹名称) # mount -F vboxfs -o ro grid /mnt/cdrom/ # su - grid $ /mnt/cdrom/runcluvfy.sh stage -pre crsinst -n host1,host2 -fixup -verbose 输出参考runcluvfy.txt,所有的检查项目都应当为"passed",并且最后提示: Pre-check for cluster services setup was successful. 安装GI software  以software only模式安装GI, 可以逐个节点安装, 只用启动需要安装的节点即可 # mount -F vboxfs -o ro grid /mnt/cdrom/ # su - grid $ export DISPLAY=10.4.120.1:0.0 $ /mnt/cdrom/runInstaller 注意选择software only, 安装完一个节点再安装其他节点, 截图及输出参考文件夹gi-software-only,如下是所有的步骤截图,供参考:   共享磁盘分区 在host1对共享磁盘分区, 注意共享磁盘分区只需要在任意一个节点执行即可, 具体命令及输出参考disk-format.txt,主要命令如下: (注意0为本地磁盘,1-5为共享磁盘) # format format> disk   AVAILABLE DISK SELECTIONS:        0. c0t0d0 <ATA    -VBOX HARDDISK  -1.0  cyl 2607 alt 2 hd 255 sec 63>           /pci@0,0/pci8086,2829@d/disk@0,0        1. c0t1d0 <ATA    -VBOX HARDDISK  -1.0 cyl 1020 alt 2 hd 64 sec 32>           /pci@0,0/pci8086,2829@d/disk@1,0        2. c0t2d0 <ATA    -VBOX HARDDISK  -1.0  cyl 1020 alt 2 hd 64 sec 32>           /pci@0,0/pci8086,2829@d/disk@2,0        3. c0t3d0 <ATA    -VBOX HARDDISK  -1.0  cyl 1020 alt 2 hd 64 sec 32>           /pci@0,0/pci8086,2829@d/disk@3,0        4. c0t4d0 <ATA    -VBOX HARDDISK  -1.0  cyl 1302 alt 2 hd 255 sec 63>           /pci@0,0/pci8086,2829@d/disk@4,0        5. c0t5d0 <ATA    -VBOX HARDDISK  -1.0  cyl 1302 alt 2 hd 255 sec 63>           /pci@0,0/pci8086,2829@d/disk@5,0 Specify disk (enter its number)[1]: 2 selecting c0t2d0 [disk formatted] format> p partition> p Current partition table (original): Total disk cylinders available: 1020 + 2 (reserved cylinders)   Part      Tag    Flag     Cylinders        Size            Blocks   0 unassigned    wm       0               0         (0/0/0)          0   1 unassigned    wm       0               0         (0/0/0)          0   2     backup    wu       0 - 1019     1020.00MB    (1020/0/0) 2088960   3 unassigned    wm       0               0         (0/0/0)          0   4 unassigned    wm       0               0         (0/0/0)          0   5 unassigned    wm       0               0         (0/0/0)          0   6 unassigned    wm       0               0         (0/0/0)          0   7 unassigned    wm       0               0         (0/0/0)          0   8       boot    wu       0 -    0        1.00MB    (1/0/0)       2048   9 unassigned    wm       0               0         (0/0/0)          0   partition> 6 Part      Tag    Flag     Cylinders        Size            Blocks   6 unassigned    wm       0               0         (0/0/0)          0   Enter partition id tag[unassigned]: usr Enter partition permission flags[wm]: Enter new starting cyl[1]: 3 Enter partition size[0b, 0c, 3e, 0.00mb, 0.00gb]: $ partition> label Ready to label disk, continue? y   partition> p partition> q format> q 值得注意是: 1) SATA端口1~5的磁盘都是共享磁盘,其中:    1~3共享磁盘为1G大小, 用于做normal redundancy的ocr和voting files;    4~5共享磁盘为10G大小, 用于做normal redundancy的disk group 存放数据文件. 2) 我们把整个磁盘都分给了part 6, 并tag为usr, 注意分区一定要从cylinder 3 开始,不能从0开始,注意Enter partition size的时候输入$代表所有剩余的磁盘 3) 分区完毕一定要执行label以保存   改变共享磁盘的owner及mode, 需要在host1和host2分别执行 # chown grid:asmadmin /dev/rdsk/c0t[1-5]d0s6 # chmod 660 /dev/rdsk/c0t[1-5]d0s6 # ls -lL /dev/rdsk/c0t[1-5]d0s6 配置GI 保持所有节点启动,但只需要以grid用户在一个节点执行即可, 本例在host1中执行 # su - grid $ export DISPLAY=10.4.120.1:0.0 $ /u01/app/11.2.0/grid/crs/config/config.sh 截图及输出参考文件夹gi-config 注意: 第9步会遇到bug 17274371, 参见gi-config/9.txt的描述:   https://docs.oracle.com/cd/E11882_01/relnotes.112/e23559/toc.htm#CJAEJECJ   Prerequisite Check May Fail When Installing Oracle Grid Infrastructure When installing Oracle Grid Infrastructure, although the correct owner, group, or permissions are set for Oracle ASM, the prerequisite check may fail with the following errors:   PRVF-9991 : Owner of device "device name" did not match the expected owner PRVF-9992 : Group of device "device name" did not match the expected group PRVF-9993 : Permission of device "device name" did not match the expected   Workaround: Ignore the error. This issue is tracked with Oracle bug 17274371. 如下是所有的步骤截图,供参考:   如果以上config失败, 可以deconfig清除配置, 逐个节点(不能是最后一个节点),root运行: # perl /u01/app/11.2.0/grid/crs/install/rootcrs.pl -deconfig -force deconfig最后一个节点执行的命令是不同的: # perl /u01/app/11.2.0/grid/crs/install/rootcrs.pl -deconfig -force -lastnode 安装Oracle数据库软件 建议选择software-only安装, 保持所有节点的crs启动,在host1以oracle执行即可, 在宿主机中, 将p13390677_112040_Solaris86-64_1of6.zip 和 p13390677_112040_Solaris86-64_2of6.zip当前路径解压, 这样会产生一个合并后的database目录, 然后在VirtualBox运行界面临时分配一个共享文件夹, 路径选择解压出来的database这个目录. 最后在虚拟机中挂载这个共享文件夹(注意database是宿主机中的共享文件夹名称) # mount -F vboxfs -o ro database /mnt/cdrom/ # su - oracle $ export DISPLAY=10.4.120.1:0.0 $ /mnt/cdrom/runInstaller 截图及输出参考文件夹oracle-software-only, 如下是所有的步骤截图,供参考:   创建diskgroup 创建diskgroup用于存放oracle数据文件, 保持所有节点crs启动,在host1以grid执行 # su - grid $ export DISPLAY=10.4.120.1:0.0 $ asmca 在这里我们创建了名称为DATA的diskgroup,当然,我们也可以在这里创建DATA这个diskgroup上的ACFS卷以及ACFS文件系统。截图及输出参考文件夹asmca, 如下是所有的步骤截图,供参考:   创建数据库 创建数据库, 保持所有节点crs启动,在host1以oracle执行 # su - oracle $ export DISPLAY=10.4.120.1:0.0 $ dbca 截图及输出参考文件夹dbca,如下是所有的步骤截图,供参考:   观察资源状况 到此所有的安装和配置结束。在任意节点上root观察资源情况。 # crsctl stat res -t -------------------------------------------------------------------------------- NAME           TARGET  STATE        SERVER                   STATE_DETAILS -------------------------------------------------------------------------------- Local Resources -------------------------------------------------------------------------------- ora.DATA.dg                ONLINE  ONLINE       host1                ONLINE  ONLINE       host2 ora.GI.dg                ONLINE  ONLINE       host1                ONLINE  ONLINE       host2 ora.LISTENER.lsnr                ONLINE  ONLINE       host1                ONLINE  ONLINE       host2 ora.asm                ONLINE  ONLINE       host1                    Started                ONLINE  ONLINE       host2                    Started ora.gsd                OFFLINE OFFLINE      host1                OFFLINE OFFLINE      host2 ora.net1.network                ONLINE  ONLINE       host1                ONLINE  ONLINE       host2 ora.ons                ONLINE  ONLINE       host1                ONLINE  ONLINE       host2 ora.registry.acfs                ONLINE  ONLINE       host1                ONLINE  ONLINE       host2 -------------------------------------------------------------------------------- Cluster Resources -------------------------------------------------------------------------------- ora.LISTENER_SCAN1.lsnr       1        ONLINE  ONLINE       host2 ora.LISTENER_SCAN2.lsnr       1        ONLINE  ONLINE       host1 ora.LISTENER_SCAN3.lsnr       1        ONLINE  ONLINE       host1 ora.cvu       1        ONLINE  ONLINE       host1 ora.host1.vip       1        ONLINE  ONLINE       host1 ora.host2.vip       1        ONLINE  ONLINE       host2 ora.oc4j       1        ONLINE  ONLINE       host1 ora.orcl.db       1        ONLINE  ONLINE       host1                    Open       2        ONLINE  ONLINE       host2                    Open ora.scan1.vip       1        ONLINE  ONLINE       host2 ora.scan2.vip       1        ONLINE  ONLINE       host1 ora.scan3.vip       1        ONLINE  ONLINE       host1 附录: 安装RAC过程中可能参考的Solaris命令 重启 # init 6   完全停止Solaris # init 5   扫描硬件改动 # devfsadm -cv # cfgadm -alv   重启并重配硬件信息, 用于添加或者改变了硬件 # touch /reconfigure # init 6   查看硬件信息 # prtconf   查看物理内存 # prtconf | grep -i memory   服务列表 # svcs   启用及禁用服务 # svcadm disable svc:network/ftp # svcadm disable svc:network/telnet # svcadm disable svc:network/smtp:sendmail   查看磁盘和光盘的名称以及状态 # iostat -En   挂载光盘 # mount -F hsfs -o ro /dev/dsk/c1t0d0s2 /mnt/cdrom   卸载光盘 # umount /mnt/cdrom/   查找某个命令属于安装介质中的哪个package 例如我想安装nslookup命令, 但是不知道nslookup命令在安装介质的哪个package中 # grep nslookup /mnt/cdrom/Solaris_10/Product/*/pkgmap 从输出结果能迅速定位需要安装的package为SUNWbind   安装package, 例如安装SUNWbind这个package # pkgadd -d /mnt/cdrom/Solaris_10/Product/ SUNWbind   列出所有的网卡 # grep e1000g /etc/path_to_inst   "/pci@0,0/pci8086,1e@3" 0 "e1000g" "/pci@0,0/pci8086,1e@8" 1 "e1000g"   或者 # dladm show-link   e1000g0         type: non-vlan  mtu: 1500       device: e1000g0 e1000g1         type: non-vlan  mtu: 1500       device: e1000g1   启用新添加的网卡e1000g1 # ifconfig e1000g1 plumb up   查看ip信息 # ifconfig –a   查看文件md5 # digest -l # digest -v -a md5 your_file_name   查看进程 # ps -ae -o user,pid,ppid,pri,pcpu,pmem,vsz,rss,wchan,s,stime,time,args   查看某进程,比如进程475打开了多少文件句柄 # pfiles 475     查看free memory # pagesize # sar -r 2 5   查看memory swap in/out # vmstat -S 2 5   查看top进程 # prstat 2 5   查看cpu使用率 # vmstat 2 5  

概述 本文来自Oracle数据库产品技术支持官方博客: https://blogs.oracle.com/Database4CN/   本文包含截图,如果需要下载完整的版本,请下载附件。   //cdn.app.compendium.com/uploads/user/e7c690e8-6ff9-102a-ac6d-e4aebca50425/f4a5b21d-66fa-4885-92bf-c4e81c06d916...

诊断方法

系统内存耗尽的案例分析

近日遇到一个RAC节点hang导致节点被重启的问题,最后经过分析,发现在系统运行一段时间后,系统内存就会耗尽,原本256G的内存,最后只剩几百M。 1. 问题时间段的TOP输出可以看到,内存只剩7G,而分析内存问题,TOP输出是不够的,一般情况下,Database的SGA和PGA是内存使用大户,所以,在TOP很难发现谁是使用内存最多的。 除非某些进程内存使用的格外明显 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Linux OSWbb v7.3.3 zzz ***Tue Feb 21 00:00:10 CST 2017 top - 00:00:12 up 14:16, 10 users, load average: 2.97, 2.31, 2.05 Tasks: 3087 total, 11 running, 3076 sleeping, 0 stopped, 0 zombie Cpu(s): 11.7%us, 2.8%sy, 0.0%ni, 83.7%id, 0.9%wa, 0.0%hi, 0.9%si, 0.0%st Mem: 257948M total, 250464M used, 7484M free, 113M buffers Swap: 65537M total, 0M used, 65537M free, 59868M cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1156 oracle 20 0 4232 568 380 R 101 0.0 0:01.67 gzip 20019 root RT 0 308m 89m 57m S 13 0.0 24:09.96 osysmond.bin 1160 oracle 20 0 11252 3492 836 R 9 0.0 0:00.17 top 49793 oracle 20 0 128g 1.2g 1.2g S 7 0.5 36:00.74 oracle ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2. 通过AWR,可以看到数据库很忙 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ DB Name   DB Id   Instance   Inst num   Startup Time   Release   RAC M2M   602741423   m2m1   1   20-Feb-17 17:02   11.2.0.4.0   YES Host Name   Platform   CPUs   Cores   Sockets   Memory (GB) node3   Linux x86 64-bit   56   28   2   251.90   Snap Id   Snap Time   Sessions   Cursors/Session   Instances Begin Snap:   1054   21-Feb-17 00:05:46   2230   7.0   2 End Snap:   1055   21-Feb-17 01:22:37   1862   6.2   2 Elapsed:     76.85 (mins)       DB Time:     18,666.61 (mins)       <<<<<<<<<< ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3. 但是Oracle的物理内存使用百分比只有33%,并不是oracle耗尽的主机内存。 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  Memory Statistics     Begin    End Host Mem (MB):    257,948.4    257,948.4 SGA use (MB):    77,824.0    77,824.0 PGA use (MB):    8,938.9    6,416.3 % Host Mem used for SGA+PGA:    33.64    32.66 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 4. 注意:一般情况下Oracle的全部进程,如smon, pmon,lgwr等,都会分别使用SGA, PGA,以及一小部分内存作为进程本身使用(这部分一般很小)。 所以,这里的33%,可以代表Oracle全部使用的物理内存。 当然,出现一些bug的情况,如LMS异常使用内存等情况,就另当别论了。 参考案例: RAC: LMS uses huge memory (Doc ID 1954701.1) RAC LMS processes using huge PGA memory: SQL> select pid,spid,program,pga_used_mem,pga_alloc_mem,pga_freeable_mem,pga_max_mem from v$process where program like '%LMS%'; PID SPID USER PROGRAM PGA_USED_MEM PGA_ALLOC_MEM PGA_FREEABLE_MEM PGA_MAX_MEM ---------- ------------------------ --------------- ------------------------------------------------ ------------ 13 23698 oracle@grid06.prod.quova.com (LMS0) 1.0644E+10 1.6525E+10 0 1.6525E+10 14 23702 oracle@grid06.prod.quova.com (LMS1) 1.0644E+10 1.6525E+10 0 1.6525E+10 15 23706 oracle@grid06.prod.quova.com (LMS2) 1.0407E+10 1.6157E+10 0 1.6157E+10 16 23710 oracle@grid06.prod.quova.com (LMS3) 1.0599E+10 1.6455E+10 0 1.6455E+10 5. 分析过程中,也确认了一下,PGA曾经使用过的最大内存情况,可以看到PGA最大也就是使用10G,对应256G物理内存来说,很少。不是问题点 select * from dba_hist_pgastat   SNAP_ID DBID INSTANCE_NUMBER NAME    VALUE      1054  602741423    1 aggregate PGA target parameter       5.5835E+10      1054  602741423    1 aggregate PGA auto target       4.3041E+10      1054  602741423    1 global memory bound       1073741824      1054  602741423    1 total PGA inuse       8010343424      1054  602741423    1 total PGA allocated       9373099008      1054  602741423    1 maximum PGA allocated       1.0711E+10      1054  602741423    1 total freeable PGA memory 396361728      1054  602741423    1 process count     2232      1054  602741423    1 max processes count     3053      1054  602741423    1 PGA memory freed back to OS       6.3224E+11      1054  602741423    1 maximum PGA used for auto workareas  5028864      1054  602741423    1 maximum PGA used for manual workareas   542720      1054  602741423    1 bytes processed       1036738560      1054  602741423    1 cache hit percentage      100      1054  602741423    1 recompute count (total)     7478    1055  602741423    2 aggregate PGA target parameter       4.8050E+10      1055  602741423    2 aggregate PGA auto target       3.7282E+10      1055  602741423    2 global memory bound       1073741824      1055  602741423    2 total PGA inuse       6643825664      1055  602741423    2 total PGA allocated       7995835392      1055  602741423    2 maximum PGA allocated       9677304832      1055  602741423    2 total freeable PGA memory 420085760      1055  602741423    2 process count     2107      1055  602741423    2 max processes count     2365      1055  602741423    2 PGA memory freed back to OS       8.2417E+11      1055  602741423    2 maximum PGA used for auto workareas 33622016      1055  602741423    2 maximum PGA used for manual workareas   542720      1055  602741423    2 bytes processed       1.3889E+10      1055  602741423    2 cache hit percentage      100      1055  602741423    2 recompute count (total)     8519   Line 384: 997 602741423 2 maximum PGA allocated 1.0699E+10 Line 967: 998 602741423 2 maximum PGA allocated 1.0699E+10 <<<<<<<<<<<<<<<10G Line 1380: 983 602741423 1 maximum PGA allocated 1.0598E+10 Line 1436: 986 602741423 1 maximum PGA allocated 1.1655E+10 Line 1808: 1056 602741423 1 maximum PGA allocated 1.1055E+10 Line 2029: 997 602741423 1 maximum PGA allocated 1.3501E+10 Line 2350: 1018 602741423 1 maximum PGA allocated 1.0049E+10 Line 2376: 985 602741423 1 maximum PGA allocated 1.1624E+10 6. 最后,查看meminfo,发现了问题,PageTables占用了168G的内存, 加上SGA和PGA的使用,刚刚好250G左右。 PageTables是内存表,是不共享的,在内存很大的情况下,如果很大process访问内存的话,就会每个process都copy一份PageTables,最终导致大量内存自耗的情况   node3_meminfo_17.02.21.0000.dat zzz ***Tue Feb 21 00:00:10 CST 2017 MemTotal:       264139120 kB  ===> 260 GB MemFree:         7720156 kB   ===> 7 GB Buffers:          116576 kB Cached:         60954824 kB  ===> 60GB (include SGA) SwapCached:            0 kB Active:         61768656 kB Inactive:       12761292 kB Active(anon):   61284872 kB  ===> Inactive(anon): 11620960 kB Active(file):     483784 kB  ===> 500 MB Inactive(file):  1140332 kB   ===> 1GB Unevictable:      333944 kB Mlocked:          223568 kB SwapTotal:      67110908 kB SwapFree:       67110780 kB Dirty:              3764 kB Writeback:             0 kB AnonPages:      13793504 kB Mapped:         58621868 kB Shmem:          59376696 kB   Slab:            1354844 kB   ===> 1 GB SReclaimable:     351496 kB SUnreclaim:      1003348 kB KernelStack:       29248 kB PageTables:     176260660 kB  ===> 168 GB NFS_Unstable:          0 kB Bounce:                0 kB WritebackTmp:          0 kB CommitLimit:    199180468 kB Committed_AS:   88076096 kB 关于PageTables,参考下图   7. 检查之前正常时间段的meminfo,可以发现,刚启动数据库时,PageTables只有700M,但是随着进程的增加,很快PageTables就增长上来了 meminfo_17.02.20.1400.dat zzz ***Mon Feb 20 14:19:05 CST 2017 MemTotal:       264139120 kB MemFree:        222005744 kB Buffers:          112332 kB   SUnreclaim:       258840 kB KernelStack:       11320 kB PageTables:       747560 kB   <<<<<<<<<<<<<<< NFS_Unstable:          0 kB Bounce:                0 kB WritebackTmp:          0 kB   Line 1113: PageTables:       752060 kB Line 1157: PageTables:       769128 kB Line 1201: PageTables:       769252 kB Line 1245: PageTables:       758068 kB Line 1289: PageTables:      2995368 kB   <<<<<<<<<<<<<<<<< Line 1333: PageTables:      4314036 kB Line 1377: PageTables:      5717752 kB Line 1421: PageTables:      6107780 kB Line 1465: PageTables:      6427636 kB Line 1509: PageTables:      7307184 kB Line 1553: PageTables:      8552708 kB Line 1597: PageTables:      9382396 kB Line 1641: PageTables:     10236492 kB   8. 既然问题找到了,如何解决呢? Hugepages是解决这种问题的最好方案。 hugepages的内存块是2M(普通内存块是4K),首先内存管理的成本就降低500倍,而且hugepages的内存表是可以共享的。   9, 最终,配置hugepages,解决问题。 相关hugepages文档,请参考: HugePages on Linux: What It Is... and What It Is Not... (Doc ID 361323.1) HugePages on Oracle Linux 64-bit (Doc ID 361468.1) HugePages and Oracle Database 11g Automatic Memory Management (AMM) on Linux (Doc ID 749851.1) Linux IA64 example of allocating 48GB SGA using hugepages (Doc ID 397568.1) Shell Script to Calculate Values Recommended Linux HugePages / HugeTLB Configuration (Doc ID 401749.1) USE_LARGE_PAGES To Enable HugePages In 11.2 (Doc ID 1392497.1)  题外话,oswatcher是Oracle分析和解决问题,非常有用的一个工具,在很多问题的分析上,都能提供很大的