Author: mac

不少Oracle的初学者都会因为checkpoint这个知识点而头痛，绝大多数Oracle文档对完全检查点和增量检查点的描述又都略显朦胧；譬如在线日志的切换引起的是完全检查点还是增量检查点这个问题，就有不少的争论。实际上增量检查点与完全检查点有一个显著的区别:完全检查点发生时控制文件和数据文件头中的checkpoint scn都会被更新，而增量检查点发生时只有控制文件中的checkpoint scn更新; 我们可以通过以下演示证明日志切换引发的到底是何种检查点?: SQL> select checkpoint_change# from v$datafile_header where status=’ONLINE’; CHECKPOINT_CHANGE# —————— 1665476 1665476 1665476 1665476 1665476 1665476 6 rows selected. SQL> alter system checkpoint; System altered. SQL> select checkpoint_change# from v$datafile_header where status=’ONLINE’; CHECKPOINT_CHANGE# —————— 1697131 1697131 1697131 1697131 1697131 1697131 6 rows selected. /* 手动执行checkpoint,数据文件头的checkpoint scn立即更新了 */ SQL> alter system flush buffer_cache;…

如果在使用数据泵时不采用parfile参数文件的话，query参数指定的查询条件是需要使用单引号括起来的，而当使用parfile时则不需要加上单引号，加上后反而会出现LPX-314: an internal failure occurred错误: [maclean@rh2 mesg]$ expdp maclean/maclean directory=dump tables=estimate_me query=estimate_me:”where t1<2000″ Export: Release 10.2.0.4.0 – 64bit Production on Tuesday, 02 November, 2010 22:32:33 Copyright (c) 2003, 2007, Oracle. All rights reserved. Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 – 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing…

昨天晚上去客户现场配合一个导入导出作业；这是一套Solaris 10上的10.2.0.1系统，导出采用expdp数据泵工具，需要导出的数据源是一张大小在120G左右的单表，该表存放了最近一年的数据，实际导出时只需要最近三个月的数据，所以使用了QUERY参数,并指定了并行度为2。 该导出作业之前未经测试过，语句也是临时写的，实际执行导出工作时发现在评估阶段(estimate phase)耗费了大约十多分钟的时间，estimate默认使用blocks模式，即通过计算对象段占用的数据库块来预估dumpfile的大小；此外还有statistics模式通过对象的统计信息来推算导出文件的大小: The block method of estimate is the least accurate. We investigate how many blocks were allocated for the storage segments for the tables specified. If the table had been recently analyzed, the estimate=statistics would be the most accurate. So remember, it is important to generate statistics before calculating the estimate using…

这是一个十分简单的单表导出作业，表上大约有200万条数据；但实际exp导出时dump文件每秒增长不足1MB，速度十分缓慢。 SQL> show user; USER is “SH” SQL> select count(*) from orders; COUNT(*) ———- 2319232 SQL> select bytes/1024/1024 from dba_segments where owner=’SH’ and segment_name=’ORDERS’; BYTES/1024/1024 ————— 261 /*该表大小为261MB*/ /*这里我们使用直接路径导出*/ [maclean@rh2 ~]$ exp sh/sh file=/s01/orders.dmp direct=y tables=orders Export: Release 11.2.0.1.0 – Production on Wed Aug 18 21:52:56 2010 Copyright (c) 1982, 2009, Oracle and/or its affiliates.…

我们使用Linux平台进行测试，OS版本为Oracle Enterprise Linux 5.5 x86_64: [root@nas servsoft]# cat /etc/issue Enterprise Linux Enterprise Linux Server release 5.5 (Carthage) Kernel \r on an \m Netbackup 6.0仅支持2.4内核的Linux版本,2.6内核的Linux版本(主流的包括RHEL4,5 Centos等)需要使用NBU,只能安装Netbackup 6.5或以上版本。 现在我们有三台主机： rh1(rac的2号节点),rh2(rac的1号节点),nas(NBU Server)。 首先需要安装的是Netbackup Server端软件，当然你需要用到安装介质，你可以尝试在Veritas的官方网站下载到最新的版本;获取到安装介质后，我们首先要解压它： [root@nas netbackup]# cp NetBackup_6.5_LinuxRedhat2.6.tar.gz /tmp [root@nas tmp]# gunzip NetBackup_6.5_LinuxRedhat2.6.tar.gz [root@nas tmp]# tar -xvf NetBackup_6.5_LinuxRedhat2.6.tar 在进入安装前确认xinetd服务正确运行着： [root@nas tmp]# service xinetd status xinetd (pid 2886) is…

