July 2009 Archives

解决Diana Nodes限制一例(续)

| No Comments

在《解决Diana Nodes限制一例》一文中,我在文章末尾提到----"这里我猜是PL/SQL Developer自身的问题,也就是说PL/SQL Developer还是沿用了8.1.3之前的3000行代码的限制。"。

 

当时我以为我找到了问题的真相,其实还差的远这里根本就不是PL/SQL Developer的问题

 

我们来看一下问题的真相是什么:

这里PL/SQL Developer在编译PCK_SAL_VFY_BATCH_RELEASE这个package body的时候为什么会报错"PLS-123 Program too large(Diana Nodes)"是因为Bug 5936020,这个bug10.2.0.4里已经被修正

 

具体来说是这样:

PL/SQL Developer默认在编译的时候是会带上debug选项的,也就是说PL/SQL Developer默认在编译package body的时候实际上是相当于执行了alter package packagename compile debug body,这个时候如果你的数据库的版本是10.2.0.4以下,那么当package body里的代码量到一定程度后很可能就会编译不过了,这时候会报错PLS-123 Program too large(Diana Nodes),但其实这个时候并没有达到Diana Nodes的上限。

 

解决方法有三个:

1、使用我在解决Diana Nodes限制一例》中提到的不带debug选项的方式编译,但用这种方式的缺陷在于编译好的package body不能debug进去了,这个对于开发人员来说通常是不可接受的:

SQL> conn ipra/acca@ipradev;

Connected to Oracle Database 10g Enterprise Edition Release 10.2.0.1.0

Connected as ipra

 

SQL> alter package PCK_SAL_VFY_BATCH_RELEASE compile debug body;

 

Warning: Package body altered with compilation errors

 

SQL> select text from sys.all_errors where name='PCK_SAL_VFY_BATCH_RELEASE';

 

TEXT

--------------------------------------------------------------------------------

PLS-00123: program too large (Diana nodes)

 

SQL> alter package PCK_SAL_VFY_BATCH_RELEASE compile body;

 

Package body altered

 

SQL> select text from sys.all_errors where name='PCK_SAL_VFY_BATCH_RELEASE';

 

TEXT

--------------------------------------------------------------------------------

 

SQL> select debuginfo,object_name,object_type from sys.all_probe_objects where object_name='PCK_SAL_VFY_BATCH_RELEASE';

 

DEBUGINFO OBJECT_NAME                    OBJECT_TYPE

--------- ------------------------------ -------------------

F         PCK_SAL_VFY_BATCH_RELEASE      PACKAGE BODY

F         PCK_SAL_VFY_BATCH_RELEASE      PACKAGE

 

2、升级数据库到10.2.0.4

如果是10.2.0.4,一模一样的代码编译的时候则不会报错

SQL> conn caipra/acca@ipratest;

Connected to Oracle Database 10g Enterprise Edition Release 10.2.0.4.0

Connected as caipra

 

SQL> alter package PCK_SAL_VFY_BATCH_RELEASE compile debug body;

 

Package body altered

 

SQL> select text from sys.all_errors where name='PCK_SAL_VFY_BATCH_RELEASE';

 

TEXT

--------------------------------------------------------------------------------

 

SQL> select debuginfo,object_name,object_type from sys.all_probe_objects where object_name='PCK_SAL_VFY_BATCH_RELEASE';

 

DEBUGINFO OBJECT_NAME                    OBJECT_TYPE

--------- ------------------------------ -------------------

T         PCK_SAL_VFY_BATCH_RELEASE      PACKAGE BODY

T         PCK_SAL_VFY_BATCH_RELEASE      PACKAGE

 

SQL> alter package PCK_SAL_VFY_BATCH_RELEASE compile body;

 

Package body altered

 

SQL> select debuginfo,object_name,object_type from sys.all_probe_objects where object_name='PCK_SAL_VFY_BATCH_RELEASE';

 

DEBUGINFO OBJECT_NAME                    OBJECT_TYPE

--------- ------------------------------ -------------------

F         PCK_SAL_VFY_BATCH_RELEASE      PACKAGE BODY

T         PCK_SAL_VFY_BATCH_RELEASE      PACKAGE

 

3、将编译出错的package body拆分成小的package body的组合,这时候在PL/SQL Developer里编译的时候(debug)就不会报Diana Nodes的错误了。

