12
返回列表 发新帖
楼主: solearn

不解的ora-30036

[复制链接]
论坛徽章:
47
蒙奇·D·路飞
日期:2017-03-27 08:04:23马上有车
日期:2014-02-18 16:41:112014年新春福章
日期:2014-02-18 16:41:11一汽
日期:2013-09-01 20:46:27复活蛋
日期:2013-03-13 07:55:232013年新春福章
日期:2013-02-25 14:51:24ITPUB 11周年纪念徽章
日期:2012-10-09 18:03:322012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:20
11#
发表于 2008-6-5 12:41 | 只看该作者
原帖由 solearn 于 2008-6-4 20:40 发表

SQL> update dengsk.t9 set id=id+1;
update dengsk.t9 set id=id+1
              *
ERROR 位于第 1 行:
ORA-30036: 无法按 8 扩展段 (在撤消表空间 'UNDO02' 中)

SQL> select xidusn,xidslot,xidsqn,ubafil,ubablk,ubasqn from v$transaction;

    XIDUSN    XIDSLOT     XIDSQN     UBAFIL     UBABLK     UBASQN
---------- ---------- ---------- ---------- ---------- ----------
        11         16          6          0          0          0


Thank you for the interesting experiments.

Question: Isn't what you show here contradicting what you observed in your first message?

Yong Huang

使用道具 举报

回复
论坛徽章:
14
奥运会纪念徽章:自行车
日期:2008-04-25 21:00:142013年新春福章
日期:2013-02-25 14:51:24ITPUB 11周年纪念徽章
日期:2012-10-10 13:11:14奥运会纪念徽章:皮划艇激流回旋
日期:2012-08-13 10:25:38鲜花蛋
日期:2012-02-10 11:40:172010新春纪念徽章
日期:2010-03-01 11:04:58授权会员
日期:2010-01-12 09:40:47ITPUB元老
日期:2010-01-12 09:33:092009新春纪念徽章
日期:2009-01-04 14:52:28奥运会纪念徽章:拳击
日期:2008-10-24 13:22:33
12#
 楼主| 发表于 2008-6-5 13:38 | 只看该作者
原帖由 Yong Huang 于 2008-6-5 12:41 发表


Thank you for the interesting experiments.

Question: Isn't what you show here contradicting what you observed in your first message?

Yong Huang


^_^

Yes, it seems contradicting.

The latter experiment issued 'set transaction user rollback segment "_SYSSMU11$"' firstly. This results in the interesting v$transaction output. Without this precondition, all DMLs works normally. Sorry for not pointing out this before.

Further tests prove: after 'set transaction use rollback segment "_SYSSMU11$"' issued, a failed dml like my 'update t9 set id=id+1' occupys not only the tranaction slot in undo header but also those undo blocks in this segment. I don't know why it does not rollback the failed dml automatically after 'set transaction use rollback segment "_SYSSMU11$"' .

[ 本帖最后由 solearn 于 2008-6-5 14:12 编辑 ]

使用道具 举报

回复
论坛徽章:
47
蒙奇·D·路飞
日期:2017-03-27 08:04:23马上有车
日期:2014-02-18 16:41:112014年新春福章
日期:2014-02-18 16:41:11一汽
日期:2013-09-01 20:46:27复活蛋
日期:2013-03-13 07:55:232013年新春福章
日期:2013-02-25 14:51:24ITPUB 11周年纪念徽章
日期:2012-10-09 18:03:322012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:20
13#
发表于 2008-6-6 04:26 | 只看该作者
原帖由 solearn 于 2008-6-4 23:38 发表


^_^

Yes, it seems contradicting.

The latter experiment issued 'set transaction user rollback segment "_SYSSMU11$"' firstly. This results in the interesting v$transaction output. Without this precondition, all DMLs works normally. Sorry for not pointing out this before.

Further tests prove: after 'set transaction use rollback segment "_SYSSMU11$"' issued, a failed dml like my 'update t9 set id=id+1' occupys not only the tranaction slot in undo header but also those undo blocks in this segment. I don't know why it does not rollback the failed dml automatically after 'set transaction use rollback segment "_SYSSMU11$"' .


Did you alter system set "_smu_debug_mode"=[some value]? I don't know all the implications of that parameter?