一套windows上的11.1.0.7系统，用户在查询时出现ORA-00600: internal error code, arguments: [15160], [], [], [], [], [], [], [], [], [], [], []错误如下: Dump continued from file: c:\app\administrator\diag\rdbms\dbuat\dbuat\trace\dbuat_ora_544.trc ORA-00600: internal error code, arguments: [15160], [], [], [], [], [], [], [], [], [], [], [] ========= Dump for incident 16131 (ORA 600 [15160]) ======== *** 2010-07-20 15:49:20.015 —– Current SQL Statement…

晚上打开MOS的页面，发现居然多出了陌生的Get Started栏目，该栏目包含了引导用户在My Oracle Support上如何注册，以及观看使用教学视频等信息: 帮助界面由Adobe flash驱动，似乎Oracle爱上了使用flash:不仅仅是此次推出的Get Started，之前在各个教学Note中也都加入了flash驱动的视频；好吧这些flash看上去还挺酷，也可以说是改善用户体验的一个重要环节，不过加载时间实在令人恼火！ 下文是blog.oracle.com上对My Oracle Support中视频小插图(Video Vignettes)的介绍: Video Vignettes for My Oracle Support: Featuring user-driven innovations My Oracle Support: Featuring user-driven innovations My Oracle Support is here and with it come new tools to help you find answers faster, more easily log and track SRs, and maintain highly available systems using…

事实上我个人对Exadata所带来的技术变革有着极大的兴趣，如果Exadata能够获得成功的话，那么Oracle就在成功收购Sun后在整合硬件领域上迈出了长足的一步，Database Machine的噱头加上自家的老牌商业数据库足可以使Oracle赚到盆满钵满；但Exadata V2始终还有很长的一段路要走，希望它能越走越远！

RAC中各节点的hostname是设成大写(UPPER CASE)形式还是小写(lower case)形式好呢？ 一开始被这个问题问得有些莫名？之后觉得一切都有必要让事实说话，回顾一下我们使用RAC的惨痛经历便见分晓: Bug 5168043If node names supplied in VIPCA silent mode are uppercase, VIPCA causes the following error: Invalid node name “” entered in an input argument. Workaround Use VIPCA GUI mode. Oracle Versions confirmed as being affected – 10203 ( fixed in 10.2.0.4) PROBLEM: ——– Env 3 node 10.2.0.1 AIX 5L During…

11g release 2中引入了针对被dropped掉的表空间的表空间时间点恢复，这是一种十分有用的新特性。TSPITR(TablesSpace Point In Time Recovery)在10g中就能做到自动创建辅助实例以恢复表空间到某个时间点，但在10g中是无法恢复一个已经被drop掉的表空间的。如同10g中一样11g仍旧可以利用全自动的TSPITR恢复被drop的表空间；Oracle会自动创建并启动辅助实例，且仅仅还原那些恢复所需的控制文件,system,sysaux,undo表空间及目标表空间，这些工作都将在用户指定的辅助目的地’Auxiliary Destination’中完成；之后Oracle将进一步使用辅助实例recover目标表空间到指定的时间点，并将其中的数据以Data Pump传输表空间的形式倒回到原数据库当中。 接下来我们要具体测试这一新特性，我们会创建一个示例表空间并在该表空间上产生少量数据，之后我们将对数据库进行备份，drop目标示例表空间，并在RMAN中使用TSPITR的方式将已经被drop掉的表空间恢复回来。在正式drop表空间前我们当然需要留意时间点或者当时的scn号，以保证正常恢复，同时在测试时使用recovery catalog恢复目录，虽然我们同样可以不用。