ITPub博客

   Python 的钱途光明、应用域广泛、以下是偶认为比较有意思的几个前景：          ㈠ 黑客语言              《unix编程艺术》的作者曾说“精明的perl黑客们都投向了python,而且再也不回头”       ㈡ 机器学习语言              《Machine Learing in Action》的作者利用高效的可复

    ㈠ 环境：                  OS    : RHEL-5.8        Server：MySQL 5.5        Engine：InnoDB                 ㈡ 问题：                  在无任何操作的前提下、磁盘IO负载都几乎跑满、然后跑了3、4个小时磁盘负载依旧       &nbs

     朴实简单的才是真、那些高端洋气的复制拓扑纯属自虐     实施复制大概会有 4 个原则：          ① 一个主库可以有多个备库     ② 一个备库只能有一个主库     ③ 每个备库 Server ID全局唯一     ④ log_slave_updates 有薪火相传之效用          下面简单谈谈几种复制的拓扑设计、

     当一条SQL提交到Oracle后、SQL引擎会分三个步骤对其处理和执行：          ① Parse(解析)     ② Execute(执行)     ③ Fetch(获取)          这三个步骤分别由SQL引擎的不同组件来完成、下面偶大概的绘出这张体系结构图：          记住这张图、对以后的优化或许会起到事半功倍的效用

     由于项目需要我在服务器上安装 openoffice + pdf2swf、装好了 OOo并启动、装好了 pdf2swf、可是启动：          于是、我就这么搞：          结果、你猜怎么着？打开openoffice以及其他的需要X11 支持的程序全部失效、一时心里拔凉拔凉的               刚开始还以为是X11 出状况了、费了好大劲重

     距离这事有过一段时间了、现下可回忆的东西也不多、那有多少算多少吧     我记得我升级glibc的初衷是因为安装3.x版本的openoffice 需要glibc-2.7     先用一副图片简介一下什么是glibc：          我的系统原本是glibc-2.5、源码升级到glibc-2.7、升级是成功了、可是依然：[root@odd ~]# ls -l /lib/libc.so.* lrwxrwxrwx 1 root root 11 2012-07-15 /l

     来自生产环境的朋友、可能都会碰到：          原本运行良好的查询语句，过了一段时间后，可能会突然变得很糟糕     一个很大可能的原因就是数据分布情况发生了变化     从而导致MySQL优化器对驱动表的选择发生了变化，进而出现索引失效的情况     所以、闲着蛋疼喝咖啡的时候、应该多收集两下表的统

     DBA 对OS的依赖、一丁点儿也不亚于DB、对于Oracle DBA、尤为突出     DB和OS的感情也与日俱增、耦合度高的让人一度以为这两要劳燕双飞了     例如、Oracle里面、          而且、故障诊断以及性能调优时、OS层的APP可能直接拖垮DB、比如：          好吧、我承认、扯这些无非就是想强调OS对DB、那剪不断

     繁琐复杂的执行计划、可能迷了开发人员的眼、导致一条性感又傻X的SQL 在服务器上跑得特欢乐     有介于此、重点抓住几个部分、至于其他的嘛、当然是、非礼勿视咯、、          ㈠ 返回行的数量                Oracle优化器是基于成本的、评估成本的一个主要指标便是查询多少行      &nb

方法一： sys@ORCL> select level from dual connect by level<=5; LEVEL ---------- 1 2 3 4 5 方法二： sys@ORCL> select rownum from dba_objects where rownum<=5; ROWNUM ---------- 1 2 3 4 5 方法三： sys@ORCL> select to_number(column_value) n from xmltable(\'1 to 5\'); N ---------- 1 2 3 4 5 方法四： s

     ㈠ 每天的工作                ① 检查 alert.log                ② 环境确认                      ● 数据库实例是否正常工作                         ▼ ps –ef|grep ora_              ▼ select status fro

     不需要通读、有重点地看、看以下 10 点：          ① Load Profile     ② Instance Efficiency Percentages     ③ Top 5 Wait Events     ④ SQL ordered by Gets     ⑤ SQL ordered by Reads     ⑥ Tablespace IO Stats     ⑦ Enqueue activity     ⑧ PGA Aggr Target Stats     ⑨ Rollback Segment Stats  &nb

     这里给个简单的经验、但不总是有效 -_-#          ① 写操作较多：自增ID     ② 读操作较多：业务IDBy David Lin2013-06-14Good Luck

   方法何其多、这里介绍的是懒人做法、也就是、借助工具   但是、生产环境是不能随便安装程序的、肿么办？   没关系、我们伟大的percona 已经为我们考虑周详鸟      这里、我们要借助三个工具：      ① pt-summary：绿色纯天然、免安装、下载即用、收集MySQL Server所在OS的基本信息   ② pt-mysql-summary：本地安装、然后

     sharding 策略大抵有二：静态和动态、静态分片优点：简单、开发成本低、维护花费小     常见的静态分片方式有哈希函数和取模、但这样就暴露了一个缺点(PS:还有很多缺点呢)：     这个缺点是这样的：          采用静态分片、我们就无法自定义数据放到哪个分片、如果、存在一些数据比其他数据活跃     而

      有时候、挺郁闷的、丫的、咋回事啊、就不走索引、      如果、你发现不走索引、却莫冒失强加自己的意志、      总得给出理由吧、做个测试先、证实/伪走索引切实明智      否则、可能会返回错误的结果、也可能导致性能下降            下面就常见不走索引的 6 种原因简要分析一下、做到心里有底 

   为什么我们需要锁？先别急着回答、回想一下我们在逛淘宝下订单时的一个场景：             InnoDB 是行锁、不存在锁升级问题、也就是、锁住 1 行和锁住 1 千万行的开销是一样   但是、InnoDB 行锁仍然存在一般的锁在高并发下所特有的"劣根性":      ● 丢失更新：A的修改被B覆盖、谓之"前浪总被后浪盖"

     用 Navicat 连接：                             错误日志：                           DNS 设置问题、如果授权的时候、只采用 IP 验证 就没有这个错误          skip-name-resolve 禁用 DNS 解析、grants table 只能使用 IP 或者 % 、否则、会告警： 

   经典的工具定律--马斯洛的锤子说：   如果你手头只有锤子、那所有东西看起来都像钉子      而在软件开发领域、对于任何设计上的问题、Java 里给出的解决方法都是创建一个新类   例如、为了封装一个“开灯”的动作、你需要创建一个LightOnCommand类来实现Command接口

     不严格的讲、daemon 就是服务、可分 2 类：     ① stand alone      ② super daemon      再不严格的讲、服务对应端口、那....那、daemon就对应了端口...？     我们可从 /etc/services 查询他们的对应关系：/*第一列为 daemon 的名称 第二列则是 port */ [root@odd ~]# cat /etc/services | grep -i --color=auto \'mysql\' mysql 3306/tcp