X

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

Recent Posts

技术支持通讯

又有新的数据库中文文档添加到 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...

TimesTen

TimesTen In-Memory Database FAQ

  Oracle 内存数据库 TimesTen 常见问题集锦   什么是 Oracle 内存数据库 TimesTen? Oracle 内存数据库 TimesTen 是一个针对内存进行了优化的关系数据库,它为应用程序提供了当今实时企业和行业(如电信、资本市场和国防)所需的即时响应性和非常高的吞吐量。 Oracle 内存数据库 TimesTen 作为缓存或嵌入式数据库部署在应用程序层中,利用标准的 SQL 接口对完全位于物理内存中的数据存储进行操作。所包括的复制技术能够在 TimesTen 数据库之间进行实时事务复制,以实现高可用性和负载共享。    什么是 Oracle In-Memory Database Cache? Oracle In-Memory Database Cache 是一个数据库选件,它为 Oracle 数据库提供了实时、可更新的缓存。Oracle In-Memory Database Cache 将来自数据库的对性能极其关键的一系列表和表碎片缓存到应用程序层,从而缩短应用程序事务响应时间。在内存数据库 TimesTen 中管理缓存表的方式与管理普通的关系型数据库表类似。因此,Oracle In-Memory Database Cache 为应用程序提供了关系型数据库的所有共性和功能、缓存和 Oracle 数据库的一致性透明维护以及内存数据库的实时性能。该数据库选件是缓存 Oracle 数据库的性能关键的子集以改进应用程序层中响应时间的理想选择。为了获得高可用性,可使用活动-备用配置部署 Oracle In-Memory Database Cache,active-standby 配置中的缓存表在 Oracle TimesTen 数据库间进行实时复制。       Oracle 内存数据库 TimesTen 是否对硬件和软件有特殊要求? Oracle TimesTen 数据库是在假设所有受管理的数据都驻留在物理内存 (RAM) 中的前提下构建的。因此,对于硬件,要考虑的最重要的事情是应用程序层中要有足够的 RAM。除此之外,TimesTen 要考虑的硬件因素极少。 与所有应用程序一样,具有适当数量的 CPU(以相应的时钟速度运行)对于应用程序尽可能快得运行是很重要的。同样,要利用多个 CPU,您需要运行多个应用程序,或应当将您的应用程序编写为使用多个线程。此外,事务日志和检查点文件持久保存在磁盘上,磁盘越快,实现的整体性能越 好。 Oracle In-Memory Database Cache 驻留在应用程序层,它使用 SQL*Net 与 Oracle 数据库进行通信。Oracle 数据库客户端软件必须作为内存数据库缓存安装在同一服务器上,以便连接到 Oracle 数据库。       内存数据库 TimesTen 是 Oracle 11g/12c 数据库的一部分吗? Oracle In-Memory Database Cache 是 Oracle 数据库的数据库选件,它包括内存数据库 TimesTen、Cache Connect To Oracle 以及 Replication - TimesTen to TimesTen 技术。 Oracle 内存数据库 TimesTen 是经过专门许可的产品,包括内存数据库 TimesTen 和复制组件。   哪些平台支持 Oracle TimesTen 技术? 支 持以下平台:AIX 32/64 位 (Power)、HP-UX 32/64 位(PA-Risc 和 Itanium2)、HP TRU64 64 位 (AlphaChip EV68)、Linux RedHat 和 SUSE 32/64 位(x86、x86-64 和 Itanium2)、Linux Oracle、MontaVista CGE 和 Asianux 32/64 位(x86 和 x86-64)、Sun Solaris 32/64 位(Sparc 和 x86)和 Windows 32/64 位(x86 和 x64)。 Oracle In-Memory Database Cache 选件支持 Oracle 数据库 10g 第 2 版、 Oracle 数据库 11g 和12c最新版本。    内存数据库 内存数据库 TimesTen 可以作为独立的数据库使用吗? 可以,现在很多客户将 Oracle 内存数据库 TimesTen (IMDB) 作为独立的数据库在应用程序层使用。TimesTen IMDB 为 SQL 操作提供了全面的事务处理支持,事务日志持久保存在磁盘上以便于恢复(数据库始终位于内存中)。       Oracle 内存数据库 TimesTen 可以作为 Oracle 数据库的内存缓存使用吗? 可以,这是 Oracle 数据库选件“Oracle In-Memory Database Cache”。该数据库选件包括内存数据库 TimesTen、Cache Connect to Oracle 以及 Replication - TimesTen to TimesTen 组件。         内存数据库 TimesTen 的数据访问 API 有哪些? 内存数据库 TimesTen 支持标准的 ODBC, JDBC, OCI, ODP.NET 等接口,以便应用程序使用 SQL-92 标准连接到数据库。     TimesTen 为 32 位和 64 位应用程序提供的接口不同吗? 不是,为 32 位和 64 位应用程序提供的应用程序接口是一样的。要利用 64 位模式,需要重新编译应用程序并将其链接到 TimesTen 64 位资料库。     开发 Oracle TimesTen 应用程序可以使用什么语言? 可以使用 C、C++ 、Java 、PL/SQL、PHP以及 R 语言等多种应用程序开发。      您所说的嵌入模式是指什么? Oracle 内存数据库 TimesTen 的设计和优化使其可在应用程序层运行。数据存储可直接链接(嵌入式)到应用程序以获得最佳性能。 通过将数据库嵌入应用程序,SQL 访问不会导致任何网络或 IPC 开销。       Oracle 内存数据库 TimesTen 是否支持类似 Oracle RDBMS 的索引? 是,Oracle 内存数据库 TimesTen 支持索引。索引可以提高数据库查询的性能,就像它们在 Oracle 中的作用一样。TimesTen 支持两种类型的索引:范围索引,用于涉及等式和不等式范围的查找;和散列索引,提供较范围索引更为快速的主键访问,可精确匹配查找和同等联接。   如何在 TimesTen IMDB 中设计和创建数据结构?  内 存数据库 TimesTen 支持 SQL 标准。要创建数据结构,可使用 SQL DDL 语句,如 CREATE TABLE、CREATE INDEX、CREATE SEQUENCE、CREATE VIEW、CREATE MATERIALIZED VIEW、ALTER TABLE 等。用于 RDBMS 的相同数据库设计技术也可用于 TimesTen。在 TimesTen 中设计和管理数据库要比在针对磁盘优化的 RDBMS 中简单,因为不需要调整表区域大小或者整理磁盘碎片。    TimesTen 是内存数据库,那它如何从节点/电源故障进行恢复?    虽然整个数据库驻留在内存中,但事务日志和检查点文件都保存在磁盘上。如果系统重新启动或者出现故障,将从检查点文件和事务日志文件恢复 IMDB。此外,客户可以配置 TimesTen Replication 以向另一个 TimesTen 节点提供事务复制。         In-Memory Database Cache 什么是 Cache Connect to Oracle? Cache Connect to Oracle 是 Oracle 数据库选件“Oracle In-Memory Database Cache”的一个组件。它使内存数据库 TimesTen 能够提供为 Oracle 数据库提供实时、可更新的缓存。Cache Connect 负责加载数据、在内存缓存和 Oracle 数据库之间传播更新,以及维护两个数据库之间的缓存一致性。    Oracle In-Memory Database Cache 支持哪些 Oracle 数据库版本? In-Memory Database Cache 支持 Oracle 数据库 10g 第 2 版、 Oracle 数据库 11g 和最新的 12c 版本。   Oracle In-Memory Database Cache 支持哪些平台? In-Memory Database Cache 作为 Oracle 数据库服务器的客户端应用程序运行。支持的平台包括 AIX、HP Tru64、HP-UX、Linux、Solaris 和 Windows。   我可以在不同平台上通过 Oracle 数据库服务器运行 Oracle In-Memory Database Cache 吗? 可以,由于 Cache Connect 作为 Oracle 客户端运行,因此它可以在不同的平台上通过 Oracle 数据库服务器运行。    我可以在Oracle 数据库的MAA架构下使用 TimesTen Cache 功能来实现容灾么? 可以,当前 TimesTen Cache 可以支持RAC 和 同步模式的Data Guard。 注:在即将推出的新版本中,TimesTen 将支持 Cache的最大高可用模式,即:TimesTen Cache 可以运行在 Active-Standby + Subscriber 的模式下,配合Oracle 数据库的RAC + 异步 Data Guard 来实现多维度的MAA架构!敬请期待!     Replication 什么是 TimesTen Replication? TimesTen Replication 是内存数据库 TimesTen 的一个组件。TimesTen Replication 技术支持 TimesTen 服务器节点之间的实时数据复制。Replication 支持使用同步或异步数据传输进行 active/standby 或 active/active 配置。        TimesTen Replication 如何在系统故出现障时确保持续的可用性? 可以将 TimesTen Replicaiton 配置为将整个 TimesTen 数据库复制到一个或多个 TimesTen 节点。发生故障转移后,备用节点将变成活动节点,出现故障的节点可以通过备用(现在为活动)数据库恢复。   我可以复制数据库中选定的表吗? 可以,表级别的复制和数据库级别的复制均受支持。    TimesTen Replication 支持哪些网络协议? TimesTen Replication 在 LAN 或 WAN 上的复制节点间使用持久的流式 TCP/IP 套接字。    TimesTen Replication 是双向的吗? 是的,单向和双向复制均受支持。对于双向复制,建议对负载进行分区以避免大量冲突。如果在对相同的数据库行进行更新时发生冲突,TimesTen Replication 支持基于时间戳的冲突检测和解决。   TimesTen 的Replication 支持 Cache 么? 是的,当前TimesTen 内置的高可用复制模式 Active-Standby 支持 TimesTen Cache。     客户选择TimesTen 产品的原因有哪些?   当前TimesTen 数据库被广泛的应用到实时处理的应用场景当中。客户选择TimesTen产品来为其OLTP应用提供数据库服务的主要原因有:   对实时事件的响应 –微秒级响应时间 •一致稳定的响应 –快速、一致的响应时间 ,低延时 •数据完全加载到内存、且支持直连模式 –高峰时段处理超大事务及事件处理 •提供持续且不间断的服务 –高可用、在线升级 •内置的基于复制的Active-Standby + Subscriber 架构,支持TimesTen Cache 以及跨版本升级 –标准 SQL/关系型模型、标准 API、缓存 且自动同步 Oracle 数据库 •极小的应用代码和接口调整即可提升现有应用             已有客户使用TimesTen 产品的架构有哪些?   TimesTen 在全球有上千家大型客户,客户行业包括电信、金融、证券、保险、交通、政府、互联网等等。以下列举的客户架构图中,有独立使用TimesTen作为核心数 据库的架构,也有使用TimesTen Cache 加速其 Oracle RAC以及Exadata 应用的客户。 1. 独立使用TimesTen 数据库的客户:   2. 已有的Oracle 数据库 RAC 用户,使用TimesTen Cache 来加速其OLTP应用并实现读、写分离架构:   3. 已有的Oracle 数据库 Exadata 用户,使用TimesTen Cache 来加速其OLTP应用:     小结:希望通过本文的介绍,可以让您对TimesTen 关系型内存数据库产品有一个基本的了解。 如果希望进一步了解和使用这款产品,点击官方网站下载并体验吧! 更多操作详情,请点击 快速入门手册  

  Oracle 内存数据库 TimesTen 常见问题集锦   什么是 Oracle 内存数据库 TimesTen?Oracle 内存数据库 TimesTen 是一个针对内存进行了优化的关系数据库,它为应用程序提供了当今实时企业和行业(如电信、资本市场和国防)所需的即时响应性和非常高的吞吐量。 Oracle 内存数据库 TimesTen 作为缓存或嵌入式数据库部署在应用程序层中,利用标准的...

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分析和解决问题,非常有用的一个工具,在很多问题的分析上,都能提供很大的帮助。 所以强烈建议部署。

近日遇到一个RAC节点hang导致节点被重启的问题,最后经过分析,发现在系统运行一段时间后,系统内存就会耗尽,原本256G的内存,最后只剩几百M。 1. 问题时间段的TOP输出可以看到,内存只剩7G,而分析内存问题,TOP输出是不够的,一般情况下,Database的SGA和PGA是内存使用大户,所以,在TOP很难发现谁是使用内存最多的。 除非某些进程内存使用的格外明显 ~~~~~~~~~~~~~~~~~...

诊断方法

关于sys CPU usage 100%问题的分析

最近一个客户抱怨他的核心EBS数据库出现性能问题。这是一个10.2.0.3的数据库, 运行在Red Hat Enterprise Linux Server release 5.5 (Linux x86-64)操作系统上。 根据客户描述,由于需要维护UPS,他们重启了数据库,结果重启数据库后他们发现只要他们的应用 开始连接数据库,那么主机的sys CPU使用率就会变成100%, 但是user CPU使用率几乎是0. 而且只要停掉监听或者应用不开启新session连接数据库,这个问题就会消失。 如下是问题发生期间的vmstat输出,可见cpu中的sys(倒数第4列)几乎100%, CPU Run Queue (第1列) 非常高,而此时free memory还有20G(第4列),看来内存很充裕。 SNAP_INTERVAL 15 CPU_COUNT 32 zzz ***Fri Dec 2 17:05:03 CST 2016 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st 48  0      0 22026868 213392 37138888    0    0    21    31   13   39  6  8 86  0  0 44  1      0 21968452 213392 37138900    0    0     0   360 1093  537  8 92  0  0  0 44  1      0 21941632 213392 37139028    0    0     0   288 1080  371  9 91  0  0  0 ...... zzz ***Fri Dec 2 17:10:12 CST 2016 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st 121  2      0 21495944 218356 37142412    0    0    21    31   13   39  6  9 85  0  0 122  4      0 21486192 218356 37142432    0    0     0   308  119  753  7 93  0  0  0 121  2      0 21478868 218364 37142424    0    0     0   592   97  517  5 95  0  0  0 首先我看了一遍客户提供的AWR,发现DB相当空闲,虽然CPU time占据了91.2,但是总的CPU Time 在119分钟的采样中只有18345秒(305分钟),相对于客户32个CPU Core来说不是个问题。 Snap Id Snap Time Sessions Cursors/Session Begin Snap: 38119 02-Dec-16 16:00:28 255 63.2 End Snap: 38121 02-Dec-16 18:00:18 193 48.7 Elapsed: 119.83 (mins) DB Time: 335.30 (mins)  <<< 相当空闲 Top 5 Timed Events Event    Waits    Time(s)    Avg Wait(ms)    % Total Call Time    Wait Class CPU time         18,345         91.2     os thread startup    971    937    965    4.7    Concurrency latch free    582    657    1,128    3.3    Other db file sequential read    4,712,799    345    0    1.7    User I/O log file parallel write    247,562    258    1    1.3    System I/O AWR中没发现什么异常,DB的alert log显示一些无法fork进程的消息,估计是资源紧张了。 Fri Dec  2 17:06:16 2016 Process q002 died, see its trace file Fri Dec  2 17:06:16 2016 ksvcreate: Process(q002) creation failed 好吧,一般情况下如果我们发现CPU高,无论是sys的还是user的,我们一般的做法是先定位top function call 然后通过这些function call来定位oracle或者OS行为,并且通过这些call来搜索与匹配已知问题。 在linux上,最方便收集这些信息的就是用perf这个工具。关于perf,参见: https://perf.wiki.kernel.org/index.php/Tutorial 结果客户说他们无法安装perf命令,不过他提到他的OS中显示很多错误: Dec  2 17:05:23 erpdb1 kernel: BUG: soft lockup - CPU#5 stuck for 10s! [oracle:15668] Dec  2 17:05:23 erpdb1 kernel: CPU 5: Dec  2 17:05:23 erpdb1 kernel: Call Trace: Dec  2 17:05:23 erpdb1 kernel:  [<ffffffff8000e9a8>] __set_page_dirty_nobuffers+0xc2/0xe9 Dec  2 17:05:23 erpdb1 kernel:  [<ffffffff80007c1b>] unmap_vmas+0x522/0x904 Dec  2 17:05:23 erpdb1 kernel:  [<ffffffff80012d08>] unmap_region+0xb8/0x12b Dec  2 17:05:23 erpdb1 kernel:  [<ffffffff80011e45>] do_munmap+0x21b/0x29a Dec  2 17:05:23 erpdb1 kernel:  [<ffffffff800655ab>] __down_write_nested+0x12/0x92 Dec  2 17:05:23 erpdb1 kernel:  [<ffffffff80121e88>] sys_shmdt+0x5b/0x133 Dec  2 17:05:23 erpdb1 kernel:  [<ffffffff8005e28d>] tracesys+0xd5/0xe0 通过call stack,看来在回收内存时报错了,推测这个错误应当发生在进程退出阶段, 不过难以断定这些错误与sys cpu高的因果关系。 结合客户描述的现象,这看起来很像连接风暴,因此我们检查了ps的输出,发现进程数并未明显增加, 不过问题最严重的时间断片了。这些零碎的信息并不能给我们一个很清晰的线索。 $ awk '/$ORACLE_SID/{n++;next}/^zzz/{if(t)print t,"-",n;t=$0;n=0}END{print t,"-",n}' XXXX_ps_16.12.02.1700.dat zzz ***Fri Dec 2 17:04:18 CST 2016 - 235 zzz ***Fri Dec 2 17:04:33 CST 2016 - 236 zzz ***Fri Dec 2 17:04:48 CST 2016 - 229 zzz ***Fri Dec 2 17:05:03 CST 2016 - 228   <<<< 此时问题实际上已经发生了 zzz ***Fri Dec 2 17:05:19 CST 2016 - 178   <<<< 17:05 ~ 17:13 的断片了 zzz ***Fri Dec 2 17:13:19 CST 2016 - 283   <<<< zzz ***Fri Dec 2 17:13:34 CST 2016 - 283 zzz ***Fri Dec 2 17:13:49 CST 2016 - 196 接下来看了top,发现虽然OS的sys CPU高,不过top的process都是oracle,表明此问题一定 与oracle有点关系。 zzz ***Fri Dec 2 17:05:03 CST 2016 top - 17:05:05 up  9:24,  3 users,  load average: 41.76, 28.54, 19.68 Tasks: 660 total,  45 running, 615 sleeping,   0 stopped,   0 zombie Cpu(s):  8.3%us, 91.7%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st Mem:  65993408k total, 44046040k used, 21947368k free,   213392k buffers Swap: 62918564k total,        0k used, 62918564k free, 37139028k cached   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND 19610 oracle   25   0 9917m 8.5g 8.5g R 101.8 13.6   1:19.76 oracle 19756 oracle   25   0 9917m 7.0g 7.0g R 100.9 11.1   1:05.76 oracle 19760 oracle   25   0 9917m 6.7g 6.7g R 100.9 10.7   1:06.56 oracle 19942 oracle   25   0 9917m 5.1g 5.1g R 100.9  8.0   0:46.67 oracle 20107 oracle   25   0 9917m 3.1g 3.1g R 100.9  4.9   0:26.39 oracle 20204 oracle   25   0 9917m 1.2g 1.2g R 100.9  1.9   0:10.63 oracle 19486 oracle   25   0 9917m 9.3g 9.3g R 99.9 14.8   1:25.10 oracle 19721 oracle   25   0 9917m 6.9g 6.8g R 99.9 10.9   1:08.22 oracle 那么问题来了,oracle软件一般都是执行user code,因此大多数情况下会消耗user space 的CPU,怎么会消耗sys CPU呢? 先man一下top: sy - This is the amount of time that the CPU spent running the kernel. All the processes and system resources are handled by the Linux kernel. When a user space process needs something from the system, for example when it needs to allocate memory, perform some I/O, or it needs to create a child process, then the kernel is running. 这说明oracle进程是有可能消耗kernel space的CPU的,比如申请内存,执行I/O等。 挑出上面的top列出的进程,在ps输出中找规律: $ grep 19610 Dec* TIME           USER       PID  PPID PRI %CPU %MEM    VSZ   RSS WCHAN  S  STARTED     TIME COMMAND Dec 2 17:03:17 oracle  19610     1  14 78.5  0.9 10155628 605564 -   R 17:03:10 00:00:05 ora_q002_XXXX Dec 2 17:03:32 oracle  19610     1  14 57.6  2.1 10155628 1437940 -  R 17:03:09 00:00:13 ora_q002_XXXX Dec 2 17:03:47 oracle  19610     1  14 67.6  4.3 10155628 2868692 -  R 17:03:10 00:00:25 ora_q002_XXXX Dec 2 17:04:02 oracle  19610     1  14 75.8  6.9 10155628 4559708 -  R 17:03:09 00:00:40 ora_q002_XXXX Dec 2 17:04:18 oracle  19610     1  14 76.7  9.1 10155628 6015688 -  R 17:03:10 00:00:52 ora_q002_XXXX Dec 2 17:04:33 oracle  19610     1  14 70.9 10.4 10155628 6865876 -  R 17:03:09 00:00:59 ora_q002_XXXX Dec 2 17:04:48 oracle  19610     1  14 67.7 11.6 10155628 7684088 -  R 17:03:09 00:01:07 ora_q002_XXXX Dec 2 17:05:03 oracle  19610     1  14 68.9 13.3 10155628 8838576 -  R 17:03:10 00:01:18 ora_q002_XXXX $ grep 19756 Dec* TIME           USER       PID  PPID PRI %CPU %MEM    VSZ   RSS WCHAN  S  STARTED     TIME COMMAND Dec 2 17:03:47 oracle  19756     1  16 50.0  0.3 10155628 222508 -   R 17:03:44 00:00:02 oracleXXXX (LOCAL=NO) Dec 2 17:04:02 oracle  19756     1  14 47.9  1.4 10155628 961764 -   R 17:03:43 00:00:09 oracleXXXX (LOCAL=NO) Dec 2 17:04:18 oracle  19756     1  14 55.5  3.0 10155628 2021664 -  R 17:03:44 00:00:18 oracleXXXX (LOCAL=NO) Dec 2 17:04:33 oracle  19756     1  14 68.4  5.6 10155628 3703572 -  R 17:03:43 00:00:34 oracleXXXX (LOCAL=NO) Dec 2 17:04:48 oracle  19756     1  14 75.4  8.2 10155628 5459948 -  R 17:03:43 00:00:49 oracleXXXX (LOCAL=NO) Dec 2 17:05:03 oracle  19756     1  14 80.6 10.9 10155628 7217680 -  R 17:03:44 00:01:04 oracleXXXX (LOCAL=NO) 从以上输出可以发现一个明显规律: 这些进程的RSS在1分多钟从几十M变成7~8G,但是VSZ却没有变化。 接着man ps VSZ: virtual memory usage of entire process. vm_lib + vm_exe + vm_data + vm_stack RSS: resident set size, the non-swapped physical memory that a task has used (in kiloBytes). (alias rssize, rsz). 任何一个oracle进程的VSZ约等于SGA加上这个进程的PGA(实际上VSZ还包含一些kernel内存),正常情况下一个进程的pga是很小的。 以上输出中VSZ没有改变,因此发生巨大变化的RSS申请的内存一定不是PGA而是SGA(因为如果增长的是PAG那么VSZ也会跟着增长)。 好吧,那么只有一个可能了,那就是这个进程在touch整个sga,为什么会这样? 我们需要再回到原点再看一眼AWR的数据库参数信息,赫然发现如下内容: sga_max_size    10250878976 sga_target    8304721920 pre_page_sga    TRUE  <<<< 看这里 这个设置中的sga_max_size正好10g,与我们在ps中看到的VSZ正好相等。 问题的原因是客户设置了pre_page_sga=true,这样在oracle进程启动阶段会touch整个SGA, 这个过程中会调用OS的sys call来touch 整个 shared memory entry,因此引发了高SYS CPU消耗。 参见如下文档的描述: Health Check Alert: Consider setting PRE_PAGE_SGA to FALSE (Doc ID 957525.1) 回过头来再看alert log,观察参数pre_page_sga是什么时候改的,发现它在很久以前的很多次重启就是true了。 也就是说,这个问题一直都存在,只是客户最近维护UPS之后才发现,维护UPS这个信息误导了我们。