Maybe we missed the basic stuff. A simple "delete from t9 where id=1" could require a lot of undo. For instance, you have millions or billions of rows matching id=1, and possibly index entries. So if the total undo space is very small, even if this is the only transaction, the undo space is still not enough.

What if you try delete from t9 where rownum=1 in your first experiment?

Yong Huang

使用道具 举报

回复
论坛徽章:
14
奥运会纪念徽章:自行车
日期:2008-04-25 21:00:142013年新春福章
日期:2013-02-25 14:51:24ITPUB 11周年纪念徽章
日期:2012-10-10 13:11:14奥运会纪念徽章:皮划艇激流回旋
日期:2012-08-13 10:25:38鲜花蛋
日期:2012-02-10 11:40:172010新春纪念徽章
日期:2010-03-01 11:04:58授权会员
日期:2010-01-12 09:40:47ITPUB元老
日期:2010-01-12 09:33:092009新春纪念徽章
日期:2009-01-04 14:52:28奥运会纪念徽章:拳击
日期:2008-10-24 13:22:33
14#
 楼主| 发表于 2008-6-6 08:45 | 只看该作者
原帖由 Yong Huang 于 2008-6-6 04:26 发表


Did you alter system set "_smu_debug_mode"=[some value]? I don't know all the implications of that parameter?

Maybe we missed the basic stuff. A simple "delete from t9 where id=1" could require a lot of undo. For instance, you have millions or billions of rows matching id=1, and possibly index entries. So if the total undo space is very small, even if this is the only transaction, the undo space is still not enough.

What if you try delete from t9 where rownum=1 in your first experiment?

Yong Huang


Yes, I did set "_smu_debug_mode"=45 as you mentioned in another thread and if not:

SQL> set transaction use rollback segment "_SYSSMU11$";
set transaction use rollback segment "_SYSSMU11$"
*
ERROR at line 1:
ORA-30019: Illegal rollback Segment operation in Automatic Undo mode

It seems that the '"smu_debug_mode"=45' and 'set transaction use rollback segment "_SYSSMU11$";' results in the output:

SQL> select xidusn,xidslot,xidsqn,ubafil,ubablk,ubasqn from v$transaction;

    XIDUSN    XIDSLOT     XIDSQN     UBAFIL     UBABLK     UBASQN
---------- ---------- ---------- ---------- ---------- ----------
        11         16          6          0          0          0

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

Then I did the test in normal situation:

SQL>startup force;


SQL> select usn,rssize,hwmsize from v$rollstat;
       USN     RSSIZE    HWMSIZE
---------- ---------- ----------
         0     385024     385024
        11     122880     122880
        12     122880     122880
        13     188416     188416
        14     122880     188416
        15     122880     122880
        16     122880     122880
        17     122880     122880
已选择8行。

SQL> delete from dengsk.t9 where id=1;
delete from dengsk.t9 where id=1
*
ERROR at line 1:
ORA-30036: unable to extend segment by 8 in undo tablespace 'UNDO02'

SQL> select xidusn,xidslot,xidsqn,ubafil,ubablk,ubasqn from v$transaction;
no rows selected

SQL> select usn,rssize,hwmsize from v$rollstat;
       USN     RSSIZE    HWMSIZE
---------- ---------- ----------
         0     385024     385024
        11     122880     122880
        12     188416     188416
        13     122880     188416
        14     122880     188416
        15     122880     122880
        16     122880     122880
        17     122880     122880
已选择8行。
SQL>

'delete from t9 where rownum=1' can surely succeed. A big tranaction would require more undo blocks than the undo segment affords.

使用道具 举报

回复
论坛徽章:
8
2009新春纪念徽章
日期:2009-01-04 14:52:28祖国60周年纪念徽章
日期:2009-10-09 08:28:002010新春纪念徽章
日期:2010-03-01 11:07:24ITPUB9周年纪念徽章
日期:2010-10-08 09:32:25ITPUB十周年纪念徽章
日期:2011-11-01 16:23:262013年新春福章
日期:2013-02-25 14:51:24沸羊羊
日期:2015-03-04 14:51:522015年新春福章
日期:2015-03-06 11:57:31
15#
发表于 2008-6-6 09:24 | 只看该作者

回复 #8 solearn 的帖子

solearn,你好,针对你的这段回答,我又这么两个疑问:
一是用光了所有非系统回滚段,用光是什么意思呢?
二是如果存在回滚段没被使用,那么没被使用是什么意思呢?

