上一页 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 下一页 (Page 7 of 23)
国内数据库技术牛人, Oracle ACE Fangxin Lou 自行开发的 AUL 最近有了一次比较重要的升级：支持压缩表。有趣的是，据他自己说是经过了 20 分钟的发呆 想到的解决方法。很多人都知道 Oracle 的 DUL(Data Unloader) 是数据恢复的最后一招，一般来说是密不可宣的，一旦给用户恢复数据则代价昂贵，而 AUL 则平民化了许多，虽然不是开源的，但是国内用户如果使用的话，基本还是不收费用的(功能还毫不逊色)。
Lou 最近也作了一次 AUL/MyDUL发展历史回顾, 这个工具都三岁了。难得的是坚持，这一点我很服气他。
关于 AUL 更多信息可以参考他为推广 AUL 而做的 英文 Blog
--EOF--
BTW: 鲜果上我的BLOG验证代码: BANG1F1D675F0C335CE77C173BA6XIANGUO
Oracle 10g 开始 引入了AWR (Automatic Workload Repository). Oracle 建议用户用这个取代 Statspack。不过这个需要注意的是使用 AWR 需要有 Diagnostic Pack License。Oracle 后来推出了一个解决方案可以禁止掉该特性。
在 Note. 436386.1 有说明:
SQL> @dbms_awr.plb然后执行：
dbms_awr.disable_awr();
如果用 sys 之外的用户创建 AWR 报告，则需要进行合适的授权。否则会报告错误 PACKAGE 执行错误。
CONNECT / AS SYSDBA;
GRANT ADVISOR TO foo;
GRANT SELECT_CATALOG_ROLE TO foo;
GRANT EXECUTE ON sys.dbms_workload_repository TO foo;
要注意 Bug 4597354 在创建基线数据的时候，对性能有很大影响。在一个非常繁忙的系统上不要进行此操作。
如果结合企业管理器用 AWR 是很方便的，如果用手工方式收集性能数据，多了很多可供调整的地方，是更加方便了呢？还是更加麻烦了?
--EOF--
经常要对一些新存储系统进行 I/O Benchmark 测试，每次测试又有可能针对不同的目的，但基本也都是围绕数据库转悠，心血来潮，对几个常见的工具做个比较。
(点击查看全图)
要强调的几点: ORION --Oracle I/O Numbers Calibration Tool 还是比较全面的针对数据库应用的 IO 测试工具。现在 Oracle 发布了不少平台的移植版本。该工具也比较好用。
数据库应用必需要考虑异步 I/O 的因素，否则结果会有很大偏差，当然如果只测试存储能力的话，到可以忽略。AIO 压力测试可以考虑以下 AIO-Stress
Unix 命令 dd 虽然很土，但还是一个测试 I/O 的基本手段和方法.有的时候即使没别的工具只用它也能发现很多问题。另外一个需要注意的就是字符设备和块设备的差别啦。更新: 就当我说得是 GNU dd 吧，谢谢下面留言的朋友。
有些工具因为用过很久了，记忆难免有问题，表格中会有误导。仅供参考。今天太累，等有空继续补充内容。
--EOF--
BTW: 我收集的关于 Benchmark 的书签 内容。
如果用关键字 "MySQL 迁移 Oracle" 在网上搜索，基本上得到的内容都是关于从 Oracle 如何迁移到 MySQL 的，而从 MySQL 迁移到 Oracle 的信息则少之又少。
抛开那些手工一点点做的方法不谈，网络上也可以找到一些第三方工具来做这个事情，免费的? 我只找到了一个，那就是 Oracle SQL Developer 了。如果采用比较傻瓜化的方法，不妨考虑这个工具。在这个工具之前，Oracle 提供了单独的 Migration Workbench 工具。在 SQL Developer 1.2 版中，Oracle 干脆把这个功能集成进来。
数据流示意图:
Source Database(MySQL/DB2 etc.) --->SQL Developer (ETL)-->Target Database (Oracle)
MySQL JDBC 下载地址：
http://dev.mysql.com/downloads/connector/j/5.0.html
配置 MySQL JDBC:
还需要注意一点就是需要调整一下迁移时候的参数:
剩下的事情就简单了，配置到不同数据库以及准备存放 Metadata 数据库的信息。然后就可以迁移了。不赘述。
这个方法只是够傻瓜化，由于运行机制的限制，速度不是非常好。对于迁移过程中产生的变化数据，也无能为力。
--EOF--
今天参加 AIX 的技术培训，听了一些关于 CPU 调度的算法，倒也都是些基本知识，回想讲课内容的时候倒让我想起 Linux Kernel 的 I/O Scheduler 来。
这篇 Choosing an I/O Scheduler for Red Hat Enterprise Linux 4 and the 2.6 Kernel 是必须的参考资料。相比 Linux 2.4 Kernel 的一种 IO 调度器，2.6 做了很多改进，共有四种 IO 调度器。
Deadline scheduler 用 deadline 算法保证对于既定的 IO 请求以最小的延迟时间，从这一点理解，对于 DSS 应用应该会是很适合的。
Anticipatory scheduler（as) 曾经一度是 Linux 2.6 Kernel 的 IO scheduler 。Anticipatory 的中文含义是"预料的, 预想的", 这个词的确揭示了这个算法的特点，简单的说，有个 IO 发生的时候，如果又有进程请求 IO 操作，则将产生一个默认的 6 毫秒猜测时间，猜测下一个 进程请求 IO 是要干什么的。这对于随即读取会造成比较大的延时，对数据库应用很糟糕，而对于 Web Server 等则会表现的不错。这个算法也可以简单理解为面向低速磁盘的，因为那个"猜测"实际上的目的是为了减少磁头移动时间。
虽然这世界上没有完全公平的事情，但是并不妨碍开源爱好者们设计一个完全公平的 IO 调度算法。Completely Fair Queuing （cfq, 完全公平队列) 在 2.6.18 取代了 Anticipatory scheduler 成为 Linux Kernel 默认的 IO scheduler 。cfq 对每个进程维护一个 IO 队列，各个进程发来的 IO 请求会被 cfq 以轮循方式处理。也就是对每一个 IO 请求都是公平的。这使得 cfq 很适合离散读的应用(eg: OLTP DB)。我所知道的企业级 Linux 发行版中，SuSE Linux 好像是最先默认用 cfq 的.
Noop 对于 IO 不那么操心，对所有的 IO请求都用 FIFO 队列形式处理，默认认为 IO 不会存在性能问题。这也使得 CPU 也不用那么操心。当然，对于复杂一点的应用类型，使用这个调度器，用户自己就会非常操心。
那么如果跑数据库应用，那个更好一些呢? 我们看Choosing an I/O Scheduler for Red Hat Enterprise Linux 4 and the 2.6 Kernel一文中的测试结果:
对于数据库应用, Anticipatory scheduler 的表现是最差的。Deadline 在 DSS 环境表现比 cfq 更好一点，而 cfq 综合来看表现更好一些。这也难怪 RHEL 4 默认的 IO 调度器设置为 cfq. 而 RHEL 4 比 RHEL 3，整体 IO 改进还是不小的。
哪一种方式更好? 很难说，每一种方式都有特定的应用对它是最适合的。就像上面的 as 好像表现比较差，如果是 CPU 密集型的应用呢?
Tip:
Q:如何确认当前用什么 IO 调度器?
A: 过滤 /var/log/boot.msg 文件, 查找 "io scheduler", 看到了么?
在 操作系统上可以查到的相关文档：
/usr/src/linux/Documentation/block/as-iosched.txt
/usr/src/linux/Documentation/block/deadline-iosched.txt
这篇文章应该只是一篇草稿...
--EOF--
更新： Ubuntu Server 使用 Deadline 而不是桌面版的 CFQ 算法。
这是我的 Oracle 11g 系列的文章之一.
Oracle 11g SQL*Plus 也有不少新功能，这个 Error Logging 的新功能很有趣，也比较实用。当激活该功能后，可以记录 SQL*Plus 操作相关错误信息到具体的数据库表里面，对于以后追查很方便。激活的语法如下：
SQL> set ERRORLOG ON
SQL> desc SPERRORLOG
Name Null? Type ----------------------------------------- -------- ---------------------------- USERNAME VARCHAR2(256) TIMESTAMP TIMESTAMP(6) SCRIPT VARCHAR2(1024) IDENTIFIER VARCHAR2(256) MESSAGE CLOB STATEMENT CLOB
激活的时候会自动创建这个表。然后即可存储 ORA、PLS 与 SP2 类型的错误信息。
SQL> drop ttt ;
drop ttt
*
ERROR at line 1:
ORA-00950: invalid DROP option
SQL> select username,timestamp,message from SPERRORLOG;
USERNAME TIMESTAMP MESSAGE
---------- ------------------------------ ----------------------------------------
SCOTT 25-AUG-07 02.22.09.000000 PM ORA-00950: invalid DROP option
除此之外，亦可自行定制表，进一步定制存储错误信息。
默认情况下该选项是关闭的。另外，为避免递归调用错误记录, internal 错误不被记录.
--EOF--
尽管很多人都在抱怨 Oracle 的 License 价格不菲，可实际上也有一些省钱的空子可钻。很多人买 Oracle 服务，其实不过是想获取 Metalink 访问权限而已。最少要多少钱可以获取一个 Oracle Metalink 账户?
可能有的人还不知道，你最少只需要 75 美元，就可以获取一个 Metalink 账户，为期一年。用 75 美元买什么产品呢? Oracle Collaboration Suite! 这 75 美元包括 60 美元的单用户永久 License ，以及一个 15 美元的软件更新 License 与支持服务，也就你可以获取一个 Metalink 账户。
大约 500 块就可以搞定，个人都承担的起。尤其是当前美元贬值的情况下 :)
正当我们为 Oracle 新版本中有的特性稍微感动激动的时候，一瓢凉水浇了下来：想用新特性，拿钱来。
在 Oracle 这篇声明中宣布了 11g 有四个额外的特性是要单独收取 License 费用的。价格呢? 就是一个字，贵! 新的四个收费功能：
* Oracle Real Application Testing -- $10,000 per processor or $200 per named user; * Oracle Advanced Compression -- $10,000 per processor or $200 per named user; * Oracle Total Recall -- $5,000 per processor or $100 per named user; and, * Oracle Active Data Guard -- $5,000 per processor or $100 per named user.
点击查看 Oracle 全部产品价格列表。
一方面四面出击，大手比收购，一方面银子大笔落袋。查看资料显示，Oracle 在整个 2007 财年，"Oracle应用软件新许可证收入增长了32%"。Oracle 的抢钱本领让人赞叹。
--EOF--
这是我的 Oracle 11g 系列的文章之一.
用压缩的方式备份，这其实是一个 Oracle 早就应该有的功能。在 10g 中，终于看到 Oracle 实现了这个特性。而 11g 中，又提供了新的可选压缩方式:
RMAN> show all;
......
CONFIGURE COMPRESSION ALGORITHM 'BZIP2'; # default
默认的压缩是 BZIP2。另外一种支持的压缩方式是 ZLIB。相比前者, ZLIB 压缩率不高，不过处理速度快。
做了一个简单的测试，无论是用BZIP2 方式还是 ZLIB 方式， 备份当前的控制文件，压缩与未压缩比率接近为 1:10. 对于海量数据的备份，节省的空间将是惊人的。
要注意的是，COMPATIBLE 初始化参数必须设置 11.0 或者更高。
--EOF--
上一页 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 下一页 (Page 7 of 23)