解决Diana Nodes限制一例

| 3 Comments

有同事今天过来找我说"我的一个package body(PCK_SAL_VFY_BATCH_RELEASE)PL/SQL Developer里编译不过,报错PLS-123 Program too large(Diana Nodes)"。

 

要想解决上述问题,我们需要了解oracle里存储过程在compile的时候会做什么事情。

 

在"Oracle 10gR2 PLSQL User's Guide and Reference"的附录C里提到:

PL/SQL is based on the programming language Ada. As a result, PL/SQL uses a variant of Descriptive Intermediate Attributed Notation for Ada (DIANA), a tree-structured intermediate language. It is defined using a meta-notation called Interface Definition Language (IDL). DIANA is used internally by compilers and other tools.

At compile time, PL/SQL source code is translated into machine-readable m-code.

Both the DIANA and m-code for a procedure or package are stored in the database. At run time, they are loaded into the shared memory pool. The DIANA is used to compile dependent procedures; the m-code is simply executed.

也就是说oracle里存储过程编译的时候,会形成一种树状的结构,这种树状结构上的节点就是Diana Nodes,存储过程里的一行代码大概会产生510Diana Nodes,这个Diana Nodes的总数在oracle里是有上限的。

 

8.1.3以前,这个Diana Nodes上限的范围是16K32K,也就是相当于是3000行代码,这就是很多朋友都知道的oracle里存储过程的代码的行数限制。

 

这个3000行代码的限制显然是不够的,oracle也意识到这个问题,于是在8.1.3以后package bodytype bodyDiana Nodes的限制被放宽到67108864,也就是相当于600万行代码。

 

好了,罗嗦了这么多,回到我同事提到的那个问题。

上述库是10.2.0.1,且又是package body,按道理讲是不应该碰到Diana Nodes的问题的。

我们来看一下:

SQL> SELECT * FROM user_object_size WHERE name = 'PCK_SAL_VFY_BATCH_RELEASE';

 

NAME      TYPE          SOURCE_SIZE PARSED_SIZE  CODE_SIZE ERROR_SIZE

------------------------------ ------------- ----------- ----------- ---------- ----------

PCK_SAL_VFY_BATCH_RELEASE   PACKAGE  22217  12984      62446          0

PCK_SAL_VFY_BATCH_RELEASE  PACKAGE BODY  149105  0        0         42

我们从结果里看到确实PCK_SAL_VFY_BATCH_RELEASEpackage body在编译的时候报错了。

 

SQL> select count(*) from dba_source where name='PCK_SAL_VFY_BATCH_RELEASE' and type='PACKAGE BODY';

 

  COUNT(*)

----------

      3177

上述package body的代码行数只有3177行,远小于600万行的限制,按道理讲是不应该出现Diana Nodes这方面的错误的。

 

这里我猜是PL/SQL Developer自身的问题,也就是说PL/SQL Developer还是沿用了8.1.3之前的3000行代码的限制。

 

好了,我们来验证一下:

这里我不用PL/SQL Developer来编译,换成由sqlplus来编译:

C:\Documents and Settings\cuihua>sqlplus /nolog

 

SQL*Plus: Release 10.2.0.1.0 - Production on 星期三 7 22 12:10:30 2009

 

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

 

SQL> conn ipra/acca@ipradev;

已连接。

 

SQL> alter package PCK_SAL_VFY_BATCH_RELEASE compile body;

 

程序包体已变更。

 

SQL> SELECT * FROM user_object_size WHERE name = 'PCK_SAL_VFY_BATCH_RELEASE';

 

NAME      TYPE          SOURCE_SIZE PARSED_SIZE  CODE_SIZE ERROR_SIZE

------------------------------ ------------- ----------- ----------- ---------- ----------

PCK_SAL_VFY_BATCH_RELEASE   PACKAGE  22217  12984      62446          0

PCK_SAL_VFY_BATCH_RELEASE  PACKAGE BODY  149105  0   201859          0

现在我们从结果里可以看到,PCK_SAL_VFY_BATCH_RELEASEpackage body现在已经能编译通过了。

 

总结一下:

以后在package body或者type body里编译的时候碰到PLS-123 Program too large(Diana Nodes)这种错误的时候,就用sqlplus编译。

