AnySQL.net

    维护生产库上的归档日志都不是一件容易的事, 一方面要尽量保存可能多的归档日志, 另一方面又要确保归档日志空间足够, 给归档日志用的卷又不会是很大, 最关键的是你不能时时盯着卷的容量, 还要保证删除不出错. 这个工作其实是有如下几个需求:

    1, 根据容量保存最新的日志, 如保存最新的200个归档. 2, 根据生成时间保存最新的日志, 如只删除一天以前产生的归档日志. 3, 只能删除已经在备库上应用过的归档日志, 以防止传输中出错, 最底要求是只能删除已经传送到一个或几个备库上的日志. 根据这三点要求来看, 你会发现目前没有好的现成的脚本来定期删除生产库上的归档日志, 所以我就自已写了一个, 可满足以上三个要求.

    根据上一篇Standby的脚本, 很容易写一个脚本来获得备库上已经应用过的日志的Sequence号, 然后在删除主库归档日志文件的脚本中, 通过ssh来调用.

sub getSSHStandbyLog
{
    my ($host,$sid) = @_;
    my $logseq = "???";

    eval {
        local $SIG{ALRM} = sub { die "???\n" }; # NB: \n required
        alarm 10;
        $logseq = `ssh -n -a -q -o NumberOfPasswordPrompts=0 $host /home/oracle/admin/bin/getstandbylog.pl $sid`;
        alarm 0;
    };
    $logseq = "???" if ($@ eq "???\n");
    $logseq = "???" if (length($logseq) == 0);
    chomp($logseq);

    scalar $logseq;
}

    然后到着查找到最小的归档日志, 再顺着删除, 就比较完全了. 昨天已经在一个库上用上了新脚本, 正在观察中.

    Perl是一门非常适合用来写数据库管理脚本的语言, Shell当然也很强, 但在这个领域还是没有Perl好. 来讲一个最简单的需求, 需要取得Standby或Dataguard上最后一个应用的归档日志, 在普通恢复和Managed恢复方式都要支持, 这个需求并不容易准确地实现. 如果用Perl来分析Oracle的alert日志文件, 则比较容易. 如下所示:

sub getLastRecoveredLog
{
    my ($alert_log_file) = @_;
    my $logseq = "???";
    my $lastline = `tail -1000 ${alert_log_file} | grep "Media Recovery Log" | tail -1`;
    if (defined($lastline))
    {
        $lastline =~ s/.*\///g;
        my @cols = ($lastline =~ /\w+_\d?_(\d+)[\.|_]/);
        if (defined($cols[0]))
        {
            $logseq = $cols[0];
            $logseq = $logseq - 1;
        }
    }
    scalar $logseq;
}

    如要删除已经应用过的归档日志, 那么只需要再写一个根据Sequence查找归档日志位置的函数就行了.

sub findLogBySequence
{
    my ($logseq) = @_;
    my $logfile = `find /data*/arch -follow -name *_${logseq}.* | head -1`;
    chomp($logfile);
    # Foloowing logic is for Oracle 10g
    if (length($logfile) == 0)
    {
      $logfile = `find /data*/arch -follow -name *_${logseq}_* | head -1`;
      chomp($logfile);
    }

    scalar $logfile;
}

    先找出所有要删除的归档日志, 存在变量中, 然后根据Sequence从小删到大就行了.

    eBay的chao_ping在Oracle-l中问如何节约历史库的空间, 经过了10年的发展, eBay的历史库积累了100多TB的数据, 并且数据的增幅很大, 虽然历史库用不着很好的存贮, 但这笔成本还是比较大的. 已经使用了压缩表将常规的表的空间压缩到了三分之一到六分之一, 但其中有一半的数据是用LONG或LONG RAW类型存放的, 没有办法用压缩表. 想想再过几年, 这样的历史库空间问题, 也会面临在很多的DBA前面.

    在Oracle中比较花存贮的有如下方面:

    字段编码. 不要小看这个字段编码, 比如状态字段, 用"E"和用"ENABLE"来表示, 当然后者更好读了, 生产库中应用开发人员可能偏向于后者, 但到历史库中时, 不如转换成前者. 其实一个表中一般不止一个这样的状态字段. 因此我将这个摆在第一位.

    索引. 在生产库上就有些索引, 用得很少, 但每次要用, 都是比较重要的情况, 因此不得不心不由己地加索引, 历史库也有一样的情况. 其实有时不如引进针对某类记录的附加表, 来解决大表的索引问题.

    LOB列. 大量的LOB不光是耗性能, 也是很耗空间的, 因为LOB的最小分配单位是一个数据块, 两个LOB值没有办法共享一个数据块. 如果是CLOB, 在变长字符集中存放大量英文文本的话, 浪费更严重, 一个英文字母在LOB中存放需要占用两个字节, 不管是INLINE还是OUTLINE.

    LONG列. 有LONG的列没有办法压缩, 在插入记录时, Oracle也会过量使用空的数据库, 因而浪费空间. 用utl_compress将值取出来, 再存到LONG RAW中或RAW中, 也是不错的选择.

    垃圾数据. 数据库中肯定多多少少会有垃级记录, 象天文数字交易额的交易记录等等, 要筛选这些记录, 过程可能过于复杂, 所以就留了它们.

    当然应对的办法, 也就随之而出了, 压缩及11g中的新的LOB格式. 也许可以将所有的字段进行序列化, 然后存在一个字段中, 要查询时用应用来解开这些字段. 过段时间也好好分析一下我们的历史库, 想想有没有办法省钱.

    AUL的DMP格式文件很方便于恢复数据, 但还是有一个地方不爽, 因为在DMP格式中, 表的所有者总是MYDUL这个用户, 而不是这个表原来的用户名. 例如用下面的命令恢复一个表:

set output_style dmp;
set charset 852;
UNLOAD TABLE GX.VIO_FORCE TO TEMP.dmp;

    在导入时, 就一定要用DBA权限用户, 并且指定FROMUSER和TOUSER选项, 才能导回到原来的用户中去.

imp system file=TEMP.dmp fromuser=MYDUL touser=GX

    改进后, 就不需要用DBA权限的用户, 也不需要指定FROMUSER和TOUSER了.

imp gx file=TEMP.dmp

    下面是真实的测试例子.

Export file created by EXPORT:V08.01.07 via conventional path
import done in ZHS16GBK character set and AL16UTF16 NCHAR character set
. importing GX's objects into GX
. importing GX's objects into GX
. . importing table      "VIO_FORCE"          0 rows imported
Import terminated successfully without warnings.

    有少数用户或中间人水平实在比较菜, 用imp导入时不知道如何写fromuser和touser选项, 只好从客户第一出发, 再作改进了.