Know more about V$BACKUP_CORRUPTION
The V$backup_corruption view shows corrupted blocks discovered during an RMAN backup. But once the corruption on this blocks has been fixed this view is not updated.
提供综合数据库运维服务与优化方案(不限Oracle MySQL PG GaussDB GoldenDB OceanBase等), 微信/Tel:(+86)134-365-60330
数据库oracle
The V$backup_corruption view shows corrupted blocks discovered during an RMAN backup. But once the corruption on this blocks has been fixed this view is not updated.
alert log frequently show the below worning ——————————————– Oradism binary does not have root privilege. Please verify if oradism has required privilege WARNING: ——————————- WARNING: oradism did not start up correctly. Return code: 16 errno 0 info1 1001 info2 65535 ———————————————– The oradism executable cannot have 755 (rwx-r-x-r-x) permissions, and should be owned by root … Read more
library cache: mutex X等待事件是当一个会话以 exclusive mode持有library cache mutex时,另一个会话当前无论何时申请此mutex时必须等待其释放。很多时候对 library cache做不同的操作时都需要申请一个mutex, 所以最重要的是确认mutex的位置”location”, 该位置有助于分析该类等待事件的原因
前几日在一客户搭建ASM环境,存储工程师为每个LUN划分了1TB大小,但是当创建ASM DISKGROUP时显示为每个ASM DISK约为4PB 大小, 当然不是存储工程师开的玩笑,也不是上帝的馈赠,实际是ASM在AIX 平台上的当ASM DISK LUN 在1T及以上的BUG.
朋友一套12C R2多组户架构3节点RAC数据库反应数据库响应缓慢,因远程不方便,只拿到事后一份AWR,数据库出现较高的cursor: mutex X 和cursor: mutex S,sql verison能达到7000多,并且high version的SQL都是递归内部SQL, 12.2的隐藏参数_CURSOR_OBSOLETE_THRESHOLD原来现在默认已加大到了8192,
第一个是从2017年开始改变了季度更新的方式,改变了过去的PSU为RUR (Release Update Revision) ,和改变 ProactiveBP 为 RU (Release Update),第二个是oracle 12c的下一个版本不再延续12.2.0.2 和12.2.0.3的形式发布,从201708月更新MOS note#742060.1确认了计划分别与2018年年第1季度和2019年第1季度发现未来的两个版本oracle 18.1 和oracle 19.1
ORACLE12C的下一个版本是18.1(12.2.0.2),这里我要分享的这个新特性是12.2 已经悄悄引入但undocument的,这个特性因为没有某些原因在12.2中都没有公开,但是SQL语法已经可用,暂时称做Sequence SCALE EXTEND 。注意公开前不建议在用户应用中使用。
TDE是从Oracle 10g R2版本时引入,Transparent Tablespace Encryption对表空间的加密是在ORACLE 11G R1版本引入,但是只支持对新建表空间时指定加密码选项,对后新数据写入加密,在12CR1中可以对表空间OFFLINE后再加密,但是那样对于非常大数据库的数据库就意味着使用更多的时间维护窗口,从12C R2版本引入了online tablespace encryption的新特性,同时还引入了新的管理密钥的方法
ORACLE 12c有些小特性非常的实用,如Oracle 12c New Feature: Last Login Time for Non-Sys Users,可以列出非SYS用户的最后登录时间,该数据可以做为清理用户里的依据, 如果找出哪些用户是ORACLE 系统用户在12C之前还是相对麻烦一些,因为我们可能知道像sys, system这些系统默认创建的用户,其它如果安装时选用较多的DB option时,往往不容易查找自动在创建数据库里脚本中创建的哪些用户。
ASM实例的ASM_DISKSTRING初始化参数使用一个逗号分割的字符串限制ASM实例发现的DISK可以用于ASM DISK, 该字符串支持通配符如使用星号(*)表示LIKE,只有匹配了该字符串中的路径,ASM disk才会被发现;同样支持如果问号(?)为该字符串的第一个字符时,像sqlplus中一样表示的是ORACLE_HOME的路径。注意同一DISK不会因为路径多次匹配而显示多次
env: 11.2.0.3 RAC Dataguard ON Exadata x2, a standby instance crash, alert log show ora-600 internal error, ORA-00600: internal error code, arguments: [H_MK_WRITING_CR_BG], []
昨天数据库有3个session记录在v$session一直是KILLED状态,且已经好几个小时,当前的等待事件为”db file sequential read”, 其中有一个session是DML SQL,所以最后在事务结束前的行级锁一直未能释放,影响了操作相同记录的业务, 从数据库尝试kill [immeidate]没报错但是无法清理,手动weekup PMON检查PMON trace无报错, 通过操作系统层KILL -9 无报错仍无法清理
突然数据库出现了较高的enq: TX – row lock contention的等待事件,这是一个APPLICATION CLASS的wait event, 通常出现在DML事务级的行或块竞争,这次的MODE为6, 语句只是简单的delete xx where rowid=:bind; 但是查看数据库和应用日志都出现了ORA-600的错误, 判断问题就不再是简单的行事务竞争, 手动模拟语句也还原出问题,但并不是所有记录每次都能触发,现象为运行DELETE SQL时失败并出现ora-600 [kcladdle_1].
这个问题就是TABLE默认的属性Tablespace已不存在,在Split IOT表失败,但是创建的递归“瞬态表”却留在了数据库中,需要人手动清理,如果不删除下次再次尝试时就会提示不同的错误信息“ORA-00959: name is already used by an existing object”,解决方法是手动清理“瞬态表”后修改表的默认属性
去年一个故障案例经过时间的沉淀问题没在发生今天有时间简单的总结一下,当时正时午睡时分,突然告警4库8个实例同时不可用,这么大面积的故障多数是有共性的关连,当时查看数据库DB ALERT日志都是I/O错误写失败,后确认8个实例都是使用了存储层的同步容灾技术…
当前ORACLE数据库提供两种方式的补丁一种是主动的Proactive Patches和另一种被动的Reactive Patches,其中Reactive Patches是指过去的ONE-OFF Patch,而过去的PSU,SPU/CPU,BP都是Proactive Patches。从12c(12.1.0.2)起数据库又提供了一个名为DBBP的补丁类型,在数据库安装选择补丁时建议是PSU,CPU,DBBP中的一种…
现在老听到抱怨在VM安装12C RAC的资源需求太大,安装个12C GI就要几十G磁盘空间和4G的内存, 这些资源被哪用了?当然离不开GIMR和ASM target memory这两个的变化,这篇就简单的谈谈这两个变化及如何突破限制…
这篇继续ORACLE 12.2的新特性, Proxy PDB顾名思义就是一种代理PDB也可以叫 referenced PDB, 实现的是像访问本地CDB中的PDB一样访问远程的PDB,简单可以说可以快捷方,它的应用场景是当一个程序在application Containers中需要调用两个不同CDB的数据源时..
近期安全扫描发现数据库服务器主机存在端口8888暴露风险, 使用http访问该端口是Oracle Containers for J2EE (OC4J)的页面, OC4J是经过J2EE认证的应用程序服务器,提供JSP, EJB, Servlet等程序支持, 在主机上查看用户进程可以确认一个JVM的OC4J进程,是Oracle CRS自带的资源ora.oc4j调用。通常对于数据库没有什么用途,可以停止该服务。
最新版的OGG 12.2还不支持ORACLE RDBMS 12.2, OGG 的版本是向前兼容的, 按ORACLE的计划会在OGG 12.3版本解决,支持从ORACLE 12.2 extract,(注意这里的OGG 12.3 不是OGG for Bigdata 12.3) , 并且会在2017年的6、7月份发布OGG 12.3, 并未说是否是所有平台。