某公司招聘数据库方面的售前

| 2 Comments

替家属发文招聘,有兴趣的朋友可以尝试一下。

 

某公司招聘数据库方面的售前,这家公司是一家大的外企(500强之一),工作地点是在上海,要求如下:

1、有5年以上的工作经验,最好是能有售前的经验

2、要是oracle数据库方面的高手,技术要好,最好能有这方面的售后经验

3、英语要过得去

 

上述职位的薪水范围是一年30万至50万,有兴趣的朋友可以和 frances8552@hotmail.com 联系。

解决dbconsole不能启动一例

| No Comments

今天一台AIX 64上的10.2.0.4dbconsole启动不了了。

对于这种dbconsole不能启动的问题,549079.1中有很详细的描述。

 

如下是我今天解决上述问题的全过程:

 

我首先执行了emctl start dbconsole,屏幕中报错:

ps: 0509-048 Flag -o was used with invalid list.
ps: Not a recognized flag: -
Usage: ps [-ANPaedfklmMZ] [-n namelist] [-F Format] [-o specifier[=header],...]
[-p proclist][-G|-g grouplist] [-t termlist] [-U|-u userlist] [-c classlist] [ -T
pid] [ -L pidlist]
Usage: ps [aceglnsuvwxU] [t tty] [processnumber]

 

这个在758568.1有相应的解决方法:

$ORACLE_HOME/bin/emctl.pl中的第1314行和第1605行的

my $ps=`ps -p $PID -o cmd --cols 1000 |grep DEMDROOT`;

修改为

my $ps=`ps -p $PID -o args | grep DEMDROOT`;

 

修改完后保存并重启dbconsole,但这时候dbconsole依然起不来,同时emdb.nohup中记录的错误信息为:

09/07/20 11:30:06 Error starting ORMI-Server.  Unable to bind socket: The socket name is already in use.

 

这个时候尝试停止dbconsole,会报如下错误:

$ emctl stop dbconsole

Oracle Enterprise Manager 10g Database Control Release 10.2.0.4.0 

Copyright (c) 1996, 2007 Oracle Corporation.  All rights reserved.

https://p690ca:1158/em/console/aboutApplication

Stopping Oracle Enterprise Manager 10g Database Control ...

--- Failed to shutdown DBConsole Gracefully ---

 failed.

这种错误很容易解决,在OS上把带关键字"oc4j"和"dbconsole"的进程都杀掉,然后重新依次执行emctl stop agentemctl stop dbconsole就可以了。

 

按上述做法做完后dbconsole还是起不来,同时emagent.trc中记录的错误信息为:

2009-07-20 13:28:27 Thread-1839 ERROR ssl: nzos_Handshake failed, ret=29024

2009-07-20 13:28:27 Thread-1839 ERROR http: 9: Unable to initialize ssl connection with server, aborting connection attempt

2009-07-20 13:28:27 Thread-1839 ERROR pingManager: nmepm_pingReposURL: Cannot connect to https://p690ca:1158/em/upload/: retStatus=-1

 

这个在749243.1中有相应的解决方法:

首先执行下述命令:

$ emctl unsecure dbconsole

Oracle Enterprise Manager 10g Database Control Release 10.2.0.4.0 

Copyright (c) 1996, 2007 Oracle Corporation.  All rights reserved.

http://p690ca:1158/em/console/aboutApplication

Configuring DBConsole for HTTP...   Done.

DBConsole is already unsecured.

 

然后执行:

$ emctl secure dbconsole

Oracle Enterprise Manager 10g Database Control Release 10.2.0.4.0 

Copyright (c) 1996, 2007 Oracle Corporation.  All rights reserved.

http://p690ca:1158/em/console/aboutApplication

Enter Enterprise Manager Root password :

Enter a Hostname for this OMS : p690ca

 

DBCONSOLE already stopped...   Done.

Agent successfully stopped...   Done.

Securing dbconsole...   Started.

Checking Repository...   Invalid Password.

这里oracle提示让我输入Enterprise Manager Root用户的密码,其实就是让我输入sysman的密码,我记得这个库的sysman的密码就是oracle,但当我输入oracle后这里提示我密码不对。

 

这种问题的解决方法很简单,只需要去改如下两个地方就可以了:

