November 18, 2005
Oracle初学者入门指南-什么是Metalink?
作者:eygle
出处:http://blog.eygle.com
身为一个Oracle DBA，你必须知道什么是Metalink.
Metalink是Oracle的官方技术支持站点，其网址为: http://metalink.oracle.com.
Oracle公司通过该网站来支持全球的客户，据Oracle公司的统计资料，据说80%的技术问题都是通过Metalink网上解决的。
Metalink的注册并非免费。当你购买了Oracle公司的软件以后，可以根据License向Oracle请求CSI(Customer Support Identifier)号,通过CSI号你就可以登录Metalink站点注册。
注意:如果你的供货商没有提供给你CSI号或者你自己无法注册,那么你的购买可能是存在问题的.
在服务期之内，你可以在Metalink上登记tar(Technical Assistance Requests),Oracle公司会专门指定工程师负责处理你的问题，最高级别的case会马上有工程师联系你进行协助解决。
现在，Tar这个词被更换成了SR--Service Request，你可以通过提交SR来申请获得帮助！
当然，在服务期满以后，你将不再能够报TAR，但是你能够继续使用Metalink的搜索功能，从Metalink的庞大资源库中受益,从2006年开始Oracle变更了Metalink策略，过期的CSI号将不再允许登录Metalink站点。
每个Oracle DBA都应该学会使用Metalink这个资源宝库。
并且每个DBA都应该学会，自己尝试找出问题的答案。
做为一个DBA我还想提醒大家,管理数据库的时候一定要慎重,不能粗心,不能无畏.
在Metalink上曾经有一句话可以做为借鉴:
Don't believe a customer when they say they didn't do it. Get evidence.
Oracle说不要相信用户,所以我们要学习值得信任,学习严谨,学习认真.学习对数据负责,对自己的行为负责.
你也可以从Oracle的官方站点上，找到相应的说明文档，参考以下链接:
Oracle MetaLink--Your Self-Service Portal
Data Sheet: Oracle MetaLink (PDF)
Internet Seminars: Oracle MetaLink
Posted by eygle at 5:34 PM | Comments (8)
案例:Move系统表DEPENDENCY$导致索引失效的数据库故障
作者:eygle
出处:http://blog.eygle.com
今天看到有一个朋友因为Move了一个系统表DEPENDENCY$,在没有Rebuild索引的情况下,重起数据库,结果收到ORA-01502错误,数据库无法启动.Thu Nov 17 01:55:30 2005
Errors in file /dcdb/admin/hidc/udump/hidc_ora_56602.trc:
ORA-00704: bootstrap process failure
ORA-00604: error occurred at recursive SQL level 1
ORA-01502: index 'SYS.I_DEPENDENCY1' or partition of such index is in unusable
在这种情况下,最好的情况是拥有备份,能够从备份中恢复.如果没有备份就很麻烦了(本案例恰恰没有备份).
和D.C.B.A讨论这个问题的时候,开始想到了3个办法:
1.通过某种手段跳过索引检测
事实证明在9i中这很难;而且这是在Bootstrap$的检测过程中发生的.
2.通过BBED进行修复
这种方法应该可行,但是会极其复杂小心.
3.使用DUL或类DUL工具
最后这种方法是万不得已.
DCBA在跟进这个案例,参考:
http://www.anysql.net/blog/p/movesystem.php
但是我们应该记住,永远不要让你的数据库处于这样的境地,这真的很危险.
这一问题的根本原因在于,数据库启动过程中,会进行如下验证:
select owner#,name,namespace,remoteowner,linkname, p_timestamp,p_obj#, d_owner#, nvl(property,0),subname from dependency$,obj$ where d_obj#=:1 and p_obj#=obj#(+) order by order# |
这一验证会导致如下执行计划:
STAT #9 id=1 cnt=1 pid=0 pos=1 obj=0 op='NESTED LOOPS (cr=6 r=3 w=0 time=694 us)' STAT #9 id=2 cnt=1 pid=1 pos=1 obj=18 op='TABLE ACCESS BY INDEX ROWID OBJ#(18) (cr=3 r=0 w=0 time=104 us)' STAT #9 id=3 cnt=1 pid=2 pos=1 obj=36 op='INDEX UNIQUE SCAN OBJ#(36) (cr=2 r=0 w=0 time=64 us)' STAT #9 id=4 cnt=1 pid=1 pos=2 obj=22 op='TABLE ACCESS CLUSTER OBJ#(22) (cr=3 r=3 w=0 time=576 us)' STAT #9 id=5 cnt=1 pid=4 pos=1 obj=11 op='INDEX UNIQUE SCAN OBJ#(11) (cr=2 r=2 w=0 time=406 us)' |
这里的'INDEX UNIQUE SCAN OBJ#(36)"就导致了最后的错误:
ORA-00704: bootstrap process failure ORA-00604: error occurred at recursive SQL level 1 ORA-01502: index 'SYS.I_DEPENDENCY1' or partition of such index is in unusable state EXEC #1:c=0,e=633371,p=39,cr=619,cu=1,mis=0,r=0,dep=0,og=2,tim=1105782888673612 ERROR #1:err=1092 tim=1563018104 |
可惜Oracle并不允许置所有索引于不顾,否则就有救了.
套用一句名言:幸运的数据库大致相同,不幸的数据库却各有各的不幸.
Posted by eygle at 1:46 PM | Comments (7)