AnySQL.net

    先给出原文出处, 是从ITPub上看到的, 我也是一名DBA, DBA只是工作不是兴趣了. 对于一大群想进入DBA行业的人来说, 可能是一种打击. 想纯粹地做点技术, 谋求个安定的生活, 真是不容易!

    99年刚毕业进公司,看着公司那些老大们熟练的操作ORACLE数据库:安装,备份,导数据.羡慕不已.心想:要是我也有那么熟练就好了.于是,凭借刚进公司的热情和新鲜感,凭借年轻人的血气方刚和充沛的精力,很快的迈进的ORACLE的大门.当时使用的ORACLE7 ,还是ORACLE的SQL FORM 来做开发.想想当初,为能够在当时DIGITAL主机上安装ORACLE734的OPS而激动不已.(估计现在没有几个人会) , 后来掌握了ORACLE8 ( 开始使用RECOVER MANAGER ) ,ORACLE8I (真正用JAVA开发的ORACLE版本,ORACLE815害我很深,STANDBY DATABASE),ORACLE9I (DATAGUARD DATABASE) .

    时光流失,日月如梭,岁月慢慢的磨蚀了我的激情和动力.我再也不会为某个问题也通宵达旦的思考和实验.而是听之任之. 面对那么的多的新特性,那么多的新方法我已经失去了学习的驱动力.看到被我招进公司的新手一个一个超过我,正象我当时超越我的前辈一样.有时候想:几年之后,我还能干什么?

    每次完成一个任务,做完一个项目,安装,升级,备份恢复,性能调整... 我再也没有成功的喜悦,而是内心的失落空虚,svrmgrl 这个命令可能已经敲过不下2万次. 天天和这些东西打交道.我已经倍感无聊.难道这就是我养家糊口的全部? 敢问,有5年以上经验的DBA,难道你没有这种感觉? 没有了激情和动力,没有了冲动和感觉,我每天无聊的打发着时间.我想,是该换换一个环境了.

    于是,离开了曾经工作7年的公司,也离开的心爱的ORACLE,找到了一份新的工作.至少到目前为止,我对这份新的工作还是比较满意的.

    我曾经已经以为自己会放不下.现在看来只是自己没有尝试罢了. 换一个环境和角度,原来我还是可以干好事情,我还是有激情和动力. 也许在不久的将来,我也会对现在的工作感到无聊,那是以后的事情,以后再说吧 .

    祝愿希望成为DBA的人梦想成真!

    今天AUL遇到了一个特别的数据, 虽然System表空间都是好的, 但却无法UNLOAD字典信息, 从而无法很好地恢复数据. 第一个特别的现象是, 数据库的第一个数据文件, SYSTEM表空间的第一个数据文件的RFILE#列不为1, 这是我第一次见到.

*  ts#  fno  rfn ver bsize     blocks filename
- ---- ---- ---- --- ----- ---------- -----------------
Y    0    1    4 02   8192     128000 system01.dbf
Y    0   10   10 02   8192      64000 system02.dbf

    另外AUL所需要读的几个系统表也有特别的地方, 我从DBA_OBJECTS中查这几个表的DATA_OBJECT_ID, 发现他们都很大. 不明白的这些系统字典表的Data Object ID是如何被搞得这么大的?

11412 COL$
11424 OBJ$
11412 TAB$
11416 USER$

    看来还是得从SYSTEM表空间数据文件的文件头取得BOOTSTRAP$的地址, 然后从BOOTSTRAP$中取得相关的系统表(USER$,OBJ$,TAB$,COL$)的信息进行处理.

    此数据库为ERP数据库, 好象是Oracle Finacials数据库, 难道和我们普通创建的数据库的不一样?

    又见图形工具引起的灾难, 在PL/SQL中用SYS用户登录, 不小心把所有的视图都删除了.

    我已经见过好多次OEM上误删表/用户/表空间的问题, 都是因为在图形工具上按错了键或点错了鼠标, 这些工具在有权限时, 要删除什么东西总是默认以CASCADE方式进行的, 因此才造成的问题. 在这个例子中, 后来发现不单单是一些视图没有了, 还有一些SYS用户下的系统表被删除了. 在运行catalog重建系统视图时, 遇到了以下错误.

CREATE OR REPLACE VIEW exu81approle (
role, schema, package) AS
SELECT u$.name, r$.schema, r$.package
FROM sys.user$ u$, sys.approle$ r$
WHERE u$.user# = r$.role#

ORA-00942: Table or view does not exist!

    涉及到SYS中的东西时总是很麻烦, 不仅是很长时间的系统停顿, 还极有可能造成不能恢复的场面.

    需要密切注意权限问题.

    在Oracle 11g之前, 普通的Insert不能使数据以Compress方式存贮, 你可以做实验对它进行验证, 只能通过将表移动一下, 或用CTAS或Bulk Insert的方式来进行表压缩. 最近也开始用Compress表存放一些几年前的数据了.

    虽然有触目惊心的Bug, 但空间的节约却是可观的, 有时也得挺而走险(没有这么严重)一下.

    在Oracle 11g中, 号称支持OLTP的Compress表, 并不是算法有什么改进(我用AUL 5去恢复11g中的压缩表, 也能恢复出来, 就说明了这一点), 也只是修复了一些Bug, 并且在普通的Insert语句下, 也可以进行压缩(还没有装11g进行验证). 如果这个功能安全可靠的话, 到是可以用于存放什么Log信息的表, 一个系统中总是不关键的数据占据了大多数存贮.

    11g安装软件太大了, 我还没有下载Windows的版本呢? 谁下载了去拷一下算了.

    想让Oracle的exp查询要导出的表时用并行去执行, 不想建一个Logon的触发器来做, 就Hack它一把了. 下面是用正常的exp跟踪(TRACE=YES)出来的SQL语句.

SELECT /*+NESTED_TABLE_GET_REFS+*/ "SH"."T_COMPRESS".*
FROM
"SH"."T_COMPRESS"

Rows     Row Source Operation
-------  ------------------------------
  10089  TABLE ACCESS FULL T_COMPRESS

    将exp拷贝一份, 命名为expp(Exp Parallel). 然后用UltraEdit打开expp文件, 在二进制模式下找到如下这一段.

BEGIN     SYS.DBMS_EXPORT_EXTENSION.SET_NO_OUTLINES;  END;

    将它编辑为"ALTER SESSION FORCE PARALLEL QUERY PARALLEL 4", 然后保存. 接下来用expp来导出一个表看看, 加上TRACE=YES选项.

SELECT /*+NESTED_TABLE_GET_REFS+*/ "SH"."T_COMPRESS".*
FROM
"SH"."T_COMPRESS"

Rows     Row Source Operation
-------  -------------------------------
  10089  PX COORDINATOR  
      0   PX SEND QC (RANDOM) :TQ10000
      0    PX BLOCK ITERATOR
      0     TABLE ACCESS FULL T_COMPRESS

    自已玩玩可以, 不要在正式的场合下这样做. 正式场合请改表的并行度或用Logon触发器.