最近一个客户抱怨他的核心EBS数据库出现性能问题。这是一个10.2.0.3的数据库, 运行在Red Hat Enterprise Linux Server release 5.5 (Linux x86-64)操作系统上。 根据客户描述,由于需要维护UPS,他们重启了数据库,结果重启数据库后他们发现只要他们的应用开始连接数据库,那么主机的sys CPU使用率就会变成100%, 但是user...

技术支持通讯

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

最新翻译的文档列表: Note 2227021.1 Oracle Database - 数据库补丁使用方法概述 Note 2226599.1 在 Unix AIX,HP-UX,Linux,Solaris 和 MS Windows 操作系统上安装和配置 Oracle 数据库(RDBMS)的要求的快速参考 Note 2226539.1 如何使用 MOS 补丁冲突检查工具[视频] Note 2226611.1 有效节点注册检查(VNCR) Note 2225765.1 12c:关于告警信息"Heavy Swapping Observation" 和 ORA-700 [kskvmstatact: excessive swapping observed] Note 2226594.1 在 11g alert 日志中报 Fatal NI Connect Error 12170, 'TNS-12535: TNS:operation timed out' Note 2227040.1 在升级/迁移/复制/移动数据库的时候如何执行全库导出导入 Note 2186003.1 如何跟踪 PMON 动态注册? Note 2194251.1 12C 新特性:隐形列 Note 2194252.1 12C 新特性:在线移动数据文件 Note 2185572.1 Oracle Net 12c:实例注册(LREG 后台进程) Note 2185573.1 如何在不关闭 PDB 的情况下克隆可插拔数据库(PDB)   Note 2226580.1 自适应执行计划 Note 2227003.1 自动动态统计信息 Note 2225748.1 11gR2 Clusterware 和 Grid Home – 你需要知道的事 Note 2226530.1 怎样格式化收集以及备份 10.1,10.2,11.1,11.2 和 12.1 的 ASM、ACFS 元数据? Note 2225754.1 如何在不同的共享存储(磁盘组、CFS、NFS 等)上移动/重建 GIMR Note 2226128.1 SRDC - 诊断 GI,ASM 和 RAC 系统故障中的数据收集 Note 2226107.1 在 12c 中使用备份集进行 RMAN ACTIVE DUPLICATE(新特性) 完整的列表请点击这里 或登录 My Oracle Support  并查找: 中文文档列表 - Oracle Database (文档 ID 1533057.1)

