AnySQL.net

    一条不能再简单的SQL引起了性能问题, Where条件中只有一个列, 并且有索引, 这是为什么呢? 请看下面的例子:

SQL> CREATE TABLE T_OBJECTS
  2  (
  3    COL1 NUMBER, COL2 VARCHAR2(20), COL3 VARCHAR2(30)
  4  );

Table created.

SQL> CREATE INDEX IDX_T_OBJECTS_1 ON T_OBJECTS(COL1);

Index created.

SQL> CREATE INDEX IDX_T_OBJECTS_2 ON T_OBJECTS(COL2);

Index created.

SQL> INSERT INTO T_OBJECTS SELECT
  2  OBJECT_ID, OBJECT_ID, OBJECT_NAME FROM DBA_OBJECTS;

9506 rows created.

SQL> COMMIT;

    在COL1上使用时可以正确地使用索引, 将1500用单引号括起来也行:

ASQL> EXPLAIN PLAN
    2   SELECT * FROM T_OBJECTS WHERE COL1=1500;

SQLPLAN                                                    
------------------------------------------------------------
  0     SELECT STATEMENT Optimizer=ALL_ROWS                
  1   0   TABLE ACCESS (BY INDEX ROWID) OF T_OBJECTS (TABLE)
  2   1     INDEX (RANGE SCAN) OF IDX_T_OBJECTS_1 (INDEX)  

    在COL2上使用时并不能使用索引, 这是因为Oracle将Where条件变成了"TO_NUMBER(COL2)=1500"来执行, 在9i上还有可能出现Index Full Scan的情况.

    Fenng发贴调查DBA最重要的书是一个很好的贴子, 从很多人的回复中看到Oracle Document CD中的官方文档(10g/9i)在人们心目中的位置. 从个人讲我看得最多的文档是下面的四个:

1, Oracle Concept(Oracle 7的看了两次, 8i的看了三次吧, 9i的一次)
2, Administrator Guide (8i的三次, 9i的一次)
3, Performance Reference and Guide (9i的三次)
4, Developer Fundermental (8i的两次, 9i的一次)

    我从Developer 2000开发做起, 做了1年对于PL/SQL早就很熟了, 这为我打下了很好的基础, Performance Tuning我是看得比较晚的. 其他的我还看了Backup and Recover Guide, Dataguard Guide, Data Warehourse Guide,OCI Programmer Reference, Pro*C reference, 还有一些吧. 其他的文档看了目录, 需到什么需要找的, 从官方文档中我可以很快地定位到.

    到了上海以后, 看了Lewis的Practise Oracle 8i和High Performance SQL Tuning两本, 在有了比较好的官方文档的基础知识后, 感觉看这两本书时将自已的思维打开得宽一些了.

    官方文档中的几本一直是我推崇的, DBA的知识不是靠一两本书就可以积累起来的.

    象Oracle这样的数据库, 在License上面的监管将越来越严历, 随着业务的增长而导致的数据库性能问题, 将如何得到解决? 在过去的相当长的一段时间内, 我们的企业都不惜在硬件升级上大花血本, 但这种简单的解决方法将变得越来越困难, 原因以下几个方面:

    1, License的费用增长

    当你用硬件升级的道路(如增加CPU)来解决性能问题时, 势必会引起Licence的增加, 你将付出硬件的成本, 同时也得支付License的费用, 并且Oracle这样的原产服务成本也随着License的增加而增加. 现在许多行业还在用盗版的Licence, 如买了标准版, 但用了企业版; 没有买Replication或RAC, 但却正在用他们. 但这种情况还能走多久呢?

    2, 硬件升级并不能解决问题

    我们大部份的企业现在用的系统业务量还少, 增长速度没有硬件技术提高的速度来得快, 因此在过去的这些年中, 通过硬件升级的方法还是帮他们解决了系统的性能问题. 但这种方法的效率正在变得越来越低, 甚至根本不起作用. 我遇到过IBM P590 (16CPU / 24G Mem)上跑一个约50G大小的数据库, 但还是遇到了性能问题. 难道我们还要对这个系统进行硬件升级吗?

    3, 时间成本

    系统慢必定带来时间的损失, 现在很多公司的时间成本并不高, 因此可能对系统慢而造成的时间成本并不在呼. 但随着时代的进步, 随还能过多地浪费时间呢?

    4, 数据增长

    一方面越来越多的业务的数据进入了数据库; 另一方面业务本身的发展也带来了数据量的增大. 现在已经没有几个企业能承受数据损失了, 这说明数据库中的数据已经很重要了, 因此性能问题绝对是一个和公司息息相关的问题了.

    在随后的几年中, 对于能够进行性能调整的DBA的需求会越来越多. 企业将会为软件和服务支持同硬件一样的成本, 技术人员的价值将越来越得到体现.

    DBA越来越春天了? 技术越来越春天了?

    今天和一个很出名的DBA聊起安全问题, 缘于他发现Perl的DBI程序在编译成机器码时, 不能执行, 我在网上花了一点时间想找解决方案, 结果没有找到. 当我问他为什么要编译成机器码时, 回答是他想将数据库的用户名和口令加密掉, 以确保安全. 我回答说建一个只读的用户, 随便这么聊了几句后, 就转到如何确保系统安全的话题上来了.

    现在的情况是, 很多的公司DBA兼SA, 知道root用户的密码, 这就是知道了一切. 当团队在迅速扩展时, 如何保证系统的安全性? 这个问题其实很复杂, 他现在面临的环境, 主要还是在内部人员的访问控制上面, 我想到的有几下几点:

1, 内部人员的素质问题, 包括人品和技术能力.
2, 所有操作都应当有Log, 每个人以不同的ID登录.
3, 控制外部对内部系统的访问.
4, 收回root权限.
5, 足够的备份.

    在这几点中, 我还是首先推崇第一点. 象bootstrap$被人有规律地修改掉了的例子, 绝对不是断电造成的, 而且在修改了几个月后数据库重起时才表现出来, 因此我首推人品问题.

    这个话题其实太复杂了, 我没有经验, 说说你的吧!

    Copy和Paste是个谁都会遇到的大问题, 众多的Blog遇到了被别的网站Copy和Paste引起的版权问题, 如: Chedong, Fenng和Eygle, 访问量较高的个人网站上的网站纷纷被很多的网站简单地Copy和Paste过去, 影响了很多人的创作积极性.

    不过这儿要讲的是另一个意思上的问题, 前不久有个朋友在逻辑灾备的机器上不小心删除了一个表, 其原因就是Copy和Paste, 从UltraEdit上拷贝到Secure CRT的屏幕上去执行, 却不知为什么Copy没有成功, 而Paste了上一次Copy的内容, 一个回车后将一个表删除了. 后来总共花了大约6个小时的时间去修复这个逻辑灾备. 这就是Copy和Paste引起的第二种问题, 试想这个问题如果发生成主库上, 而且没有备份的话, 服务将会被迫停止多久?

    解决问题的方法是, 需要更改Copy和Paste的习惯. 对于第一个问题来说, 在Copy和Paste后, 请将原文出处加入进去, 并保留一个链接指向原文. 对于第二个问题, 则请你在Copy和Paste时, 不要带上最后的分号, 或拷贝到一个临时的文件中, 并进行检查, 确认无误后再执行角本.

    你遇到过上面两个由Copy和Paste引起的问题吗? 有什么好的建议可以分享一下? 有一点是Copy和Paste久了, 也会遇到问题的.