还有,针对这种奇怪的现象,我有如下猜想,当然,目前我还抽不出时间做这个试验:
你在两种情况下,也就是用set transaction和不用set transaction,确定两次DML操作用的是一个回滚段吗?或者说你确定没用set transaction情况下,用的也是usn为11的回滚段吗?如果都是用的一个回滚段,那确实奇怪了,如果不是,那就这个原因了,共同探讨。我看到你一次强制启动后,用到了usn12的回滚段,这次似乎没用set transaction,似乎也分配了空间对吗?

还有,这种情况下,我记得看到过资料,这个事务只能挂在这里了,虽然失败了,也该回滚,但拿什么来回滚呢?如果能回滚,拿这个事务就失败不了了,当时资料大体是这个意思。

[ 本帖最后由 sqysl 于 2008-6-6 09:36 编辑 ]

使用道具 举报

回复
论坛徽章:
14
奥运会纪念徽章:自行车
日期:2008-04-25 21:00:142013年新春福章
日期:2013-02-25 14:51:24ITPUB 11周年纪念徽章
日期:2012-10-10 13:11:14奥运会纪念徽章:皮划艇激流回旋
日期:2012-08-13 10:25:38鲜花蛋
日期:2012-02-10 11:40:172010新春纪念徽章
日期:2010-03-01 11:04:58授权会员
日期:2010-01-12 09:40:47ITPUB元老
日期:2010-01-12 09:33:092009新春纪念徽章
日期:2009-01-04 14:52:28奥运会纪念徽章:拳击
日期:2008-10-24 13:22:33
16#
 楼主| 发表于 2008-6-6 10:44 | 只看该作者
原帖由 sqysl 于 2008-6-6 09:24 发表
solearn,你好,针对你的这段回答,我又这么两个疑问:
一是用光了所有非系统回滚段,用光是什么意思呢?
二是如果存在回滚段没被使用,那么没被使用是什么意思呢?

还有,针对这种奇怪的现象,我有如下猜想,当然,目前我还抽不出时间做这个试验:
你在两种情况下,也就是用set transaction和不用set transaction,确定两次DML操作用的是一个回滚段吗?或者说你确定没用set transaction情况下,用的也是usn为11的回滚段吗?如果都是用的一个回滚段,那确实奇怪了,如果不是,那就这个原因了,共同探讨。我看到你一次强制启动后,用到了usn12的回滚段,这次似乎没用set transaction,似乎也分配了空间对吗?

还有,这种情况下,我记得看到过资料,这个事务只能挂在这里了,虽然失败了,也该回滚,但拿什么来回滚呢?如果能回滚,拿这个事务就失败不了了,当时资料大体是这个意思。


一、“用光”这里指全部的undo segment都被使用了,或者因为undo segment header被耗尽或者因为undo extent不能再扩展。我是试图理解administrator's guide上的那段话,也没有实验。
二、“存在回滚段没被使用”是指我实验的情况,7个非系统回滚段只是用了一个“_SYSSMU11$”,其他几个没被使用。这时候系统回滚段也不被使用。

在AUM情况下使用set transaction和不使用,结果不一样。在上面的实验中可以看出来。第二次startup force是为了unset "_smu_debug_mode",这时候回滚段由系统自己指定。可以看出“_SYSSMU12$”size增长,“_SYSSMU13$”回缩,证明“_SYSSMU12$”被使用并尽可能扩展了空间。没有察看undo segment header的情况,估计transaction table中也分配了slot,只是语句失败后自动回滚了。

使用道具 举报

回复
论坛徽章:
8
2009新春纪念徽章
日期:2009-01-04 14:52:28祖国60周年纪念徽章
日期:2009-10-09 08:28:002010新春纪念徽章
日期:2010-03-01 11:07:24ITPUB9周年纪念徽章
日期:2010-10-08 09:32:25ITPUB十周年纪念徽章
日期:2011-11-01 16:23:262013年新春福章
日期:2013-02-25 14:51:24沸羊羊
日期:2015-03-04 14:51:522015年新春福章
日期:2015-03-06 11:57:31
17#
发表于 2008-6-6 19:42 | 只看该作者
我更赞成用光是回滚段头被用完的说法。