最新翻译的文档列表: Note 2227021.1 Oracle Database - 数据库补丁使用方法概述 Note 2226599.1 在 Unix AIX,HP-UX,Linux,Solaris 和 MS Windows 操作系统上安装和配置 Oracle 数据库(RDBMS)的要求的快速参考 Note 2226539.1 如何使用 MOS 补丁冲突检查工具[视频]Note...

新特性

在12.1版本中如何能使用Oracle12.2的Adaptive新特性

 从Oracle 12.2 中引入新特性:加入参数OPTIMIZER_ADAPTIVE_PLANS和 OPTIMITER_ADAPTIVE_STATISTICS;  但是在Oracle 12.1中我们也可以通过打补丁来使用12.2的Adaptive新特性来摒弃本用一个参数OPTIMIZER_ADAPTIVE_FEATURES来管理ADAPTIVE PLANS 和 ADAPTIVE STATISTICS两个部分的机制。关于Adaptive新特性的推荐, 请您参考:    MOS: Note: 2187449.1     Recommendations for Adaptive Features in Oracle Database 12.1关于12.2新特性的更多信息, 请您参考:    http://docs.oracle.com/database/122/REFRN/OPTIMIZER_ADAPTIVE_PLANS.htm#BEGIN    ==> 1.211 OPTIMIZER_ADAPTIVE_PLANS 默认值为 true    http://docs.oracle.com/database/122/REFRN/OPTIMIZER_ADAPTIVE_STATISTICS.htm#BEGIN    ==> 1.213 OPTIMIZER_ADAPTIVE_STATISTICS 默认值为 false    http://docs.oracle.com/database/122/UPGRD/initialization-parameter-changes-oracle-database-12c-r2.htm#UPGRD-GUID-BBBA10C4-F00A-4A9A-95A8-CCD925E4041C    ==>OPTIMIZER_ADAPTIVE_PLANS 和 OPTIMIZER_ADAPTIVE_STATISTICS    https://blogs.oracle.com/UPGRADE/entry/optimizer_adaptive_features_obsolete_in    https://blogs.oracle.com/optimizer/entry/optimizer_adaptive_features_in_the在您的数据库升级到Oracle 12.1后,推荐您打下面的两个补丁:    The patch for bug# 22652097  --引入两个参数OPTIMIZER_ADAPTIVE_PLANS 和 OPTIMIZER_ADAPTIVE_STATISTICS,并进一步删除OPTIMIZER_ADAPTIVE_FEATURES    The patch for bug# 21171382  -- 无效化扩展统计信息的自动创建,除非把优化器参数AUTO_STATS_EXTENSIONS设置成ON.    在打上面的patch的时候,执行命令:alter system reset optimizer_adaptive_features; 在打完上面补丁后,请您务必从spfile中删除参数OPTIMIZER_ADAPTIVE_FEATURES。这样的话,如果当您升级数据库到Oracle 12.1后碰到adaptive特性导致的性能问题时,这两个one off patch应该能帮助到您(使得 Adaptive Plan<参数:OPTIMIZER_ADAPTIVE_PLANS默认true>和Adaptive Statistics<参数:OPTIMITER_ADAPTIVE_STATISTICS默认false>分别用自己的参数来进行管理, 这两个默认值设置使得执行计划更加稳定)。请注意没有必要把参数OPTIMIZER_DYNAMIC_SAMPLING设置成非默认值(2以外),因为这些补丁将无效化adaptive dynamic sampling的使用; 并进一步删除OPTIMIZER_ADAPTIVE_FEATURES为false<默认>参考于:https://blogs.oracle.com/UPGRADE/entry/enabling_adaptive_features_of_oracle

 从Oracle 12.2 中引入新特性:加入参数OPTIMIZER_ADAPTIVE_PLANS和 OPTIMITER_ADAPTIVE_STATISTICS;  但是在Oracle 12.1中我们也可以通过打补丁来使用12.2的Adaptive新特性来摒弃本用一个参数OPTIMIZER_ADAPTIVE_FEATURES来管理ADAPTIVE PLANS 和 ADAPTIVE...

诊断方法

一个奇怪的ora-4030错误的诊断过程

