AnySQL.net

    今天写了下面这一段SQL语句, 在写之前总觉得有更简便的方法, 可就是没有想出来:

SELECT
   REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(
      REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(TABLE_NAME,'0','#'),
         '1','#') ,'2','#') ,'3','#') ,'4','#')
             ,'5','#') ,'6','#') ,'7','#') ,'8','#') ,'9','#')  PATTERN_NAME
FROM USER_TABLES

    下班时坐地铁, 突然想到了Translate函数, 原来可以这么简单:

SELECT
   TRANSLATE(TABLE_NAME,'0123456789','##########') PATTERN_NAME
FROM USER_TABLES

    我写这个SQL是用来找出一些表结构应当相同的表, 最终的SQL应当如下:

SELECT TABLE_NAME FROM USER_TABLES
WHERE TRANSLATE(TABLE_NAME,'0123456789','##########') IN
(SELECT
   TRANSLATE(TABLE_NAME,'0123456789','##########') PATTERN_NAME
FROM USER_TABLES
GROUP BY TRANSLATE(TABLE_NAME,'0123456789','##########')
HAVING COUNT(*) > 1)

    看来选择最佳的方法是很必要的.

    最近常研究和分析Hash Cluster表, 发现要选建一个Cluster, 再在上面建表, 过程麻烦, 明明只有一个表, 却要分成两步, 或三步走. 在电视广告上什么都说一片能顶三片或五片的时代下, Oracle也应当进步一下. 我总是只在一个Cluster上建一个表, 称为Single Table Cluster吧.

    IOT是很好, 可是他的主要缺点是必需要有主键, 另外由于没有物理的ROWID, 因此在建第二个索引时, 从效率和维护代价上来看有些高. 而Index Cluster则不需要一定是主键, Hash Cluster则根本就不需要Index, 都是很好的东西.

    其实出一个Organization Cluster(COT)不是很好吗?

Organization Cluster (column, ...) SIZE ...
Organization Cluster (column, ...) SIZE ... HASHKEYS ...

    你看这一下一个新的语句顶原来多个语句了吧? 最近不好好看书, 老想些这个. 留恋过去好象是开始退步的标志啊!

    第一个是在用高版本的sqlldr向低版本的数据库中装载数据时遇到的, 解决的方法是将DIRECT=TRUE去掉, 不用DIRECT方式装载. 错误信息为:

SQL*Loader-951: Error calling once/load initialization
ORA-00942: table or view does not exist

    第二个问题是, sqlldr装载很慢, 一开始几乎以为是sqlldr死了, 装载几十条记录恢然等了足足十几分钟, 不管是DIRECT方式还是常规方式. 最后仔细地检查了一下, 原来是数据库中表的字段定义小了, 在log中报字段值过长, 改了就好了.

    第三个问题的情况和上面一个一样, 只不过最后的原因是因为出问题的数据库的字符集是UTF8, 而好的那个数据库的字符集是ZHS16GBK, 一些中文转换成UTF8时变长了, 导致了和字段不够长一样的效果.

    其中第二个问题是别人遇到的, 当时他用805版本的sqlldr试的, 而我用10g的版本试的, 还以为是sqlldr版本的问题. 其实没有那么多版本的问题, 这种最基本的功能应当是最稳定的. 值得写下来纪念一下.

    最近范错的人比较多, 这不? 就收到了一封求救信. 内容如下:

anysql,你好:

    我是山东的革命老区临沂人, 非常冒昧打扰你, 我把单位的一个ORACLE数据库弄坏了. 从网上搜索到你开发的工具aul可以直接从DBF中读取数据, 因此就很冒昧的给你这个邮件, 还是关于注册码的事情, 不知道你能否.... 我们这里经济很不好, 尤其是这几年物价飞涨, 能否给个注册码.

    非常感谢!

    一个希望获得你帮助的小人物.

    请大家建议我应当如何做?

    在数据库中有一个表, 在其上面有一个索引, 现在的情况是没有分析数据的. 如下所示:

SQL> SELECT TABLE_NAME, NUM_ROWS, LAST_ANALYZED
  2    FROM USER_TABLES WHERE TABLE_NAME='POS_SELL';

TABLE_NAME                       NUM_ROWS LAST_ANAL
------------------------------ ---------- ---------
POS_SELL

SQL> SELECT INDEX_NAME, NUM_ROWS, LAST_ANALYZED
  2    FROM USER_INDEXES WHERE INDEX_NAME='POS_SELL_IX1';

INDEX_NAME                       NUM_ROWS LAST_ANAL
------------------------------ ---------- ---------
POS_SELL_IX1

    接着需要再创建一个索引, 在创建时, 我加上了计算统计信息的选项, 如下所示:

SQL> CREATE INDEX POS_SELL_IX2 ON POS_SELL (USERCODE)
  2    COMPUTE STATISTICS;

Index created.

    现在我们再来查一下, 表及索引的分析情况, 发现在10g中, 只有新创建的索引有统计数据:

SQL> SELECT TABLE_NAME, NUM_ROWS, LAST_ANALYZED
  2    FROM USER_TABLES WHERE TABLE_NAME='POS_SELL';

TABLE_NAME                       NUM_ROWS LAST_ANAL
------------------------------ ---------- ---------
POS_SELL

SQL> SELECT INDEX_NAME, NUM_ROWS, LAST_ANALYZED
  2      FROM USER_INDEXES WHERE INDEX_NAME='POS_SELL_IX1';

INDEX_NAME                       NUM_ROWS LAST_ANAL
------------------------------ ---------- ---------
POS_SELL_IX1

SQL> SELECT INDEX_NAME, NUM_ROWS, LAST_ANALYZED
  2      FROM USER_INDEXES WHERE INDEX_NAME='POS_SELL_IX2';

INDEX_NAME                       NUM_ROWS LAST_ANAL
------------------------------ ---------- ---------
POS_SELL_IX2                        24398 14-MAY-07

    但今天在9i中创建索引时, 发现表被分析了, 但另一个索引则没有分析. 由于表的统计信息变了, 引起了一些SQL选择了错误的执行计划, 导致了服务器的性能问题.