作者:d.c.b.a, 订阅AnySQL, Oracle数据库恢复及服务, Sybase恢复, 磁盘及RAID恢复

    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从小删到大就行了.

相关文章 | Related Artiles

我要留言(当前0)

上午去参加互联网协会的一个论坛，中心议题是搜索引擎的社会责任。搜索引擎乃至所有企业，都应该将自己的道德底线稍微提高一点，这个我支持，因为现在企业的道德水平实在是太低了，连我都看不下去。但我也不得不承认，相关的监管部门，其实应该对企业道德水准低下负直接责任。

我相信，所有在中国经营的互联网公司，都至少有一个这样的大客户，它是你的上帝，它让你怎么做，你就得怎么做，它让你屏蔽什么，你就得当机立断地屏蔽什么，它让你捧谁，你就得欢天喜地地捧谁。没错，它就是监管部门。他们如太上皇一般，对企业指手画脚，要求企业做这做那。在很多时候，不是企业在控制用户能看到什么，而是他们。

搜索，本来是个技术活儿，需要长期不断地调整算法，努力通过技术手段，而不是人工，将用户最需要的结果呈现给用户。但在中国，不人工干预结果，比马丁·路德·金的那个梦，还难实现，监管部门的一道圣旨，要比所有的算法重要1000倍。所以，监控、删除、屏蔽，成了中国互联网公司的一项基本功。而且这个大客户脾气古怪，今天让你捧的，明天可能就要你屏蔽，你永远都要对它弯腰低头，笑脸相迎，否则有你好看。

如果这个大客户需要企业特别保护，那么别的客户为什么就不可以呢？如果这个大客户有权，那么别的客户有钱行不行？

也许，这就是国情，就是中国特色。是这个大客户帮助中国互联网公司练就了删除、屏蔽的基本功，也是这个大客户让中国互联网公司学会了看客户脸色行事。现在，他们又要求企业讲道德。拜托，您真的对自己的道德水准那么有信心？有你们这种无法无天的大客户在，中国企业的道德水准怎么可能高得起来。

作者:d.c.b.a, 订阅AnySQL, Oracle数据库恢复及服务, Sybase恢复, 磁盘及RAID恢复

    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格式. 也许可以将所有的字段进行序列化, 然后存在一个字段中, 要查询时用应用来解开这些字段. 过段时间也好好分析一下我们的历史库, 想想有没有办法省钱.

相关文章 | Related Artiles

我要留言(当前0)