首页 | 摘要显示 | 上一页 1 2 3 4 5 6 7 下一页
ociuldr工具(文档)越来越被人接受, 还有一位外国人特意发邮件来告诉我说, 他成功地将这个工具用于一个项目中. 即使是小工具, 也需要花不少时间去完善和维护的. 今天为这个工具新增了一个小选项:
log = log file name, prefix with + to append mode
用法如下:
ociuldr user=ansyql/anysql@s8i query="select * from tab" log=tab.log
ociuldr user=ansyql/anysql@s8i query="select * from tab" log=+tab.log
指定log选项后, 运行ociuldr后将不会在屏幕上打印出log信息. 如果在文件名之前有加号, 表示将log信息添加在文件最后, 否则是覆盖. 这个参数有利于将ociuldr作为一个job来运行, 用追加模式, 方便查找错误.
欢迎使用更新后的版本, 可下载源代码自行编译, 我只提供Windows平台的可执行文件.
半年多前有人提出这个需求, 当时我也没有空去处理这事, 就搁下了. 今天将程序改动了一下, 增加了退出代码, 退出代码的含义如下:
0 = Successful
1 = Cannot login to database
2 = Cannot create cursor handle
3 = Cannot prepare SQL statement
4 = Cannot execute SQL query
5 = Cannot get the metadata of the result set
6 = Cannot create output file
7 = Oracle error found when fetching rows, such as ORA-01555 etc.
接下来验证一下, 先是不能连接数据库的情况:
bash-2.03$ ./ociuldr.bin user=anysql/anysq1@test query="select * from tab"
Cannot connect as anysql/anysq1@s8i.
Connection failed. Exiting...
bash-2.03$ echo $?
1
提供一个错误的SQL语句:
bash-2.03$ ./ociuldr.bin user=anysql/anysql@test query="select * from tab1"
ORA-00942: table or view does not exist
bash-2.03$ echo $?
3
将文件放到没有权限的目录中:
bash-2.03$ ./ociuldr.bin user=anysql/anysql@test query="select * from tab" file=/test.txt
15500 bytes allocated for column TNAME (1)
4000 bytes allocated for column TABTYPE (2)
20500 bytes allocated for column CLUSTERID (3)
ERROR -- Cannot write to file : /test.txt
bash-2.03$ echo $?
6
希望那位朋友可以看到这个贴子. 但是如果中间空间不够了, 可能还是得不到返回值的.
我想你基本上不知道MyLOG是什么样的东西, 不过下面的一些网上常见到的话题你可能会懂一些. 如何实时同步两边的数据? 如何将数据实时地同步到远程的数据库? 如何做远程冗灾? 比较低级的解决的方案有实体化视图, 或自已写程序来实现自动导出导入, 如果两边的网络很好, 还可以用触发器来实现. 中级一些的方案有Oracle的Stream和Replication, 说他们中级是因为他们还不够成熟. 高级一些的方案是用目前市面上的专用软件, 如很有名气的Quest Shareplex, 不是很有名气的DSG Realsync(缺少宣传)和基本上没有听说过的GoldenGate. 这些高级的专业软件在911事件后, 被国际上的大公司大量采用, 用于制作数据冗灾. 不过11g传闻中的一些功能很值得关注.
这些中高级的解决方案中, 都有一个共同的技术特点, 就是分析源数据库上产生的日志, 然后从日志中分解生成SQL语句, 最后在目标数据库端执行. 因为是从日志中去获得数据, 所以基本上对源数据库没有什么压力, 并且目标数据库不是源数据库的物理拷贝, 是在打开的情况下运行的, 因此还可以用来分担部份读操作. 当源数据库不可用时, 可以迅速将目标数据库转换为新的源数据库.
可以看到分析日志的Log Miner是一个关键, 两年之前我开始研究Oracle日志的格式, 不过由于工作和个人精力的问题, 直到两个月之前才做出了一个相当成型的Log Miner, 这就是MyLOG, 可以脱离Oracle的环境来分析Oracle的日志文件, 解出重做的SQL语句, 并且可以跨平台进行分析, 指在Windows下的MyLOG可以用来分析Solaris上的Oracle生成的日志文件. Oracle自带的Log Miner当然是最权威的, 不过不一定是最好的, 你看他的Stream和Replication就知道了.
单单一个离线Log Miner是没有用的, 只有进一步发展, 形成一个较便宜较可靠的类Shareplex或Realsync的产品, 才能将研究的成果造福于广大的DBA及企业. 不过国内的研究氛围并不好, 为了在自然界生存, 我已经没有精力继续往下研究和开发了. 所以正在思考做一个开源项目, 让别人去研究, 如果没有国内的人去参加，估计要造福我们还是很难的.
开源还是不开源呢? 是个想不清楚的问题!
要写一个能跑的程序不难, 用C写一个能跑的程序就不易, 写一个能不停顿跑一周的C程序就有点难了. 为了达到理想的效果, 历经周折, 终于搞明白了线程问题, 而我写的程序也已经在服务器上不停顿地运行了一周, 最怕的两个问题, 一个是内存汇漏, 另一个是Segment Fault(core dump), 都没有发生. C程序就有点象Unix小型机, 要出问题则会很快就体现出来, 要不出问题则可以很稳定.
当然测试还要续继, 看看一个月后, 或三个月后, 或半年后, 程序是不是还在不停顿的跑? 队了程序本身要稳定之外, 占用的资源也不能多, 否则那么多的DBA在管理数据库, 总会被发现最后被kill掉, 很多的程序都有这种下场的, 要逃过这一劫才算真正成功的程序.
用有自已的工具来监控数据库的性能是件很有意思的事, 会不停地改进你对数据库的直观认识, 然后你又会再次改进工具, 这个过程就象是炼金一样, 何况是在这样的一个单位呢? 最近在OTop和OPMon中去掉了Wait Event和Latch的输出, 使这两个程序在繁忙的数据库中也能跑, 又被重新使用起来了. 实时就是这两个工具的创意, 也是开发这两个程序时最迫切的现实需求.
虽然运行了一周, 但是还要经历更多的劫难才行.
