……
Recover rows from chained block RDBA=29371932 ...
Recover rows from chained block RDBA=29371771 ...
Recover rows from chained block RDBA=29371579 ...
Recover rows from chained block RDBA=29371868 ...
Recover rows from chained block RDBA=29371884 ...
Recover rows from chained block RDBA=29371900 ...
Recover rows from chained block RDBA=29371916 ...
Recover rows from chained block RDBA=29371932 ...
……

    由于要恢复的表中含有LONG RAW字段，里面存放的都是比较大的图片，PDF文档或WORD文档的二进制文件，从1MB到8MB不等，所以需要链接块（Chained Blocks）来用多个块存放一条记录。从上面截取的调试信息中，红色的第一行和最后一行，访问的数据块是相同的，这一点是不能理解的。当我们通过标记第一个块为损坏块后，后面又出现了类似的情况，通过求助于Oracle官方的支持网站，进行资料查找，发现有一个Bug和这种情况息息相关：

Bug 7705591 Corruption with self-referenced row in MSSM tablespace

    这个Bug已经确认会在10.2.0.2和10.2.0.4上遇到，并且目前的所有版本中都可能遇到，Oracle在这个Bug上写明，要到未来版本才能修复。这个Bug详细的英文解说如下：

A chained row (logical row continued in another row) in a table can be corrupted where the next row piece (nrid) points to itself.Data corruption resulting from a lost row piece can occur very intermittently in blocks experiencing high concurrency in MSSM tablespaces (dba_tablespaces.segment_space_management=MANUAL). It is most likely to happen but not limited to tables with a large number of columns (e.g. more than 255 columns). Without the fix of Bug 8720802 tools like DBVERIFY / RMAN / ANALYZE don't detect this logical corruption. The fix for this bug does not repair existent corruptions.

    简单地说就是CHAINED BLOCKS形成了一个环路, 无法跳出去，如果没有打上8720802这个补丁，连Oracle的工具DBV/RMAN/ANALYZE命令等都检测不出这种情况。并且修复这个Bug也不能纠正现有的记录。在Metalink上还有其他一些有关行链接的Bug, 可以用关键字“oracle chained row corruption bug”去搜索，也可能造成记录头的混乱。

    而恢复软件能顺利恢复的基础是，要么块是完好的，要么块能免被检查出来是损坏的，但按照现状，这个Bug引起的问题，很多工具都不能检测到这种情况。AUL现在可以检测出来行链接进行死循环的情况，但无法应对其他一些有关行链接的Bug引起的逻辑损坏，目前来讲逻辑损坏会导致，恢复出来的DMP文件无法导入，引起恢复失败。

Relative Posts:

• 2009/06/09 -- AUL程序上的两处缺陷 (1)
• 2008/12/27 -- AUL并行扫描Extent (1)
• 2008/08/01 -- 终极Oracle数据恢复工具 — AUL (8)
• 2008/05/12 -- Oracle不行再用AUL (7)
• 2008/04/17 -- Oracle DUL不行就用AUL (10)
• 2008/03/26 -- 不是好人, 这么无耻! (24)
• 2008/03/20 -- AUL恢复Oracle视图代码? (0)
• 2008/03/20 -- AUL恢复Oracle Sequence? (0)
• 2008/03/20 -- AUL恢复Oracle触发器? (0)
• 2008/03/20 -- AUL恢复Oracle索引结构? (0)

    写了一个Windows上的批处理脚本, 用SQLULDR2从Oracle中查询数据, 并生成MySQL的Insert脚本, 用管道输入到MySQL中去执行.

@echo off
echo %TIME%
sqluldr2 ... table=emp_his format=mysql quote=0x27 escape=0x53 null=null file=- | mysql test
echo %TIME%

    首先在MyISAM下测试, 先将表改成MyISAM方式存贮.

mysql> alter table emp_his engine= myisam;
Query OK, 0 rows affected (0.05 sec)
Records: 0  Duplicates: 0  Warnings: 0

    进行数据装载测试, 可以看出还是很快的.

D:\mysql-5.0.84-win32\bin>runload.bat
7:12:28.10
7:12:41.87

    查一下总共迁移的记录数.

mysql> select count(*) from emp_his;
+----------+
| count(*) |
+----------+
|  951308 |
+----------+
1 row in set (0.00 sec)

    接下来在Innodb下测试, 将表改成Innodb方式存贮.

mysql> alter table emp_his engine= innodb;
Query OK, 0 rows affected (0.06 sec)
Records: 0  Duplicates: 0  Warnings: 0

    进行数据装载测试, 可以看出比MyISAM要慢不少.

