系统慢得一批？看数据库运维老司机如何做优化
|
程序中存在连接泄露，简单理解成程序报错后事务不能有效处理，导致事务未提交阻塞系统。
针对第一部分报表，语句更是复杂至极，这东西不是短期就可以优化的，考虑分出去; 针对第二部分接口，修改接口视图，包括写法优化、添加索引、调用频率等; 针对第三部分业务语句进行细致优化，查询提示，计划向导、重编译等等手段。 优化阶段三(报表分离) 经过前两个阶段的优化一般系都会明显好转，只剩报表没有处理，和一部分高消耗的频繁接口查询，这部分我们采用报表分离的方式去解决。 这里面我们遇到一个问题，报表要写物理表。用2012 自带的AlwaysOn是没有办法实现的(辅助节点只能读)。 使用发布订阅，又不能同时满足数据安全和业务连续的要求，客户又不满意。 我们想到是否可以把写入物理表变成写入#temp 临时表? 软件厂商给出的结论是：不可能.... 那这里面我们使用了第三方的产品Moebius集群(这里真的不是广告....) 如何实现： 多活集群，几个节点数据实时一致，这样的基本知识就不普及了...集群介绍也免了; 首先程序只有一个连接字符串没法把报表指向到辅助服务器，我们只能通过Moebius集群的前端调度引擎，定制规则把报表所使用的存储过程定点指向到第二台服务器，解决了程序不能分离的问题。 其次Moebius集群可以实现两个节点都可写，以满足辅助节点报表查询写入物理表的需要。 再次临时表的写入量太大，千万级别数据同步也是问题，这里好就好在程序中写入的物理临时表都是以“Temp_” 开头并以GUID类型结尾。我们在这里设置了只要这样的表写入不会反向同步给主节点，这样根据规则控制双向同步满足了报表的要求，最终实现了报表的分离。 报表快了? 当然没有，只是分离不可能快，但是好处有三个： OLAP和OLTP分离事务阻塞得到解决; 报表服务器和业务服务器可以根据自身的业务特别进行单独的个性化设置; 根据报表的要求我们配置高速IO的硬件。 预期： 语句已经优化，阻塞情况也被解决，CPU、内存、磁盘压力也没有了，系统肯定快起来了! 结果： 系统快起来了! 最终业务系统节点全天24小时的慢语句数量： (虽然还有慢语句存在，毕竟是TB级别的数据量，不影响业务运行客户完全可以接受。)
总结 系统慢往往我们要全面分析，本文提供的维度：
往往优化真的不是简单的调一调语句，加一加硬件，全面地分析是根本解决性能问题的首要任务。 当然不是所有的优化都可以彻底解决，如本文中报表的改善是通过读写分离的方式实现，很多时候在ERP系统中报表的处理方式都是如此，报表如果细致优化，那需要多长时间呀!也许都是重写了。 本文的优化过程主要是： 全面分析系统问题 → 宏观层面解决(环境、数据库内部运行因素、硬件压力) → 低效代码调整 → 架构方案实现(稳定、安全、高效) → 最终系统顺畅无压力。 （编辑：西安站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
