Author: mac

Slideshare版的了解Oracle在线重定义online redefinition，可供下载，下载地址。   了解Oracle在线重定义online redefinition View more documents from Maclean Liu

Online Redefinition在线重定义对象是Oracle中很酷的一种特性，它可以帮助我们在7*24在线的系统中从容地做出数据对象的在线定义修改，是Oracle数据库保证其高可用性的重要技术。       在线重定义Online Redefinition特性在许多场景中都是十分有用的，例如：     修改表的Storage存储参数     在同一Schema下将表移动到不同的表空间     转换非分区表为分区表     添加或删除分区     重新创建表以减少碎片,降低高水位     将堆组织的表改变为索引组织表     添加或删除列   使用Online Redefinition在线重定义需要用到DBMS_REDEFINITION程序包，EXECUTE_CATALOG_ROLE角色默认被赋予该PL/SQL Package的执行权限。除了执行该程序包的权限外，用户还需要拥有以下权限:     CREATE ANY TABLE     ALTER ANY TABLE     DROP ANY TABLE     LOCK ANY TABLE     SELECT ANY TABLE   若要执行COPY_TABLE_DEPENDENTS存储过程则还需要以下权限：     CREATE ANY TRIGGER     CREATE ANY INDEX…

今天处理了这样一问题，where条件中存在函数fun(date)<to_date(‘9999-01-01′,’YYYY-MM-DD’)这样的无实际意义谓词，导致CBO计算基数时cardinality远小于实际情况，导致优化器认为2个源数据集的基数都不大，从而选择了HASH JOIN Right SEMI+SORT ORDER BY的执行计划，但是由于实际基数远大于computed 计算值所以变成了大的数据集做HASH JOIN并全数据排序，而实际该SQL只要求返回几十行数据而已，使用NESTED LOOP SEMI JOIN可以立即返回排序的前20行数据。 这里就需要解释带函数的谓词时CBO如何计算基数，我们通过下面的例子来说明:     create or replace function check_date( RDATE in date) return date is begin IF rdate< to_date(‘2099-01-01′,’YYYY-MM-DD’) then return rdate; ELSIF rdate >=to_date(‘2099-01-01′,’YYYY-MM-DD’) then return to_date(‘2000-01-01’); end if; end check_date; / SQL> select check_date (sysdate) from dual; CHECK_DAT ——— 06-DEC-12 drop table tab1;…

LMHB是11gR2中新引入的后台进程，官方文档的介绍是Global Cache/Enqueue Service Heartbeat Monitor，Monitor the heartbeat of LMON, LMD, and LMSn processes，LMHB monitors LMON, LMD, and LMSn processes to ensure they are running normally without blocking or spinning。  Database and ASM instances, Oracle RAC 该进程负责监控LMON、LMD、LMSn等RAC关键的后台进程，保证这些background process不被阻塞或spin。 LMHB可能是Lock Manager Heartbeat的缩写。   我们来看一下该进程的trace跟踪文件以便了解其功能： 按照 100s -> 80s -> 100s -> 80s的间隔监控并输出一次LMSn、LCKn、LMON、LMD等进程的状态及wait chain，由kjfmGCR_HBCheckAll函数控制   *** 2012-02-03 00:03:10.066…

最早想要实现禁止某些特定用户使用SQLPLUS或PL/SQL Developer等工具登陆是在2010年的3月，当时发现用户的一套数据库中有大量的用户使用老版本的PL/SQL Developer登陆，具体的版本号记不清楚了，大约是PL/SQL Developer 5的版本，是否正版授权不得而知， 反正就是一个办公室里有大量的阿姨、大叔都靠这个图形化工具访问数据库，做一些必要的数据操作，主要是一些SQL查询语句，有时候他们还会用工具栏查一些对象(search object)，正是因为他们使用了老版本的PL/SQL Developer，造成在使用一些widget的时候会引起Oracle出现一些非致命的ORA-00600错误，虽然这些600错误不会导致严重的问题，但是只要是出现在告警日志Alert.log中的600还是需要我们去分析。 当时我的想法是直接从Oracle的角度禁止普通用户以PL/SQL Developer工具登陆，虽然当时没有真的这样做。 题外话，要真的这么做了，估计那一办公室的阿姨、叔叔都要找我的麻烦，他们可不会用SQLPLUS来登数据库；让他们升级PL/SQL Developer到高版本的想法也基本可以打住，让阿姨、叔叔们升级可要比登天还难。 Google了一番，没有找到太多有用的信息。 闲来无事，我在著名的Oracle-l Freelist邮件列表中发了一封邮件，集思广益：   Hello every, Anyone can advise how to ban plsql developer connect to oracle? The plsql developer search widget may cause some ora-600 warning in alert log . So I want to ban any connection using plsql developer.   Oracle-l…

