ITPub博客

    较好的实践是，oracle的密码操作通过profile来实现，而资源则是通过资源消费组来控制，profile其实是种限制。 通过profile来控制密码的使用，大抵有四： 1） 密码的历史     在这里，有两个参数：password_reuse_time和password_reuse_max，比较好的实践是，这两个参数当关联起来使用。 如：password_reuse_time=30，password_reuse_max=10，     用户可以在30

    undo表空间只做一件事：保存旧值。在AUM下，段是自动生成，区是自动分配与回收，且是不连续的。每个段至少有2个区。oracle自动使用undo段，在某种意义上，我们只要关注undo表空间的大小就可以了。     查询当前哪个undo表空间被激活： sys@ORCL> show parameter undo_tablespace NAME TYPE VALUE ------------------------------------ ----

早上做数据迁移，部署完slave2,发现3台机子的日志狂刷：旧slave：2014-05-29 14:35:35 996 [Note] Slave: received end packet from server, apparent master shutdown: 2014-05-29 14:35:35 996 [Note] Slave I/O thread: Failed reading log event, reconnecting to retry, log \'mysql-bin.000005\' at position 407 2014-05-29 14:35:35 996 [Warning] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommende新slave：2014-05-29

昨天同事在做主从时，从库报如下错误：Got fatal error 1236 from master when reading data from binary log: \'Misconfigured master - server id was not set\'粗粗看好像是master的server-id没有设置，但同事做如下查询：备库采集： root@localhost Fri May 23 14:18:59 2014 14:18:59 [(none)]> show variables like \'%server_id%\'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | server_id | 2 | +---------------+-------+ 主库

复合索引最令人困惑的当属索引列的顺序，不仅依赖于使用该索引的查询，更需考虑排序和分组。前段时候我发了个帖子：where条件顺序和复合索引字段顺序。感兴趣的朋友不妨参与讨论。今天我提个自己的观点。在应用开发阶段，【选择性】是我们首要考虑因素，请看简图：当出现sql性能问题时，你可能需要注意以下几个：1. 随机IO2. 排序(order by)3. 分组(group by or distinct)这时

以下面关键字眼为例：1 物理备库健康检查依据：Tue Apr 22 16:44:51 CST 2014Media Recovery Log /data/CMS/arch_log/1_58334_722210153_58334arch.dbfMedia Recovery Waiting for thread 1 sequence 58335 (in transit)2 逻辑备库健康检查依据：Tue Apr 22 16:44:48 CST 2014LOGMINER: Begin mining logfile for session 1 thread 1 sequence 58335, /data/CMS/standbyredo22.logBy 数据牧羊人Good Luck！

事情是这样的，我们DBA组有位同学误删了备库的一个临时表，导致复制出错老大给力，江湖救急。关于该参数，淘宝丁奇写了篇文章还不错：MySQL小误区：关于set global sql_slave_skip_counter=N 命令的一些点还有360的杨挺也有一篇：sql_slave_skip_counter 介绍这2篇文章看下大概理解了最后说下，保险点的做法是 N恒等于 1，比较不容易出错 :-)当然跳得多了主从的不一致性的gap就越大如果

前天在搭建物理standby时，前面步骤都没错(实际上是有错)，在验证归档日志是否同步到备库时发现：ORA-16047: DGID mismatch between destination setting and standby我们的处理方案是：在主备同时设置log_archive_config1. 备库idle> show parameter log_archive_config; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ log_archive_config string DG_CONFIG=(ORCL_PRY,ORCL_PHY)2. 主库sys@OR

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

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

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.soc

该篇是SQL优化的第4篇。这里主要表达我的一个观点是：不该存在的索引就该干掉，留着碍事在2014-3-12 15:39:01 -- 15:55:00这段时间内，在某个业务系统我们发现2个问题：1. 数据库存在大量的查询等待2. 服务器的存在较严重的io等待这种现象在数据库中实际也是很常见，就是某个慢查询，始作俑者，执行特马慢，把后面本该很快的查询给堵住，导致系列长查询出现经诊断，我们发

这是MySQL SQL优化的第三篇。公司某个业务系统频繁抛出问题SQL，我们对此类SQL做了基本面统计：此类SQL近期共执行了12次，最长一次花费480秒，最短286秒t1表的rows有90多万，始终会扫描这么多不需要的数据这是由于MySQL查询优化器在处理相关子查询方面存在局限性MySQL总是会将相关的外层表压到子查询中，它认为这可以更高效地查找数据行。这就意味着MySQL先选择对外层表进行

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

赶着这几天有些时间，把前段时间优化的几条SQL经验分享并总结下，以飨来者。第一个要分享的是对MyISAM优化limit分页。背景来自公司某个业务系统提供给爬虫抓取数据。基础信息：MySQL版本是5.1，引擎为MyISAM，原始SQL内容大致如下：注：为避免敏感信息，将很多字段变为col，但不影响阅读 :-)     SELECT Aa.* , B.col, B.col, C.col, C.col FROM (SELECT A.col,

最近开始做运维，连着2天发生过意外，虽然都有惊无险，但我认为是侥幸！故障记录如下：1. 2014-4-1 新项目上线，在执行DDL时忘了确认字符集，导致开发同学那边查出来是乱码。2. 2014-4-3 部署Oracle DG，自以为主库不是线上库，初始化后重启了主库发生事情是我们都喜欢事后诸葛亮，然后扪心自谓:"我下次注意"，不要忘了，生产环境是随机行走的，你无法意料它的走向

我们先看2种情况：P 1：[ 21:56:33-root@ssdtest:~ ]#mysqldump -S /data/mysql/test_3306/mysql.sock --single-transaction --force --databases tpcc > v1.sqlP 2：[ 21:56:54-root@ssdtest:~ ]#mysqldump -S /data/mysql/test_3306/mysql.sock --single-transaction --force tpcc > v2.sql加了参数【--databases】在dump文件里会多了一个【use dbname】操作，这将导致相同实例同名数据库无辜惨遭"恢复出厂设置" :-)线上操作必须列出执行方案，

在执行开发童鞋给的SQL脚本更新时，切记先用【\s】看下字符集，笔者今天在新项目上线时忘了确认字符集，导致页面查出来是乱码，还好老大给力，速度帮我背了黑锅，存底警醒自己以后不要再干出这种蠢事。Good Luck！

临时表简介MySQL在执行SQL查询时可能会用到临时表，一般而言，用到临时表就意味着性能较低。MySQL临时表可分：内存临时表和磁盘临时表，磁盘临时表使用MyISAM存储，而内存临时表则使用Memory引擎。MySQL使用内存临时表来存放查询的中间结果集，如果中间结果集大于临时表的容量设定，又或者中间结果集含TEXT或BLOB列类型字段，则MySQL会把其转化为磁盘临时表。Linux平台缺省是/

一提字符集，可能有人会说，不管天崩地裂，全用utf8，整个世界都清净了。但某些字符集是需要更多CPU、消费更多的内存和磁盘空间、甚至影响索引使用，这还不包括令人蛋碎的乱码。可见、我们还是有必要花点时间略懂下MySQL字符集。先直观认识各阶梯下显示使用字符集：# 囊括三个层级：DB、Table、Column mysql> create database d charset utf8; Query OK, 1 row affected (0.04 sec) mysql> cr