AnySQL.net

    今天一个网友在用Log Miner恢复时, 发现怎么都恢复不了想要的DML语句, 所有步骤都是正确无误的.

execute dbms_logmnr.add_logfile(options =>dbms_logmnr.new,logfilename => ...
execute dbms_logmnr.add_logfile(options =>dbms_logmnr.addfile,logfilename =>...
EXECUTE dbms_logmnr.start_logmnr(DictFileName=>'.....');
SELECT sql_undo,sql_redo FROM v$logmnr_contents WHERE seg_name=...

    我用自已的MyLOG程序去查, 是找到了一条DML语句的, 可是Log Miner怎么不行呢? 你看他为什么要用Log Miner?

1, 表被删除(Drop).
2, 从昨天的dmp中恢复这个表.
3, 生成Log Miner数据字典文件.
4, 用Log Miner去解出今天的所有归档中对这个表的操作.

    结果肯定是恢复不出来了, 最后远择重新录入今天的数据. 这个年代, 会用工具的人是很多了, 理解后面的人不多了.

    来杭两周多一点, 扣去入职培训一周, 接触系统仅一周多一点的时间, 已经遇到了两个数据库方面的Bug了. 第一个是在10.2.0.2版本上遇到的, 和Oracle CBO优化器有关的, 在某些用了INDEX这个HINT的数据库中, Oracle居然选择了INDEX FULL SCAN的方法, 而不是效率更高的INDEX RANGE SCAN, 由于表及索引较大, 导致了SQL语句执成本过高, 引起了主机负荷超常.

4323868 INDEX hints can lead to INDEX SCAN FULL

    另一个是在9i中遇到的, 和UNDO表空间有关的, 平时的事务都很小, 某一点作了一个比较大的事务, 引起了回滚段的扩展, 虽然UNDO中有大量的可用未分配的空间, 但这个扩展的过程却极慢. Oracle并不从可用未分配的空间中优先分配, 而是先去检查有没有已用的空间可以回收再加以利用, 导致一个操作比测试时间多了20分钟.

4070480 Unexpired extents used when there is free space available in the UNDO tablespace

    做一个Oracle DBA实在不容易, 做事总有不可预见的一面.

    一直都反对使用ASSM表空间, 因为空间浪费比较严重. 但也从没有认真比较过, 还是先测试一下再说话吧.

SQL> select count(*) from t_assm;

  COUNT(*)
----------
        19

    将这个表复制一份到非ASSM表空间中, 再分析计算一下统计信息后, 看表的大小.

SQL> select table_name, blocks
  2 from user_tables where table_name like '%ASSM%';

TABLE_NAME                BLOCKS
---------------------- ----------
T_ASSM                          4
T_NONASSM                      1

    要是有些小表, 搞在ASSM表空间上, 又没有索引的话, 代价可在四倍以上啊.

    数据库的事务数高了, 再好的机器, 也顶不了多少, Log Write这块会成关键, 在一个每秒有几百上千个事务的库上, 发现了这样的负载现象, Rq是Run Que, Act是Active Session.

www.AnySQL.net  Load SY/WT/US  Rq  Act
07/23-22:18:02  6.09 11/27/31  64  16 
07/23-22:18:12  6.43 10/29/29  48  41 
07/23-22:18:22  5.82  7/42/21  39 1173
07/23-22:18:32  6.07 12/41/34  72  196 
07/23-22:18:42  5.62  8/52/24  52  329 
07/23-22:18:52  5.41 16/27/35  60  50 
07/23-22:19:02  5.03 13/27/33  44  26

    看一下V$SYSTEM_EVENT中的内容, 就会明白了, 206是单块读事件, 203是log file sync事件.

07/23-22:18:02 206-32714:206455:63, 203-12736:14704:11
07/23-22:18:12 206-30236:227577:75, 203-11799:12400:10
07/23-22:18:22 203-8999:1922849:2136, 206-19601:358029:182
07/23-22:18:32 206-38475:3520870:915, 203-16434:1425936:867
07/23-22:18:42 203-12308:3448652:2801, 206-27495:3031272:1102
07/23-22:18:52 206-34469:322209:93, 203-13581:107794:79
07/23-22:19:02 206-32916:234741:71, 203-13072:16812:12

    两周前Oracle的人来交流时, 我反映过这个问题, 他们说有几个和log file sync超长时间等待有关的Bug. 我也向他们要这些Bug的patch了, 可还没有发送给我们, 有些bug, 发现的晚了, 在metalink是找不到老版本的patch的, 需要特殊对待.

Bug 5065930 - "log file sync" timeouts can occur
Bug 3748799 - Average "log file sync" wait per transaction greater than 1 (no timeouts)
Bug 5087592 - "log file sync" waits from read only commits
Bug 6319685 - LGWR posts do not scale on some platforms

    上面是我自已搜索到的相关Bug, 和交流时Oracle工程师给我看的有些不一样.

    今天想根据输入的带季度值的分区名, 再转换成季度的日期, 如下所示:

SELECT ...
FROM ...
WHERE DATECOL >= TO_DATE('20&&partname.','YYYY"Q"Q')
  AND DATECOL <  ADD_MONTHS(TO_DATE('20&&partname.','YYYY"Q"Q'),3)

    却发现怎么都不行, 报了一个Oracle错误. 正向是可以的.

SQL> SELECT TO_CHAR(SYSDATE,'YYYY-Q') FROM DUAL;

TO_CHA
------
2008-3

    反向就不行了, 报日期的格式串不行.

SQL> SELECT TO_DATE('2008-3','YYYY-Q') FROM DUAL;
SELECT TO_DATE('2008-3','YYYY-Q') FROM DUAL
                        *
ERROR at line 1:
ORA-01820: format code cannot appear in date input format

    其他的象年月日等都是可以的, 为什么季度不行呢?