还有,系统是先获取一个事务嘈(transaction slot)后,才写回滚数据的。我觉得,你试验中的两种情况下,即人为指定和系统自动分配,使用的不是一个回滚段,系统指定情况下的试验根本就没获得一个事务槽,而人为指定回滚段的情况事务获取了一个事务槽,并且写了一部分回滚数据,原因就是一个回滚段没自由空间,另外一个有点自由空间但不够。

使用道具 举报

回复
论坛徽章:
14
奥运会纪念徽章:自行车
日期:2008-04-25 21:00:142013年新春福章
日期:2013-02-25 14:51:24ITPUB 11周年纪念徽章
日期:2012-10-10 13:11:14奥运会纪念徽章:皮划艇激流回旋
日期:2012-08-13 10:25:38鲜花蛋
日期:2012-02-10 11:40:172010新春纪念徽章
日期:2010-03-01 11:04:58授权会员
日期:2010-01-12 09:40:47ITPUB元老
日期:2010-01-12 09:33:092009新春纪念徽章
日期:2009-01-04 14:52:28奥运会纪念徽章:拳击
日期:2008-10-24 13:22:33
18#
 楼主| 发表于 2008-6-10 10:13 | 只看该作者
原帖由 sqysl 于 2008-6-6 19:42 发表
我更赞成用光是回滚段头被用完的说法。

还有,系统是先获取一个事务嘈(transaction slot)后,才写回滚数据的。我觉得,你试验中的两种情况下,即人为指定和系统自动分配,使用的不是一个回滚段,系统指定情况下的试验根本就没获得一个事务槽,而人为指定回滚段的情况事务获取了一个事务槽,并且写了一部分回滚数据,原因就是一个回滚段没自由空间,另外一个有点自由空间但不够。


sqysl:

大周末过去了,接着来讨论。

————————————————————————————————
我更赞成用光是回滚段头被用完的说法。

还是很难断定oracle是根据什么来却确定使用system回滚段。


————————————————————————————————
还有,系统是先获取一个事务嘈(transaction slot)后,才写回滚数据的。我觉得,你试验中的两种情况下,即人为指定和系统自动分配,使用的不是一个回滚段,系统指定情况下的试验根本就没获得一个事务槽,而人为指定回滚段的情况事务获取了一个事务槽,并且写了一部分回滚数据,原因就是一个回滚段没自由空间,另外一个有点自由空间但不够。

系统自动指定回滚段的情况下,也是分配了事务槽的。只不过这是一个未完成的事务,在事务表中得到没有回滚链的头部块地址。

在执行了失败的dml后,我dump了undo segment header of _SYSSMU12$。

index 0X00和index 0X01是最后2个事务,是oracle内部更新smon_scn_to_time的,不管它。
index 0X2f就是那个失败的dml操作。

Dump file fracleadmin        estdbudump        est_ora_3288.trc
Fri Jun 06 10:00:53 2008
ORACLE V9.2.0.1.0 - Production vsnsta=0
vsnsql=12 vsnxtr=3
Windows 2000 Version 5.1 Service Pack 2, CPU type 586
Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.1.0 - Production
Windows 2000 Version 5.1 Service Pack 2, CPU type 586
Instance name: test
Redo thread mounted by this instance: 1
Oracle process number: 12
Windows thread id: 3288, image: ORACLE.EXE

*** 2008-06-06 10:00:53.000
*** SESSION ID9.7) 2008-06-06 10:00:53.000

********************************************************************************
Undo Segment:  _SYSSMU12$ (12)
********************************************************************************
  Extent Control Header
  -----------------------------------------------------------------
  Extent Header:: spare1: 0      spare2: 0      #extents: 3      #blocks: 23   
                  last map  0x00000000  #maps: 0      offset: 4080  
      Highwater::  0x02000056  ext#: 2      blk#: 5      ext size: 8     
  #blocks in seg. hdr's freelists: 0     
  #blocks below: 0     
  mapblk  0x00000000  offset: 2     
                   Unlocked
     Map Header:: next  0x00000000  #extents: 3    obj#: 0      flag: 0x40000000
  Extent Map
  -----------------------------------------------------------------
   0x0200001a  length: 7     
   0x02000021  length: 8     
   0x02000051  length: 8     
  
Retention Table
  -----------------------------------------------------------
Extent Number:0  Commit Time: 1212712189
Extent Number:1  Commit Time: 1212712189
Extent Number:2  Commit Time: 1212712189
  
  TRN CTL:: seq: 0x000e chd: 0x0002 ctl: 0x0001 inc: 0x00000000 nfb: 0x0001
            mgc: 0x8201 xts: 0x0068 flg: 0x0001 opt: 2147483646 (0x7ffffffe)
            uba: 0x02000056.000e.02 scn: 0x0000.00638cd8
