站内搜索
Oracle证书
分类目录
- ASM (30)
- Database (86)
- backup&recovery (21)
- expdp/impdp (5)
- Installation and Deinstall (31)
- network (7)
- ORA-600 or ORA-7445 (6)
- Performence Tuning (13)
- troubleshoooting (2)
- Dataguard (7)
- EBS (3)
- Exadata (120)
- FAQ (19)
- POC和性能调整 (11)
- 体系架构 (19)
- 内部机制 (22)
- 安装和升级 (14)
- 性能指标 (8)
- Exadata V1 (1)
- Exadata V2 (1)
- Exadata X2-2 (2)
- Exadata X3-2 (1)
- Exadata X4-2 (1)
- FAQ (1)
- 故障诊断 (3)
- 日常运维 (15)
- 硬件配置 (43)
- Exadata V1 (6)
- Exadata V2 (6)
- Exadata X2-2 (6)
- Exadata X3-2 (8)
- Exadata X4-2 (8)
- FAQ (1)
- FAQ (16)
- Internal (21)
- Linux (20)
- MYSQL (8)
- OGG (1)
- ORA-600/7445 (2)
- ORA-XXXXX (5)
- Oracle 11.1 & Oracle11.2 (6)
- ORACLE 12C (21)
- Oracle 8 & Oracle 8i (1)
- RAC (47)
- SAP (2)
- Scripts (6)
- 未分类 (1)
- 虚拟化 (1)
2024 年十二月 S M T W T F S « Nov 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 文章归档
-
近期文章
- 针对最近黑客攻击数据库的解决方案和预防建议
- CentOS7.2(RHEL 7.2)的CPU占用高(%system 占用高)
- Oracle 12.1 RAC 系列 – 配置第二个网络和相应的SCAN2
- Oracle 12.1 RAC 系列-安装新主机,识别老存储和恢复数据库
- Oracle 12.2的Sharding-1-基础概念
- 11.2 RAC 系列-安装新主机,识别老存储-3-配置老存储的数据库
- 11.2 RAC 系列-安装新主机,识别老存储-2-准备识别数据库
- 11.2 RAC 系列-安装新主机,识别老存储-1-识别ASM磁盘
- 2016年1月PSU列表
- 单实例数据库转换为RAC数据库–使用rconfig转换
近期评论
- tom 发表在《exadata巡检报告的模板》
- cyx 发表在《关于我》
- 李科胜 发表在《EBS克隆–db和app分开在两个服务器上》
- xiao 发表在《exadata巡检报告的模板》
- Chris Sun 发表在《使用Oracle 11.2的DBMS_RESOURCE_MANAGER.CALIBRATE_IO对Exadata X5(HC)进行测试》
分类目录归档:Database
让“select min(xxx),max(xxx) from xxx”走索引
首先,做一个测试表: 在extent_id列上创建非唯一索引: 下面的语句没有走索引: 手工指定IDX_LUNAR_EXTENT_ID时,也不走索引: 指定该列为非空时,可以走索引(Oracle的索引不保存空值): 可以看到,无论是否使用hint都走索引了: 再次验证,依然这个结果: LUNAR@lunar>alter table lunar modify extent_id null; Table altered. Elapsed: 00:00:00.01 单独查询最小值或者最大值时,也可以走索引,采用“INDEX FULL SCAN (MIN/MAX)”: 假设,在不能修改表结构的情况下,怎么才能让“select min(extent_id),max(extent_id) from lunar”走索引呢? 参考了网上的一些建议,改写sql如下:
使用coe脚本固定执行计划和手工指定profile的outline的方式有什么区别?
测试目的: 1,假设下面的两个语句分别为A语句和B语句: A语句: select count(*) from lunar where extent_id=1; B语句: select /*+ FULL(lunar) */ count(*) from lunar where extent_id=1; 2,使用coe的脚本(在SQLT中可以知道整套coe脚本)手工为A语句指定B语句的执行计划,看看什么效果 (即,让原本正常走索引的A语句使用全表扫描的B语句的执行计划) 3,使用dbms_sqltune.import_sql_profile为A语句指定执行计划,看看什么效果 首先,做一个测试表: 在extent_id列上创建非唯一索引: 可以看到下面的语句正确的使用了索引(把这条语句称之为A语句): 我使用hint指定该语句必须走全表扫描,姑且把这条语句称为B语句: 找到A语句和B语句的sql_id: 使用coe的脚本来固定执行计划,291688323是B语句的执行计划: 根据提示执行COE_XFR_SQL_PROFILE_fvrmp2a2t38dc_291688323.sql脚本: 再次查询,验证一下A语句是否已经按照我们指定的那样采用了B语句的全表扫描的执行计划: 结论:我们的猜测是错误的,使用coe的脚本固定执行计划,必须是从该sql_id的已经有的所有执行计划中挑选其一,而不能凭空指定一个你认为合适的。 下面,我们使用其他方法固定SQL的执行计划。首先找出B语句的执行计划和outline: 使用下面的脚本为A语句指定B语句的outline: 结论: 1,使用coe的脚本固定执行计划,必须是从该sql_id的已经有的所有执行计划中挑选其一,而不能凭空指定一个你认为合适的。 因此,如果需要从某条sql已经执行过的执行计划中挑选一个合适的,那么coe的脚本简单轻巧,非常合适。 2,如果要手工构造一个该SQL语句从未使用的执行计划,可以采用dbms_sqltune.import_sql_profile的方式手工设置outline,从而改变执行计划。 在这种需求下,coe的脚本是无能为力的。
浅谈Oracle非常规恢复
一直以来,类似非归档无备份的数据库损坏,或者备份不可用,或者用备份恢复因为时间太长或者空间限制等等原因制约,非常规恢复一直是我们不能扔掉的救命稻草,在这个方面我并不擅长,但是一直都很喜欢。 记得2001年前后,我第一次有兴趣想要认真学习一下Oracle(以前做开发相关比较多,菜鸟dba),在还没有了解Oracle备份恢复的机制时,忘记为什么首先接触了Oracle 817的Standby,一周内完整的读了一遍文档,动手搭建了两个,并记录在ITPUB和我自己的blog上,很有成就感,而那时,我还没有意识到,其实Standby 的本质就是数据库的备份和恢复的完美结合。 后来有机会作为dba参加一个公司(在当时没觉得公司小,但是只有我一个菜鸟dba,O(∩_∩)O哈哈~)的一个海外项目,是做一个3节点Oracle 817 OPS 克隆数据库的事情,当时我还不熟悉RMAN,使用dd裸设备的方式完成了任务。这个项目之后,我开始迷上Oracle的备份和恢复,并且开始玩rman了。 迄今为止,我还是认为数据库备份恢复是学习Oracle的最佳入口,因为很多时候你可以方便的模拟场景,并研究恢复,在一个个案例中,学习和了解更多internal的原理。当然,任何时候官方文档都是第一步,没有这个基础,很多都如同空中楼阁。 还有一点,一个好的架构设计、备份恢复策略和灾备设计都是最好的选择,这个是毋庸置疑的。 但是中国大量D版客户,尤其是小客户中太多情况下是没有专业的设计,出了问题,非常规恢复的手段就是救命稻草了。 下面的ppt就是去年一个客户在备份不可用的情况下,花“巨资”请人做了非常规恢复后,找我们去做的一次交流,客户要求的主题就是“非常规恢复”: 浅谈Oracle非常规恢复-lunar
expdp中跟踪每一个步骤的时间——metrics=y
在12c中,我们知道expdp和impdp可以看到每一步的时间,其实这个功能在11.2中就可以了,需要加一个未公开的参数 metrics=y,例如: 看一下各个部分执行所花费的时间:
对于已经存在的exp导出文件或者expdp的导出文件,如何获取导出文件头的信息呢?
对于已经存在的exp导出文件或者expdp的导出文件,如何获取导出文件头的信息呢? 我们来测试下,我的expdp导出文件是: 方法1:利用dbms_datapump.get_dumpfile_info我们可以得到dump文件头的信息,具体脚本参考 抽取exp/expdp导出文件头的信息 方法2: 使用string来看: 方法3: impdp lunar/lunar DIRECTORY=lunar_dir DUMPFILE=lunartest.dmp NOLOGFILE=y SQLFILE=lunartest_impdp.sql TABLES=lunar_par_test TRACE=100300 这里TRACE=100300是生成data pump进程trace信息。其他trace信息还有很多,后面陆续会介绍其他的data pump的相关trace。 我们知道data pump进程启动的时候,会有两类进程,即:Datapump Master (DM) 和 Worker (DW) processes 他们生成的trace文件产生在BACKGROUND_DUMP_DEST目录里面,命名格式如下: — Master Process trace file: _dm_.trc — Worker Process trace file: _dw_.trc 我们具体看一下3个文件的内容: … 继续阅读
抽取exp/expdp导出文件头的信息
抽取exp和expdp的dump文件头信息,同时支持oracle 7.3.4以后的exp导出文件和oracle 10.1以后的expdp导出文件
艰难的修复数据库过程,却发现Oracle 11.2果然强大
具体参见: http://t.askmaclean.com/thread-3790-1-1.html http://www.itpub.net/thread-1839128-1-1.html 纯属自娱自乐,没有实际意义的,顺便说下我的发现和测试中的发现(虽然到现在为止数据库还没有open,我还会继续鼓捣他,毕竟还有些方法还没用上,O(∩_∩)O哈哈~。。。); 首先就是11.2太强大了,很多时候以往的错误都可以fixed,数据库可以open后,做很多跟损坏先关的check 1, 从11.2开始,控制文件自动备份完成的信息由m000完成,且他还完成很多其余工作,当然,只在别的进程触发的时候,他才会去工作 2,DBA_TABLESPACE和V$TABLESPACE的来源不同,一个来源于控制文件,一个来源于基表ts$ 3,ts$和file$不能跳号 4,DBMS_HM很强大(Health Manager),他会定期检查数据库的很多东西,然后让m000进程写trace 。。。 主要的测试步骤已经不太都记得了,但是主要模拟步骤如下: 我的环境: db 11.2.0.3 OEL 5.8 1,创建2个表空间(其实1个也可以,几个都行,为了看得更加清晰),然后切换日志,然后在OS上讲包括UNDOTBS在内的这些数据文件(普通的数据文件和undo的数据文件就可以) 2,启动数据库的时候,你会发现,报错说文件丢失或者损坏,这时你offline drop掉这个报错的文件,数据库应该就可以打开,当然后台有m000生成的trace,HealthManager会不断的触发m000把所有其余随坏的信息都写入trace 3,想办法清理undo$中的问题回滚段 4,创建新的普通数据的表空间,例如“UNDTBS333”,但是设置UNDO_TABLESPACE=这个普通的表空间(scope=spfile),然后启动数据库————–这时我当时的第一个误操作 5,数据库报错,具体忘记了,怎么解决的也忘记了,印象中无非就是undo的隐含参数等等,然后创建正确的undo表空间(create undo tablespace …)给数据库使用 6,解决后,数据库可以正常open,delete from fs$ where name=‘你曾经误操作的那个普通数据表空间 UNDTBS333’,这么做是因为当时我没有仔细考虑风险,因此,手工清理了 其实如果全部都是手工做的话,也可以的,后面发现了需要手工清理什么,但是当时确实么有想太多,误操作了。。。 7,其实这样数据库也还是可以open的,没有太大问题,我用DBMS_HM.RUN_CHECK(‘Dictionary Integrity Check’, ‘lunar-ck-Dict’)检查,其实这时数据库只有undo$, ts$ 和file$数据不一致,没有影响其他数据对象(因为测试过程没有添加用户测试数据) … 继续阅读
无法解释的ORA-12537
今天忽然想看下12c的一个小东东,结果遇到ORA-12537: 我这个VM当初装的很别扭,前一段又折腾了一下,更加别扭了,主要问题如下: 1,初始加盘的时候整的太小了,只给了12G,结果装了grid后,再装oracle软件就很困难,这里grid的所在的盘mount在/u01这个目录下 2,然后增加了一块盘,结果没吸取教训,继续折腾太小了,还是12G,不过12c可以装上玩了,这个oracle的软件所在的盘mount在 /u01/app/oracle目录下 3,前一段时间觉得磁盘空间不够了,于是把一个11.2的vm的软件使用root用户tar过来,解压后,ORACLE_BASE和ORACLE_HOME目录是:/u01/app/oracle(这个跟12c的oracle软件是同一个ORACLE_BASE)和/u01/app/oracle/product/11.2.0.3/dbhome_1 够乱了吧,O(∩_∩)O哈哈~ 检查listener.log: 发现报错:TNS-12518: TNS:listener could not hand off client connection 于是google,mos,设置一堆乱七八糟参数,并设置了trace: trace中最后出问题的信息如下,貌似是某些文件找不到或者权限问题: 使用strace sqlplus sys/oracle@lunarbb as sysdba进行跟踪,发现了如下可以信息: 貌似写什么东西时报错了 MOS了一下,Troubleshooting ORA-12537 / TNS-12537 TNS:Connection Closed (Doc ID 555609.1) 发现,我的这个文件没啥问题,权限都对: 这时候,看见刚刚修改过的oracle文件权限不对了,再重新修改回去: 重启下ORACLE,再测试,居然好了,O(∩_∩)O哈哈~:
模拟ORA-600 [4000] 并修复
我没有测试,但是我感觉,从一个好的库上直接dd一个file 1 block 520,可能也可以的,O(∩_∩)O哈哈~ 我这里使用了bbed去修改文件,生产库请勿效仿,后果自负 :) 模拟ORA-600 [4000]: 查看alert: 查看trace: trace中其他有用的信息如下: 摘要上面的信息,有用的如下: 下面清除锁标识: 成功打开数据库:
使用exp+pipe将导出文件生成压缩包(文本数据的话,空间通常节省10倍左右)
有时候我们的存储空间不够,一个exp会产生一个很大的dmp文件,因此,我们就像exp的时候直接生成一个压缩包,那么管道就可以派上用场了,O(∩_∩)O哈哈~ 10g以后,可以使用expdp compression,例如: [oracle@lunar ~]$ expdp lunar/lunar file=expdp_ff.dmp compression=all tables=ff Export: Release 11.2.0.3.0 – Production on Sun Oct 27 01:48:15 2013 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. Connected to: Oracle Database 11g … 继续阅读