浅谈Oracle Database 19c
Oracle Database 19c是大多数客户将其升级目标定位的版本,Oracle已将稳定性作为此版本的核心目标。 在Oracle Database 19c中,开发人员专注于修复已知问题,而不是添加新功能。 这导致了数百人年的测试和数千台服务器每天24小时运行测试。这种对稳定性的关注远不止核心数据库功能
提供综合数据库运维服务与优化方案(不限Oracle MySQL PG GaussDB GoldenDB OceanBase等), 微信/Tel:(+86)134-365-60330
Oracle Database 19c是大多数客户将其升级目标定位的版本,Oracle已将稳定性作为此版本的核心目标。 在Oracle Database 19c中,开发人员专注于修复已知问题,而不是添加新功能。 这导致了数百人年的测试和数千台服务器每天24小时运行测试。这种对稳定性的关注远不止核心数据库功能
在12c以前的版本数据库实例使用操作系统认证连接ASM实例,因为ASM CLIENT(DB INSTANCE)和ASM Server总是在同一个主机上, 从12c版本开始引入的FLEX ASM架构允许数据库实例可以和ASM运行在不同的主机中
2018年的10月份发布了oracle goldengate最新版本 18c(18.1),下载时分别对于oracle db就两种安装文件: 传统Classic 架构和微服务Microservices架构
每年都习惯性的记录当年的“足迹”, 今年是开BLOG的第10个年头, 显然我已到了喝水都要放枸杞的年纪,没有了年轻时的时间和精力, 但未忘初心,坚持不易,希望给大伙分享更多的”锦鲤”。 数了一下目前已记录了845篇笔记,不算多也不算少。 环顾2018年,或许欢乐,或许忧伤, 经历些许还未准备好又是中年该面对的问题,曾一个小同事开玩笑说如果他像我经历的今年事一样,可能就去报复社会了,(_o_)!。 我的2018: 跟医院还是少不了的交集,希望各位及家人新的一年都能有个好身体 跟公司去认识了一下越南(北越) 现在带娃出门就跟搬家似的,活动也少了 睡个懒觉就跟过年似的,时间可贵,报了快一年的驾照,科目1才刷了1个课时 天天劳碌无休止就跟判了无期徒刑似的,而且今年还加刑了 年中意外从堆积的邮件里发现了2月前的一个ORACLE 给的一个ACE -A的消息 经历了繁重的装修过程,今年也算是高于段落,乔迁新居算是一喜事 家里没矿,工作一刻不能停歇, 换了一新东家 一些忘了的事… 新的一年,祝愿各位在“猪”年, 每觉睡到自然醒。 我们 “佩奇”一家给您拜年。 好嗨哟,感觉人生已经到达了高潮,感觉人生已经到达了巅峰…
“row cache objects”是序列化latch,用于保护对SGA中dictionary cache的访问。 只要是参考dictionary cache中的元数据对象,就会获取此latch。 Row Cache Objects Latch 是 shared pool latch 相关。”row cache objects”是序列化latch,用于保护对SGA中dictionary cache的访问。 只要是参考dictionary cache中的元数据对象,就会获取此latch。 Row Cache Objects Latch 是 shared pool latch 相关
如何分析RAC中的GC 问题,结合案例分析11.2.0.3 RAC中异常高的gc cr grant 2-way等待事件, bug 的解决方法”_max_cr_rollbacks” …
前段时间的一个案例,突然好几个数据库出现了ora-600 坏块相关的错误, 但是幸运的是使用rman, dbv, analyze table validate structure 都没有实际的坏块, 也就是说很可能只是出现在memroy 中,目标和源都是11.2.0.3.7 2nodes RAC, 最终是确认了为Procedure中使用了DBLINK触发
Recently, we have faced a very serious problem with Oracle SCN. The SCN with a production env ORACLE RDBMS grows very fast, the SCN rate is more than 30k per second . In theory, there should not be such a high transaction volume. The environment is a 11.2.0.3 2-nodes RAC ON AIX 6.1 platform, and have applied PSU11.2.0.3.7 .
升级了Oracle 12cR2的同学,尤其是安装了2018 4月RU的版本(12.2.0.1.180417), 遇好检查下你的trace目录下是否生成了超大量的trace file,或单个超大的trace file文件,因为在这个版本下有两个原因很可能生成这些trace:
1. Trace files generation with message “AUTO SGA: kmgs_parameter_update_timeout gen0 0 mmon alive 1”.
2. Trace files generated from RMAN module with KRB messages.
2C中为了在不同实例间统一的密码管理, 支持把DB密码(ASM password same)存储到ASM DISKGROUP中,这样在维护DG环境时,当同步密码文件时就要先确认一下密码的位置, 同样DG端也可以把密码存储到ASM中,然后使用srvctl modify database修改pwd路径. 这个案例通过在标准化DG配置中因密码不一致产生了各种错误
本11.2.0.4 2-nodes RAC, 现象是service_name 参数出现了一些SYS.KUPC$ 的service, 监听上同样有,且停节点1 ,service会漂到节点2, 重启双实例后同样存在, 手动修改service_name可以临时解决,但是重启实例还是会存在,虽然是新增service, 监听上看着乱,其它没什么影响, 这类服务常见于datapump 自动增加的…
又近年末,各种事情忙的不可开交, 但最近的BUG又突然接二连三, 争取把在2018年的最后几天习惯性简单的总结了结, 这篇简单的记录一下上个月一套11.2.0.4 2-ndes RAC的案例, 问题发生的第二天说有个表还是不能insert和grant, insert报ora-600[qesmaGetTblSeg1] 和grant 报 ora-7445 [kss_first_child] ,得知事前有对该表做truncate, 这是一个HASH分区表, 相同的表结构在用其它表名一切正常,但是rename tabler后问题又能重现, 包括把表删了重建问题依旧。 下面来还原这个问题: SQL> CREATE TABLE ANBOB.LOC_ANBOB_VARLOG 2 ( “OID” NUMBER(14,0) NOT NULL ENABLE, 3 “VARIABLEID” VARCHAR2(32) NOT NULL ENABLE, 4 “SQLBANDVAL” VARCHAR2(256), 5 “RUNTIME” VARCHAR2(32) NOT NULL ENABLE, 6 “INTIME” DATE DEFAULT sysdate 7 ) PARTITION BY HASH (“OID”) … Read more
前日有套11.2.0.3 RAC on HPUX数据库环境突然出现较高的latch: free wait event, 该event在10G以后的版本较为少见(已经细化为具体latch) , 通过p1 or p2值可以确认具体latch. transaction branch allocation占用较高的db time
建议在SLSE 12或以后的版本,或LINUX 7等以后的版本时,先了解一下系统变化,至少在安装RAC时, 把DefaultTasksMax修改加入到安装方档中去, 可能Oracle 在以后的安装文档或最佳实践中会增加该内容。
在许多公司中,各种与Oracle数据库相关的任务(如管理ASM和备份/恢复Oracle数据库)都有明确的职责分离。在过去都是使用sysdba管理所有权限如asm\DG\备份, 从Oracle Database 12c R1开始,可以使用SYSBACKUP,SYSDG和SYSKM管理权限。从Oracle Database 12cR2开始,新增加了SYSRAC管理权限..
This issue happens on Oracle RAC environment 11.2.0.3 , db alert log show ora-21780 frequently caused by the SMON is not able to clean some objects, This short article simply record it. and how to fixed it. # db alert log Fri Nov 02 09:55:59 2018 Errors in file /oracle/app/oracle/diag/rdbms/anbob/anbob1/trace/anbob1_smon_12872.trc: ORA-21780: Maximum number of object … Read more
今天遇到的一个案例,一套ORACLE 12.2 FLEX CLUSTER, 在安装了RU(20180417)后节点2的CRS启动正常,但是其它如ASM、DB、GIMR 等资源都未启动, GI alert log并未发现错误,手动使用srvctl启动ASM资源提示:
CRS-2549: Resource ‘ora.asm’ cannot be placed on ‘anbob02’ as it is not a valid candidate as per the placement policy
Oracle database XE发布过10G、 11G, 最近XE 18C 发布,而且是18.4版, 注意这里的版本不等同于ORACLE DATABASE EE的版本号。
ORACLE DATABASE XE 18C IS FREE For Me, FREE For You, FREE For Everyone! and Free to Download , Free to Use, Free to Deploy!
看到FREE无比的激动,她不只免费,而且较比之前的版本,是一个Full OPTION ON的版本
近日oracle发布了传说已久的RPMs安装版本18.3, 但不是oracle database core mini版, 安装文件有3.5GB左右大小。 业界这么关注是因为这是oracle database的第一个可以使用rpm方式安装的版本, 这样就简化了数据库的安装部署,降低了oracle安装的技术门槛, 目前可以去官方OTN下载 FOR Linux x86-64bit 版本。 安装介质 安装软件 开始前如果你使用OEL, 拥有ULN, 可以以root身份执行 yum -y install oracle-database-ee-18c 如果当前环境没有ULN需要下载率离线的安装包和oracle数据库的原装软件请求包preinstall,然后以root身份执行 yum install -y install oracle-database-preinstall-18c yum -y localinstall oracle-database-ee-18c-1.0-1.x86_64.rpm 如果是RHEL环境需要手动下载源文件,然后以root身份安装 # RHEL7 curl -o oracle-database-preinstall-18c-1.0-1.el7.x86_64.rpm https://yum.oracle.com/repo/OracleLinux/OL7/latest/x86_64/getPackage/oracle-database-preinstall-18c-1.0-1.el7.x86_64.rpm yum -y localinstall oracle-database-preinstall-18c-1.0-1.el7.x86_64.rpm rm oracle-database-preinstall-18c-1.0-1.el7.x86_64.rpm # RHEL6 curl -o oracle-database-preinstall-18c-1.0-1.el6.x86_64.rpm https://yum.oracle.com/repo/OracleLinux/OL6/latest/x86_64/getPackage/oracle-database-preinstall-18c-1.0-1.el6.x86_64.rpm yum -y localinstall … Read more
Connected to an idle instance.
Errors in file /s01/oracle/app/oracle/diag/rdbms/anbob/ANBOB1/trace/ANBOB1_cjq0_14004.trc:
Process J000 died, see its trace file
kkjcre1p: unable to spawn jobq slave process