D:\mysql-5.0.84-win32\bin>runload.bat
7:09:34.85
7:10:06.15

    查一下总共迁移的记录数.

mysql> select count(*) from emp_his;
+----------+
| count(*) |
+----------+
|  951308 |
+----------+
1 row in set (2.11 sec)

    在MySQL中, 将同样的表从MyISAM转到Innodb, 需要多少时间?

mysql> alter table emp_his engine= innodb;
Query OK, 951308 rows affected (16.67 sec)
Records: 951308  Duplicates: 0  Warnings: 0

    对于在笔记本上测试的这个结果, 个人是相当满意的, 测试的表有8个字段, 差不多等于平均数.

Relative Posts:

• 2009/10/30 -- SQLULDR2功能增加, 性能不减 (9)
• 2009/10/28 -- SQLULDR2生成Insert SQL语句 (4)
• 2009/10/27 -- 将SQLULDR2转义符进行到底 (3)
• 2009/10/26 -- SQLULDR2处理MySQL转义符 (1)
• 2009/08/31 -- SQLULDR2处理MySQL的空值 (2)
• 2009/06/25 -- oramon如何收集V$SYSTEM_EVENT数据? (3)
• 2009/06/25 -- oramon如何从V$SESSION收集性能数据? (0)
• 2009/06/24 -- oramon如何从V$SYSSTAT收集性能数据? (1)
• 2009/06/09 -- copydata异构数据拷贝 (6)
• 2009/05/26 -- MySQL或Oracle, 是个问题? (7)

    可重用日志组数指数据库中已经归档, 并且状态为不活动(INACTIVE)的联机日志的组数, 可以用于监控归档速度及日志切换速度, 并根据这个数据进行报警. 回滚段使用指的是所有回滚段占用的空间的总大小, 在OLTP数据库中, 如果UNDO表空间满了, 可能会遇到Bug, 引起数据库表空间锁的争用. 日志同步时长可以用来评价日志写出去的速度, 或Oracle面临的事务压力.

    下面是在笔记本上获得的数据库性能数据.

www.AnySQL.net  Arc Undo Lgfc
11/05-18:59:17    0  62    5
11/05-18:59:27    0  62  10
11/05-18:59:37    0  62  10
11/05-18:59:47    0  62  10
11/05-18:59:57    0  62  10
11/05-19:00:07    0  62  10
11/05-19:00:17    0  62  10
11/05-19:00:27    0  62    0
11/05-19:00:37    0  62    0
11/05-19:00:47    0  62    0
11/05-19:00:57    0  62  10

    收集了数据后, 可以根据数据轻松地增加监控点, 或者将数据显示在WebChart的图上, 以供性能或容量分析. 在真实的苛刻的环境下的应用, 会使oramon越来越成熟, 为诊断Oracle的疑难杂症提供有力的数据依据.

Relative Posts:

• 2009/06/25 -- oramon如何收集V$SYSTEM_EVENT数据? (3)
• 2009/06/25 -- oramon如何从V$SESSION收集性能数据? (0)
• 2009/06/24 -- oramon如何从V$SYSSTAT收集性能数据? (1)
• 2009/05/22 -- 从oramon新报警中受益 (1)
• 2009/05/21 -- 用oramon的数据进行报警 (3)
• 2009/04/21 -- 用图表显示oramon数据 (2)
• 2009/04/15 -- 装载oramon性能数据 (0)
• 2009/04/15 -- 安装与运行oramon (2)
• 2009/04/14 -- oramon, 收集性能数据 (5)
• 2007/08/20 -- oramon稳定运行一周 (5)

    先是测试不做任何转义符处理, 生成文本文件的速度, 基本上受制于笔记本硬盘写出的速度了.

C:\>sqluldr2 scott/tiger query=emp_his
      0 rows exported at 2009-10-30 22:37:14, size 0 MB.
  961307 rows exported at 2009-10-30 22:37:21, size 48 MB.
        output file uldrdata.txt closed at 961307 rows, size 49 MB.

    接下是生成转义符处理过后的, MySQL用的文本文件, 速度在这次测试环境下没有下降.

C:\>sqluldr2 scott/tiger query=emp_his escape=0x5c quote=0x22 null=0x5cN field=0x2c record=0x0a
      0 rows exported at 2009-10-30 22:38:49, size 0 MB.
  961307 rows exported at 2009-10-30 22:38:56, size 52 MB.
        output file uldrdata.txt closed at 961307 rows, size 56 MB.

    测试生成MySQL插入用的Insert SQL文件, 速度在这次测试环境下也没有下降.

