DB Time 去哪了? Oracle 12C AWR 增加了on cpu runqueue

是否遇到过在分析AWR报告时,明明AAS很高,但从Top 10 Foreground Events by Total Wait Time 上看top event使用的百分比加起来离100%很远? 那DB TIME去哪了?下面我附一个11G(11.2.0.4 RAC on AIX) AWR 案例,这个问题在12c的AWR中提供了TOP EVENT。

,

Oracle 20c新特性: dbms_xplan.display_awr 增加了谓词信息

执行计划中的谓词信息非常的重要,有助于我们判断是否进行了隐式转换,为什么没有使用索引等, 使用dbms_xplan.display_cursor可以从shared_pool中取到sq cursor的谓词,但是在20c之前dbms_xplan.display_AWR 在之前的版本中并不能, 但是Oracle社区的投票和诸多人的推动下,终于在oracle 20c所谓词信息也在dbms_xplan.display_AWR中显示

,

Enable DDL logging in Oracle databaase (安全审计)

Oracle database use DDL statements to define structures such as tables to store data and functions to store code. By default Oracle database does not log any DDL operations performed by any user.When someone do some destructive DDL in DB, we often need the DDL log..In this article I will only record the method of using Oracle Database Lifecycle Management Pack( Enable_ddl_logging)

Oracle 12c Alert log show ” ADVISORY: Please collect redo for investigation of ORA-8103″ frequently

叕一个oracle 12c频繁生成日志文件的问题,最近一套12.2的RAC突然又文件系统告警,生成了大量的trace文件,db alert log也在不停的显示如下内容:
ADVISORY: Please collect redo for investigation of ORA-8103. Use command:
ALTER SYSTEM DUMP REDO scn min 1 scn max 16716635042430 dba min 32 2094058 dba max 32 2094058;

Troubleshooting ORA-01578 ORA-01110 ORA-26040 NOLOGGING corrupted block

The following errors have recently occurred in our database( Oracle 19c RAC):
ORA-01578: ORACLE data block corrupted (file # xxx, block # yyyyy)
ORA-01110: data file xxx: ‘xxxxxxxxxxxxxxxxx.dbf’
ORA-26040: Data block was loaded using the NOLOGGING option

, , , ,

Oracle 哪些进程可以KILL不会导致实例重启?

oracle后台进程当出现问题时,有些进程kill会导致实例立即重启,像smon, pmon,ckpt.. , 而有些进程kill并不会影响实例可用性, 甚至会立即做进程级重启从db alert log可以观测到,如mmon,rec,jnnn, pnnn等, 前两天看到Poder在其BLOG分享v$process的基表X$KSUPR中中有记录哪些是oracle的致命进程,在X$KSUPR.KSUPRFLG第3位, 下面我做个测试, kill 点X$KSUPR.KSUPRFLG第3位都不为1的进程。

Wait Event: L1 validation

The ‘L1 validation’ looks like a segment space management issue. Although it’s not documented (yet) v$event_name suggests that the p1 and p2 parameter are the “segheader” and “l1bmb”. L1 BMB – stands for L1 bitmap block.

Oracle多租户环境,如何直接登录到PDB, 不指定TNS? 18c、 19c、20c

Oracle 20C non-CDB将不再支持,多租户架构(multitenant architecture )已深入Oracle内核, 没有理由再拒绝CDB,有时计划核心业务库上在CDB中只有一个PDB, DBA在主机本地登录数据库,感觉每次都要sqlplus 直接登录cdb$root后,还要再alter session set container=xx切换到PDB,或者使用pdb的service_name,很麻烦,那有没有办法可以像非多租一样直接登录到PDB呢? 有!

,

Oracle 18c新特性:PDB Snapshot Carousel (PDB快照 旋转木马)

在一些生产容灾环境中有一种定期clone一份数据库的需求,如BCV存储快照技术 ,当然最近几年CDP, CDM技术的出现也是基于存储快照实现数据库历史时间的恢复。Oracle 在18c中同样提供了一种自动生成并清理历史数据库快照的技术PDB Snapshot Carousel…

,

Troubleshooting DB instance start fail ‘kggpnpInit: failed to init gpnp’ after apply DB PSU 11g,12c,18c,19c

ORACLE RAC环境记的之前GI和DB的version 前4位相同是可以兼容的,甚至有时DB PSU比GI PSU新,最近有朋友遇到只安装了DB PSU后,RAC中实例启动失败的问题, db alert show:
USER(3037)]CRS-2316:Fatal error: cannot initialize GPnP, CLSGPNP_ERR (Generic GPnP error).
kggpnpInit: failed to init gpnp
WARNING: No cluster interconnect has been specified

,