初学Oracle的朋友肯定对Controlfile控制文件中到底记录了何种的信息记录而感到好奇，实际上我们可以通过一个视图v$controlfile_record_section来了解控制文件的信息片段：   SQL> select type, record_size, records_total from v$controlfile_record_section; TYPE RECORD_SIZE RECORDS_TOTAL —————————- ———– ————- DATABASE 316 1 CKPT PROGRESS 8180 35 REDO THREAD 256 32 REDO LOG 72 192 DATAFILE 520 1024 FILENAME 524 4674 TABLESPACE 68 1024 TEMPORARY FILENAME 56 1024 RMAN CONFIGURATION 1108 50 LOG HISTORY 56 292 OFFLINE RANGE 200 1063…

有这样一个需求，用户使用RMAN Catalog恢复目录保存多台Database Server的备份信息。 由于每天都会执行大量的backup操作，而且所备份的DB的结构本身都已经十分复杂了，导致recovery catalog恢复目录占用空间迅速增长，且用户的磁盘空间较为紧张，可能在短期内无法扩disk space，这就让我们考虑到需要清理RMAN Recovery Catalog中一些不再需要的记录。 首先搞清楚在Catalog库中那些数据段占用了最多的空间Space:   这里 RMAN 用户是Catalog Schema 的拥有者 SQL> select bytes/1024/1024 “MB” ,segment_name,segment_type from dba_segments where owner=’RMAN’ order by bytes desc; MB SEGMENT_NAME SEGMENT_TYPE ———- ——————– —————— 88 ROUT TABLE 47 ROUT_U1 INDEX 31 ROUT_I_RSR INDEX 23 ROUT_I_DB INDEX .125 RSR TABLE   可以看到是ROUT表占用了最多的空间，那么这张表是做什么用处的呢？ ROUT表用于记录RMAN在执行backup等命令时的输出内容，实际上堆积了V$RMAN_OUTPUT视图中的内容，当目标数据库连接到CATALOG库执行操作或Resync Catalog时会将V$RMAN_OUTPUT中的信息同步到Catalog库的ROUT表中。   SQL>…

之前有同学想要给11gR2的RAC添加LISTENER监听器，查看了listener.ora并发现问题:   [oracle@vrh2 ~]$ lsnrctl status LSNRCTL for Linux: Version 11.2.0.3.0 – Production on 04-DEC-2011 02:51:40 Copyright (c) 1991, 2011, Oracle. All rights reserved. Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)) STATUS of the LISTENER ———————— Alias LISTENER Version TNSLSNR for Linux: Version 11.2.0.3.0 – Production Start Date 02-DEC-2011 05:40:09 Uptime 1 days 21 hr. 11 min. 31 sec…

之前有同学问我如何才能给非自身的其他会话设置会话级别(alter session)的参数；在实际的Oracle管理过程中我们往往希望在不修改实例级别参数的情况下， 让部分session使用指定的参数值。 如果仅仅是修改本地会话的参数值，那么很好办，只需要alter session set parameter 即可，如:   SQL> select * from v$version; BANNER ——————————————————————————– Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 – 64bit Production PL/SQL Release 11.2.0.3.0 – Production CORE 11.2.0.3.0 Production TNS for Linux: Version 11.2.0.3.0 – Production NLSRTL Version 11.2.0.3.0 – Production SQL> select * from global_name; GLOBAL_NAME ——————————————————- www.askmac.cn &…

在11g之前串行的扫描大表默认总是先将数据读取到Oracle高速缓冲中，其等待事件常为db file scattered read。   从11g开始Oracle通过内部算法来决定串行扫描大表是通过直接路径读direct path read，还是先读入到buffer cache中，此算法依据表的大小评估。   _small_table_threshold 隐藏参数指定了 ORACLE中大表的阀值，其单位为block，即大于_small_table_threshold 所指定的块数的表被视作大表， 否之视为”small table”。 对于大表”large table”，SQL执行层认为存在直接路径读取的意义(direct path read)。 对于小表，将它缓存在buffer cache中的收益更大，所以直接路径读取不具有意义。_small_table_threshold 隐藏参数的值在实例启动时动态决定，一般为 2% * DB_CACHE_SIZE。   direct path read的优势：     1. 减少了对闩(latch)的使用，避免可能的闩争用   2.物理IO的大小不再取决于buffer_cache中所存在的块；试想某个8个块的extent中1,3,5,7号块在高速缓存中，而2,4,6,8块没有被缓存，传统的方式在读取该extent时将会是对2,4,6,8块进行4次db file sequential read，其效率往往要比单次读取这个区间的所有8个块还要低得多，Oracle为了避免这种情况总是尽可能的不缓存大表的块(读入后总是放在队列最冷的一端);而direct path read则可以完全避免这类问题，尽可能地单次读入更多的物理块。     当然直接路径读取也会引入一些缺点：   1.即便在buffer cache足够大到可以放下整个大表的情况下，direct path read无法从高速缓冲受益，每次扫描大表均需重复等量的直接路径物理读取IO 2.在直接路径读取某段前需要对该对象进行一次段级的检查点(A segment checkpoint). 3.可能导致重复的延迟块清除操作    …