一个奇怪的ora-4030错误的诊断过程前些天我收到一个客户报出的相当奇怪的ora-4030的问题,特和大家分享一下。根据客户的描述,他是在Solaris 10 Sparc上尝试将一个Oracle 10.2.0.5.6的数据库升级到Oracle 12.1.0.2,在执行数据字典升级($ORACLE_HOME/perl/bin/perl catctl.pl -n  6 -l $ORACLE_HOME/diagnostics catupgrd.sql)的时候,报出了ora-4030,而且他尝试重复多次执行升级脚本,总是在第70步左右报出ora-4030。trace文件内容大概如下:ORA-04030: out of process memory when trying to allocate 616 bytes (SQLA^b20dbe57,frodef:qcpitnm)=======================================PRIVATE MEMORY SUMMARY FOR THIS PROCESS---------------------------------------******************************************************PRIVATE HEAP SUMMARY DUMP42 MB total:  <<<< 可见这个进程总共只allocate了42M的PGA    42 MB commented, 270 KB permanent    86 KB free (0 KB in empty extents),      37 MB,   2 heaps:   "callheap       "            44 KB free held    4990 KB,   1 heap:    "session heap   "           Private memory usage per Oracle process -------------------------Top 10 processes:-------------------------(percentage is of 3108 MB total allocated memory) <<<< 所有Oracle进程总共allocate了3108M的PGA >>>> 1% pid 43: 42 MB used of 42 MB allocated  <= CURRENT PROC 1% pid 11: 7558 KB used of 20 MB allocated (12 MB freeable)......swap info: free_mem = 55412.04M rsv = 406039.34M            alloc = 364360.94M avail = 93020.98M swap_free = 134699.38M==> 可见OS有55G的free memory, swap有134G的free客户的PGA设置为pga_aggregate_target = 4G 基于以上信息,我们可见Oracle总共allocate了3G不到的PGA,并且发生问题的进程只allocate了42M的PGA后就报出ora-4030了,这显然不是oracle自身问题,因为PGA使用很少,并未使用完。接下来,我们很容易想到这可能是ulimit配置不当。因为如果ulimit的 data 和 stack (尤其是data)配置不当,很容易出现以上现象。我们让客户再做一次升级,然后在尚未报错的时候,定位执行upgrade的server process进程号。对这个进程提取了ulimit,对Solaris来说,plimit命令就能做到。# plimit 1649716497:  oraclexxxxxx (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))  resource              current         maximum time(seconds)         unlimited       unlimited file(blocks)          unlimited       unlimited data(kbytes)          unlimited       unlimited stack(kbytes)         32768           unlimited coredump(blocks)      unlimited       unlimited nofiles(descriptors)  65536           65536 vmemory(kbytes)       unlimited       unlimited 结果让我们大失所望,因为data是unlimited的,而且stack完全满足12c安装最低要求。接下来我们收集了OSWatcher和OS log,希望从这里面发现一些线索。ora-4030发生的时间为15:13:30,问题期间的vmstat输出表明此时OS有充分的memory及swap资源zzz ***Mon Oct 31 15:13:23 CST 2016 kthr      memory r b w   swap  free 3 38 0 142269152 95078552 0 30 0 102388240 58454584 0 29 0 102382384 58453432  <<< 58G free memory但是排序后发现在某些时间点swap只剩下100多m了,不过与ora-4030时间点对不上。$ awk '/^zzz/{t=$5;next}/^\s*[0-9]/{print t,$4,$5}' xxxxxx_vmstat_16.10.31.1500.dat | sort -k2,2rntime     swap   free15:22:42 231952 5876948815:06:04 136480 5855541615:27:14 133456 5883572815:22:42 131288 58799792可见在15:06/15:22/15:27的时候,swap只有100~200多m了,此时free memory尚有58g另外可见的是swap的使用跨度巨大,比如下面的详细信息表明从15:22:42到15:22:57之间15秒,swap跨度为100多G,zzz ***Mon Oct 31 15:22:42 CST 2016r b w   swap  free3 38 0 142267000 950766161 18 0 231952 587694882 24 0 131288 58799792  <<<<  131m swapzzz ***Mon Oct 31 15:22:57 CST 2016  <<< 时隔15秒后r b w   swap  free3 38 0 142266920 950765680 16 0 103208360 58855448  <<<< 100g swap1 29 0 103214056 58860848观察ps的输出,发现这个host上竟然运行着58个oracle数据库.$ grep -oE "[^ ]+_lgwr_.+" xxxxxx_ps_16.10.31.1500.dat | sort -u | wc -l58这样我们可以猜测问题原因可能在swap上,只是因为vmstat采样频率15秒太低了,发生问题的那一瞬间没有采样,并且由于变化巨大,在相邻的采样也看不到低swap的现象。接下来我们分析了OS log,发现大量如下信息:Oct 31 11:03:58 xxxx genunix: [ID 470503 kern.warning] WARNING: Sorry, no swap space to grow stack for pid 24989 (oracle)Oct 31 15:37:21 xxxx tmpfs: [ID 518458 kern.warning] WARNING: /tmp: File system full, swap space limit exceededOct 31 17:11:28 xxxx genunix: [ID 470503 kern.warning] WARNING: Sorry, no swap space to grow stack for pid 23708 (oracle)这样进一步证明了我们的猜测,接下来我们检查了OS的swap配置:# topMemory: 512G phys mem, 62G free mem, 100G swap, 100G free swap可见有512G的物理内存,但是swap只配了100G,这显然不符合我们的推荐标准,参见How to Configure Swap Space (Doc ID 286388.1)这样我们的solution就是将swap space提高到75%的OS memory大小,设置成512G更佳。但是问题来了,发生问题时我们还有58G的free memory,为什么oracle不用这些free的memroy而是用swap呢?这是因为Solaris的设计使之然,如下的文档给出了答案:How does the Solaris Operating System Calculate Available Swap? (Doc ID 1010585.1)When a process calls the malloc()/sbrk() commands, only virtual swap is allocated.The operating system allocates the memory from physical disk-based swap first.If disk-based swap is exhausted or unconfigured, the reservation is allocated from physical memory.If both resources are exhausted then the malloc() call fails.To ensure malloc() won't fail due to lack of virtual swap, configure a large physical disk-based swapfacility in the form of a device or swapfile.  You can monitor swap reservation via "swap -s" and "vmstat:swap",as described above.Follow the guidelines below to calculate amount of virtual swap usage:Virtual swap = Physical Memory + Fixed Disk swap这位具有深厚技术背景的客户甚至自己写了一个程序来印证以上观点:该程序会通过malloc分配20G内存:#include <stdlib.h>#include <unistd.h>int main() {  int i;  for (i=1; i<(20 * 1024); i++) {    int * mem = (int *) malloc(262144 * sizeof(int)); /* allocate 1M memory */  }  sleep(3600);} 运行以上脚本,观察vmstat,从vmstat看到swap有下降20G,但是free(物理内存)是不变的# vmstat 5kthr      memoryr b w   swap  free3 38 0 142014200 947390000 25 0 149185672 1018547760 26 0 149206240 1018581441 30 0 146200840 1016728400 38 0 128054088 101455256 <<< 这里swap减少了18G1 30 0 127985768 1014631360 31 0 128119312 101556752到这里,我们可以完全确认这个ora-4030的问题是由于swap配置不当导致的。由于客户当前尚没有足够的disk资源来添加swap,并且问题紧急,他们最后的解决办法是停掉了一些应用释放出了更多的free memory,最后升级成功了,等今后有disk的时候再添加swap。

