MySQL5.1新特性（一）日志的增强

对于MySQL，很多印象其实都是来自比较老的4.x版本，实际上MySQL在后续的5.0，5.1和6.0版本中还是做出了很多的改进，特别是原来一些动不动要重启的操作，慢慢的都可以在线做了，如果要做企业级数据库，在线操作的支持是必不可少的。由于我们在产品库中大量开始使用5.1，所以打算写一个系列短文，介绍一些个人觉得比较实用的新特性。因为MySQL这样的开源软件，版本分支比较多，所以每篇文章涉及的一些小版本可能不太一样。

MySQL有很多种日志，包括error log，general query log，binary log，slow query log等。在以前的版本，这些日志的开启或者关闭，都是需要重启服务器的，而且都是记录到日志文件。从MySQL5.1.6版开始，general query log和slow query log开始支持写到文件或者数据库表两种方式，并且日志的开启，输出方式的修改，都可以在Global级别动态修改。

如果说日志是写到文件还是表，对于DBA来说不是那么在乎的话，那么可以动态的开启关闭日志真的可以说是DBA们梦寐以求的。尤其是slow log query，以前一直在头疼，开启吧，可能影响性能，不开吧，对于一些性能差的SQL又没有其他好用的捕获方式。因为开还是不开，涉及到重启服务的问题。

下面演示一下通过设置几个Global级别参数来开启关闭general query log和slow log query的过程：

root@NinGoo>select version();
+---------------+
| version()     |
+---------------+
| 5.1.25-rc-log |
+---------------+
1 row in set (0.00 sec)

设置日志输出方式为文件

root@NinGoo>set global log_output=file;
Query OK, 0 rows affected (0.00 sec)

设置general log和slow query log的日志文件路径

root@NinGoo>set global general_log_file='/tmp/general.log';
Query OK, 0 rows affected (0.00 sec)

root@NinGoo>set global slow_query_log_file='/tmp/slow.log';
Query OK, 0 rows affected (0.00 sec)

开启general log和slow query log，相应的，关闭只要设置参数为off

root@NinGoo>set global general_log=on;
Query OK, 0 rows affected (0.04 sec)

root@NinGoo>set global slow_query_log=on;
Query OK, 0 rows affected (0.02 sec)

如果设置log_output=table的话，则日志结果会记录到名为gengera_log和slow_log的两张表中，这两张表的默认引擎都是CSV，其实就是将日志保存为CSV文件格式了。当然，也可以将这两张表改为MyISAM引擎，这不是问题。

更多关于MySQL5.1日志的新特性，请参考MySQL 5.1 Reference Manual

Oracle11g部分新特性移植到9i和10g

Oracle10.2.0.4出来的时候包含了属于Oracle11g的新特性Real Application Testing，现在，通过patch，可以在9i～10g各版本中获得包括SQL Performance Analyzer和Database Replay在内的Oracle11g新特性。

SQL Performance Analyzer可用于诊断由于系统改变等引起的SQL性能问题，通过在做出改变前后收集一个性能统计报告，然后比较得到性能改变的主要原因。

Database Replay则可以捕获产品数据库的压力等，在测试数据库中进行重演，可以更加准确的模拟产品库的压力对应用进行测试，这也是Oracle11g主推的Real Application Testing的主要功能。

要获得这两个新特性，需要安装Patch，对应的Patch请参考：Metalink Note:560977.1

Oracle11g新特性：Active Database Duplicate

利用Rman的duplicate命令，可以很方便的将原库复制出一个新库，这在诸如data guard等应用中非常有用。但是在Oracle11g之前，执行duplicate要求首先对原库用rman进行备份，然后将备份复制到复制库，同时连接原库(做为target)和复制库(做为auxiliary)，执行duplicate命令进行复制。在Oracle11g中推出的active database duplicate特性，则省略了进行rman备份的步骤，能够直接从原库复制出新库，对于一些大型的数据库来说，这个特性可以节省很多操作时间。本文将简单的演示一下操作过程(在同一个主机上执行duplicate)：

原库：ora11g(归档模式)
新库：oradup
操作系统:windows

一、首先手工创建新的instance
包括windows服务，dump路径，初始化参数文件，password文件，监听配置等等，这些步骤就不赘述了。理论上，初始化参数最少只需要指定db_name一个参数就可以了。当然，简单起见，最好还是设置如下参数：

DB_NAME=ORADUP
CONTROL_FILES=(’F:\ORACLE\ORADATA\ORADUP\CONTROL01.CTL’,
‘F:\ORACLE\ORADATA\ORADUP\CONTROL02.CTL’)
DB_FILE_NAME_CONVERT=(’F:\ORACLE\ORADATA\ORA11G’,'F:\ORACLE\ORADATA\ORADUP’)
LOG_FILE_NAME_CONVERT=(’F:\ORACLE\ORADATA\ORA11G’,'F:\ORACLE\ORADATA\ORADUP’)
log_archive_dest_1=F:\ORACLE\ARCH\ORADUP
compatible=11.1.0

经过试验，必须加入compatible＝11.1.0的参数，如果不加，默认是compatible＝11.0.0，那么rman duplicate最后在创建控制文件的时候会报错：

RMAN-03002: Duplicate Db 命令 (在 10/23/2007 22:43:40 上) 失败
RMAN-06136: 来自辅助数据库的 ORACLE 错误: ORA-01503: CREATE CONTROLFILE 失败
ORA-01130: 数据库文件版本 11.1.0.0.0 与 ORACLE 版本 11.0.0.0.0 不兼容
ORA-01110: 数据文件 1: ‘F:\ORACLE\ORADATA\ORADUP\SYSTEM01.DBF’

这个应该算是一个bug吧，11.0.0应该是beta版的版本号

加入log_archive_dest_1参数，则是因为最后需要复制原库的归档日志到备库，如果两个库都没有设置归档路径，那么都会放在默认的$ORACLE_HOME\rdbms目录下，就会发生冲突。当然，如果原库和新库在不同的主机上，则只需要db_name和compatible就足够了。

[继续阅读全文]

Oracle11g新特性：Automatic Memory Management(AMM)

Oracle9i引入pga_aggregate_target，可以自动对PGA进行调整；Oracle10引入sga_target，可以自动对SGA进行调整。Oracle11g则对这两部分进行综合，引入memory_target，可以自动调整所有的内存，这就是新引入的自动内存管理特性。

[继续阅读全文]

订阅本站 | Subscribe

文章分类 | Categories

最近文章 | Recent posts

站点信息 | Statistics