AnySQL.net

    一提到系统监控就会联想到Cacti这个优秀的开源软件, 或用Nagios. 不管什么样的监控软件平台, 监控可做的事大约有四个方面.

    一定的报警机制. 对于特定的事件, 需要用特定的方式(手机, 邮件, 淘宝旺旺等)通知相关人员, 通知的事件大小由监制的机制来决定, 如果是7x24的, 那一般只有交易量下降多少比例时才会报警, 如果不是7x24的, 那么有任何错误发生时都需要报警.

    一定的图表显示. 图表是最好的表现数据趋势的方式, 对于交易量或主机负荷之类的少数重要数据, 用图的方式显示. 缺点是一个屏幕内能提供的信息量比较少, 对于详细诊断问题所在起不了多少帮助.

    很多的详细信息. 用网页方式显示某些方面详细的数据, 如将所有的消息滞留的情况记录下来, 用来查找发生的问题. 更多的如应用中关键的API调用次数, 显示一个当前值和历史平均值, 也可以确定某个点是不是有问题. 非常适合于详细问题的快速确定.

    一定的自动响应机制. 管理出身的会很关注这一点, 是很好的设想, 但不容易实现, 最简单地说表空问不足这个问题吧, 让程序自动加文件? 还是做一个空间预测, 提前加好空间, 个人偏向于后者.

    现在监时做的一些监控就是建立在自已开发的WebChart基础上的, 表格和图形并存的方式. 更适合于白天工作时段的监控, 好好保存一定历史信息, 还可用于事后问题查找.

    这几天要做几个远程的Standby, 由于是在数据库用的是将要过时的裸设备(Oracle 12g要)上的, 发现以前最喜欢的方式不好用了. 最喜欢的是停止源端的Standby的恢复, 然后用rsync拷到远程的机器上, 以前面对的是Veritas文件系统, 因此很容易编写运行很稳定的脚本, 来自动创建Standby. 用一步一步搞的方式, 所需要的归档日志的空间也特别地小, 实在是网络不好(远程)时的最佳方案.

    目前的rsync不能用于我们这种情况的原因是, 在拷文件时, 在目标端会创建监时文件, 然后改文件名实现, 因此不适合于裸设备. 程序中改一下应当就可以了, 估计不难, 象我这样不是专业出身的人也能搞定这一段代码吧. 有意向准备改一个, 可以取名为raw-sync.

    基于rsync的代码改是最好的, 因为网络不好, 所以最想用它的自动压缩解压功能, 在过去几年的经验中, 这对于提升传输速度是十分有效的. 基于scp的代码也行, scp虽然在源端不生成临时文件, 但还是将目标端的文件重建了一下, 看开始拷时, 目标端的文件大小变成0就知道了.

    对于裸设备, 一直都推荐用dd, 因此写一个Remote DD也不错, 不过没有基础, 这一步有很高的难度, 至少这个名字很好.

    看来我的创意还不少, 虽然Oracle 12G要过时了, 但还没有见影呢, 得过好几年呢.

    题目为基于数据的性能调整, 来到杭州的新公司, 首要面对的问题是性能问题, 如何让系统支持未来业务的增长. 另外, 由于是中间进来的, 对应用并不了解, 那就只能将一些性能数据共享给应用开发人员, 请他们一起来关注, 以解决一些很明显的性能问题. 用数据来说明问题, 而不是用感觉, 那是必须的, 才能获得认同. 来听的人主要有系统分析师及程序开发人员.

    主要给人介绍了三个SQL方面成本值的含义. 1, 执行次数. 这一块DBA很难去发现问题, 而应用开发人员或熟悉业务的人员则很容易, 每秒的执行次数和业务量一比, 结果就出来了. 2, 逻辑读. 逻辑读的含义, 和逻辑读的高成本, 没有想象中的内存访问那么简单. 按卖家去查的一些SQL逻辑读特别高, 单次执行的历史成本数据等等. 3, 返回记录数. 部分表单次查询返回记录数大于1时和业务的关系, 单次执行返回小于1条记录时的含义. 也抛出了一些很明显的有待解决的问题.

    介绍了几个Statspack信息的查询界面, 如何去看这些页面上的信息. 主要有以下几类:

1, Abnormal SQL Costs Change

2, Abnormal DML Rows Change

3, Top SQL by Execs

4, Top SQL by Gets

5, Top SQL by Reads

6, Top SQL by Rows

7, Top DML by Rows

8, Search SQL by Tablename

    最后介绍了一下用这些数据发现的一些优化案例, 用事实说明一下这些数据, 以证实其有效性. 连续讲了1小时30分钟, 加上问答时间20分钟, 时间算控制得比较好.

    又得开始准备下一次讲课的内容了, 一定要从实践中出来内容.

    rsync适合于用来文件系统上文件的网络拷贝, 但并不适合于裸设备的网络对拷, 主要原因如下:

1, 区分符号链接.

2, 源端是符号链接时不传内容.

3, 目标端先生成监时文件.

4, 目标端先删除原文件, 然后重命令传好的监时文件.

    当面对裸设备时, 则不需要以上功能, 实际上要变成只传内容, 不管两边的文件类型是否一样, 如下所示:

1, 不要区分符号链接.

2, 只要传内容就行.

3, 目标端不先生成监时文件.

4, 以覆盖方式写, 不去缩小目标端文件.

    今天改了半天的rsync源代码, 初步实现了以上功能, 但有待正式场合的考验. 我的测试用例.

源端: 几个大小不同的文件

目标: 一个链接文件, 指向别的文件

    传了几次, 目标端的link没有被替换掉, 并且用小的文件替换大的文件时, 只有前面部份内容被冲掉, 已达到我的设想了. 下载rawsync(AIX/Linux), 开始试试吧？

    制作一个远程Standby, 如果数据库很忙, 生成的归档太多了, 没有足够的空间可以保存所有的归档日志, 可以参考如下步骤, 一部份一部份地将Standby建起来.

1, 在远程Standby机器上安装Oracle, 规划裸设备
2, 创建Standby的参数文件, 启动实例
3, 从主库生成Standby控制文件, 拷到备库, MOUNT备库
4, 配置参数, 自动接收或用脚本传输归档日志
5, 将Standby端的所有数据文件offline drop
6, 用rman在线拷出一部份数据文件
7, 用rawsync将数据文件传到Standby
8, 将拷贝过来的数据文件online起来
9, 恢复数据库, 应用部分归档日志
10, 停止恢复, 转到第5步, 直到所有的数据文件都过来

    当网络不好时, 可以用rawsync的"-z"选项来透明地压缩和压缩文件, 以节约网络带宽. 也可以用脚本来实现第3步到第10步, 也就是说创建一个Standby也就是发一个脚本命令再加上等待就行了, 不管这个数据库多大多忙, 是否建在裸设备(由rawsync处理)上.