一个奇怪的ora-4030错误的诊断过程 前些天我收到一个客户报出的相当奇怪的ora-4030的问题,特和大家分享一下。 根据客户的描述,他是在Solaris 10 Sparc上尝试将一个Oracle 10.2.0.5.6的数据库升级到Oracle 12.1.0.2,在执行数据字典升级($ORACLE_HOME/perl/bin/perl catctl.pl -n  6...

诊断方法

关于RunQ过高引起的latch等待问题

最近一个客户新上线系统做压力测试发现负载一直上不去,cpu 只有20%左右,遇到大量latch: ges resource hash list等待事件,客户怀疑数据库存在瓶颈,导致测试结果无法达到他们性能要求,要求进行诊断。我们先看一下AWR 情况:Top 10 Foreground Events by Total Wait Timevent Waits Total Wait Time (sec) Wait Avg(ms) % DB time  latch: ges resource hash list 723,722 76.6K 105.86 16.8    <<<16.8%DB CPU 31K 6.8                                             <<<6.8latch free 207,653 22.5K 108.33 4.9 Other                  <<<<< 上述top10可以看到,的确latch: ges resource hash list等待占用了大量的DB time,平均达到了105ms,这个是非常差的一个指标,因为latch是cpu上的操作,连普通磁盘操作一般才几毫秒,所以的确像是DB端遇到了问题,根据这个等待事件搜索MOS系统,的确有一个已知bug,但是进一步check用户的Opatch,居然这个bug已经打上了,难道补丁fix不完整?我们暂时不能下这个结论, 看看AWR的负载情况: Snap Id Snap Time Sessions Cursors/Session InstancesBegin Snap: 462 03-Oct-16 23:15:24 1166 11.4 2  <<1166End Snap: 463 03-Oct-16 23:24:39 1149 11.7 2    <<1149 Host Name Platform CPUs Cores Sockets Memory (GB)nsdb3 AIX-Based Systems (64-bit) 512 256   945 <<cpu=512 Buffer Cache: 214,528M 214,528M Std Block Size: 8K   <<<214GShared Pool Size:51,200M 51,200M Log Buffer: 1,565,292K<<<51G 上面看出新系统配置非常高,512颗cpu,内存接近1T,给DB使用也足有250G多G可是session 数量只有1000+,笔者见过配置比这低得多,但是session轻松超过7000+,所以的确压力是没上来,我们在看一下top10,发现排名第二个的居然是DB CPU,这说明等待CPU也花费了很长时间,这个应该是cpu不够的征兆,但是客户说cpu利用率才20%,我们看一下vmstat输出:kthr    memory                           faults        cpu    ----- ----------- ------------------------ ------------ -----------r  b   avm   fre          cy  in   sy  cs us sy id wa40  0 151956625 91351897 86916 672284 227787 14  3 82  1 <<idle=8219  0 151956150 91352222 81535 324016 207307 13  2 84  1 <<idle=8425  0 151954274 91353963 82828 329847 206551 13  2 84  1 <<idle=84 的确idle平均超过80%, 再次查看mpstat输出:cpu  min  maj  mpc  int   cs  ics   rq  mig lpa sysc us sy wa id   pc 0  236    0    0  440  828   12    1   45 100 2539 52  9  5 34 0.38   <<<<工作cpu 1    0    0    0  194    0    0    0    1 100    0  0  1  0 99 0.21 2    0    0    0  189    0    0    0    1 100    0  0  1  0 99 0.21 3    0    0    0  191    0    0    0    1 100    0  0  1  0 99 0.21 4  150    0    0  318  771   62    1   57 100 7003 37 15  1 46 0.36  <<<<工作cpu 5    0    0    0  191    0    0    0    1 100    0  0  1  0 99 0.22 6    0    0    0  191    0    0    0    1 100    0  0  1  0 99 0.22 7    0    0    0  188    0    0    0    1 100    0  0  1  0 99 0.21  ...... 从上面可以看出列出8颗cpu只有2个在干活,所以整个系统只有1/4 cpu在干活,最终定位是OS 问题 。从上面的问题分析来看,对于latch等待过高的场景除了怀疑已知bug之外最有可能的是CPU资源不足,若是idle很空闲,可能是OS层面的问题,这次mpstat就给了我们一个很好的线索,所以一定要结合OS层面的监控数据来进一步分析原因。

最近一个客户新上线系统做压力测试发现负载一直上不去,cpu 只有20%左右, 遇到大量latch: ges resource hash list等待事件,客户怀疑数据库存在瓶颈, 导致测试结果无法达到他们性能要求,要求进行诊断。我们先看一下AWR 情况: Top 10 Foreground Events by Total Wait Timevent Waits Total Wait Time...

技术共享

全局临时表GTT的统计信息收集办法:

我们都知道,全局临时表GTT分为两种,一种是transaction level,一种是session level,分别通过on commit delete rows/preserve rows实现,其中session level表示在本sessoin数据有效,相同session内,之前事务操作的数据,对于后续的操作都可见,而事务级的GTT表示一旦事务结束(commit)那么立即delete,相同session 的后续操作看不到之前事务操作。在9i阶段可以使用GATHER_TABLE_STATS调用来收集统计信息须传入参数GATHER_TEMP为TRUE,10g开始oracle对于普通表和GTT收集统计信息并没有特殊处理,都是通过GATHER_TABLE_STATS存储过程来收集,但是由于上述的两种GTT特殊性,收集统计信息有特殊性: 1.对于session level的,因为GTT数据并不持久化,存在session 隔离性,需要在当前session 收集,若是通过另起窗口(新session)收集统计信息会不成功,原因就是收集统计信息的session 没有数据,自然也收集不到统计信息了。 2.对于transaction level的,即便是当前session 收集,因为GATHER_TABLE_STATS会先执行默认提交,所以数据就自动删除,自然也就没有数据可收集了。所以针对这种情景,oracle 有官方note 403587.1介绍下面就是移花接木办法来收集事务级GTT的步骤1. create a PRESERVE ROWS tableSQL> create global temporary table TT(I number) on commit preserve rows;2. populate with representative dataSQL> insert into TT select rownum from dba_objects where rownum<1000;3. gather statsSQL> exec dbms_stats.gather_table_stats(null,'TT');4. create a STAT tableSQL> exec dbms_stats.create_stat_table(null,'TTSTATS');5. export the stats from the PRESERVE ROWS tableSQL> exec dbms_stats.export_table_stats(null,'TT',null,'TTSTATS',null,true);6. truncate then drop the PRESERVE ROWS tableSQL> truncate table TT;SQL> drop table TT;7. now create the real temporary table (defined using DELETE ROWS - the default)SQL> create global temporary table TT(I number);8. finally import the stats exported from the STAT tableSQL> exec dbms_stats.import_table_stats(null,'TT',null,'TTSTATS',null,true); 3.在12c版本,oracle已经进步改善了对这种transaction level GTT的统计信息收集,也就是说GATHER_TABLE_STATS收集统计信息的时候不会默认发起commit,这样就不会破坏当前session的事务完整性,收集统计信息的存储过程就可以看到当前session的数据情况并收集统计信息。下面是一个简单的测试过程:3.1.创建transaction level GTTCreate Global Temporary Table maob_temp  (a number,b varchar2(100)) On Commit delete Rows; <<delete RowsTable created. 3.2.插入数据insert into maob_temp select rownum,object_name from dba_objects where rownum<1000;SQL> 999 rows created. 3.3.收集统计信息exec dbms_stats.gather_table_stats(user,'MAOB_TEMP');SQL>PL/SQL procedure successfully completed. 3.4.check是否数据已经被删除 select count(*)from maob_temp;SQL>  COUNT(*)----------       999 3.5.查看统计信息是否已经收集成功 SQL> select TABLE_NAME,NUM_ROWS,BLOCKS,SCOPE from DBA_TAB_STATISTICS where owner='MAOB' AND TABLE_NAME='MAOB_TEMP'; TABLE_NAME    NUM_ROWS BLOCKS SCOPE--------------------------------------MAOB_TEMP    0      0 SHAREDMAOB_TEMP  999      4 SESSION <<<< 注意:这一步要在和上述步骤相同的session执行,因为12c的这个新功能默认对GTT收集统计信息是session scope的,也就是说统计信息也是session 隔离的,其他session 看不到这个session收集的统计信息,若是变成传统的shared scope,那么仍然会默认先commit再收集统计信息并记录数据字典表,供其他session 使用,对于transaction level仍然存在先commit在收集情况,那么要解决问题,仍需要参考步骤2的移花接木办法,但是创建表之后要先指定为shared scope再收集统计信息。EXEC DBMS_STATS.SET_TABLE_PREFS (NULL,'TT','GLOBAL_TEMP_TABLE_STATS','SHARED');

我们都知道,全局临时表GTT分为两种,一种是transaction level,一种是session level, 分别通过on commit delete rows/preserve rows实现,其中session level表示在本sessoin 数据有效,相同session内,之前事务操作的数据,对于后续的操作都可见,而事务级的GTT表示一旦事务结束(commit)那么立即delete,相同...

技术共享

时区调整对job的运行时间的影响

调整时区既可以在操作系统调整,也可以在session 调整,那么不同的方式对于job的计划时间是否有影响呢,我们用实际例子来验证一下:Test1:1.首先看一下默认系统时区:oracle@fmw11g.vm.oracle.com $ dateSat Nov 19 03:50:10 GMT 2016 <'TJ1', job_type => 'STORED_PROCEDURE', job_action => 'JOB_PRO_TEST1', start_date => sysdate + 1/24, <<1hour 之后开始运行 enabled => true, auto_drop => true );end;/ 3.check job的运行状态select owner,job_name,job_action,start_date, state from ALL_SCHEDULER_JOBS where owner='MAOB';MAOBTJ1 JOB_PRO_TEST111/19/2016 4:51:26.000000 AM +00:00 SCHEDULED<< 03:51提交的,计划在GMT的上午4:51开始运行 Test2:1.检查一下当前时间oracle@fmw11g.vm.oracle.com $ dateSat Nov 19 03:54:30 GMT 2016 << alter SESSION set time_zone='+08:00'; <<<begindbms_scheduler.create_job( job_name=>'TJ2', job_type => 'STORED_PROCEDURE', job_action => 'JOB_PRO_TEST1', start_date => sysdate + 1/24, <<仍然1hour 之后开始运行 enabled => true, auto_drop => true);end;/3.check job的运行状态select owner,job_name,job_action,start_date, state from ALL_SCHEDULER_JOBS where owner='MAOB';MAOBTJ2JOB_PRO_TEST111/19/2016 4:54:34.000000 AM +08:00 RUNNING <<刚刚提交的job,居然计划在中国时区的4:54:34+08:00运行,因为系统当前时间是03:54:30 GMT,对应中国时区的11:54:30+08:00,所以显然是之前的时间,所以等于过期了,于是scheduler发现需要立即运行,也就处于RUNNING状态了Test3:1.检查一下当前时间并通过操作系统设置时区oracle@fmw11g.vm.oracle.com $ dateSat Nov 19 04:02:42 GMT 2016 < begindbms_scheduler.create_job( job_name=>'TJ3', job_type => 'STORED_PROCEDURE', job_action => 'JOB_PRO_TEST1', start_date => sysdate + 1/24, <<仍然1hour 之后开始运行 enabled => true, auto_drop => true);end;/ 3.check job的运行状态select owner,job_name,job_action,start_date, state from ALL_SCHEDULER_JOBS where owner='MAOB';MAOBTJ3JOB_PRO_TEST111/19/2016 1:02:57.000000 PM +08:00 SCHEDULED新job计划时间是北京时间1:02:57,这个正式符合要求的综上所述,正常在操作系统层面调整时区是不会影响job时间的,但是对于通过alter sessoin 调整时区需要谨慎,因为server process还是fork起来时候的时间(GMT)我们突然把session的时区给修改了,但是时间是不会变的,所以start_date就是变成GMT的时间和新时区的组合体了。