1、以sys用户登陆后把sysman用户的密码改为oracle

2、执行emctl setpasswd dbconsolesysman用户的密码oracle登记到emoms.properties中去,如下所示:

$ emctl setpasswd dbconsole

Oracle Enterprise Manager 10g Database Control Release 10.2.0.4.0 

Copyright (c) 1996, 2007 Oracle Corporation.  All rights reserved.

http://p690ca:1158/em/console/aboutApplication

Please enter new repository password:

Repository password successfully updated.

 

执行完上述两步后,现在可以执行emctl secure dbconsole了:

$ emctl secure dbconsole

Oracle Enterprise Manager 10g Database Control Release 10.2.0.4.0 

Copyright (c) 1996, 2007 Oracle Corporation.  All rights reserved.

http://p690ca:1158/em/console/aboutApplication

Enter Enterprise Manager Root password :

Enter a Hostname for this OMS : p690ca

 

DBCONSOLE already stopped...   Done.

Agent is already stopped...   Done.

Securing dbconsole...   Started.

Checking Repository...   Done.

Checking Em Key...   Done.

Checking Repository for an existing Enterprise Manager Root Key...   Done.

Fetching Root Certificate from the Repository...   Done.

Updating HTTPS port in emoms.properties file...   Done.

Generating Java Keystore...   Done.

Securing OMS ...   Done.

Generating Oracle Wallet Password for Agent....   Done.

Generating wallet for Agent ...    Done.

Copying the wallet for agent use...    Done.

Storing agent key in repository...   Done.

Storing agent key for agent ...   Done.

Configuring Agent...

Configuring Agent for HTTPS in DBCONSOLE mode...   Done.

EMD_URL set in /u01/app/oracle/product/10.2.0/p690ca_ipratest/sysman/config/emd.properties

   Done.

Configuring Key store..   Done.

Securing dbconsole...   Sucessful.

 

执行完上述步骤后,dbconsole现在终于可以起来了:

$ emctl start dbconsole

Oracle Enterprise Manager 10g Database Control Release 10.2.0.4.0 

Copyright (c) 1996, 2007 Oracle Corporation.  All rights reserved.

https://p690ca:1158/em/console/aboutApplication

Starting Oracle Enterprise Manager 10g Database Control .............. started.

------------------------------------------------------------------

Logs are generated in directory /u01/app/oracle/product/10.2.0/p690ca_ipratest/sysman/log

 

感觉dbconsole的相关问题弄起来还是挺麻烦,有兴趣的朋友可以仔细去看一下549079.1

解决undo global data等待一例

| 5 Comments

今天bing问我"v$sessionsidactive,v$processv$transaction 均能查到spid和相应的事务,但是在OSps -ef却查不到process了,此时如何干掉该session现在手工杀session,session已不存在"

 

这个问题在Bug 6955824里也有相类似描述:

Customer killed the OS process attatched to the oracle process first using  'kill -9' command. Then he tried killing the session from the database using 'alter system kill session' command but got the error ora-30. The killed session status was ACTIVE in v$session after following the above  procedure. The killed session blocked many transactions. PMON has not cleaned up the killed session for hours and customer has at last bounced the database to resolve the problem.

这个session必须要杀掉(它锁定了一部分数据,堵塞了相关操作),但bing的这个数据库是7*24小时的,又不允许重启。

 

这个sessionsid780

 

首先执行了一下select event from v$session_wait where sid=780 返回的结果是undo global dataundo global data控制串行化访问sgaundo block的一个latchbing的这个库是9.2.0.8

 

接着我让bing查了一下v$latchholder,发现没有process持有上述latch

去查了一下metalinkmetalink上推荐的方法就是重启数据库:)

 

怎么办?

 

吃饭的时候我就一直在琢磨这个问题,等快吃完的时候就有了处理的思路,赶紧回到座位上,如下是我跟bing之间的MSN的聊天记录:

2009-7-17  12:44:31    bing  我还有这样的想法,你看看是否可行:

2009-7-17  12:44:34  bing    说说听听

2009-7-17  12:45:22    bing  v$latchholder既然没有process hold undo global data

2009-7-17  12:45:54    bing  就说明并不是某个process阻塞了780

2009-7-17  12:46:17    bing  在这种情况下:

