前天在搭建物理standby时，前面步骤都没错(实际上是有错)，在验证归档日志是否同步到备库时发现：ORA-16047: DGID mismatch between destination setting and standby我们的处理方案是：在主备同时设置相同的log_archive_config1. 备库idle> show parameter log_archive_config; NA ...继续阅读 (5)

1 基础例子比较常用的做法是，创建一个进程时可以提供参数来告诉他要做什么。本例子里，输出的"worker"将打印5次，不过不清楚孰先孰后，因为每个进程都在竞争访问输出流。1.1 输出顺序的不同[root@localhost pydoc]# ./tmp.py worker 0 worker 1 worker 2 worker 3 worker 4 [root@localhost pydoc]# ./tmp.py worker 0 worker 1 worker 2 worker 4 worker 31.2 简单的代码实现[root@localhost pydoc]# cat tmp.py #!/usr/bin/env python #coding=utf-8 from multiprocessing import Process def worker(num): """test python multi process""" print 'worker',num return def main(): jobs = [] for i in range(5): p = Process(target=worker,args=(i,)) jobs.append(p) p.start() if __name__=='__main__': ...继续阅读 (12)

1 基础例子比较常用的做法是，创建一个进程时可以提供参数来告诉他要做什么。本例子里，输出的"worker"将打印5次，不过不清楚孰先孰后，因为每个进程都在竞争访问输出流。1.1 输出顺序的不同[root@localhost pydoc]# ./tmp.py worker 0 worker 1 worker 2 worker 3 worker 4 [root@localhost pydoc]# ./ ...继续阅读

这个地雷我没踩过，不过今天周老大在微博记录了，想必这是他老人家心中的一个痛。为什么要记录？因为我认为这和我上次踩过的一个雷有异曲同工之妙，不同的是，我那个是数据库级别，而周老大那是表级。感兴趣的不妨结合起来看：我踩了mysqldump的一个地雷这种默认带删除操作真是坑死人不偿命啊，啊啊啊，受不了，功能多也是不好，这和MySQL的作风完全不符呀，完全属于PG一类。下面我来揭露下周老大心中的痛 :-)1 默认备份[ 18:22:57-root@ssdtest:~ ]#mysqldump -S /data/mysql/test_3312/mysql.sock --single-transaction --force test > s1.sql2 加--skip-add-drop-table[ 17:56:18-root@ssdtest:~ ]#mysqldump -S /data/mysql/test_3312/mysql.sock --single-transaction --skip-add-drop-table --force test > s2.sql希望您在mysqldump时能看下这2篇文章，免得........你懂的哦Good Luck！ ...继续阅读 (10)

这个地雷我没踩过，不过今天周老大在微博记录了，想必这是他老人家心中的一个痛。为什么要记录？因为我认为这和我上次踩过的一个雷有异曲同工之妙，不同的是，我那个是数据库级别，而周老大那是表级。感兴趣的不妨结合起来看：我踩了mysqldump的一个地雷这种默认带删除操作真是坑死人不偿命啊，啊啊啊，受不了，功能多也是不好，这和MySQL的作风完全不符呀，完全属于PG一类。下面我来揭露下周老大心中的痛 :-) ...继续阅读 (6)

1 测试环境指标测试环境机型DELL PE R720（2U PC Server）CPUXeon E5-2620(6核，12线程，2.0GHz, L3 15MB) * 2内存32G(4G * 8)阵列卡及设置PERC H710，512MB，BBU(FW：12.10.1-0001)，RAID 1+0FORCE WB硬盘15K RPM 300G SAS * 8网卡Intel 1GbE操作系统RHEL 5.8文件系统xfsMySQL版本5.5.36测试工具mysqlslap2 测试实例mysqlslap –S /data/mysql/test_3314/mysql.sock --concurrency=100 --iterations=5 --auto-generate-sql --auto-generate-sql-load-type=write --auto-generate-sql-add-autoincrement --engine=存储引擎 --auto-generate-sql-write-number 数据量 --debug-info3 测试结果3.1 单条SQL平均insert执行时间3.2 CPU %user时间Good Luck！ ...继续阅读 (12)

1 测试环境指标测试环境机型DELL PE R720（2U PC Server）CPUXeon E5-2620(6核，12线程，2.0GHz, L3 15MB) * 2内存32G(4G * 8)阵列卡及设置PERC H710，512MB，BBU(FW：12.10.1-0001)，RAID 1+0FORCE WB硬盘15K RPM 300G SAS * 8网卡Intel 1GbE操作系统RHEL 5 ...继续阅读 (6)

该篇是SQL优化的第4篇。这里主要表达我的一个观点是：不该存在的索引就该干掉，留着碍事在2014-3-12 15:39:01 -- 15:55:00这段时间内，在某个业务系统我们发现2个问题：1. 数据库存在大量的查询等待2. 服务器的存在较严重的io等待这种现象在数据库中实际也是很常见，就是某个慢查询，始作俑者，执行特马慢，把后面本该很快的查询给堵住，导致系列长查询出现经诊断，我们发现某张表里存在dateline索引，该索引会让MySQL优化器选择错了执行计划，导致后续大量SQL拥堵，大概有5000条Query相互堵住如果不走dateline索引，效果很好，下面对比：1. 执行计划对比2. 执行时间对比：因此，我们给开发童鞋的反馈是，卡擦掉dateline索引起初我们并不知道该索引是否还提供给其他Query使用，所以胆战心惊害怕会引起其他查询变慢不过经过这段时间的观察，实际上，并没有其他查询在使用这条索引索引是好东西，但不要贪哦Good Luck！ ...继续阅读 (10)

这是MySQL SQL优化的第三篇。公司某个业务系统频繁抛出问题SQL，我们对此类SQL做了基本面统计：此类SQL近期共执行了12次，最长一次花费480秒，最短286秒t1表的rows有90多万，始终会扫描这么多不需要的数据这是由于MySQL查询优化器在处理相关子查询方面存在局限性MySQL总是会将相关的外层表压到子查询中，它认为这可以更高效地查找数据行。这就意味着MySQL先选择对外层表进行全表扫描，然后根据相关字段一个一个执行子查询，如果是个小表，情况可能还不会引起我们注意，但是如果外层表示一个非常大的表，那么这个查询的性能会非常槽糕，很不幸，我们的场景刚好应了后者我们优化后的执行效果：Good Luck！ ...继续阅读 (20)

这是MySQL SQL优化分享第2篇，大家都很崇尚MySQL的一个强大分支Percona，真该跟风吗？有些时候，还是原配靠谱，小三不一定给力。我们先看下sar报告：明显地，CPU %idle 非常低，粗大事了。我们的告警邮件里显示，单条SQL执行时间长达 300秒左右。原始SQL非常长，这里就不贴了，但要表述的一个优化技巧是，优化的第一步，就是格式化 SQL :-)我们看下问题SQL的问题部分：LEFT OUTER JOIN `yy_game_info` `game` ON (`t`.`game_code`=`game`.`game_code`) LEFT OUTER JOIN `yy_company_list` `corp` ON (`t`.`company_id`=`corp`.`company_id`) LEFT OUTER JOIN `yy_sp_game_rel` `sp` ON (`t`.`sp_id`=`sp`.`sp_id` AND `t`.`game_code`=`sp`.`game_code`) WHERE (((t.game_code=game.game_code) AND (t.company_id=corp.company_id)) AND ...继续阅读 (21)