调整时区既可以在操作系统调整,也可以在session 调整,那么不同的方式对于job的计划时间是否有影响呢, 我们用实际例子来验证一下: Test1: 1.首先看一下默认系统时区: oracle@fmw11g.vm.oracle.com $ date Sat Nov 19 03:50:10 GMT 2016 <'TJ1', job_type => 'STORED_PROCEDURE',job_act...

诊断工具

网罗收集10046的各种Case,方便trace信息的收集

每逢与遇到SQL相关性能,我们总是需要收集10046的,来查看和诊断问题。因为10046真实的反应的SQL语句执行的时候的真实信息,解析,执行,获取的时间消耗,row source operation的具体情况。具体等待事件,每个时间具体的时间消耗等等。希望下面的Case有一种就能帮助到您。EVENT: 10046 "enable SQL statement tracing (including binds/waits)" (Doc ID 21154.1)Interpreting Raw SQL_TRACE output (Doc ID 39817.1)General SQL_TRACE / 10046 trace Gathering Examples (Doc ID 1274511.1)==================SQL性能常用:所有版本    10046 on session/system    To start tracing:    Alter session/system(慎用) set events '10046 trace name context forever, level 12';    /* execute your selects to be traced */     To stop tracing    Alter session/system(慎用) set events '10046 trace name context off';11g以上    1. event++在system级别指定sql_id,对新起的会话和当前的会话有效, 对其他已经存在的会话无效         SQL> alter system set events 'sql_trace [sql: 5qcyrymp65fak] level=12';          注释:当前事件对当前的session和新创建的session有效,对已经存在的其他session无效。         关闭 event ++:         SQL>  alter system set events 'sql_trace [sql: 5qcyrymp65fak] off';     2. event ++ 指定某个process的sql_id         SQL> oradebug setospid  <SPID>   <<<<<指定检测的会话的spid   <<<<<<<<<<<select spid from V$process, V$session where audsid=userenv('SESSIONID') and paddr=addr;         SQL> oradebug unlimit         SQL> oradebug tracefile_name         SQL> oradebug event sql_trace [sql: 5qcyrymp65fak] level=12          关闭 event ++:         SQL>  oradebug event sql_trace [sql: 5qcyrymp65fak] off     3. 不知道SQL_ID手动执行SQL收集10046    SQL>connect username/password    SQL>alter session set timed_statistics = true;    SQL>alter session set statistics_level=all;    SQL>alter session set max_dump_file_size = unlimited;    SQL> select value from v$diag_info where name='Default Trace File';   <<<<在11g以上工作    SQL> variable a1 <the type of ACCOUNT_TYPE_ID>;   <<<<<请执行类型    SQL> exec :a1 := 123123或'abded';   <<<<<<<请设置数值或字符串    SQL>alter session set events '10046 trace name context forever, level 12';    SQL>UPDATE /*+ RESTRICT_ALL_REF_CONS */ "LBI_ODS"."T_O_CUSTOMER_ACCOUNT" SET    "ACCOUNT_TYPE_ID" = :a1    WHERE    "ACCOUNT_NO" = 1234565;                                     <<<<<<<<<<<<执行sql重现问题    SQL>alter session set events '10046 trace name context off'; ==================使用Trigger设置10046    Use a Logon TriggerTo start tracing:    create or replace trigger user_logon_trg    after logon on database    begin    if USER = 'xxxx' then    execute immediate    'Alter session set events ''10046 trace name context forever, level 8''';    end if;    end;    /     /* Login a new session as User 'xxxx' and execute your selects to be traced */     To stop tracing: via LogOff Trigger (needs to be created before logging off)    create or replace trigger user_logoff_trg    before logoff on database    begin    if USER = 'xxxx' then    execute immediate    'Alter session set events ''10046 trace name context off''';    end if;    end;    /==================MMON的10046    1. 请打开auto purge的trace?     begin      dbms_monitor.serv_mod_act_trace_enable               (service_name=>'SYS$BACKGROUND',               module_name=>'MMON_SLAVE',               action_name=>'Auto-Purge Slave Action');    end;    /     2. 请至少等待一天,请您明天查看时候auto purge被执行,并产生m00x trace文件包含10046     3. 关闭auto purge的trace    begin      dbms_monitor.serv_mod_act_trace_disable               (service_name=>'SYS$BACKGROUND',               module_name=>'MMON_SLAVE',               action_name=>'Auto-Purge Slave Action');    end;    /==================Data pump 10046    1. enable 10046 trace for DM/DW process     alter system set events 'sql_trace{process: pname=dw | pname=dm} level=12';     2. Please reproduce the issue, then add "TRACE=480300" in data pump importing command     3. Please upload data pump importing log and the generated DM/DW process trace     To disable the tracing by issuing:     alter system set events 'sql_trace {process : pname = dw | pname = dm} off'; ==================其他方式设置10046    1. DBMS_SUPPORTTo start tracing:       exec sys.dbms_support.start_trace ;       /* execute your selects to be traced */        To stop tracing:       exec sys.dbms_support.stop_trace ;        Tracing from Another SessionThe examples below demonstrate how to trace session with SID=18 and Serial# =226 obtained from V$SESSION.    2. Using "dbms_system.SET_BOOL_PARAM_IN_SESSION"To start tracing:       exec sys.dbms_system.SET_BOOL_PARAM_IN_SESSION(18, 226, 'sql_trace', TRUE);       /* execute your selects to be traced */       To stop tracing:       exec sys.dbms_system.SET_BOOL_PARAM_IN_SESSION(18, 226, 'sql_trace', FALSE);    3. Using "dbms_system.set_ev"To start tracing:       exec dbms_system.set_ev(18, 226, 10046, 12, '');        To stop tracing:       exec dbms_system.set_ev(18, 226, 10046, 0, '');    4. Using "dbms_system.set_sql_trace_in_session"To start tracing:       exec dbms_system.set_sql_trace_in_session(18,226,TRUE);       /* execute your selects to be traced */       To stop tracing:       exec dbms_system.set_sql_trace_in_session(18,226,FALSE);    5. Using "sys.dbms_monitor"To start tracing:       exec sys.dbms_monitor.session_trace_enable(session_id=>18,serial_num=>226, waits=>true, binds=>true);       /* execute your selects to be traced */        To stop tracing:       exec sys.dbms_monitor.session_trace_disable(session_id=>18,serial_num=>226);   http://docs.oracle.com/cd/B28359_01/appdev.111/b28419/d_monitor.htm#CFAHBEAB   CLIENT_ID_STAT_DISABLE Procedure   CLIENT_ID_STAT_ENABLE Procedure   CLIENT_ID_TRACE_DISABLE Procedure   CLIENT_ID_TRACE_ENABLE Procedure   DATABASE_TRACE_DISABLE Procedure   DATABASE_TRACE_ENABLE Procedure   SERV_MOD_ACT_STAT_DISABLE Procedure   SERV_MOD_ACT_STAT_ENABLE Procedure   SERV_MOD_ACT_TRACE_DISABLE Procedure   SERV_MOD_ACT_TRACE_ENABLE Procedure   SESSION_TRACE_DISABLE Procedure   SESSION_TRACE_ENABLE Procedure    6. Using Oradebug (as SYS)To start tracing:       oradebug setospid xxxx       oradebug event 10046 trace name context forever, level 12;       /* In the session being traced execute the selects  */        To stop tracing:       oradebug event 10046 trace name context off ;