2009-7-17  12:46:49    bing  因为undo global data是控制串行化访问sgaundo block一个latch

2009-7-17  12:47:05    bing  sga有关

2009-7-17  12:47:35    bing  那就说明是sga可能有问题了

2009-7-17  12:48:04    bing  那么我们强制刷一下sga 

2009-7-17  12:48:19    bing  即执行alter session set events 'immediate trace name flush_cache level 1'

2009-7-17  12:49:02  bing    这是刷新buffer cache

2009-7-17  12:49:04    bing  oracle先把所有buffer cache里的东西刷到data file上去

2009-7-17  12:49:31    bing  是呀

2009-7-17  12:50:01    bing  相当于清理一下buffer cache

2009-7-17  12:50:25    bing  undo global data这个latch是在buffer cache

2009-7-17  12:52:04    bing  这样刷一下后780必然要重新去获得undo global data这个latch,说不定这时候就可以了

2009-7-17  12:52:21    bing  因为并没有process hold这个latch

2009-7-17  12:52:37  bing    刷新完之后,780会自动消失了?

2009-7-17  12:52:52    bing  有可能

2009-7-17  12:53:35    bing  你这个库的buffer cache有多大?现在这个库忙吗?

2009-7-17  12:54:56    bing  如果很忙的话刷buffer cache对应用是有影响的

2009-7-17  12:55:14  bing    现在这库不忙

2009-7-17  12:55:27    bing  那可以刷一下

2009-7-17  12:55:37  bing    Buffer Cache: 10,752M

2009-7-17  12:55:59    bing  如果能行的话就不用重启了

2009-7-17  12:56:15  bing    10g左右

2009-7-17  12:57:07    bing  我觉得重启是在实在没有办法的情况下做的事情

2009-7-17  12:57:19    bing  而且你这个系统还不允许重启

2009-7-17  12:58:29  bing    10gbuffer cache会不会导致库hang住呢

2009-7-17  12:59:24    bing  恩,有可能会

2009-7-17  12:59:51  bing    呵呵,buffer cache刷完了

2009-7-17  13:00:12    bing  哦,现在780还在吗?

2009-7-17  13:00:18  bing    正在看

