Mon, 15 May 2006 14:54:00 GMThttp://blog.csdn.net/lunar2000/http://item.feedsky.com/~csdn.net/lunar2000/~1121516/22621389/1121512/1/item.htmlhttp://blog.csdn.net/lunar2000/comments/729549.aspx2http://blog.csdn.net/lunar2000/comments/commentRss/729549.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=729549又一个特殊需求，呵呵。。。<img src ="http://blog.csdn.net/lunar2000/aggbug/729549.aspx" width = "1" height = "1" />Mon, 15 May 2006 22:54:00 +0800lunarhttp://blog.csdn.net/lunar2000/archive/2006/05/15/729549.aspx#Feedbackhttp://blog.csdn.net/lunar2000/archive/2006/05/15/729549.aspxlunarhttp://blog.csdn.net/lunar2000/archive/2006/05/15/729549.aspxhttp://blog.csdn.net/lunar2000/rss.aspxcsdn.net/lunar2000/~1121516/22621389/1121512http://item.feedsky.com/~csdn.net/lunar2000/~1121516/22621391/1121512/1/item.htmlhttp://blog.csdn.net/lunar2000/comments/694861.aspx1http://blog.csdn.net/lunar2000/comments/commentRss/694861.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=694861使用vi可以很轻松的给文件加密和解密。。。 <img src ="http://blog.csdn.net/lunar2000/aggbug/694861.aspx" width = "1" height = "1" />Fri, 28 Apr 2006 19:59:00 +0800lunarhttp://blog.csdn.net/lunar2000/archive/2006/04/28/694861.aspx#Feedbackhttp://blog.csdn.net/lunar2000/archive/2006/04/28/694861.aspxlunarhttp://blog.csdn.net/lunar2000/archive/2006/04/28/694861.aspxhttp://blog.csdn.net/lunar2000/rss.aspxcsdn.net/lunar2000/~1121516/22621391/1121512http://item.feedsky.com/~csdn.net/lunar2000/~1121516/22621392/1121512/1/item.htmlhttp://blog.csdn.net/lunar2000/comments/694858.aspx0http://blog.csdn.net/lunar2000/comments/commentRss/694858.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=694858metlaink上曾经有一篇文章上大致列举了job不能运行的可能的十多种原因，包括sga变量kkjsre为0；uptime超过497天（solarisd 系统上的bug 3427424）；JOB_QUEUE_PROCESSES为0;_SYSTEM_TRIG_ENABLED 为false等等，还有些人为的原因 这里仅仅想讨论一下如何简单的broke系统中所有用户的job，或者如何使用sys用户remove其他用户的job. oracle有一个undocument的函数DBMS_IJOB，可以让sysdba改变其他用户job的状态 <img src ="http://blog.csdn.net/lunar2000/aggbug/694858.aspx" width = "1" height = "1" />Fri, 28 Apr 2006 19:57:00 +0800lunarhttp://blog.csdn.net/lunar2000/archive/2006/04/28/694858.aspx#Feedbackhttp://blog.csdn.net/lunar2000/archive/2006/04/28/694858.aspxlunarhttp://blog.csdn.net/lunar2000/archive/2006/04/28/694858.aspxhttp://blog.csdn.net/lunar2000/rss.aspxcsdn.net/lunar2000/~1121516/22621392/1121512http://item.feedsky.com/~csdn.net/lunar2000/~1121516/22621393/1121512/1/item.htmlhttp://blog.csdn.net/lunar2000/comments/667969.aspx0http://blog.csdn.net/lunar2000/comments/commentRss/667969.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=667969对于技术问题的研究，或许就是需要大家不断的探索，不断的测试，能提出问题当然是第一步，然后就是不断的测试，大家会逐步从中得出更为妥当的结论，谢谢eygle ：）<img src ="http://blog.csdn.net/lunar2000/aggbug/667969.aspx" width = "1" height = "1" />Wed, 19 Apr 2006 00:39:00 +0800lunarhttp://blog.csdn.net/lunar2000/archive/2006/04/18/667969.aspx#Feedbackhttp://blog.csdn.net/lunar2000/archive/2006/04/18/667969.aspxlunarhttp://blog.csdn.net/lunar2000/archive/2006/04/18/667969.aspxhttp://blog.csdn.net/lunar2000/rss.aspxcsdn.net/lunar2000/~1121516/22621393/1121512http://item.feedsky.com/~csdn.net/lunar2000/~1121516/22621394/1121512/1/item.htmlhttp://blog.csdn.net/lunar2000/comments/667947.aspx0http://blog.csdn.net/lunar2000/comments/commentRss/667947.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=667947在归档数据库中，一般碰到类似下面的错误： ORA-00354: corrupt redo log block header ORA-00353: log corruption near block 3740 change 0 time 04/11/2006 13:49:56 ORA-00312: online log 1 thread 1: '/oracle/oradata/TSMISC02/redo01.log' 不管是哪种原因引起的（包括这里的这个隐含参数，也包扩其他导致日志文件损坏的情况）， 我们一般都是采取下面的措施。。。 <img src ="http://blog.csdn.net/lunar2000/aggbug/667947.aspx" width = "1" height = "1" />Tue, 18 Apr 2006 23:26:00 +0800lunarhttp://blog.csdn.net/lunar2000/archive/2006/04/18/667947.aspx#Feedbackhttp://blog.csdn.net/lunar2000/archive/2006/04/18/667947.aspxlunarhttp://blog.csdn.net/lunar2000/archive/2006/04/18/667947.aspxhttp://blog.csdn.net/lunar2000/rss.aspxcsdn.net/lunar2000/~1121516/22621394/1121512http://item.feedsky.com/~csdn.net/lunar2000/~1121516/22621395/1121512/1/item.htmlhttp://blog.csdn.net/lunar2000/comments/667946.aspx0http://blog.csdn.net/lunar2000/comments/commentRss/667946.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=667946在归档数据库下，如果设置了 _disable_logging＝true，那么数据库就会将所有的online redo logfile标记为corrput，从而在归档数据库下不能够正常的归档了，因此，每次需要当数据库中所有的日志组归档状态都为“NO”，且STATUS列的值出现n-1个“INACTIVE”和一个“CURRENT”时，即，除了当前日志外，其余所有的日志都是不活动且没有归档的时候，对数据库的所有操作（只要产生的日志超过current日志的可用大小的时候，也就是需要发生日志切换的时候）就会hang。<img src ="http://blog.csdn.net/lunar2000/aggbug/667946.aspx" width = "1" height = "1" />Tue, 18 Apr 2006 23:23:00 +0800lunarhttp://blog.csdn.net/lunar2000/archive/2006/04/18/667946.aspx#Feedbackhttp://blog.csdn.net/lunar2000/archive/2006/04/18/667946.aspxlunarhttp://blog.csdn.net/lunar2000/archive/2006/04/18/667946.aspxhttp://blog.csdn.net/lunar2000/rss.aspxcsdn.net/lunar2000/~1121516/22621395/1121512http://item.feedsky.com/~csdn.net/lunar2000/~1121516/22621396/1121512/1/item.htmlhttp://blog.csdn.net/lunar2000/comments/667943.aspx0http://blog.csdn.net/lunar2000/comments/commentRss/667943.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=667943不管是非归档模式还是归档模式，_disable_logging＝true都不一定会使数据库的数据加载操作的速度增加（我猜想oracle说到的提高数据加载速度可能是在某些特殊条件下的）。 根据eygle的测试，基本上可以推测出这个参数对于批量加载的真面作用（详细请参考eygle的网站）。 但是，要想使用_disable_logging提高数据加载的速度，那么需要设置这个参数后重启数据库，注意，eygle的数据库是9204,刚好不会触发Bug 3868748，因此，他可以得到一些测试的良好效果（仍然有一点不能解释的就是，为什么一个可以scopy＝both的参数非要到重启数据库才能起作用）。<img src ="http://blog.csdn.net/lunar2000/aggbug/667943.aspx" width = "1" height = "1" />Tue, 18 Apr 2006 23:20:00 +0800lunarhttp://blog.csdn.net/lunar2000/archive/2006/04/18/667943.aspx#Feedbackhttp://blog.csdn.net/lunar2000/archive/2006/04/18/667943.aspxlunarhttp://blog.csdn.net/lunar2000/archive/2006/04/18/667943.aspxhttp://blog.csdn.net/lunar2000/rss.aspxcsdn.net/lunar2000/~1121516/22621396/1121512http://item.feedsky.com/~csdn.net/lunar2000/~1121516/22621397/1121512/1/item.htmlhttp://blog.csdn.net/lunar2000/comments/667929.aspx0http://blog.csdn.net/lunar2000/comments/commentRss/667929.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=667929在非归档模式的数据库下，不论_disable_logging是false还是true，数据库都可以继续操作，而不受该参数的影响。<img src ="http://blog.csdn.net/lunar2000/aggbug/667929.aspx" width = "1" height = "1" />Tue, 18 Apr 2006 23:03:00 +0800lunarhttp://blog.csdn.net/lunar2000/archive/2006/04/18/667929.aspx#Feedbackhttp://blog.csdn.net/lunar2000/archive/2006/04/18/667929.aspxlunarhttp://blog.csdn.net/lunar2000/archive/2006/04/18/667929.aspxhttp://blog.csdn.net/lunar2000/rss.aspxcsdn.net/lunar2000/~1121516/22621397/1121512http://item.feedsky.com/~csdn.net/lunar2000/~1121516/22621398/1121512/1/item.htmlhttp://blog.csdn.net/lunar2000/comments/667913.aspx0http://blog.csdn.net/lunar2000/comments/commentRss/667913.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=667913不管是归档数据库，还是非归档数据库，只要设置了_disable_logging=true参数，那么在数据库的启动过程中都会因为ORA-07445 core dump [kcrfwcint()+1625]而异常终止的。 从metalink可以找到这个问题主要是由于bug 3868748引起的： When attempting to run Oracle with redo logs disabled (ie: with "_disable_logging"=true) the instance crasheswith SIGFPE (integer divided by zero exception) in kcrfwcint. ** NOTE: Oracle does *NOT* support the use of _disable_logging=true but this parameter is sometimes used for bulk load operations. No customer system should be running with t<img src ="http://blog.csdn.net/lunar2000/aggbug/667913.aspx" width = "1" height = "1" />Tue, 18 Apr 2006 22:51:00 +0800lunarhttp://blog.csdn.net/lunar2000/archive/2006/04/18/667913.aspx#Feedbackhttp://blog.csdn.net/lunar2000/archive/2006/04/18/667913.aspxlunarhttp://blog.csdn.net/lunar2000/archive/2006/04/18/667913.aspxhttp://blog.csdn.net/lunar2000/rss.aspxcsdn.net/lunar2000/~1121516/22621398/1121512http://item.feedsky.com/~csdn.net/lunar2000/~1121516/22621399/1121512/1/item.htmlhttp://blog.csdn.net/lunar2000/comments/663264.aspx2http://blog.csdn.net/lunar2000/comments/commentRss/663264.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=663264一个rebuild分区索引的小bug ORA-14185: incorrect physical attribute specified for this index partition <img src ="http://blog.csdn.net/lunar2000/aggbug/663264.aspx" width = "1" height = "1" />Fri, 14 Apr 2006 21:29:00 +0800lunarhttp://blog.csdn.net/lunar2000/archive/2006/04/14/663264.aspx#Feedbackhttp://blog.csdn.net/lunar2000/archive/2006/04/14/663264.aspxlunarhttp://blog.csdn.net/lunar2000/archive/2006/04/14/663264.aspxhttp://blog.csdn.net/lunar2000/rss.aspxcsdn.net/lunar2000/~1121516/22621399/1121512http://item.feedsky.com/~csdn.net/lunar2000/~1121516/22621402/1121512/1/item.htmlhttp://blog.csdn.net/lunar2000/comments/661775.aspx1http://blog.csdn.net/lunar2000/comments/commentRss/661775.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=661775metalin上随便看点东西，记得以前在哪里（ITPUB?）讲过其中文版。<img src ="http://blog.csdn.net/lunar2000/aggbug/661775.aspx" width = "1" height = "1" />Thu, 13 Apr 2006 21:58:00 +0800lunarhttp://blog.csdn.net/lunar2000/archive/2006/04/13/661775.aspx#Feedbackhttp://blog.csdn.net/lunar2000/archive/2006/04/13/661775.aspxlunarhttp://blog.csdn.net/lunar2000/archive/2006/04/13/661775.aspxhttp://blog.csdn.net/lunar2000/rss.aspxcsdn.net/lunar2000/~1121516/22621402/1121512http://item.feedsky.com/~csdn.net/lunar2000/~1121516/22621404/1121512/1/item.htmlhttp://blog.csdn.net/lunar2000/comments/652798.aspx1http://blog.csdn.net/lunar2000/comments/commentRss/652798.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=652798将undo改变成手工管理的， 然后设置隐含参数 _ALLOW_RESETLOGS_CORRUPTION = TRUE 和 _corrupted_rollback_segments ,因为redo损坏的时候，undo数据也大都不一致了。 2，open resetlogs之前，先使用recover database using backup controlfile until cancel;命令 如果此时又遇到600错误，就使用ADJUST_SCN事件来调整当前的SCN，如果SCN相差不多，可以通过多次重起数据库解决。 （这个level 1批的是每次打开不行的话将scn推进1百万，可以根据trace中的信息, 将level调高一些.） alter session set events '10015 trace name adjust_scn level 1'; 如果SCN相差比较多，可以设置level 2，。。。level 10等 (level 1是每次打开时将将scn推进1百万)<img src ="http://blog.csdn.net/lunar2000/aggbug/652798.aspx" width = "1" height = "1" />Thu, 06 Apr 2006 22:56:00 +0800lunarhttp://blog.csdn.net/lunar2000/archive/2006/04/06/652798.aspx#Feedbackhttp://blog.csdn.net/lunar2000/archive/2006/04/06/652798.aspxlunarhttp://blog.csdn.net/lunar2000/archive/2006/04/06/652798.aspxhttp://blog.csdn.net/lunar2000/rss.aspxcsdn.net/lunar2000/~1121516/22621404/1121512http://item.feedsky.com/~csdn.net/lunar2000/~1121516/22621406/1121512/1/item.htmlhttp://blog.csdn.net/lunar2000/comments/652773.aspx2http://blog.csdn.net/lunar2000/comments/commentRss/652773.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=652773模拟当前日志损坏，给出通常的处理方法和步骤<img src ="http://blog.csdn.net/lunar2000/aggbug/652773.aspx" width = "1" height = "1" />Thu, 06 Apr 2006 22:41:00 +0800lunarhttp://blog.csdn.net/lunar2000/archive/2006/04/06/652773.aspx#Feedbackhttp://blog.csdn.net/lunar2000/archive/2006/04/06/652773.aspxlunarhttp://blog.csdn.net/lunar2000/archive/2006/04/06/652773.aspxhttp://blog.csdn.net/lunar2000/rss.aspxcsdn.net/lunar2000/~1121516/22621406/1121512http://item.feedsky.com/~csdn.net/lunar2000/~1121516/22621407/1121512/1/item.htmlhttp://blog.csdn.net/lunar2000/comments/652263.aspx2http://blog.csdn.net/lunar2000/comments/commentRss/652263.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=652263很多时候，在系统出现性能问题的时候，大都和不良SQL有关，当然调整系统参数有一些情况下是必须的（是指系统参数明显存在问题的时候），这里将陆续总结一点近期的调整案例来说明一些典型的问题。<img src ="http://blog.csdn.net/lunar2000/aggbug/652263.aspx" width = "1" height = "1" />Thu, 06 Apr 2006 17:00:00 +0800lunarhttp://blog.csdn.net/lunar2000/archive/2006/04/06/652263.aspx#Feedbackhttp://blog.csdn.net/lunar2000/archive/2006/04/06/652263.aspxlunarhttp://blog.csdn.net/lunar2000/archive/2006/04/06/652263.aspxhttp://blog.csdn.net/lunar2000/rss.aspxcsdn.net/lunar2000/~1121516/22621407/1121512http://item.feedsky.com/~csdn.net/lunar2000/~1121516/22621408/1121512/1/item.htmlhttp://blog.csdn.net/lunar2000/comments/651050.aspx0http://blog.csdn.net/lunar2000/comments/commentRss/651050.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=651050我们这里所有的都使用HP DP 或者EMC 的legato来备份数据库和文件系统的，因此，对于他们的维护也就是必须的工作内容了，尽管我很不喜欢做类似的工作，但是工作毕竟不都是如人所愿的啊，呵呵。 这里就HP DP中最常出现的POOL满了又不能自动回收的情况给出一点方法。。。 <img src ="http://blog.csdn.net/lunar2000/aggbug/651050.aspx" width = "1" height = "1" />Wed, 05 Apr 2006 16:43:00 +0800lunarhttp://blog.csdn.net/lunar2000/archive/2006/04/05/651050.aspx#Feedbackhttp://blog.csdn.net/lunar2000/archive/2006/04/05/651050.aspxlunarhttp://blog.csdn.net/lunar2000/archive/2006/04/05/651050.aspxhttp://blog.csdn.net/lunar2000/rss.aspxcsdn.net/lunar2000/~1121516/22621408/1121512