Alert: 升级19C(19.6) impdp导入分区表使用network_link时ORA-39029 ORA-31671 ORA-00600 [qesmaGetPamR-NullCtx]

升级oracle 19c的计划基本都已提上日程,数据泵也是一种对于小型数据库常用的解决方案,但是还是有个bug在那悄悄等着,对于本地没有存放dumpfile存储空间时常常使用network_link“不落地式”的导入方式, 这里记录一个同步时遇到ORA-39014、ORA-39029、ORA-31671案例。

, ,

Alert:Oracle19c DBCA take many hours after apply 19.6 DBRU without OJVM patch (DBCA超级慢)

上周同事在安装Oracle 19c RAC环境时,全新的软件在安装了当前最新的19.6 RU后,DBCA创建数据库居然花了4个小时左右,环境RHEL 7.5 , 本地全SSD 硬盘,共享存储是”菊厂”的高端全闪阵列,这样的速度不能忍。

,

Troubleshooting ‘ORA-28041: Authentication protocol internal error’ change password 12c R2 DB

如果 Oracle client version 较低(<11.2.0.3),且数据库升级到 Oracle 12.2 并且应用了 April 2018 PSU 、18C 、19C databases 后, 当用户密码过期后,使用低版本的oracle client尝试修改用户密码时会遇到下面的错误,: ORA-28041: Authentication protocol internal error.

Oracle12c R2注意事项: 又一个BUG 生成大量的trace 含 kjshash() kjqghd()

Oracle 12c R2 又一bug,DIAG目录一天生成100GB的trace文件, 之前分享过几篇,这里再记录一种情况,遇到该现象时,需要先查看生成的trace文件进程是前台还是后台, trace的文件内容,当前数据库是否有配置诊断类event. 这个trace文件是有前台进程生成的,trace文件中包含kjshash和kjqghd。

,

Alert: Patch 28553832(11g R2 Extended Support patch) need apply upgrade to 19c

Direct Upgrade to Oracle Database 19c的版本有11.2.0.4,12.1.0.2,12.2.0.1,18c. 在最近11G (11204)升级19C的方案测试时遇到了上面的错误, 是不是很惊喜?在GI升级19c时需要检查patch 28553832是否安装,而且不允许跳过。这个从Patches to apply before upgrading Oracle GI and DB to 19c or downgrading to previous release (Doc ID 2539751.1) 可以确认。

,

Alert: oracle 12\18\19\20c 不要滥用“_ORACLE_SCRIPT”=true

“_ORACLE_SCRIPT”参数首先是个隐藏参数,所以很少有文档中描述他打开了哪些开关,因为它是oracle内部维护时使用,在ORACLE_HOME下的脚本中不少都有alter session set “_oracle_script”=ture的SQL, 但是注意执行完后即使的再改回false. 千万不要为了突破oracle的默认限制而随意使用_oracle_script参数,生产库除了oracle要求更不建议修改,因为后期有可能会遇到不些不必要的麻烦。

,

Alert: Oracle 19c DDL “COMMENT on Table” sql cursor no invalidation(deferred invalidation增强)

有时我们是希望做了一些改变后希望SQL再次解析生成更好的执行计划(maybe), 通常是comment DDL或grant select on xx to system等相对影响较小的操作。但是注意“COMMENT ON” DDL 在Oracle 19c中行为貌似又改变了(12c未改变,18c不确认),SQL CURSOR不再失效invalidation

, ,

Oracle 20C 关于Security安全的行为改变

Oracle 20-22c是12c后的下一个大版本集,也有了大的改变,如本身就云架构数据库定位从20c起不再支持非多租户,了解新版本可以了解数据库的发展方向,减少不必要的麻烦,如短时间内再次升级功能不再支持应用程序又要重写, 对于安全方面同样也有一些变化,这里简单的记录。

Troubleshooting long wait “enq: US – contention” & “enq: IV – contention” after DDL, alert show “libcache interrupt action by LCK”

一套12C R2版本的4节点RAC数据库,记录一起高并发业务繁忙时,DDL导致数据库出现大量前台会话长时间等待”enq: US – contention” & “enq: IV – contention” ,该SQL(INSRT VALUE)的只是一个Children cursor无法执行(sql_start_exec 时间已过去数小时),第二个的children cursor执行效率正常,最终KILL 这些长时间运行前端会话解决。

, ,

Oracle 20C新特性一:Blockchain Tables(区块链表)

尽管新兴的分布式应用程序受益于去中心化信任模型中,但当今大多数应用程序都具有中央权限(银行,代管公司,交易交易所,政府办公室等),并且借助Oracle数据库中的区块链表,可以使这些应用程序更安全,而无需增加更改为托管服务器的复杂性去中心化模型。这就是使用Oracle Database 20c本机区块链表的原因

,