Version: 0x01
  FREE BLOCK POOL::
    uba: 0x02000056.000e.02 ext: 0x2  spc: 0x1e3a  
    uba: 0x00000000.000b.01 ext: 0x2  spc: 0x1fa0  
    uba: 0x00000000.000b.01 ext: 0x2  spc: 0x1fa0  
    uba: 0x00000000.000c.01 ext: 0x0  spc: 0x1fa0  
    uba: 0x00000000.0003.01 ext: 0x0  spc: 0x1fa0  
  TRN TBL::

  index  state cflags  wrap#    uel         scn            dba            parent-xid    nub     stmt_num
  ------------------------------------------------------------------------------------------------
   0x00    9    0x00  0x0008  0x0001  0x0000.00644517  0x02000056  0x0000.000.00000000  0x00000001   0x00000000
   0x01    9    0x00  0x0008  0xffff  0x0000.006447d9  0x02000056  0x0000.000.00000000  0x00000001   0x00000000
   0x02    9    0x00  0x0007  0x0003  0x0000.00638d7c  0x0200001a  0x0000.000.00000000  0x00000001   0x00000000
   0x03    9    0x00  0x0007  0x0004  0x0000.00638f4f  0x0200001a  0x0000.000.00000000  0x00000001   0x00000000
   0x04    9    0x00  0x0007  0x0005  0x0000.00639219  0x0200001a  0x0000.000.00000000  0x00000001   0x00000000
   0x05    9    0x00  0x0007  0x0006  0x0000.006394db  0x0200001a  0x0000.000.00000000  0x00000001   0x00000000
   0x06    9    0x00  0x0007  0x0007  0x0000.0063979d  0x0200001a  0x0000.000.00000000  0x00000001   0x00000000
   0x07    9    0x00  0x0007  0x0008  0x0000.0063998b  0x00000000  0x0000.000.00000000  0x00000000   0x00000000
   0x08    9    0x00  0x0007  0x0009  0x0000.006399ca  0x00000000  0x0000.000.00000000  0x00000000   0x00000000
   0x09    9    0x00  0x0007  0x000b  0x0000.006399cc  0x00000000  0x0000.000.00000000  0x00000000   0x00000000
   0x0a    9    0x00  0x0007  0x0011  0x0000.0063a16f  0x0200001a  0x0000.000.00000000  0x00000001   0x00000000
   0x0b    9    0x00  0x0007  0x000c  0x0000.006399ce  0x00000000  0x0000.000.00000000  0x00000000   0x00000000
   0x0c    9    0x00  0x0007  0x000d  0x0000.006399d0  0x00000000  0x0000.000.00000000  0x00000000   0x00000000
   0x0d    9    0x00  0x0007  0x000e  0x0000.006399d2  0x00000000  0x0000.000.00000000  0x00000000   0x00000000
   0x0e    9    0x00  0x0007  0x000f  0x0000.00639b9b  0x0200001a  0x0000.000.00000000  0x00000001   0x00000000
   0x0f    9    0x00  0x0007  0x0010  0x0000.00639d60  0x0200001a  0x0000.000.00000000  0x00000001   0x00000000
   0x10    9    0x00  0x0007  0x000a  0x0000.00639f11  0x0200001a  0x0000.000.00000000  0x00000001   0x00000000
   0x11    9    0x00  0x0007  0x0012  0x0000.0063a3cb  0x0200001a  0x0000.000.00000000  0x00000001   0x00000000
   0x12    9    0x00  0x0007  0x0013  0x0000.0063a629  0x0200001a  0x0000.000.00000000  0x00000001   0x00000000
   0x13    9    0x00  0x0007  0x0014  0x0000.0063a8ea  0x0200001a  0x0000.000.00000000  0x00000001   0x00000000
   0x14    9    0x00  0x0007  0x0015  0x0000.0063abac  0x0200001a  0x0000.000.00000000  0x00000001   0x00000000
   0x15    9    0x00  0x0007  0x0016  0x0000.0063ae6e  0x0200001a  0x0000.000.00000000  0x00000001   0x00000000
   0x16    9    0x00  0x0007  0x0017  0x0000.0063b130  0x0200001a  0x0000.000.00000000  0x00000001   0x00000000
   0x17    9    0x00  0x0007  0x0018  0x0000.0063b3f2  0x0200001a  0x0000.000.00000000  0x00000001   0x00000000
   0x18    9    0x00  0x0007  0x0019  0x0000.0063b6b4  0x0200001a  0x0000.000.00000000  0x00000001   0x00000000
   0x19    9    0x00  0x0007  0x001a  0x0000.0063b976  0x0200001a  0x0000.000.00000000  0x00000001   0x00000000
   0x1a    9    0x00  0x0007  0x001b  0x0000.0063bc38  0x0200001a  0x0000.000.00000000  0x00000001   0x00000000
   0x1b    9    0x00  0x0007  0x001c  0x0000.0063befb  0x0200001a  0x0000.000.00000000  0x00000001   0x00000000
   0x1c    9    0x00  0x0007  0x001d  0x0000.0063c1bd  0x0200001a  0x0000.000.00000000  0x00000001   0x00000000
   0x1d    9    0x00  0x0007  0x001e  0x0000.0063c47f  0x0200001a  0x0000.000.00000000  0x00000001   0x00000000
   0x1e    9    0x00  0x0007  0x001f  0x0000.0063c741  0x0200001a  0x0000.000.00000000  0x00000001   0x00000000
   0x1f    9    0x00  0x0007  0x0020  0x0000.0063ca03  0x0200001a  0x0000.000.00000000  0x00000001   0x00000000
   0x20    9    0x00  0x0007  0x0021  0x0000.0063ccc5  0x0200001a  0x0000.000.00000000  0x00000001   0x00000000
   0x21    9    0x00  0x0007  0x0022  0x0000.0063cf87  0x0200001a  0x0000.000.00000000  0x00000001   0x00000000
   0x22    9    0x00  0x0007  0x0023  0x0000.0063d249  0x0200001a  0x0000.000.00000000  0x00000001   0x00000000
   0x23    9    0x00  0x0007  0x0024  0x0000.0063d50b  0x0200001a  0x0000.000.00000000  0x00000001   0x00000000
   0x24    9    0x00  0x0007  0x0025  0x0000.0063d7cd  0x0200001a  0x0000.000.00000000  0x00000001   0x00000000
   0x25    9    0x00  0x0007  0x0026  0x0000.0063da8f  0x0200001a  0x0000.000.00000000  0x00000001   0x00000000
   0x26    9    0x00  0x0007  0x0027  0x0000.0063dd51  0x0200001a  0x0000.000.00000000  0x00000001   0x00000000
   0x27    9    0x00  0x0007  0x0028  0x0000.0063e013  0x0200001a  0x0000.000.00000000  0x00000001   0x00000000
   0x28    9    0x00  0x0007  0x0029  0x0000.0063e2d5  0x0200001a  0x0000.000.00000000  0x00000001   0x00000000
   0x29    9    0x00  0x0007  0x002a  0x0000.0063e597  0x0200001a  0x0000.000.00000000  0x00000001   0x00000000
   0x2a    9    0x00  0x0007  0x002b  0x0000.0063e859  0x0200001b  0x0000.000.00000000  0x00000001   0x00000000
   0x2b    9    0x00  0x0007  0x002c  0x0000.0063eb1b  0x0200001b  0x0000.000.00000000  0x00000001   0x00000000
   0x2c    9    0x00  0x0007  0x002d  0x0000.0063eddd  0x0200001b  0x0000.000.00000000  0x00000001   0x00000000
   0x2d    9    0x00  0x0007  0x002e  0x0000.0063f09f  0x0200001b  0x0000.000.00000000  0x00000001   0x00000000
   0x2e    9    0x00  0x0007  0x002f  0x0000.00644036  0x0200001b  0x0000.000.00000000  0x00000001   0x00000000
   0x2f    9    0x00  0x0007  0x0000  0x0000.00644259  0x00000000  0x0000.000.00000000  0x00000000   0x00000000

使用道具 举报

回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

TOP技术积分榜 社区积分榜 徽章 团队 统计 知识索引树 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档
  ChinaUnix | ChinaUnix博客 | ChinaUnix论坛
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有 联系我们 未成年人举报专区 
京ICP备16024965号-8  北京市公安局海淀分局网监中心备案编号:11010802021510 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表