AnySQL.net

    前几天体会到保持好的习惯不容易, 在一个几十个GB的分区表上建一个索引, 为了加快速度, 就用了并行. 命令如下所示:

CREATE INDEX ... ON ... (...) PARALLEL 2 LOCAL ONLINE;
ALTER INDEX ... NOPARALLEL;
ANALYZE INDEX ... ESTIMATE STATISTICS SAMPLE 10000 ROWS;
ANALYZE INDEX ... ESTIMATE STATISTICS SAMPLE 2 PERCENT;

    其实这样也算不错了, 不应当有什么大问题的. 结速跑完后, 看到有50个并行的进程, 第二句执行失败, 索引的并行度不为1, 还好是在主要用于灾难备份的只读节点上做时先发现的. 主要原因是心中认为这个表并不是很忙的, 就不考虑ORA-00054这个错误的处理了, 差点就造成问题了.

    要保持一个好的习惯真不容易, 心中不是不知道, 有时就是懒一些, 不想贴那么多的PL/SQL代码进去, 这不是知识点的问题, 这只是一个习惯上的问题, 其他类似需要注意的事情, 如用一句话执行UPDATE或DELETE, 更新或删除了大量的记录, 这种情况一般要求写一段PL/SQL来分段提交地处理.

    一年时间培养一个高级DBA, 绝不是将所有的知识灌进去, 而是指做事能让人放心, 有很好的习惯.

    Oracle数据库支持多种字符集, 目标是为了方便支持全球的各种不同语言, 但在实际生活中则常给我们带来麻烦, 98年刚出道时在老板兼师傅的指导下犯过一次错, 将所有的中文都导出成了问号, 最后客户请了一个学五笔输入法的班来重新纠正那些问号, 因此需要特别加注意, 一般情况下不允许在导出时进行字符集转换.

    准确的方法是, 导出工具所用的NLS_LANG设置和数据库的字符集一致就对了, 在exp的日志输出中可以看到以下信息:

Connected to: Oracle Database 10g Enterprise Edition ......
With the Partitioning, OLAP and Data Mining options
Export done in UTF8 character set and AL16UTF16 NCHAR character set

    当不一致时, 日志输出中会告诉你exp的NLS_LANG的设置, 以及数据库所用的字符集, 在下例中, NLS_LANG中用了US7ASCII, 服务器端则是UTF8.

Connected to: Oracle Database 10g Enterprise Edition ......
With the Partitioning, OLAP and Data Mining options
Export done in US7ASCII character set and AL16UTF16 NCHAR character set
server uses UTF8 character set (possible charset conversion)

    当不一致时, 如果导表时也导出了统计信息, 则还会得到以下错误信息.

EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
Export terminated successfully with warnings.

    外面流传可以改dmp文件中的字符集标识, 但如果在导出时已经发生了字符集转换, 就没用了. 我也改过, 那是将数据从US7ASCII的库导到GBK库中时做的, NLS_LANG设成US7ASCII进行导出, 再改dmp文件中的字符集标识, 然后NLS_LANG设成ZHS16GBK再进行导入.

    去查询一个大表时, 大家都不会忘记Oracle的并行(Parallel)操作, 比如:

CREATE TABLE xxx PARALLEL 4 AS SELECT /*+ PARALLEL(...) */
SELECT /*+ PARALLEL(...) */ FROM ...

    但手工并行则易被忘记, 一个朋友花了28小时导出300多G的带BLOB的表, 我的第一反应就是为什么不用并行? 这时是指手工并行. 使用exp的Query参数.

exp ... query=\"where mod(pk,4) = 0\"
exp ... query=\"where mod(pk,4) = 1\"
exp ... query=\"where mod(pk,4) = 2\"
exp ... query=\"where mod(pk,4) = 3\"

    由于LOB默认设置是NOCACHE, 因此导出LOB是很慢的, 采用多个进程进行导出, 可以节约很多的时间. 28小时的痛苦时间, 可以缩短为7小时, 或更短.

    要想办法偷懒, 这才是DBA的好生活.

    今天有人打电话问Windows Vista上不能安装Oracle 11g的问题, 和几年以前在Intel P4的机器上不能安装Oracle 8.1.7一样, 都是Java运行环境引(简称JRE)起的问题. Oracle安装程序会调用安装盘中自带的JRE, 自带的JRE存放在如下路径.

stage\Components\oracle.swd.jre

    当时我将一个smcjitc.ddl的文件删除, 或拷贝Oracle 9i下的JRE 1.1.8来让安装程序工作. 换成Oracle 11g后也可以用同样的原理来处理, 自带的JRE文件存放路径如下, 和以前的版本有所不同.

stage\Components\oracle.jdk\1.5.0.1.1\1\DataFiles\jre.jar

    你可以从SUN Java网站下载可运行于Windows Vista的版本, 安装到根目录下的jdk目录.

c:\jdk

    然后在根目录下运行如下命令, 生成新的JRE文件.

c:\jdk\bin\jar -cvf jre.jar jdk\jre

    用这个新的jre.jar文件替换自带的(事先作好老文件的备份), 就可以运行安装程序了.

    "我身高1.76, 体重85kg"与"我体重85kg, 身高1.76"有什么不同? 在关系数据库理论中, 确明地写着实体属性的顺序并不重要, 因此在我的DBDiff程序(表结构比较)中是不比较列的顺序的. 如果说硬要说列的顺序有关系, 那只能是说明应用程序代码习惯不够好.

INSERT INTO tablename VALUES (...)

    只有Insert语句不带字段列表的情况下, 才与列的顺序有关系, 但这不是一个好的习惯. 比方在多表关联时, 选择列时不加表名就不是个好习惯. 去年参加年会时, 淘宝的朋友曾提及以前就遇到过这样的问题, 在一个不太重要的系统中, 关联的两个表一开始所有字段名都不同, 后来有一天在一个表上加了和另一个表中某列同名的列, 这时应用出问题了.

SELECT A.COL1, B.COL2, ... FROM A, B WHERE ...

    很多都是简单的事, 如果一直坚持了就很好, 如果不坚持, 有时就是很坏的事. 要让一个人坚持, 那还比较容易, 要让一个队伍坚持, 就有些难了, 让一个IT业流动性较大的队伍坚持, 就更难了.