天道酬勤

前几天有朋友问在DBCA的时候有没有碰到如下类似的错误：

$ dbca
/u01/app/oracle/jre/1.1.8/bin/../lib/i686/native_threads/libzip.so: symbol errno,
version GLIBC_2.0 not defined in file libc.so.6 with link time reference (libzip.so)
Unable to initialize threads: cannot find class java/lang/Thread
Could not create Java VM

我已记不清安装oracle多少次了，但记忆中好像没有遇到过，难道是我运气太好每次都设对了LD_ASSUME_KERNEL参数，做技术的不仅要知其然，而且还要知其所以然，故在metalink上一顿疯狂search，可以参考下面的文档。
Doc ID:243979.1      Doc ID:377217.1      Note:443475.1

这些文档适用于linux 2.4的内核，下面来看看关于LD_ASSUME_KERNEL变量的解释：

Kernel 2.4 comes with a i686 optimized glibc package. The optimized glibc package contains two versions of the libc itself, one with and one without “floating stack” support. Which one an application picks up depends on the setting of the environment variable LD_ASSUME_KERNEL. If this is set to “2.2.5″ the application will use the lib without “floating stack”. Some older java versions do not work correctly if the glibc “floating stack” is used. As a result, “universal installer” and some utilities as “database configuration assistant” will not work if the glibc “floating stack” is activated. On Sues SLES8 for Oracle to scale well, this variable must be set. With a glibc with “floating stack” support Oracle scales significantly worse (number of users) than without (several thousand vs. less than 1000 users in tests).

Read the rest of this entry »

以前安装完oracle，在用DBCA创建数据库时，在配置了一系统列参数之到了最后点”完成”的时候，创建画面异常消失没了任何反映，以前用在网上找到的方法解决如下：
Case：JRE 的版本不对, Oracle 一般使用的JRE是1.1.8到$ORACLE_BASE/jre 目录下，发现Oracle本身已经有1.3.1版的JRE
#ls $ORACLE_BASE/jre
1.1.8/ 1.3.1/
Fix：只要改变一下链接使用1.3.1的JRE就可以了。（可以查看dbca的script）

   1. #rm $ORACLE_HOME/JRE    (此JRE目录是1.1.8 的符号链接)
   2. #ln -s $ORACLE_BASE/jre/1.3.1  $ORACLE_HOME/JRE
   3. #cd $ORACLE_BASE/jre/1.3.1/bin
   4. #ln -s $ORACLE_BASE/jre/1.3.1/bin/.java_wrapper   jre
       OR: #ln -s Java jre
   5. #cd i386/native_threads
   6. #ln -s java  jre

完成以上步骤后再启动dbca问题就解决了。

Read the rest of this entry »

说说08年的一个案例，Oracle的高级复制，尽管现在大家都不用了。公司扩大业务，在HB建了分公司，要将SZ这边的一部分数据（其实有一千多张表）同步到HB，在配置好高级复制之后测试，由于要复制的数据量增长比较快，以至于表空间飞快增长，当我们想要停止和删除复制环境的时候，就被挂起，google的很多文章都不见效，最后救助Oracle TS解决，以下是解决方案：

SOLUTION / ACTION PLAN
To implement the solution, please execute the following steps:

For each of the 5 groups,just do the actions one by one.
1. if posible,please stop the application for a while. But do not stop the resouce oracle using
(including network,listener,etc)

2. Stop all the replication push and purge job. Stop current running push&purge job first.note:
1)in 2 sites,run the whole step 2
2)no special comments, all user please use ‘repadmin’

2.1 Check if the push job is currently running

1
2
3
4
5
6

sql>select /*+ ORDERED */ j.job, j.sid, d.dblink,
SUBSTR(TO_CHAR(J.THIS_DATE,'MM/DD/RRRR HH24:MI:SS'),1,20) START_DATE
FROM defschedule d, dba_jobs_running j
WHERE j.job IN (SELECT job FROM dba_jobs
WHERE UPPER(what) LIKE '%DBMS_DEFER_SYS.PUSH%')
AND j.job = d.job;

       JOB SID DBLINK START_DATE
       ---------- ---------- ------------------------------
        44 9 DB2.WORLD 05/16/2002 12:14:47

Read the rest of this entry »

方法来自Piner的新书《构建Oracle高可用环境》
1.先增加一个字段

sql>Alter TABLE TABLE_NAME ADD field_name NUMBER;

2.把该字段修改为有默认值

sql>Alter TABLE TABLE_NAME MODIFY field_name DEFAULT 0;

该语句并不修改以前的记录，只是标记以后的记录将会有默认值0,所以，这个语句的执行很快，不会引发阻塞。
3.修改以前的记录，让其有默认值（每修改1000条记录 commit一次）

1
2
3
4
5
6
7
8
9
10
11
12

DECLARE
       row_num NUMBER := 0;
BEGIN
       FOR c_test IN (SELECT ROWID rid FROM table_name t WHERE field_name IS NULL) LOOP
             UPDATE table_name t SET t.field_name = 0 WHERE ROWID = c_test.rid;
             row_num := row_num + 1;
             IF MOD(row_num,1000) =0 THEN
                  COMMIT;
             END IF;
        END LOOP;
        COMMIT;
END;