C:\>sqluldr2 scott/tiger query=emp_his escape=0x5c quote=0x27 null=null field=0x2c format=mysql table=emp_his
      0 rows exported at 2009-10-30 22:39:28, size 0 MB.
  961307 rows exported at 2009-10-30 22:39:34, size 56 MB.
        output file uldrdata.txt closed at 961307 rows, size 60 MB.

    生成普通的Insert SQL文件, 因为每一条记录都是一个Insert语句, 所以文件很大, 花在IO上的时间多了一些.

C:\>sqluldr2 scott/tiger query=emp_his  quote=0x27 null=null field=0x2c format=sql table=emp_his
      0 rows exported at 2009-10-30 22:40:01, size 0 MB.
  961307 rows exported at 2009-10-30 22:40:11, size 124 MB.
        output file uldrdata.txt closed at 961307 rows, size 128 MB.

    生成100万条记录的Insert SQL语句的速度基本上没有下降, 没有因为处理逻辑的复杂而增加处理时间, 功能增强而性能不减, 实属不易.

    当你需要迁移Oracle数据到MySQL或其他数据库时, 不妨用用SQLULDR2, 还可以生成普通的Insert SQL语句, 来迁移数据到不知名的小数据库, 比如说SQLite, Microsoft Access等.

Relative Posts:

• 2009/10/28 -- SQLULDR2生成Insert SQL语句 (4)
• 2009/10/27 -- 将SQLULDR2转义符进行到底 (3)
• 2009/10/26 -- SQLULDR2处理MySQL转义符 (1)
• 2009/08/31 -- SQLULDR2处理MySQL的空值 (2)
• 2008/11/28 -- ociuldr还有可改进之处! (4)
• 2009/11/07 -- MySQL数据迁移测试 (4)
• 2009/04/02 -- 给SQLULDR2加上Key保护 (6)
• 2009/04/01 -- SQLULDR2输出到STDOUT (4)
• 2009/03/31 -- 指定表名导出文本 (0)
• 2009/03/27 -- 用OCI 8实现了sqluldr2 (8)

    考虑到MySQL没有绑定变量的概念, 其实都是文本SQL操作, 因此使用Insert的性能也许不比LOAD DATA差. 在加入MySQL标准的转义符支持后, 要生成INSERT语句也很容易, 就在SQLULDR2中加入了这个功能.

    使用SQLULDR2的FORMAT参数, 可以实现这个功能.

sqluldr2 ... table=tablename format=mysql null=null escape=0x5c quote=0x27

    这时在输出文件中, 就是INSERT语句, 如下所示, 一个批处理(由ARRAY参数决定)是一条INSERT语句.

INSERT INTO tablename (COL1,COL2,COL3) VALUES
('A\\B\"\t','2009-10-28 22:31:22',1),
('A\\B\"\t','2009-10-28 22:32:24',2);

    当我们要迁移数据时, 就可以用管道操作了.

sqluldr2 ... table=table_name format=mysql null=null escape=0x5c quote=0x27 file=- | mysql database_name

    这样迁移数据, 也许要比生成文件中转来得快, 有空找几百万条记录试试看. 并研究准备的插入语句, 是不是值得支持一下.

Relative Posts:

• 2009/10/30 -- SQLULDR2功能增加, 性能不减 (9)
• 2009/10/27 -- 将SQLULDR2转义符进行到底 (3)
• 2009/10/26 -- SQLULDR2处理MySQL转义符 (1)
• 2009/08/31 -- SQLULDR2处理MySQL的空值 (2)
• 2008/11/28 -- ociuldr还有可改进之处! (4)
• 2009/11/07 -- MySQL数据迁移测试 (4)
• 2009/04/02 -- 给SQLULDR2加上Key保护 (6)
• 2009/04/01 -- SQLULDR2输出到STDOUT (4)
• 2009/03/31 -- 指定表名导出文本 (0)
• 2009/03/27 -- 用OCI 8实现了sqluldr2 (8)

#include <stdio.h>

void main ()
{
  int i;
  for (i=0;i<20000000;i++)
  {
      printf("%012d\n",i);
  }
}

    下午居然想到要来优化这段程序, 并且写出了更好的程序, 性能提升了30%, 从18秒提升到了12秒.

#include <stdio.h>

typedef struct _NUMERLIST
{
    int len;
    char buf[5];
} NUMBERLIST;