每逢与遇到SQL相关性能,我们总是需要收集10046的,来查看和诊断问题。 因为10046真实的反应的SQL语句执行的时候的真实信息,解析,执行,获取的时间消耗,row source operation的具体情况。 具体等待事件,每个时间具体的时间消耗等等。希望下面的Case有一种就能帮助到您。EVENT: 10046 "enable SQL statement tracing...

诊断方法

一个IP packet reassembles failure导致的IPC Send timeout和实例驱逐

记一个IP packet reassembles failure导致的IPC Send timeout和实例驱逐案例 一般来说,对于IPC Send timeout,可能的情况有以下几种: 1、节点本地盘CPU等待队列超高或IO繁忙、空闲物理内存用尽等,这种情况往往是相互伴随发生的,可以从OSWatcher的vmstat和iostat来发现; 2、私网网络发生丢包或异常,从OSWatcher的netstat和trace route输出中可以看到; 3、DRM或skgxp等方面的Oracle Bug,如(Doc ID 1594578.1)   这个案例属于上述第二种,但由于处理过程比较反复,且最后一次重现时问题指向IP reassembles failure,而不是UDP packet drop,所以记录下来以备今后参考。详细信息请下载附件文档:   IP reassembles failure导致节点驱逐的案例 有客户可能会问:是不是LINUX所有的系统都需要调整上面的参数呢? 从后来在网上查到的类似案例来看,RHEL方面确认这个问题基本也就出现在LINUX6.6和部分6.7中,这个问题的根本原因是在linux6.6中引入了percpu counters计数器在内核 kernel-2.6.32-477.el6, 在后面的linux 6.8(kernel-2.6.32-642.el6)和linux 6.7.x(kernel-2.6.32-573.8.1.el6)已经修复了该问题, 所以在其它配置中没有影响。

记一个IP packet reassembles failure导致的IPC Send timeout和实例驱逐案例 一般来说,对于IPC Send timeout,可能的情况有以下几种: 1、节点本地盘CPU等待队列超高或IO繁忙、空闲物理内存用尽等,这种情况往往是相互伴随发生的,可以从OSWatcher的vmstat和iostat来发现; 2、私网网络发生丢包或异常,从OSWatcher的netst...

诊断方法

Index Unique Scans我们要说的

最近遇到一个客户发现一个sql语句的执行计划走了index range scan,他期望的结果是Index Unique Scans,因为对应的字段上是有主键的。经过排查我们发现INDEX_NAME IX_XXXXXXXXXXXXXINDEX_TYPE NORMALTABLE_OWNER CXXXTABLE_NAME CXXX_XXXXXXXXTABLE_TYPE TABLEUNIQUENESS NONUNIQUE                              <<<<<<<<<<<<<<<< NONUNIQUE 主键可以使用NONUNIQUE INDEX吗? NONUNIQUE INDEX的存在是引起执行计划改变的原因吗?带着疑问我做了下面的测试:drop table t_table;--创建表CREATE TABLE t_table(numcol INT);--创建非唯一性索引CREATE INDEX t_table_idx ON t_table(numcol);--追加主键约束ALTER TABLE t_table ADD CONSTRAINT t_table_pk PRIMARY KEY(numcol);SELECT  /*+gather_plan_statistics*/ * FROM t_table WHERE numcol = 1;select sql_id, child_number from v$sql where sql_text like q'!SELECT  /*+gather_plan_statistics*/ * FROM t_table WHERE numcol = 1!' and sql_text not like '%v$sql%';SQL_ID        CHILD_NUMBER------------- ------------698t1z5ruk076            0--查看执行计划,确实重现了客户的问题select * from table(dbms_xplan.display_cursor(sql_id=>'698t1z5ruk076', cursor_child_no=> 0 , format=>'TYPICAL IOSTATS'));PLAN_TABLE_OUTPUT                                                                                                                                                                                                                                                                                          ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------SQL_ID  698t1z5ruk076, child number 0                                                                                                                                                                                                                                                                        -------------------------------------                                                                                                                                                                                                                                                                        SELECT  /*+gather_plan_statistics*/ * FROM t_table WHERE numcol = 1                                                                                                                                                                                                                                           Plan hash value: 3519940426                                                                                                                                                                                                                                                                                  ---------------------------------------------------------------------------------------------------------------                                                                                                                                                                                              | Id  | Operation        | Name        | Starts | E-Rows |E-Bytes| Cost (%CPU)| A-Rows |   A-Time   | Buffers |                                                                                                                                                                                              ---------------------------------------------------------------------------------------------------------------                                                                                                                                                                                              |   0 | SELECT STATEMENT |             |      1 |        |       |     1 (100)|      0 |00:00:00.01 |       1 |                                                                                                                                                                                              |*  1 |  INDEX RANGE SCAN| T_TABLE_IDX |      1 |      1 |    13 |     0   (0)|      0 |00:00:00.01 |       1 |                                                                                                                                                                                              ---------------------------------------------------------------------------------------------------------------                                                                                                                                                                                              Predicate Information (identified by operation id):                                                                                                                                                                                                                                                          ---------------------------------------------------                                                                                                                                                                                                                                                            1 - access("NUMCOL"=1)                                                                                                                                                                                                                                                                                    选定了 18 行--索引是NONUNIQUE INDEXselect OWNER,INDEX_NAME,UNIQUENESS from dba_indexes where table_name='T_TABLE';OWNER                          INDEX_NAME                     UNIQUENESS------------------------------ ------------------------------ ----------SKYDL                          T_TABLE_IDX                    NONUNIQUE 优化器是如何考虑是否使用Index Unique Scans的呢? 有两点:1. 是否一个查询的谓词参照了所有的唯一性索引键值的字段并使用了等值操作符,比如 where emp_id = 100;2. 索引必须是唯一性的。同时满足上面的两个条件,优化器才会考虑使用Index Unique Scans。很显然上面的例子不满足第二个条件,因此优化器忽略了Index Unique Scans。

最近遇到一个客户发现一个sql语句的执行计划走了index range scan,他期望的结果是Index Unique Scans,因为对应的字段上是有主键的。 经过排查我们发现INDEX_NAME IX_XXXXXXXXXXXXX INDEX_TYPE NORMAL TABLE_OWNER CXXX TABLE_NAME CXXX_XXXXXXXX TABLE_TYPE TABLEUNIQUEN...

Oracle

Integrated Cloud Applications & Platform Services