<?xml version="1.0" encoding="UTF-8"?><rss version="0.92">
<channel>
	<title>Oracle Clinic</title>
	<link>http://www.oracledatabase12g.com</link>
	<description>提供专业Oracle技术支持,性能调整以及数据恢复服务，QQ:47079569, Mail:DBA@YOUYUS.COM，Mobile:13764045638</description>
	<lastBuildDate>Sat, 11 Sep 2010 00:03:01 +0000</lastBuildDate>
	<docs>http://backend.userland.com/rss092</docs>
	<language>en</language>
	<!-- generator="WordPress/3.0.1" -->

	<item>
		<title>ORA-07445 [SIGBUS] [Object specific hardware error]错误一例</title>
		<description><![CDATA[一套Solaris上的9.2.0.7系统，实例意外终止，告警日志中出现以下记录: Thu Sep 2 02:15:41 2010 Errors in file /u01/app/oracle/admin/preg063/bdump/preg063_smon_11391.trc: ORA-07445: exception encountered: core dump [0000000101E05500] [SIGBUS] [Object specific hardware error] [0xFFFFFFFF7CB3BF90] [] [] Thu Sep 2 02:15:48 2010 Errors in file /u01/app/oracle/admin/preg063/bdump/preg063_pmon_11379.trc: ORA-00474: SMON process terminated with error Thu Sep 2 02:15:48 2010 PMON: terminating instance due to error 474 Wed Sep 1 15:04:20 [...]]]></description>
		<link>http://www.oracledatabase12g.com/archives/2010/09/09/ora-07445-sigbus-object-specific-hardware-error%e9%94%99%e8%af%af%e4%b8%80%e4%be%8b.html</link>
			</item>
	<item>
		<title>sort_area_size参数的一些表现</title>
		<description><![CDATA[我们来看看该sort_area_size参数对创建索引时排序的具体影响: SQL&#62; select * from v$version; BANNER ---------------------------------------------------------------- Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi PL/SQL Release 10.2.0.4.0 - Production CORE 10.2.0.4.0 Production TNS for Linux: Version 10.2.0.4.0 - Production NLSRTL Version 10.2.0.4.0 - Production /* 测试使用版本10.2.0.4 */ SQL&#62; archive log list; Database log mode No Archive Mode Automatic archival Disabled Archive destination [...]]]></description>
		<link>http://www.oracledatabase12g.com/archives/2010/09/09/sort_area_size%e5%8f%82%e6%95%b0%e7%9a%84%e4%b8%80%e4%ba%9b%e8%a1%a8%e7%8e%b0.html</link>
			</item>
	<item>
		<title>CTAS VS create table and then insert</title>
		<description><![CDATA[很多情况下我们都会需要复制源表数据以达到冗余数据的目的，那么到底是使用CREATE TABLE AS SELECT的CTAS方式，还是先建好表的结构然后再插入数据好呢？ 我们来看看这2种方式的不同表现： SQL&#62; select * from v$version; BANNER ---------------------------------------------------------------- Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi PL/SQL Release 10.2.0.4.0 - Production CORE 10.2.0.4.0 Production TNS for Linux: Version 10.2.0.4.0 - Production NLSRTL Version 10.2.0.4.0 - Production SQL&#62; archive log list; Database log mode Archive Mode Automatic archival Enabled Archive destination [...]]]></description>
		<link>http://www.oracledatabase12g.com/archives/2010/09/07/ctas-vs-create-table-and-then-insert.html</link>
			</item>
	<item>
		<title>Oracle常用的几个父栓</title>
		<description><![CDATA[Oracle中的父闩大致可以分成2类：有子闩的父闩或者独居的父闩，我们来看看这些父闩的属性: SQL&#62; select * from v$version; BANNER ---------------------------------------------------------------- Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi PL/SQL Release 10.2.0.4.0 - Production CORE 10.2.0.4.0 Production TNS for IBM/AIX RISC System/6000: Version 10.2.0.4.0 - Productio NLSRTL Version 10.2.0.4.0 - Production SQL&#62; select count(distinct name) from v$latch_children; COUNT(DISTINCTNAME) ------------------- 82 /* 10.2.0.4下共有82种不同子闩，同比11.2.0.1是75种，要比10g中少一些，因为一部分闩在11g中被mutex替代了 */ SQL&#62; select count(distinct name) [...]]]></description>
		<link>http://www.oracledatabase12g.com/archives/2010/09/07/oracle%e5%b8%b8%e7%94%a8%e7%9a%84%e5%87%a0%e4%b8%aa%e7%88%b6%e6%a0%93.html</link>
			</item>
	<item>
		<title>有趣的数字记录方式</title>
		<description><![CDATA[著名的Tanel Poder最近在他的博客上发表了《Which number takes more space in an Oracle row?》；Oracle是如何存储数字类型字段的？如果我们惯性思维的话，存储数字123肯定要比存储数字10000000000000000所占用的空间少吧，事实是这样吗？ SQL&#62; select vsize(123) from dual; VSIZE(123) ---------- 3 SQL&#62; select dump(123,16) from dual; DUMP(123,16) -------------------- Typ=2 Len=3: c2,2,18 /* 可以看到Oracle存储数字123需要用到3个字节的空间，其16进程形式为c2,02,18 */ /* 如果是gooooogle(1后面跟n个零)呢? * / SQL&#62; select vsize(power(10,38)) from dual; VSIZE(POWER(10,38)) ------------------- 2 SQL&#62; select dump(power(10,38),16) from dual; DUMP(POWER(10,38) ----------------- Typ=2 Len=2: d4,2 /* power(10,38)居然仅占用2个字节空间，其16进程形式为d4,02 [...]]]></description>
		<link>http://www.oracledatabase12g.com/archives/2010/09/07/%e6%9c%89%e8%b6%a3%e7%9a%84%e6%95%b0%e5%ad%97%e8%ae%b0%e5%bd%95%e6%96%b9%e5%bc%8f.html</link>
			</item>
	<item>
		<title>DNS设置引起的登录延迟</title>
		<description><![CDATA[一套Linux上的11.1.0.7系统，操作系统管理人员最近对该服务器上的网络配置文件/etc/nsswitch.conf进行了调整，调整前其主机名解析选项为&#8221;hosts:files dns&#8221; ，调整后被修改成了&#8221;hosts:files [NOTFOUND=continue] dns&#8221;；此后应用人员尝试在该主机上使用 &#8220;sqlplus username/password@connect_string&#8221;远程登录数据库都会出现多达五分钟的延迟，使用lsnrctl status命令查看监听器状态，发现LISTENER一切正常；初步可以判断是dns解析导致了长时间的延迟。 针对以上问题，首先想到的是设置client端Oracle network trace以了解造成延迟的具体原因,在$ORACLE_HOME/network/admin/sqlnet.ora配置文件中加入以下记录: TRACE_LEVEL_CLIENT = 16 TRACE_FILE_CLIENT = client TRACE_DIRECTORY_CLIENT = [any valid directory path] TRACE_TIMESTAMP_CLIENT = ON DIAG_ADR_ENABLED=off 之后再次尝试登录就会触发Oracle Network Trace文件在$TRACE_DIRECTORY_CLIENT指定的目录下产生(如果DIAG_ADR_ENABLED未设置为false，那么11g下TRACE_DIRECTORY_CLIENT并不生效，而会产生在11g特有的diag目录下)。 登录测试产生的trace文件记录: [02-SEP-2010 07:36:57:719] nsc2addr: (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=m218279apss2012-vip)(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=MOTOIDP.MOT.COM)(INSTANCE_NAME=MOTOIDP1)(CID=(PROGRAM=sqlplus)(HOST=m218279apss2012.mot.com)(USER=oraoid)))) [02-SEP-2010 07:36:57:719] nttbnd2addr: entry [02-SEP-2010 07:36:57:719] snlinGetAddrInfo: entry [02-SEP-2010 07:36:57:719] snlinGetAddrInfo: getaddrinfo() failed with error -2 [02-SEP-2010 07:36:57:719] snlinGetAddrInfo: exit [...]]]></description>
		<link>http://www.oracledatabase12g.com/archives/2010/09/06/dns%e8%ae%be%e7%bd%ae%e5%bc%95%e8%b5%b7%e7%9a%84%e7%99%bb%e5%bd%95%e5%bb%b6%e8%bf%9f.html</link>
			</item>
	<item>
		<title>ORA-03137: TTC protocol internal error : [12333]错误一例</title>
		<description><![CDATA[Oracle Solaris上的一套11.2.0.1.0最近出现以下告警记录: Dump file /cnbbs01/app/oracle/diag/rdbms/nbbsprd1/nbbsprd1/incident/incdir_373041/nbbsprd1_ora_24754_i373041.trc Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production ORACLE_HOME = /cnbbs01/app/oracle/product/11.2.0/db_1 System name: SunOS Node name: ut06db03 Release: 5.10 Version: Generic_142901-12 Machine: i86pc Instance name: nbbsprd1 Redo thread mounted by this instance: 1 Oracle process number: 130 Unix process pid: 24754, image: oracle@ut06db03 *** 2010-08-25 02:01:19.169 *** SESSION [...]]]></description>
		<link>http://www.oracledatabase12g.com/archives/2010/09/05/ora-03137-ttc-protocol-internal-error-12333%e9%94%99%e8%af%af%e4%b8%80%e4%be%8b.html</link>
			</item>
	<item>
		<title>11g Multi-Column Correlation Stats and Dynamic Sampling</title>
		<description><![CDATA[Oracle CBO优化模式中列的统计信息是一个十分重要的概念，但在11g之前我们所讨论的都是基于单列的统计信息或直方图，也就是说基于成本的优化器总是假设where子句后的谓词中列与列之间不存在联系。但是有的查询包含一个表的多个列，而每个列又都与不同的选择度。这些列中有的是相关的，但优化器并不知道这些关系。在这种情况下，优化器如果要估计出真实的基数(card)，必须要了解增加另一列到某个给定列是否会引起结果集的减少。多列上的相关统计数据能提供比单列统计数据或直方图更好的基数估计。当2个列紧密相关时，增加额外的谓词可以减少结果集。Oracle database 11g中引入了扩展统计(也叫多列统计，multicolumn statistics)，可以收集一组列上的统计数据，从而让优化器能准确地计算多个单列谓词的选择性。因为把紧密相关的列作为一个组才能正确地放映其组合选择性，所以把相关列作为一组，在其上(列祖)收集统计数据，这些信息足以让优化器能准确地进行选择性估计，在包含使用相关列的谓词查询中，这是我们实际关心的问题。多列统计的引入意味着，在11g中cbo优化器可以对具有多列复杂谓词判断的SQL语句做出更准确的成本估算，许多原本&#8221;误用&#8221;全表扫描的查询现在可以使用索引扫描的执行计划，语句将运行地更快速。 我们试看下例: SQL&#62; select * from v$version; BANNER -------------------------------------------------------------------------------- Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production PL/SQL Release 11.2.0.1.0 - Production CORE 11.2.0.1.0 Production TNS for Linux: Version 11.2.0.1.0 - Production NLSRTL Version 11.2.0.1.0 - Production SQL&#62; conn maclean/maclean Connected. SQL&#62; drop table YOUYUS; Table dropped. /* 建立测试样本表YOUYUS [...]]]></description>
		<link>http://www.oracledatabase12g.com/archives/2010/09/03/11g-multi-column-correlation-stats-and-dynamic-sampling.html</link>
			</item>
	<item>
		<title>ORA-00600:[32695], [hash aggregation can&#039;t be done]错误一例</title>
		<description><![CDATA[还是那个<a href="http://www.oracledatabase12g.com/archives/2010/08/04/10g%E4%B8%ADhash-group-by%E7%AE%97%E6%B3%95%E5%BC%95%E8%B5%B7%E7%9A%84%E9%97%AE%E9%A2%98.html">hash group by算法的问题</a>，日志文件中出现以下记录]]></description>
		<link>http://www.oracledatabase12g.com/archives/2010/09/03/ora-0060032695-hash-aggregation-cant-be-done%e9%94%99%e8%af%af%e4%b8%80%e4%be%8b.html</link>
			</item>
	<item>
		<title>ORA-00600[6711]错误一例</title>
		<description><![CDATA[一套Linux上的10.2.0.4系统，日志中频繁出现ORA-00600[6711]内部错误: Wed Sep 1 21:24:30 2010 Errors in file /s01/10gdb/admin/YOUYUS/bdump/youyus_smon_5622.trc: ORA-00600: internal error code, arguments: [6711], [4256248], [1], [4256242], [0], [], [], [] Wed Sep 1 21:24:31 2010 Non-fatal internal error happenned while SMON was doing logging scn-&#62;time mapping. MOS上有一个关于6711内部错误十分简单的Note,该文档声称出现6711错误极有可能是部分类型为簇(cluster)的数据字典表存在潜在的讹误，这个Note甚至没有告诉我们该错误argument参数的意义。 不过其实我们可以猜出来,因为是和corruption相关的错误，那么实际上可能关联的几个因素无非是obj#,file#,block#；4256248和4256242 两个数字像极了Data Block Address，把他们当做dba来看待，也就指向了1号数据文件的61938块和61944数据块，我们来看看这些块属于哪个对象： SQL&#62; set linesize 200; SQL&#62; select segment_name, segment_type 2 from dba_extents [...]]]></description>
		<link>http://www.oracledatabase12g.com/archives/2010/09/01/ora-006006711%e9%94%99%e8%af%af%e4%b8%80%e4%be%8b.html</link>
			</item>
</channel>
</rss>