void printNumber(int num, NUMBERLIST numlist[])
{
    int v_num,i,j,k,pos=0;
    char tmpbuf[32];
    memset(tmpbuf,0,32);
    v_num=num;
    for(i=3;i>=0;i--)
    {
  v_num = num;
  for(k=0;k<i;k++) v_num = v_num/1000;
  v_num = v_num % 1000;
  if (v_num > 999)
      pos = pos + sprintf(tmpbuf+pos,"%03d", v_num);
        else
  {
      memcpy(tmpbuf+pos, numlist[v_num].buf,3);
      pos = pos + 3;
  }
    }
    printf("%s\n", tmpbuf);
}

void main ()
{
  NUMBERLIST numlist[1000];
  int i;
  for (i=0;i<1000;i++)
  {
      sprintf(numlist[i].buf, "%03d", i);
  }
  for (i=0;i<20000000;i++)
  {
      printNumber(i, numlist);
  }
}

    如果优化一下两个程序的IO, 采用缓冲输出, 估计第二段程序更显优势.

Relative Posts:

• 2009/11/05 -- oramon新增三个性能数据 (3)
• 2009/07/09 -- SQL执行filter条件的顺序问题 (2)
• 2009/07/01 -- 分区表用哪个级别的统计信息? (2)
• 2009/06/25 -- oramon如何收集V$SYSTEM_EVENT数据? (3)
• 2009/06/25 -- oramon如何从V$SESSION收集性能数据? (0)
• 2009/06/24 -- oramon如何从V$SYSSTAT收集性能数据? (1)
• 2009/05/22 -- 从oramon新报警中受益 (1)
• 2009/05/21 -- 用oramon的数据进行报警 (3)
• 2009/05/19 -- 新版oramon正式上线 (4)
• 2009/05/08 -- 分析性能数据之二 (5)

    最新版本的SQLULDR2可以对六个字符进行转义处理, 指定的转义符本身, 单引号, 双引号, 回车符, 换行符及TAB键. 我们来测试一下, 在一个表的字段值插入这六个字符组成的字符串.

SQL> create table escape_test (col1 varchar2(100));

表已创建。

SQL> INSERT INTO ESCAPE_TEST VALUES ('''\"'||CHR(9)||CHR(13)||CHR(10));

已创建 1 行。

    然后用SQLULDR来导出, 需要指定ESCAPE选项.

D:\>sqluldr2 sys query="select * from system.escape_test" escape=\ quote='
      0 rows exported at 2009-10-27 09:14:46, size 0 MB.
      1 rows exported at 2009-10-27 09:14:46, size 0 MB.
        output file uldrdata.txt closed at 1 rows, size 0 MB.

    如果是巨量数据导出, 使用ESCAPE选项时性能可能会有很大的下降, 或者CPU的使用量会上升很多.

D:\>type uldrdata.txt
'\'\\\"\t\r\n'

    可以看到, 这六个字符全被转义了, 有了这个功能, 可以生成更好的CSV文件, 就可以始终用逗号分隔字符, 用换行分隔记录了, 不必费心地选择字符分隔符与记录分隔符了.

Relative Posts:

• 2009/10/26 -- SQLULDR2处理MySQL转义符 (1)
• 2009/08/31 -- SQLULDR2处理MySQL的空值 (2)
• 2009/10/30 -- SQLULDR2功能增加, 性能不减 (9)
• 2009/10/28 -- SQLULDR2生成Insert SQL语句 (4)
• 2009/04/02 -- 给SQLULDR2加上Key保护 (6)
• 2008/11/28 -- ociuldr还有可改进之处! (4)
• 2008/01/25 -- ociuldr更新(2008/01/25) (13)
• 2007/08/22 -- ociuldr的更新, 为了更好的long类型支持 (1)
• 2007/01/02 -- 在ociuldr的SQL中使用绑定变量 (4)
• 2009/11/07 -- MySQL数据迁移测试 (4)

SQL> select col1 from test;

COL
---
A\B

    继续测试了其他的一些不常见的字符作为转义符, 可是在几亿条记录中, 这些不常见的字符统统不可用. 这里我们有两个解决方法, 第一个是在源端替换, 使用Oracle的Replace函数, 如下所示:

SQL> select replace(COL1,'\','\\') as col1 from test;

COL1
----
A\\B

    使用REPLACE函数, 有些不方便, 要在SELECT的很多字段上都加上REPLACE函数, 性能影响自不必说, 改SQL也是一件麻烦的事情, 于是就使用第二种方法, 使用不可见的字符来做控制符, 比如Control + Z, 其ASCII代码是26, MySQL中用\Z表示. 用SQLULDR2导出记录时, 指定如下NULL选项.

NULL=0x1AN

    接下来在MySQL导入时, 指定转义符为\Z就可以了.

LOAD DATA ... ESCAPE BY '\Z' ...
LOAD DATA ... ESCAPE BY X'1A' ...

    如果用了不可见字符还不行, 即Oracle字段值中有不可见字符, 那就回到第一种方法吧.

Relative Posts:

• 2009/10/27 -- 将SQLULDR2转义符进行到底 (3)
• 2009/08/31 -- SQLULDR2处理MySQL的空值 (2)
• 2009/10/30 -- SQLULDR2功能增加, 性能不减 (9)
• 2009/10/28 -- SQLULDR2生成Insert SQL语句 (4)
• 2009/04/02 -- 给SQLULDR2加上Key保护 (6)
• 2008/11/28 -- ociuldr还有可改进之处! (4)
• 2008/01/25 -- ociuldr更新(2008/01/25) (13)
• 2007/08/22 -- ociuldr的更新, 为了更好的long类型支持 (1)
• 2007/01/02 -- 在ociuldr的SQL中使用绑定变量 (4)
• 2009/11/07 -- MySQL数据迁移测试 (4)

    第二种是差距(Difference)图.

    第二种是步线(Step)图.

    第二种是堆叠面积(Stacked Area)图.

    接下来要增加的是甘特(Gantt)图和拔号(Dial)图, 争取将DataReport做成指定数据的SQL来源就可以画出各种业务图的简易平台.

Relative Posts:

• 2009/07/28 -- DataReport增加JfreeChart支持 (7)
• 2009/07/25 -- DataReport的图片服务功能 (0)
• 2009/07/23 -- 更灵活的DataReport格式控制 (0)
• 2009/07/20 -- 解决Tomcat 6上的中文问题 (0)
• 2009/07/11 -- 持续改进DataReport报表程序 (2)
• 2009/07/08 -- DataReport的结果集合并 (0)
• 2009/06/30 -- DataReport的数据共享改进 (2)
• 2009/04/20 -- 设定WebChart多行值 (0)
• 2009/04/01 -- WebChart的颜色定制 (0)
• 2009/06/04 -- 如何打开WebChart的链接? (0)

    个人成就, 我们工作不外乎追求个人成就, 这个成就可以是赚到所需的钱, 让你的家庭过得很好, 得到别人的认同, 承认你的工作付出与工作效果, 或可以是得到名声, 让很多的人尊重你, 或是帮助了别人所得到的快乐感, 或是上面几种的一个综合体. 如果单以薪水收入来计算个人成就, 就扭曲了个人成就了, 如果你是打工者, 不论何种岗位, 都不可能比你的老板赚得多, 打工者就永远没有快乐与个人成就感吗? 多想想一个职业除薪水之外的可以让你有成就感的事情, 市场决定了公司里某个职位的薪水的上下震幅, 如果你的工作成绩不超出职位范围, 那么很难得到超过范围的薪水.

    个人价值, 企业用社会价值来换取财富, 个人用个人价值来换取薪水, 这一切都以价值为基础, 价值决定回报, 而不是职业决定回报, 不以价值决定回报的只是拥有超级资源的少数人, 你是那类少数人吗? 对于大多数人来讲都要努力创造额外价值, 以让自已更上一层楼. DBA只是一个工作的称呼而已, 但是我们常会想, 某某事不是DBA的职责范围, 而不去做, 不去创造更多的个人价值, 以至于有些人只认为导出和导入是DBA的事, 其他的都不是DBA这个职位的事, 找个人换掉当然也很容易了.

    工作职责, 不知道从何时起, DBA成了众多IT从业人员最向望的职业, 事情不多工资又高, 却实有些企事业单位就只需要这样的DBA, 但不是所有的单位都这样, 新兴行业及信息化的深入, 都对DBA提出了真真实实的技术要求, 你不可能也不会在一个企业做一辈子, 你允许, 企业也不允许, 或企业允许, 你也不会允许, 因此一定要考虑其他企业对于DBA的要求, 你才能被很多的企业接受. 这就要求你能承担更多的工作职责, 学会没事去找事做, 从实践中成长, 享受自已技术成长的乐趣. 人家找你做事时, 不要去想这是不是DBA做的事, 而是去想这事我能不能做得好, 达到人家的需求, 能达到就去做. 或者主动去了解其他人的需求, 看看能不能帮助他们, 别用什么职业应当做的圈子去死扣在自已头上.

    除了去关注人家的收入外, 多去看看人家在职业上的付出, 改变一下对个人成就的衡量标准, 努力在岗位上创造应有价值, 超出工作职责的范围去创造额外价值, 除了钱外, 个人的成长或与其他人一同成长, 更能给我们带来快乐.

Relative Posts:

• 2009/08/25 -- 关于技术积累的几点想法 (5)
• 2009/08/17 -- 努力创造DBA额外价值 (27)
• 2009/08/12 -- 个人价值决定个人回报 (9)
• 2009/08/04 -- DBA最缺的不是技术 (8)
• 2009/08/02 -- 当群众演员比干DBA还累 (9)
• 2007/01/18 -- 华为万件专利没有原创, 中国的DBA呢? (4)
• 2009/11/05 -- oramon新增三个性能数据 (3)
• 2009/09/08 -- 因丈母娘的需求而买房? (5)
• 2009/09/03 -- 收费有助于网购信用 (1)
• 2009/07/29 -- 域名解释与行人问路 (2)

    租房其实是一个不错的选择, 但目前没有以公司名义来出租房子的, 居住的权利得不到保证, 如果房东哪一天想卖房, 随时可以赶你走, 要想长期租房却没有法律保护, 因此也不能好好地改善自已的居住环境, 例如对房子进行装修, 生活质量就大打折扣, 为了和谐生活, 还是得自已买房. 政府搞的廉租房, 量太少了, 解决不了租房的问题, 没有公司来搞专业出租, 是因为买房来出租是不划算的, 是亏本的, 所以租房不能改善生活. 租房没有成体系, 是买房的一大动力.

    不是中国人喜欢存款, 都喜欢用钱投资, 以钱生钱的, 但目前可以投资的方法基本上只有两种: 股市和房产, 投资实业还没有这样的信用环境, 基本上都是被老板卷钱逃跑的命, 所以股市好时, 大量人涌入股市, 房子会不涨价, 股市不好时, 大量的人去炒房, 房市会涨价, 反正房价涨了, 对于税收, GDP及地方政府的业绩, 近期内都是好的, 加上近几年投资房产的都赚得流油, 如今至少能在水电煤依次呼叫着涨价的经济形势下, 让资金保值吧. 投资渠道的缺少, 是房价高的一大重要原因.

    有了小孩子后, 户口的重要性就提升了, 没有户口会给小孩的生活及上学带来众多的麻烦, 另外需要办个什么证明的, 或什么证的, 如出生证, 护照等, 没户口办起来就很麻烦, 很容易花个几千块钱才能拿到一张盖着萝卜章的纸, 成本其实很高, 小孩上个学, 没有房子要多交一定的赞助费, 等等. 为了户口, 为了小孩, 也得买个房子住.

    专家说的丈母娘的需求, 也是有一点的, 但没有那么重要. 到是中国自古以来养成的习惯意识, 会促使每个男人想去买房, 以给一个家庭安定的生活, 但这是一种动力, 不能成为房价高的原因. 如果非得说这是主要原因, 估计这专家曾被丈母娘逼过.

    以上几点, 都是小人物我的真实经历与想法, 但丈母娘的需求产生的影响很少, 其他三点大约起着相等的作用, 结婚时没有房, 是租房住的, 从没有对租的房子进行装修, 以改善居住水准. 小孩也要上学了, 也担心目前的依次涨价, 所以出手买房了, 而不是选择租房. 也说说你选择买房而非租房的理由吧,

Relative Posts:

• 2009/09/11 -- DBA有什么个人前途? (13)
• 2009/09/03 -- 收费有助于网购信用 (1)
• 2009/08/25 -- 关于技术积累的几点想法 (5)
• 2009/08/17 -- 努力创造DBA额外价值 (27)
• 2009/08/12 -- 个人价值决定个人回报 (9)
• 2009/08/04 -- DBA最缺的不是技术 (8)
• 2009/08/02 -- 当群众演员比干DBA还累 (9)
• 2009/07/29 -- 域名解释与行人问路 (2)
• 2009/07/24 -- 用户行为概率曲线 (0)
• 2009/07/22 -- 2009年日全食对网络交易的影响 (9)

    我经历过以下三种情况下的挂起, 第一种是在调用sqlplus时, 由于连接信息不对, 导致第一次不能登录数据库, sqlplus处于等待输入密码的阶段, 引起脚本挂起. 解决方法如下, 使用"-L"选项禁止出现密码输入提示.

sqlplus -L -s "/ as sysdba" << EOF
...
exit;
EOF

    第二个情况是, 用ssh去远程主机执行命令时, 和远程主机的ssh没有打通, 导致ssh也出现等待输出密码阶段, 引起程序挂起. 解决方法也是用选择禁用密码输入.

ssh -n -a -q -o NumberOfPasswordPrompts=0 …

    第三种情况是, 由于网络路由问题, 或其他网络服务问题, 引起网络IO一直等待. 解决的方法是要选择可控性比较强的脚本语言, 比如在Perl中(Linux/Unix)中, 就可以通过信号中断机制来处理挂起情形.

eval {
  local $SIG{ALRM} = sub { die "???\n" };
  alarm 20;
  可能会超时的任务代码;
  alarm 0;
};

    有其他的情况, 请共享出来, 好让大家少走弯路, 助人为快乐之本.

Relative Posts:

• 2009/11/07 -- MySQL数据迁移测试 (4)
• 2009/11/05 -- oramon新增三个性能数据 (3)
• 2009/10/30 -- SQLULDR2功能增加, 性能不减 (9)
• 2009/10/28 -- SQLULDR2生成Insert SQL语句 (4)
• 2009/10/27 -- 将SQLULDR2转义符进行到底 (3)
• 2009/10/26 -- SQLULDR2处理MySQL转义符 (1)
• 2009/09/21 -- 多支持了四种业务图 (0)
• 2009/08/31 -- SQLULDR2处理MySQL的空值 (2)
• 2009/07/28 -- DataReport增加JfreeChart支持 (7)
• 2009/07/25 -- DataReport的图片服务功能 (0)

    网上购物, 我们看重网购信用, 但又不相信网购信用. 那么多卖家在炒作网购信用, 说明很看重网信用, 也有很多的人想炒高了网购信用去骗人一把, 又让人不得不去怀疑网购信用, 所以支付宝的担保交易在网购中很吃香. 建设一个良好的信用炒作预防系统, 也只能发挥一点点的作用, 因为获取网购信用, 及失去网购信用的成本都不高.

    因为在网上成交并没有额外付出成本, 所以任何卖家可以无限制地去炒作网购信用, 所需要的成本只是找到一个比防信用炒作系统更高明的方法而已, 不被发现我就可以快速重新获得网购信用. 网购信用失去了, 注册一个帐号, 再去炒就行了.

    在防信用炒作系统建设方面, 目前看来永远是道高一尺, 魔高一丈, 实在只能发挥有限的作用. 由于网购信用获得成本过低, 导致了网上信用失去的成本也很低, 因此网购信用可以被任意地一次一次地重新摧毁和重新建设. 导致了积累的网购信用信息很难被人认可, 发挥出应用的价值.

    落后的地方, 网上的信用一般会较差, 网下的信用会较好, 比如, 向农村的商店去赊商品, 就不会这么不讲信用, 因为你不讲信用, 后面就赊不到了, 同村的其他商店也不会赊给你, 以后有困难时向人借钱也会很难. 这种情况下失去网下的信用, 所付的成本就比较大.

    从整个世界来看, 服务收费的地方, 信用都比较好, 而服务免费的地方, 信用都比较差, 网络购物平台只是为大量的网民提供服务的一个平台, 因此要解决网购信用, 按成交收费, 也是一个很重要的手段, 增加信用炒作的成本, 使人们更珍惜网购信用.

Relative Posts:

• 2009/09/11 -- DBA有什么个人前途? (13)
• 2009/09/08 -- 因丈母娘的需求而买房? (5)
• 2009/08/25 -- 关于技术积累的几点想法 (5)
• 2009/08/17 -- 努力创造DBA额外价值 (27)
• 2009/08/12 -- 个人价值决定个人回报 (9)
• 2009/08/04 -- DBA最缺的不是技术 (8)
• 2009/08/02 -- 当群众演员比干DBA还累 (9)
• 2009/07/29 -- 域名解释与行人问路 (2)
• 2009/07/24 -- 用户行为概率曲线 (0)
• 2009/07/22 -- 2009年日全食对网络交易的影响 (9)

ICOL$,TABLE,4
CON$,TABLE,
UNDO$,TABLE,
C_COBJ#,CLUSTER,
PROXY_ROLE_DATA$,TABLE,
......

    用mysqlimport导入数据时, 第三列上的空值(Oracle中)导入到MySQL中时, 就不是空值(NULL)了, 而是长度为0的字符串, 如果导入到数字类型中, 则全变成0, 很显然这不是我们想要的结果. mysqlimport在默认情况下, 会将\N处理成NULL值, 因此从Oracle导出成文本时, 需要将空值处理一下, 以方便在MySQL中准确导入.

ICOL$,TABLE,4
CON$,TABLE,\N
UNDO$,TABLE,\N
C_COBJ#,CLUSTER,\N
PROXY_ROLE_DATA$,TABLE,\N
......

    在使用SQLULDR2时, 指定NULL命令行选项即可, 如下所示.

SQLULDR2 sys QUERY=tab NULL=\N

    前几天还在想SQLULDR2都这么多命令行选项了, 应当齐了吧, 没想到又多了一个用户需求导致的命令行选项. 用户需求真是值得我们好好研究.

Relative Posts:

• 2009/10/27 -- 将SQLULDR2转义符进行到底 (3)
• 2009/10/26 -- SQLULDR2处理MySQL转义符 (1)
• 2009/10/30 -- SQLULDR2功能增加, 性能不减 (9)
• 2009/10/28 -- SQLULDR2生成Insert SQL语句 (4)
• 2009/04/02 -- 给SQLULDR2加上Key保护 (6)
• 2008/11/28 -- ociuldr还有可改进之处! (4)
• 2008/01/25 -- ociuldr更新(2008/01/25) (13)
• 2007/08/22 -- ociuldr的更新, 为了更好的long类型支持 (1)
• 2007/01/02 -- 在ociuldr的SQL中使用绑定变量 (4)
• 2009/11/07 -- MySQL数据迁移测试 (4)

    基础知识积累, 这一点大伙都没有疑问, 并且谁都很重视, 例如努力阅读技术资料, 积极与人讨论, 上ITPub阅读技术贴子, 参加技术培训等, 都是基础知识积累的有效手段. 有个一年半载的时间, 可以将基础知识学得比较扎实, 可以将DBA的常规工作做得非常好了.

    实践经验积累, 这部份是经过亲自实践的那部份基础知识的集合, 加上在运用基础知识的过程中措索出来的有效解决问题的方法或思维模式的结合体. 这部份其实并没有超出基础知识的范畴, 经常会发现, 一个问题得到解决的手段是靠很基础的知识点, 单独拎出来的话, 绝对是考100分的那种, 但往往解决问题的人不是你. 因此我也认为只完成了基础知识积累是不够的, 还必须经过一层有效的转换, 能够确实去解决问题.

    用户需求积累, 学习技术后最大的乐趣是去帮助别人, 一种是去教导别人, 还有一种是去解决用户的需求. 既然解决需求是技术的最终目的, 那么我们就要去积累用户的需求, 根据用户的需求深化技术领域, 学以致用比较重要. 对于这一点体会比较深刻的是文本导出工具, 居然前前后后历时三年, 还有新的用户需求出来, 不是因为什么OCI编程的基础知识积累驱动了我, 而是用户需求驱动我去持续维护.

    工具脚本积累, 要轻构地发挥DBA价值, 就要有称手的利器, 脚本和工具就是称手的利器. 在DBA的领域里, 虽然有很多前辈们写的现成脚本或工具, 但出自国内的DBA之手的工具还很少, 国内的DBA还是需要关注这一点, 这方面和国外DBA的差距不是一点的大, 虽然我们的基础知识及实践经验比他们丰富, 对比工作过的一个外资公司和一个国内公司, 在工具方面的差别有点让我震憾. SQLULDR, WebChart及oramon为我的DBA工作提供了很大的方便, 让我可以比其他DBA更快更好地了解所要管理的系统的运行特点.

    以上是个人对自身技术积累的一点总结, 希望对大家有点帮助.

Relative Posts:

• 2009/09/11 -- DBA有什么个人前途? (13)
• 2009/08/17 -- 努力创造DBA额外价值 (27)
• 2009/08/12 -- 个人价值决定个人回报 (9)
• 2009/08/04 -- DBA最缺的不是技术 (8)
• 2009/08/02 -- 当群众演员比干DBA还累 (9)
• 2007/01/18 -- 华为万件专利没有原创, 中国的DBA呢? (4)
• 2009/11/05 -- oramon新增三个性能数据 (3)
• 2009/09/08 -- 因丈母娘的需求而买房? (5)
• 2009/09/03 -- 收费有助于网购信用 (1)
• 2009/07/29 -- 域名解释与行人问路 (2)