2009-7-17  13:00:59  bing    780 没了,偶也~~~~~~~~~~~~~~`

2009-7-17  13:01:05    bing  :)

 

在生产库上刷10Gbuffer cache,对我来说也还是头一次。

关于distributed transaction

| 5 Comments

有朋友问我"带dblinkquery会起一个transaction吗?"

我说会呀。

他接着问"那为什么我在PL/SQL Developercommand window中执行一个带dblinkquery后,PL/SQL Developer的工具栏上的标识transaction的按钮'commit'和'rollback'没有高亮显示呢?"。

----我们知道,当你在PL/SQL Developercommand window中执行一个transaction的时候,如果你没有commit或者rollback,其工具栏上的标识transaction的按钮'commit'和'rollback'是一直会高亮显示的。

 

我试了一下,还真是这样。

不可能呀,在我印象里,dblinkquery一定会起一个distributed transaction

 

我来证明给大家看。

不用PL/SQL Developercommand window了,直接用sqlplus,开两个session,分别为session 1session 2

 

先在session 1中删除表uplbth中的一条记录:

Session 1

SQL> delete from uplbth where ubtbth='HPCAN081200010';

 

已删除 1 行。

 

接着在session 2中也做同样的删除动作,只不过在执行删除前先执行一个带dblinkquery语句:

Session 2

SQL> select count(*) from uplbth@caipratest;

 

  COUNT(*)

----------

        36

 

SQL> delete from uplbth where ubtbth='HPCAN081200010';

delete from uplbth where ubtbth='HPCAN081200010'

            *

1 行出现错误:

ORA-02049: timeout: distributed transaction waiting for lock

 

session 2大概等待了一分钟后,oracle这里报错ORA-02049这就是最好的证明,如若"select count(*) from uplbth@caipratest"不起一个distributed transaction的话,session 2是会一直等待下去的

这里为什么会等待一分钟,是因为distributed_lock_timeout的值是60(这也是默认值)。

 

好了,我们这里再来看一下为什么在PL/SQL Developercommand window中做同样的事情,session 2就会一直等待session 1

 

我感觉这是因为在session 2中执行"select count(*) from uplbth@caipratest"的时候PL/SQL Developer人为的commit了一下。

 

好了,我们来做一个10046验证一下。

打开一个PL/SQL Developercommand window,执行"select count(*) from uplbth@caipratest",执行完了看一下产生的trace文件:

XCTEND rlbk=1, rd_only=1

WAIT #0: nam='SQL*Net message to dblink' ela= 1 driver id=675562835 #bytes=1 p3=0 obj#=-1 tim=31020960699684

WAIT #0: nam='SQL*Net message from dblink' ela= 436 driver id=675562835 #bytes=1 p3=0 obj#=-1 tim=31020960700143

WAIT #0: nam='SQL*Net message to client' ela= 0 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=31020960700211

WAIT #0: nam='SQL*Net message from client' ela= 16592 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=31020960716827

=====================

PARSING IN CURSOR #1 len=61 dep=0 uid=56 oct=47 lid=56 tim=31020960716966 hv=356401299 ad='78651b38'

begin :id := sys.dbms_transaction.local_transaction_id; end;

在产生的trace文件里,我们看到了XCTEND rlbk=1, rd_only=1,这表示"select count(*) from uplbth@caipratest"已经用到了回滚段了,也就是产生了一个transaction,并且这个transactionread only的。

 

但我并没有从trace文件中看到显式的commit语句,估计是PL/SQL Developerbegin :id := sys.dbms_transaction.local_transaction_id; end;做了这样的事情。

对eygle推荐的一篇文章的解释

| No Comments

eygle"使用errorstack跟踪ORA-01438错误"这篇文章里,推荐了itpub上一篇文章----"一次ora-01438错误的处理",我去看了这篇文章。

 

看到itpub上有很多朋友不知道写这篇文章的人的想法,我看上面很多朋友都觉得是高深莫测。

 

呵呵,其实是很简单的问题,我来解释一下eygle推荐的那篇文章里所谓的两个高深莫测的地方: 

1、为什么搜索的字符串变成了"2E313133 02C10604 C8C6BBC9 014D0252 48023130 0433F3FF"

答:因为他的系统是redhat 4 64bit,是little endian,所以要颠倒过来。这里的颠倒过来倒不是说oracleblock内会颠倒过来存,而是指oracle在内存里会颠倒存。比如如下的例子:

比如对于一个number(24)的整数123456789123456789123456,在little endian的操作系统里,block内部oracle还是会存成CC 0D 23 39 4F 5C 18 2E 44 5A 0D 23 39,只不过对于上述操作系统而言,oracle在内存里会这么存:

Dump of memory from 0x0792DFE8 to 0x0792E450
792DFE0                   00010000 000AE94F        

792DFF0 00000000 00000000 00000000 00000000

792E000 00000000 00000000 39230DCC 2E185C4F

792E010 230D5A44 00000039 00000000 00000000 

792E020 00000000 00000000 00000000 00000000 

即按照4byte为一组,每组里高位跟低位颠倒

 

如果是AIX,则oracle在内存里不会颠倒,因为AIXbig endian。比如同样对于上述值,在AIXoracle在内存里会这样存:

Dump of memory from 0x000000011067B670 to 0x000000011067BB80

11067B670 00010000 EDD5FBB0 00090000 00000000

11067B680 00000000 00000000 00000000 00000000

11067B690 CC0D2339 4F5C182E 445A0D23 39000000

11067B6A0 00000000 00000000 00000000 00000000

 

2、他在文中提到"本值在数据库中定义为number(8)类型,但从结果来看,系统把这个值当成了number(24)类型",很多朋友不明白为什么这里是number(24)

答:这是因为上述trace文件里记录的值是"3331312E 0406C102 C9BBC6C8 52024D01 30310248 00003304"我们来还原一下这个值

SQL> select utl_raw.cast_to_number(hextoraw('3331312E0406C102C9BBC6C852024D013031024800003304')) from dual;

 

UTL_RAW.CAST_TO_NUMBER(HEXTORA

------------------------------

             -5.25255979409E23

 

这不就是一个number(24)吗?

但我并不认为这里应该是number(24)

 

这里其实应该以oracle实际存在dmp文件中的值来判断上述column的长度,即以"2E313133 02C10604 C8C6BBC9 014D0252 48023130 04330000"来判断上述字段的长度:

SQL>  select utl_raw.cast_to_number(hextoraw('2E31313302C10604C8C6BBC9014D02524802313004330000')) from dual;

 

UTL_RAW.CAST_TO_NUMBER(HEXTORA

------------------------------           

           -5.2525098089598E33

所以这里实际上是一个number(34)

2009年年中总结

| 10 Comments

上周五写一个模块的概要设计和我们部门的年中总结,写到晚上8点多才走。

今天我忽然想起来,我也应该对我自己在09年上半年做的事情做一个总结,算是对我自己的一个交代。

 

对照我09年年初的计划,我09年上半年主要做了这样一些事情:

1、  身体还不错,闺女也在茁壮成长。我尽可能的做到了每周五都去171中学打一次篮球(171的地板太滑了,使得我的突破完全发挥不出来,太不爽了!),每天晚上和老婆一起打打羽毛秋(在没有风的情况下),跑跑步,跳跳绳。闺女在茁壮成长,我闺女太皮了,一刻也不闲着。后来我二姨给我打电话,她告诉我说我从小就特别皮,一直调皮捣蛋到78岁,这下我明白我闺女为什么会这样了。

2、  09年年初本来是计划把我带的一个项目在09年的时候全力做好,但计划赶不上变化,我临时被抽调到另外一个项目组救火,而且一年内肯定是出不来,这个计划肯定是完不成了。

3、  我利用国家关于解决干部夫妻两地分居的政策把我老婆的北京户口给解决了,当她两个月前拿到北京这边的第二代身份证的时候,我算是了了她多年的一个心愿(她本是在北京出生,也是在北京念的小学和初中,从小到大受够了户口给她带来的诸多不便)。为了这一天,我耐心等待了两年多的时间。除了要感谢国家的好政策之外,也是由于我们俩运气出奇的好,才得以使这件事情成为现实。

4、  09年计划是要在年内拿到驾照,现在看起来问题不大。昨天刚刚去了东方时尚报了假日班(C13900),如果不出意外的话,今年年内肯定是可以拿到驾照。

5、  上半年的后几个月一直在集中精力看4字头的书,计划是要在年内看完401402402e403e404e,目前进展顺利,年内看完上述几本书应该问题不大。感觉上述几本书还是很浅显,完全没有我想象的那么难

6、  我还是基本上保持了每个工作日至少会在metalink上看10篇文章(这个10篇里面包括复习以前看过的,因为knowledge base里面只要一修改,就会置前)的习惯,我已经至少在metalink上看过1000篇文章了,希望这个习惯可以一直保留下去。

 

好了,我09年上半年的总结就是这些了。

我对自己要求并不高,就是希望平静的生活能这样延续下去,身体健康、家庭和睦、能踏踏实实的做一辈子技术就可以了

Recent Comments

  • Noma Lauw: Great job for creating such one of a kind collection read more
  • Vina Pagni: Damn, cool website. I actually came across this on Ask read more
  • the diet solution program reviews: By far, one of the best post l have come read more
  • Lose Ten Pounds in Three Days: By a long shot, one of the best post l read more
  • exercises to help lose 15 pounds: Without doubt, one of the best article l have come read more
  • Lose 20 Pounds a Week: I certainly enjoy your post, but having problem subscribing to read more
  • Aiko Potsander: Please continue to keep the good work! Cheers. read more
  • 毕业论文: 学习了。 read more
  • cui hua: 不用改数据,你改row directory里的指针就可以了——这就是我文中提到的update internal。 read more
  • yangjiawei: 领导,不好意思,再请问一下 我现在遇到一个问题,我现在已经将ind$里两个索引的状态改好了,数据库也拉起来了~! 但是在修改obj$里name里为DEPENDENCY$这一行数据的data_object_id时遇到了困难,因为他原先的长度为2个字节,现在由于我move了一下,他的长度变成了4个字节,结果如下: 原先: col 1[2] @906: 0xc1 0x5d ==>92 read more

About this Archive

This page is an archive of entries from July 2009 listed from newest to oldest.

June 2009 is the previous archive.

August 2009 is the next archive.

Find recent content on the main index or look in the archives to find all content.