刚才在线学习了一下 Oracle Secure Enterprise Search Administration Tutorial. 目前 Oracle 还不提供 Secure Enterprise Search 10g 的下载, 所以只能看看联机教程过点干瘾.
安装相对比较简单, 和普通的数据库安装很相似．类 Unix 服务器上需要修改核心参数, 最后系统会直接安装一个 DB 到服务器上．
从教程中可以得知搜索引擎的基本由三部分构成:
Oracle数据库服务器 --管理存储与源数据以及搜索索引．
数据库 Listener --监听 Oracle Net 连接.
搜索中间层 -- 监听来自 HTTP 的请求. 我从 URL 中判断其实是一个 HTMLDB . Secure Enterprise Search 的管理工具也通过这个中间层来进行．
Oracle 杀入了搜索领域。虽然 Google 在互联网搜索领域独领风骚, 但 Oracle 显然要在企业搜索领域力拔头筹。日前，Oracle 推出了号称划时代的产品：Oracle Secure Enterprise Search(SES) 10g。赶紧找来白皮书研究研究。
这个产品的名字值得捉摸：Security + Enterprise + Search + 10g.
Security Oracle 首先强调了这款产品的安全特性。可以安全的与 Oracle Internet Directory 同步；与微软的活动目录同步；查询结果与爬虫的选项以及索引数据都各自有一些安全特性。比如，关于查询，Oracle 引入了查询时验证的特性，未经授权的用户搜索特定信息的时候，他不应该看到的信息会被搜索引擎过滤掉。这个验证是动态的，用户友好程度应该不错，但是因为是动态验证，性能上会有影响。该特性可以和 ACL 验证方式结合使用，或者单独使用。
Enterprise 软件目标是企业客户。SES 可以处理企业内容几乎所有的数据源(Web Page/ Email /DB table/ API 定制的数据源)。这其中激动人心的是直接搜索数据库表。这应该是 Oracle 的强项，以前还没听说哪个企业产品是直接搜索 DB 内容的。SES 这个特定对很多潜在的企业用户来说是一个卖点。至于运行效率则不得而知。
以前写过一则 Blog , 如何重编译无效的数据库对象. 可是有的时候,因为一些原因,在对一些数据库的 Package 对象的权限做修改之后, 会出现大量的无效对象, 即使反复编译,也是无济于事的.
今天就遇到过一起.
ops$oracle@demo>select object_name,owner,object_type
from dba_objects where status='INVALID';
OBJECT_NAME OWNER OBJECT_TYPE
---------------------------- -------------------------- ------------------
DRIDDLR CTXSYS PACKAGE BODY
ops$oracle@demo>alter package ctxsys.DRIDDLR compile body;
Warning: Package Body altered with compilation errors.
ops$oracle@demo>execute utl_recomp.recomp_serial('CTXSYS');
PL/SQL procedure successfully completed.
ops$oracle@APAYCA>select object_name,owner,object_type
from dba_objects where status='INVALID';
OBJECT_NAME OWNER OBJECT_TYPE
---------------------------- -------------------------- ------------------
DRIDDLR CTXSYS PACKAGE BODY
因为刚刚撤销了 Public 对 DBMS_METADATA 和 DBMS_JOB 的执行权限. 本着最小权限授予原则,所以决定尝试恢复 CTXSYS 对两个包的执行权限.经过测试,
SQL> grant execute on DBMS_JOB to ctxsys;
今天参加培训的时候胡思乱想,忽然间想起来墨菲定律(Murphy's Law)这个有趣的话题. 西方文化中，有很多所谓的"定律", 墨菲定律应该算是一则比较著名的"定律"了.什么是墨菲定律? 最简单的表达形式是"有可能出错的事情，就会出错(Anything that can go wrong will go wrong)"。
爱德华·墨菲、约翰·保罗·斯特拉普和乔治·尼克斯凭这条定律居然还得到了搞笑诺贝尔奖(IgNobel)奖。而墨菲定律的一些衍生版本也的确有趣.比如"东西久久都派不上用场，就可以丢掉；东西一丢掉，往往就必须要用它",再比如"你出去买爆米花的时候，银幕上偏偏就出现了精采镜头".
抛开 Murphy's Law 衍生出来如此多的版本不谈，说一下墨菲定律和 DBA 之间的关系。Anything that can go wrong will go wrong, 这句话对 DBA 来说，应该是引起注意的, 甚至作为金科玉律也不为过,一般来说，没有哪一个人管理的数据库是完美无缺的，但是如果你发现了数据库的缺限置之不理，存在侥幸心理，那么最后往往会发生你最担心的问题。我就曾经亲生经历过几起类似的事件，事后总结的时候想 "如果我...如何做" 就好了. 但是已经发生的事情就不允许假设了.
最近的 Oracle 产品消息:Oracle Database XE 推出正式版。正式版本在 32-bit 的 Linux 和 Windows 上可用.
这个免费版本可以直接平滑升级到 Oracle 的其他版本，而且部署简单，能让开发人员迅速入手。不得不让人深深感到 Oracle 为了争夺客户煞费苦心.
好长时间没怎么看 Oracle 技术文档了，今天阅读了一篇 Oracle Response Time Optimization with Method R. 这是 Optimizing Oracle Performance 经典图书这本经典图书的主旨方法。R 代表响应时间(response time).具体的定义如下：
这里面的核心元素是 Profile .Profile 要提供应用程序到最终用户的响应时间的详细描述.体现到 Oracle 数据库这一层，就是要得到扩展的 SQL Trace 数据。
是不是感觉有些"虚", R 方法和一些我们已知的数据库优化方法颇一些相似之处，但是 Cary Millsap 宣称 R 方法是目前已知 Oracle 优化方法中的最优秀的、最全面的。我们来看看一些简单比较：
有的时候, DBA 需要迅速找出来同一个 Oracle 数据库上或者不同数据库的两个 Schema 的差异.这种情况应该比较常见，比如测试数据库发布到产品数据库的时候,需要 DBA 做频繁的检查。
应对的办法之一是通过 Toad 这样的 GUI 工具来查找.具体操作应该是很简单的。Oracle 自带的 OEM 工具也有这样的功能( Oracle 变化管理工具包,不过不是免费的)。对于不喜欢图形工具的 DBA 来说, 用手工的方式更容易接受一些。如果已经建立了 Database Link ,可以通过类似如下的 SQL 简单的发现一些差异:
select * from user_tables@a minus select * from user_tables@b;
可以考虑先从 用户的 objects 入手,然后表->字段->索引 等等.
在 AskTom 上有一个关于 Schema 比较的讨论,以及一些参予讨论的人提交的 SQL 脚本。
今天测试了一个 Perl 脚本 Schemadiff, 这个工具分两个部分组成，一个执行 Perl 脚本加上一个配置文件。配置文件比较简单。看看就可以清楚。比较结果能够输出为 ASCII 文本与 HTML 两种格式。文本的结果比较类似 Unix 命令 diff 的输出．相对来说，比较直观的了．需要说明的是,使用这个脚本需要安装 DDL::Oracle 包。间接拒绝了对 Perl 不熟悉的朋友.
小技巧一个:在一个开发环境中,可以考虑把用户的SQL执行计划历史也收集进来.很简单,但是对开发 DBA 会很有帮助, 根据 HASH_VALUE 查询相关过去某个时间段内的 SQL 执行计划.一共两步:
1 Statspack 的 level 6 收集所有的统计和执行计划. 用 level 6 收集快照(Snap)信息:
SQL> execute statspack.snap (i_snap_level=>6);
2 运行 $ORACLE_HOME/rdbms/admin/sprepsql.sql 脚本抽取特定 HASH_VALUE 的 SQL 信息:
