metlaink上曾经有一篇文章上大致列举了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的状态
阅读全文>
发表于 @ 2006年04月28日 11:57:00|评论(loading...)|收藏
对于技术问题的研究，或许就是需要大家不断的探索，不断的测试，能提出问题当然是第一步，然后就是不断的测试，大家会逐步从中得出更为妥当的结论，谢谢eygle ：）阅读全文>
发表于 @ 2006年04月18日 16:39:00|评论(loading...)|收藏
在归档数据库中，一般碰到类似下面的错误：
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'
不管是哪种原因引起的（包括这里的这个隐含参数，也包扩其他导致日志文件损坏的情况），
我们一般都是采取下面的措施。。。
阅读全文>
发表于 @ 2006年04月18日 15:26:00|评论(loading...)|收藏
在归档数据库下，如果设置了 _disable_logging＝true，那么数据库就会将所有的online redo logfile标记为corrput，从而在归档数据库下不能够正常的归档了，因此，每次需要当数据库中所有的日志组归档状态都为“NO”，且STATUS列的值出现n-1个“INACTIVE”和一个“CURRENT”时，即，除了当前日志外，其余所有的日志都是不活动且没有归档的时候，对数据库的所有操作（只要产生的日志超过current日志的可用大小的时候，也就是需要发生日志切换的时候）就会hang。阅读全文>
发表于 @ 2006年04月18日 15:23:00|评论(loading...)|收藏
在非归档模式的数据库下，不论_disable_logging是false还是true，数据库都可以继续操作，而不受该参数的影响。阅读全文>
发表于 @ 2006年04月18日 15:03:00|评论(loading...)|收藏
不管是归档数据库，还是非归档数据库，只要设置了_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阅读全文>
发表于 @ 2006年04月18日 14:51:00|评论(loading...)|收藏
一个rebuild分区索引的小bug
ORA-14185: incorrect physical attribute specified for this index partition
阅读全文>
发表于 @ 2006年04月14日 13:29:00|评论(loading...)|收藏
将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百万)阅读全文>
发表于 @ 2006年04月06日 14:56:00|评论(loading...)|收藏