打对了

宇宙和生命从哪里来?又要到哪里去呢?

 

最新评论

共2页: 1 2 下一页 
re: Oracle 10G重建EM DB Control. rql_shark 2008-10-16 16:04  
emca -config dbcontrol db -repos create
太谢谢啦!不知道给你说点什么好!谢谢谢谢
re: Oracle 10G重建EM DB Control. - 打对了 - 博客园 蓝奇高级验证码识别引擎QQ:631753663 2008-04-08 06:25  
出售蓝奇高级验证码识别引擎,可准确识别新浪动网淘宝CSDN等多种复杂验证码。

输出为一个标准DLL,可供VB,VC,Delphi,C#.NET,VB.NET,模拟精灵,按键精灵等多平台调用,调用方法简单,几行代码即可完成。独具特色的边缘检测字符分离、旋转倾斜纠正和通用字符匹配算法(无论字体和大小), 使得该引擎对于像新浪、动网、淘宝、CSDN等多种验证码均有不错的识别率,是一款效果较为理想的验证码识别引擎。附详细的调用实例和代码注释等相关技术文档。

官方网站 - http://www.purejoy.cn/yzm_advocr
识别效果怎么样一试就知道 - DEMO下载 http://www.purejoy.cn/yzm_advocr/advocr.rar
lz 是中联公司的吗!
太感谢楼主了
好了
谢谢
衷心的感谢
lz内容挺有用的,不过例子太不详细了
谢谢楼主,重装了三次oracle也没解决的问题,终于解决了!
好像不行吧,在oracle9i中,我有LZ的那段黑色字体的部分,但是也不行?
3q,困扰多时的问题终于坚决了
就是windows的Oracle服务停止状态.
关闭状态?到底是idle, nomount, mount中的哪个状态?
关闭状态貌似无论如何都不能连接数据库吧?
我错了,不好意思,我用的是 little endian
“连通”两个字的Unicode标准编码UTF-16 (big endian)为:DE 8F 1A 90


错了!
\

应该: 8FDE 901A
re: 对条件子句中带IN的SQL语句使用绑定变量 知道得越多知道的越少 2007-04-02 10:36  
目前发现一个问题,在Oracle 817上使用需要注意一个BUG。
在使用In子句一个记录集表时,如果使用了Group by则会出现“通信信道结束”的错误。改为表联接方式就不会出现这个问题。
Where NO In (Select * From Table(Cast(f_Str2list('A01,A02,A03') As zlTools.t_Strlist)));

改为:
From 病人费用记录 A, Table(Cast(f_Str2list('A01,A02,A03') As zlTools.t_Strlist)) B
Where A.NO = B.Column_Value;
re: 对条件子句中带IN的SQL语句使用绑定变量 知道得越多知道的越少 2007-03-30 17:53  
表名和字段名都是真实的汉字,实践表明没有什么不可以。
请问...
Select a.No, a.结算方式, Nvl(b.性质, 1) As 性质, a.金额, a.摘要, a.结算号码
这些汉字是伪代码还是...
re: 在Oracle中重编译所有无效的存储过程 知道得越多知道的越少 2006-10-18 09:18  
其实PLSQL Developer中工具菜单下的编译无效对象非常方面,也更全面
就是填写不同的值
re: HIS行业的技术先锋?先烈? 知道得越多知道的越少 2006-06-29 14:27  
进度怎么样了,我最近也没有关注,可以在他们的博客上看看有没有新的消息:
http://www.agilelabs.cn
re: HIS行业的技术先锋?先烈? 路人丙 2006-06-24 11:30  
我只是现在想知道他们的项目进展得怎么样了,看他们的样子好像很有把握,不过我觉得his不是这么简单的。感觉他们有点低估了。
re: 位图索引深度探讨 知道得越多知道的越少 2006-05-29 18:19  
下面的对比实验表明,使用位图索引时,由于访问的索引块少了很多,查询速度得到较大的提高
查询1087行数据,B树索引用了157块,CPU耗用0.05,位图索引用了82块,CPU耗用0.01


--使用B*Tree索引查询
SQL> drop index H票据使用明细_IX_领用ID;
SQL> create index H票据使用明细_IX_领用ID on H票据使用明细(领用ID);
SQL> Select * From H票据使用明细 Where 领用id=102;

已选择1087行。

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'H票据使用明细'
2 1 INDEX (RANGE SCAN) OF 'H票据使用明细_IX_领用ID' (NON-UNIQUE)
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
157 consistent gets
0 physical reads
0 redo size
53393 bytes sent via SQL*Net to client
1295 bytes received via SQL*Net from client
74 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1087 rows processed

Select *
From
H票据使用明细 Where 领用id=102


call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 74 0.01 0.05 2 157 0 1087
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 76 0.01 0.05 2 157 0 1087

Misses in library cache during parse: 1
Optimizer goal: ALL_ROWS
Parsing user id: 311

Rows Row Source Operation
------- ---------------------------------------------------
1087 TABLE ACCESS BY INDEX ROWID H票据使用明细
1087 INDEX RANGE SCAN H票据使用明细_IX_领用ID (object id 49919)



--使用位图索引查询
SQL> drop index H票据使用明细_IX_领用ID;
SQL> create bitmap index H票据使用明细_IX_领用ID on H票据使用明细(领用ID);
SQL> Select * From H票据使用明细 Where 领用id=102;

已选择1087行。

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=3 Card=10 Bytes=1060)
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'H票据使用明细' (Cost=3 Card=10 Bytes=1060)
2 1 BITMAP CONVERSION (TO ROWIDS)
3 2 BITMAP INDEX (SINGLE VALUE) OF 'H票据使用明细_IX_领用ID'
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
82 consistent gets
0 physical reads
0 redo size
53393 bytes sent via SQL*Net to client
1295 bytes received via SQL*Net from client
74 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1087 rows processed

Select *
From
H票据使用明细 Where 领用id=102


call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 74 0.01 0.01 0 82 0 1087
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 76 0.01 0.01 0 82 0 1087

Misses in library cache during parse: 0
Optimizer goal: ALL_ROWS
Parsing user id: 311

Rows Row Source Operation
------- ---------------------------------------------------
1087 TABLE ACCESS BY INDEX ROWID H票据使用明细
1087 BITMAP CONVERSION TO ROWIDS
1 BITMAP INDEX SINGLE VALUE H票据使用明细_IX_领用ID (object id 49920)
re: 位图索引深度探讨 知道得越多知道的越少 2006-05-29 13:47  
Oracle 10G R2

下面的实验:
--修改索引的一个键值(更新或插入行),是否会更新关于该索引的所有键的位图
--a.更新或插入的行,在同一个块内
--b.更新或插入的行,不在同一个块内

SQL> alter table H病人挂号记录 add 备注 char(2000);
SQL> truncate table H病人挂号记录;
SQL> Insert Into H病人挂号记录(Id,No,号别,执行人) Values(1,'G000001',1,'张1');
SQL> Insert Into H病人挂号记录(Id,No,号别,执行人) Values(2,'G000002',1,'张2');
SQL> commit;
--此时的位图
SQL> alter system dump datafile 1 block 61434;

row#0[7988] flag: ------, lock: 2, len=27
col 0; len 3; (3): d5 c5 31 --键值'张1'
col 1; len 6; (6): 00 00 00 00 00 00 --rowid的起始位置
col 2; len 6; (6): 00 40 ef f2 00 07 --rowid的终止位置
col 3; len 6; (6): c0 d2 d5 dc bc 01 --位图
row#1[7940] flag: ------, lock: 2, len=27
col 0; len 3; (3): d5 c5 32
col 1; len 6; (6): 00 00 00 00 00 00
col 2; len 6; (6): 00 40 ef f2 00 07
col 3; len 6; (6): c1 d2 d5 dc bc 01
----- end of leaf block dump -----
End dump data blocks tsn: 0 file#: 1 minblk 61434 maxblk 61434

再插入一行键值为'张2'的,观察键值为'张1'的位图是否改变
SQL> Insert Into H病人挂号记录(Id,No,号别,执行人) Values(2,'G000002',1,'张2');
SQL> commit;
SQL> alter system dump datafile 1 block 61434;

row#0[7988] flag: ------, lock: 0, len=27
col 0; len 3; (3): d5 c5 31
col 1; len 6; (6): 00 00 00 00 00 00
col 2; len 6; (6): 00 40 ef f2 00 07
col 3; len 6; (6): c0 d2 d5 dc bc 01
row#1[7912] flag: ------, lock: 2, len=28
col 0; len 3; (3): d5 c5 32
col 1; len 6; (6): 00 00 00 00 00 00
col 2; len 6; (6): 00 40 ef f2 00 07
col 3; len 7; (7): f8 e4 d5 dc bc 01 06
----- end of leaf block dump -----
End dump data blocks tsn: 0 file#: 1 minblk 61434 maxblk 61434

--对比发现,索引键'张1'的位图c0 d2 d5 dc bc 01没有发生变化,
索引键'张2'的位图c1 d2 d5 dc bc 01变成了f8 e4 d5 dc bc 01 06
与8i的差别是,不用删除旧的位图,而是直接修改对应的索引键的位图来表示新的数据信息.

--b.更新或插入的行,不在同一个块内

SQL> exec show_space('H病人挂号记录','SYS','TABLE');

Free Blocks.............................1
Total Blocks............................8
Total Bytes.............................65536
Unused Blocks...........................6
Unused Bytes............................49152
Last Used Ext FileId....................1
Last Used Ext BlockId...................61425
Last Used Block.........................2

PL/SQL procedure successfully completed

--添加一列备注,添加5行信息,使表数据的存储超过1个块
SQL> Insert Into H病人挂号记录(Id,No,号别,执行人,备注) Values(1,'G000001',1,'张1',lpad('2000byte',2000,'*'));
1 row inserted
SQL> /
1 row inserted
SQL> /
1 row inserted
SQL> /
1 row inserted
SQL> /
1 row inserted

SQL> exec show_space('H病人挂号记录','SYS','TABLE');

Free Blocks.............................1
Total Blocks............................8
Total Bytes.............................65536
Unused Blocks...........................5
Unused Bytes............................40960
Last Used Ext FileId....................1
Last Used Ext BlockId...................61425
Last Used Block.........................3

PL/SQL procedure successfully completed

--对比前面的Last Used Block,由2变为了3,Unused Blocks由6变成了5,
说明高水标记已移动了一个块的位置.此时再插入数据,会放入块ID为61428的块中.

--先记下此时的索引块的情况
SQL> alter system dump datafile 1 block 61434;

row#0[7767] flag: ------, lock: 2, len=31
col 0; len 3; (3): d5 c5 31
col 1; len 6; (6): 00 00 00 00 00 00
col 2; len 6; (6): 00 40 ef f3 00 07
col 3; len 10; (10): f8 e4 d5 dc bc 01 39 f8 56 03
row#1[7912] flag: ------, lock: 0, len=28
col 0; len 3; (3): d5 c5 32
col 1; len 6; (6): 00 00 00 00 00 00
col 2; len 6; (6): 00 40 ef f2 00 07
col 3; len 7; (7): f8 e4 d5 dc bc 01 06
----- end of leaf block dump -----
End dump data blocks tsn: 0 file#: 1 minblk 61434 maxblk 61434

--再插入键值为'张2'的记录,注意,此时插入的记录已经不在该表以前的块上了(块号:61425+3)
SQL> Insert Into H病人挂号记录(Id,No,号别,执行人) Values(2,'G000002',1,'张2');
SQL> commit;

--索引的块没有变,仍是61434
SQL> alter system dump datafile 1 block 61434;

row#0[7767] flag: ------, lock: 0, len=31
col 0; len 3; (3): d5 c5 31
col 1; len 6; (6): 00 00 00 00 00 00
col 2; len 6; (6): 00 40 ef f3 00 07
col 3; len 10; (10): f8 e4 d5 dc bc 01 39 f8 56 03
row#1[7737] flag: ------, lock: 2, len=30
col 0; len 3; (3): d5 c5 32
col 1; len 6; (6): 00 00 00 00 00 00
col 2; len 6; (6): 00 40 ef f3 00 07
col 3; len 9; (9): f8 e4 d5 dc bc 01 06 c2 44
----- end of leaf block dump -----
End dump data blocks tsn: 0 file#: 1 minblk 61434 maxblk 61434

--与上面的比较发现,索引块内的位图行并没有增加,只是改变了位图f8 e4 d5 dc bc 01 06变成了f8 e4 d5 dc bc 01 06 c2 44
这一点,与8i区别很大,也就是说,10G中一个键值只有一个索引位图,
而8i中一个键值可能有一个或多个位图,单行数据插入时,每8行数据,或者当数据行分布在不同的数据块时,就会新建一个位图来记录.

是不是数据量少,才只有一个位图呢,下面再插入10000行数据的情况下,观察发现一个键值仍然只有一个位图.
一个位图索引块,由于采用位方式表示键值对应的数据,表达的数据是非常大的.
SQL> Declare
Begin
For i In 1..10000
Loop
Insert Into H病人挂号记录(Id,No,号别,执行人) Values(i,'G000001',1,'张1');
End Loop;
Commit;
End;
/

SQL> exec show_space('H病人挂号记录_IX_执行人','SYS','INDEX');

Free Blocks.............................0
Total Blocks............................8
Total Bytes.............................65536
Unused Blocks...........................6
Unused Bytes............................49152
Last Used Ext FileId....................1
Last Used Ext BlockId...................61433
Last Used Block.........................2

PL/SQL procedure successfully completed

SQL> alter system dump datafile 1 block 61434;

row#0[390] flag: ------, lock: 2, len=1530
col 0; len 3; (3): d5 c5 31
col 1; len 6; (6): 00 00 00 00 00 00
col 2; len 6; (6): 00 40 f3 27 00 67
col 3; len 1508; (1508):
ff e4 d5 dc bc 01 ff ff ff ff ff ff ff ff cf ff ff ff ff ff ff ff ff cf ff
ff ff ff ff ff ff ff cb ff ff ff 7f ff 3b ff ff ff ff ff ff ff ff cf ff ff
ff ff ff ff ff ff cf ff ff ff ff ff ff ff ff cb ff ff ff 0f ff 3b ff ff ff
ff ff ff ff ff cf ff ff ff ff ff ff ff ff cf ff ff ff ff ff ff ff ff cb ff
ff ff 0f ff 3b ff ff ff ff ff ff ff ff cf ff ff ff ff ff ff ff ff cf ff ff
ff ff ff ff ff ff cb ff ff ff 0f ff 3b ff ff ff ff ff ff ff ff cf ff ff ff
ff ff ff ff ff cf ff ff ff ff ff ff ff ff cb ff ff ff 0f ff 3b ff ff ff ff
ff ff ff ff cf ff ff ff ff ff ff ff ff cf ff ff ff ff ff ff ff ff cb ff ff
ff 0f ff 3b ff ff ff ff ff ff ff ff cf ff ff ff ff ff ff ff ff cf ff ff ff
ff ff ff ff ff cb ff ff ff 0f ff a3 06 ff ff ff ff ff ff ff ff cf ff ff ff
ff ff ff ff ff cf ff ff ff ff ff ff ff ff cb ff ff ff 0f ff 3b ff ff ff ff
ff ff ff ff cf ff ff ff ff ff ff ff ff cf ff ff ff ff ff ff ff ff cb ff ff
ff 0f ff 3b ff ff ff ff ff ff ff ff cf ff ff ff ff ff ff ff ff cf ff ff ff
ff ff ff ff ff cb ff ff ff 0f ff 3b ff ff ff ff ff ff ff ff cf ff ff ff ff
ff ff ff ff cf ff ff ff ff ff ff ff ff cb ff ff ff 0f ff 3b ff ff ff ff ff
ff ff ff cf ff ff ff ff ff ff ff ff cf ff ff ff ff ff ff ff ff cb ff ff ff
0f ff 3b ff ff ff ff ff ff ff ff cf ff ff ff ff ff ff ff ff cf ff ff ff ff
ff ff ff ff cb ff ff ff 0f ff 3b ff ff ff ff ff ff ff ff cf ff ff ff ff ff
ff ff ff cf ff ff ff ff ff ff ff ff cb ff ff ff 0f ff 3b ff ff ff ff ff ff
ff ff cf ff ff ff ff ff ff ff ff cf ff ff ff ff ff ff ff ff cb ff ff ff 0f
ff bb ae 04 ff ff ff ff ff ff ff ff cf ff ff ff ff ff ff ff ff cf ff ff ff
ff ff ff ff ff cb ff ff ff 0f ff 3b ff ff ff ff ff ff ff ff cf ff ff ff ff
ff ff ff ff cf ff ff ff ff ff ff ff ff cb ff ff ff 0f ff 3b ff ff ff ff ff
ff ff ff cf ff ff ff ff ff ff ff ff cf ff ff ff ff ff ff ff ff cb ff ff ff
0f ff 3b ff ff ff ff ff ff ff ff cf ff ff ff ff ff ff ff ff cf ff ff ff ff
ff ff ff ff cb ff ff ff 0f ff 3b ff ff ff ff ff ff ff ff cf ff ff ff ff ff
ff ff ff cf ff ff ff ff ff ff ff ff cb ff ff ff 0f ff 3b ff ff ff ff ff ff
ff ff cf ff ff ff ff ff ff ff ff cf ff ff ff ff ff ff ff ff cb ff ff ff 0f
ff 3b ff ff ff ff ff ff ff ff cf ff ff ff ff ff ff ff ff cf ff ff ff ff ff
ff ff ff cb ff ff ff 0f ff 3b ff ff ff ff ff ff ff ff cf ff ff ff ff ff ff
ff ff cf ff ff ff ff ff ff ff ff cb ff ff ff 0f ff 3b ff ff ff ff ff ff ff
ff cf ff ff ff ff ff ff ff ff cf ff ff ff ff ff ff ff ff cb ff ff ff 0f ff
3b ff ff ff ff ff ff ff ff cf ff ff ff ff ff ff ff ff cf ff ff ff ff ff ff
ff ff cb ff ff ff 0f ff 3b ff ff ff ff ff ff ff ff cf ff ff ff ff ff ff ff
ff cf ff ff ff ff ff ff ff ff cb ff ff ff 0f ff 3b ff ff ff ff ff ff ff ff
cf ff ff ff ff ff ff ff ff cf ff ff ff ff ff ff ff ff cb ff ff ff 0f ff 3b
ff ff ff ff ff ff ff ff cf ff ff ff ff ff ff ff ff cf ff ff ff ff ff ff ff
ff cb ff ff ff 0f ff 3b ff ff ff ff ff ff ff ff cf ff ff ff ff ff ff ff ff
cf ff ff ff ff ff ff ff ff cb ff ff ff 0f ff 3b ff ff ff ff ff ff ff ff cf
ff ff ff ff ff ff ff ff cf ff ff ff ff ff ff ff ff cb ff ff ff 0f ff 3b ff
ff ff ff ff ff ff ff cf ff ff ff ff ff ff ff ff cf ff ff ff ff ff ff ff ff
cb ff ff ff 0f ff 3b ff ff ff ff ff ff ff ff cf ff ff ff ff ff ff ff ff cf
ff ff ff ff ff ff ff ff cb ff ff ff 0f ff 3b ff ff ff ff ff ff ff ff cf ff
ff ff ff ff ff ff ff cf ff ff ff ff ff ff ff ff cb ff ff ff 0f ff 3b ff ff
ff ff ff ff ff ff cf ff ff ff ff ff ff ff ff cf ff ff ff ff ff ff ff ff cb
ff ff ff 0f ff 3b ff ff ff ff ff ff ff ff cf ff ff ff ff ff ff ff ff cf ff
ff ff ff ff ff ff ff cb ff ff ff 0f ff 3b ff ff ff ff ff ff ff ff cf ff ff
ff ff ff ff ff ff cf ff ff ff ff ff ff ff ff cb ff ff ff 0f ff 3b ff ff ff
ff ff ff ff ff cf ff ff ff ff ff ff ff ff cf ff ff ff ff ff ff ff ff cb ff
ff ff 0f ff 3b ff ff ff ff ff ff ff ff cf ff ff ff ff ff ff ff ff cf ff ff
ff ff ff ff ff ff cb ff ff ff 0f ff 3b ff ff ff ff ff ff ff ff cf ff ff ff
ff ff ff ff ff cf ff ff ff ff ff ff ff ff cb ff ff ff 0f ff 3b ff ff ff ff
ff ff ff ff cf ff ff ff ff ff ff ff ff cf ff ff ff ff ff ff ff ff cb ff ff
ff 0f ff 3b ff ff ff ff ff ff ff ff cf ff ff ff ff ff ff ff ff cf ff ff ff
ff ff ff ff ff cb ff ff ff 0f ff 3b ff ff ff ff ff ff ff ff cf ff ff ff ff
ff ff ff ff cf ff ff ff ff ff ff ff ff cb ff ff ff 0f ff 3b ff ff ff ff ff
ff ff ff cf ff ff ff ff ff ff ff ff cf ff ff ff ff ff ff ff ff cb ff ff ff
0f ff 3b ff ff ff ff ff ff ff ff cf ff ff ff ff ff ff ff ff cf ff ff ff ff
ff ff ff ff cb ff ff ff 0f ff 3b ff ff ff ff ff ff ff ff cf ff ff ff ff ff
ff ff ff cf ff ff ff ff ff ff ff ff cb ff ff ff 0f ff 3b ff ff ff ff ff ff
ff ff cc ff ff ff ff 01
----- end of leaf block dump -----

re: 位图索引深度探讨 知道得越多知道的越少 2006-05-29 13:46  
oracle 8.1.7.0.0

下面的实验:
--修改索引的一个键值(更新或插入行),是否会更新关于该索引的所有键的位图
--a.更新或插入的行,在同一个块内
--b.更新或插入的行,不在同一个块内

Oracle 8i
SQL> alter table H病人挂号记录 add 备注 char(2000);
SQL> truncate table H病人挂号记录;
SQL> Insert Into H病人挂号记录(Id,No,号别,执行人) Values(1,'G000001',1,'张1');
SQL> Insert Into H病人挂号记录(Id,No,号别,执行人) Values(2,'G000002',1,'张2');
SQL> commit;
--此时的位图
SQL> alter system dump datafile 1 block 40028;

row#0[8008] flag: -----, lock: 2
col 0; len 3; (3): d5 c5 31 --键值'张1'
col 1; len 6; (6): 00 40 9c 54 00 00 --rowid的起始位置
col 2; len 6; (6): 00 40 9c 54 00 07 --rowid的终止位置
col 3; len 1; (1): 00 --位图,当一个段中,只有一条记录的时候,oracle不是采用bitmap映射的方式,而是直接给出这条记录在这个段中的位置。例如这里的00表示了这个段中的第一条记录
row#1[7986] flag: -----, lock: 2
col 0; len 3; (3): d5 c5 32
col 1; len 6; (6): 00 40 9c 54 00 00
col 2; len 6; (6): 00 40 9c 54 00 07
col 3; len 1; (1): 01
row#2[8030] flag: ---D-, lock: 2
col 0; NULL
col 1; NULL
col 2; NULL
col 3; NULL
----- end of leaf block dump -----
End dump data blocks tsn: 0 file#: 1 minblk 40028 maxblk 40028


再插入一行键值为'张2'的,观察键值为'张1'的位图是否改变
SQL> Insert Into H病人挂号记录(Id,No,号别,执行人) Values(2,'G000002',1,'张2');
SQL> commit;
SQL> alter system dump datafile 1 block 40028;

row#0[8008] flag: -----, lock: 0
col 0; len 3; (3): d5 c5 31
col 1; len 6; (6): 00 40 9c 54 00 00
col 2; len 6; (6): 00 40 9c 54 00 07
col 3; len 1; (1): 00
row#1[7986] flag: ---D-, lock: 2
col 0; len 3; (3): d5 c5 32
col 1; len 6; (6): 00 40 9c 54 00 00
col 2; len 6; (6): 00 40 9c 54 00 07
col 3; len 1; (1): 01
row#2[7963] flag: -----, lock: 2
col 0; len 3; (3): d5 c5 32
col 1; len 6; (6): 00 40 9c 54 00 00
col 2; len 6; (6): 00 40 9c 54 00 07
col 3; len 2; (2): c8 06
----- end of leaf block dump -----
End dump data blocks tsn: 0 file#: 1 minblk 40028 maxblk 40028

对比位图的变化,键值为'张1'的位图(row#0[8008])并没有变化
键值为'张2'的位图,索引块内新增加了一个位图行(row#2[7963]),用新的位图来表示插入的行,旧的索引位图(row#1[7986])做了删除标记.
与10G的差别是,先删除了旧的位图,再增加新的位图来表示.

--b.更新或插入的行,不在同一个块内

SQL> exec show_space('H病人挂号记录','SYS','TABLE');

Free Blocks.............................1
Total Blocks............................8
Total Bytes.............................65536
Unused Blocks...........................6
Unused Bytes............................49152
Last Used Ext FileId....................1
Last Used Ext BlockId...................40019
Last Used Block.........................2

PL/SQL procedure successfully completed

--添加一列备注,添加5行信息,使表数据的存储超过1个块
SQL> Insert Into H病人挂号记录(Id,No,号别,执行人,备注) Values(1,'G000001',1,'张1',lpad('2000byte',2000,'*'));
1 row inserted
SQL> /
1 row inserted
SQL> /
1 row inserted
SQL> /
1 row inserted
SQL> /
1 row inserted

SQL> exec show_space('H病人挂号记录','SYS','TABLE');

Free Blocks.............................1
Total Blocks............................8
Total Bytes.............................65536
Unused Blocks...........................5
Unused Bytes............................40960
Last Used Ext FileId....................1
Last Used Ext BlockId...................40019
Last Used Block.........................3

PL/SQL procedure successfully completed

--对比前面的Last Used Block,由2变为了3,Unused Blocks由6变成了5,说明高水标记已移动了一个块的位置.
此时再插入数据,会放入块ID为40021的块中.

--先记下此时的索引块的情况
SQL> alter system dump datafile 1 block 40028;

row#0[8008] flag: ---D-, lock: 2
col 0; len 3; (3): d5 c5 31
col 1; len 6; (6): 00 40 9c 54 00 00
col 2; len 6; (6): 00 40 9c 54 00 07
col 3; len 1; (1): 00
row#1[7940] flag: ---D-, lock: 2
col 0; len 3; (3): d5 c5 31
col 1; len 6; (6): 00 40 9c 54 00 00
col 2; len 6; (6): 00 40 9c 54 00 07
col 3; len 2; (2): c8 09
row#2[7917] flag: ---D-, lock: 2
col 0; len 3; (3): d5 c5 31
col 1; len 6; (6): 00 40 9c 54 00 00
col 2; len 6; (6): 00 40 9c 54 00 07
col 3; len 2; (2): c8 19
row#3[7894] flag: -----, lock: 2
col 0; len 3; (3): d5 c5 31
col 1; len 6; (6): 00 40 9c 54 00 00
col 2; len 6; (6): 00 40 9c 54 00 07
col 3; len 2; (2): c8 39
row#4[7872] flag: ---D-, lock: 2
col 0; len 3; (3): d5 c5 31
col 1; len 6; (6): 00 40 9c 55 00 00
col 2; len 6; (6): 00 40 9c 55 00 07
col 3; len 1; (1): 00
row#5[7849] flag: -----, lock: 2
col 0; len 3; (3): d5 c5 31
col 1; len 6; (6): 00 40 9c 55 00 00
col 2; len 6; (6): 00 40 9c 55 00 07
col 3; len 2; (2): c8 03
row#6[7963] flag: -----, lock: 0
col 0; len 3; (3): d5 c5 32
col 1; len 6; (6): 00 40 9c 54 00 00
col 2; len 6; (6): 00 40 9c 54 00 07
col 3; len 2; (2): c8 06
----- end of leaf block dump -----
End dump data blocks tsn: 0 file#: 1 minblk 40028 maxblk 40028
--以上数据可以发现,由于刚才插入了5条键值为"张1"(d5 c5 31)的记录,
索引块中的位图行,发生了5次变化,删除了4个位图行,最后,键值为'张1'的共有两个位图行.(7894,7849)


--再插入键值为'张2'的记录,注意,此时插入的记录已经不在该表以前的块上了(块号:40019+3)
SQL> Insert Into H病人挂号记录(Id,No,号别,执行人) Values(2,'G000002',1,'张2');
SQL> commit;

--索引的块没有变,仍是40028
SQL> alter system dump datafile 1 block 40028;

row#0[7894] flag: -----, lock: 0
col 0; len 3; (3): d5 c5 31
col 1; len 6; (6): 00 40 9c 54 00 00
col 2; len 6; (6): 00 40 9c 54 00 07
col 3; len 2; (2): c8 39
row#1[7849] flag: -----, lock: 0
col 0; len 3; (3): d5 c5 31
col 1; len 6; (6): 00 40 9c 55 00 00
col 2; len 6; (6): 00 40 9c 55 00 07
col 3; len 2; (2): c8 03
row#2[7963] flag: -----, lock: 2
col 0; len 3; (3): d5 c5 32
col 1; len 6; (6): 00 40 9c 54 00 00
col 2; len 6; (6): 00 40 9c 54 00 07
col 3; len 2; (2): c8 06
row#3[7827] flag: -----, lock: 2
col 0; len 3; (3): d5 c5 32
col 1; len 6; (6): 00 40 9c 55 00 00
col 2; len 6; (6): 00 40 9c 55 00 07
col 3; len 1; (1): 02
----- end of leaf block dump -----
End dump data blocks tsn: 0 file#: 1 minblk 40028 maxblk 40028

--与上面的比较发现,索引块内键值为"张2"的范围(7963)没有像上次增加5条键值为"张1"的那样被删除,而是只增加了新的段:7827
--这是因为新插入的数据行已经不在原来的块上,原有的索引块内的段位图已无法表示,需要索引块内用新的段位图来表示.
--另外,注意到由于新的索引数据的产生,以前插入5条记录时标记为删除(-D)的索引块内的段已经被回收.

--这一点与10G差别较大,10G中一个键值一直只有一个位图,即使键值对应的数据分布在不同的数据块中.

re: 全表扫描比索引更慢吗?物理访问比逻辑读更慢吗? 知道得越多知道的越少 2006-04-06 14:14  
Oracle 8i的优化模式缺省是Choose,即使你没有分析过表,Oracle仍然会在某些情况下选择CBO

上面这个例子就是这样,我并没有分析过表,但是Oracle却选择了CBO

Hash连接的好处与表的大小关系不大,主要是它是在用户区建立Hash矩阵来实现快速匹配.在并发下,可以大量减少栓锁.

而上面那个例子的索引扫描慢,是因为嵌套循环,每次循环对索引的读取的单块顺序读,因为索引范围扫描是对一个双向链表进行读,只能顺序读.

嵌套连接和Hash连接之所以慢,举个例子:
有1000个男的和1000个女的,按高矮进行配对跳舞.
如果用嵌套连接的话,在一个公用的广场上,有一个教练,他先对1000个男的和女的按高矮排序编号(建索引),再对1000个编号中的每一个(1000次循环),去匹配那些排好序的1000个女的编号,找到后,再根据编号去找他们的位置,一直牵手走出来。
如果这时,广场上有很多人,会很挤,可能排对进行,如果同时有很多教练要对这两千个人男女,进行同样的操作,就会形成争用,需要锁定和排队。

如果用Hash连接的话,这个教练它会找一个私有房间,把这些人的档案复印一份,直接对1000个男的和女的档案建立两个Hash矩阵图,这个图中记录这些人的位置,不用事先排序和编号,使用一种快速算法进行配对,配对完成后,再排序。如果同时有很多教练做相同的操作,他们都使用自己的私有房间,不会形成争用。
re: HIS行业的技术先锋?先烈? 知道得越多知道的越少 2006-04-06 10:09  
@jackei
我并不是说卢彦现在的做法有什么问题.相反,他的作法确实很先进.
我对卢彦的才华和技术是很佩服的,并且他是一个很有思想的成熟程序员.只是觉得趟上HIS这混水,太不值得了.
如果选择了其它行业,成功不会这么辛苦.主要是中国的HIS没有规范,行业成熟度很低.需要很大的投入,付出很多艰辛,但是收获少,并且需要较长的周期.
re: HIS行业的技术先锋?先烈? 知道得越多知道的越少 2006-04-06 10:03  
@[ IceSharK - PP.Poet ]
没有看过Cambio,不妨介绍一下.
re: HIS行业的技术先锋?先烈? [ IceSharK - PP.Poet ] 2006-04-06 09:51  
楼主 看过 Cambio 没有?


re: HIS行业的技术先锋?先烈? jackei 2006-04-05 19:46  
嗯,有点同意。
从 2001-2004 年间一直在从事 HIS 系统的研发和测试,截止到 2001 年之前是 6 年漫长的 医学生 生涯。就个人对医院业务的理解和开发经验来看,做一个通用的 HIS 系统的确是不太现实的,因为那需要系统提供极大的灵活性——至于多大,恐怕是要多大有多大。先不说不同的省份的医院对需求的不同,及时同一地区的医院,在内部核算方式、内部业务流程方面也都会一些差别,最常见的就是某些业务需求会影响到门诊或住院结算的算法,而不同的内部核算方式又会影响报表和数据表结构的设计。一般来说,分地区有一个稳定版本是可行的,例如广东版、浙江版,但是每个地区的版本在每次实施时也有 20% 左右的代码修改量——以往的经验。

估计作一些符合 HIS 系统需求的通用控件还可以考虑一下,但是整个庞大的 HIS 系统也做成通用,似乎有些理想化。

另外,他在自己的 blog 中说的:举个实际点的例子,如果你们的产品有几万个互相之间有联系的业务模块,改动其中任何一个模块都有可能会对许多模块造成影响。那么你为了让软件可以被修改,你就必须制订一套非常严格的管理流程来控制修改行为,比如要修改之前先要提交变更申请,然后由公司组织一个专家委员会来对每个模块进行详细的检查来评估你的修改会对现在的软件造成什么影响,然后还要制订一个修改策略,最后由测试人员做验收测试。恩,看起来这个软件公司的管理水平非常高,你也许会认为这家软件公司很优秀是吧?错!正是因为这家公司的软件技术水平不行,因为当初没有做好设计,没有把变化集中到一处,没有做好自动化测试,所以才不得不制订这么严格的一套高成本管理流程来保证软件可以被正确修改。

这个例子太极端了。
估计是版太低。我是在8.1.7上成功的,记得还有init文件中的兼容参数也要改。
请问还有其他的需要设置吗,为什么我的总是不行呢
ORA-29278: SMTP 临时性错误: 421 Service not available
ORA-06512: 在 "SYS.UTL_SMTP", line 21
ORA-06512: 在 "SYS.UTL_SMTP", line 97
ORA-06512: 在 "SYS.UTL_SMTP", line 139
ORA-06512: 在 "SYSTEM.POST_HTML_MAIL", line 17
ORA-06512: 在 line 2
mail:pxiaoxiao9911@163.com
re: Oracle外部身份认证研究 猜猜 2006-01-16 11:33  
好文章,支持多发,谢谢
re: 字符集编码ANSI和UNICODE 王者之风 2005-12-23 14:30  
搞错了,应该是
EF BB BF    UTF-8
FE FF     UTF-16/UCS-2, big endian
FF FE     UTF-16/UCS-2, little endian
好象中文不可以,英文就可以
re: Cache缓存的一个初级错误 王 2005-08-26 16:27  
和你遇到同样问题,但是去掉 ds.Clear(),还是不行,郁闷
问:需要设置怎样的邮件服务器
请mail:sinbo@e165.com
我用的是ORACLE 8.1.5.0.0。以前在P4的服务器上安装,只设置USE_SHARED_SOCKET=TRUE就可以透过防火墙连接到服务器上了。现在我们新安装了一台CPU是XEON的服务器,设置USE_SHARED_SOCKET=TRUE不能连接,看到你的文章后,在INIT .ORA中加入了mts_dispatchers="(address=(protocol=tcp)(host=MainServer)(port=1521))(dispatchers=1)" 参数,从TCP端口检查来看,都是使用1521连接了,但防火墙外的客户端还是连接不上,并且也可以看到,SERVER的确也是使用1521来连接了。不知这又是什么原因?为什么在P4下是可以的,而到了XEON下就不行了。

re: 来点入门级的:最近遇到的一些小问题及经验 知道得越多知道的越少 2005-05-26 10:32  
估计博客园的高手也就那么十来个,处于金字塔顶端的必竟是少数.
所以发在这里是正确的,为大多数爱好者们一起交流经验.
况且,即便是高手,也会范一些低级错误的.基础的问题,不一定都知道的.
感觉博客园对初学者不是很友好啊,难道来这里的都是传说中的高手?
老大 你去那发好不?
re: 字符集编码ANSI和UNICODE 过客 2005-05-07 10:40  
我检测了一下好像是这样的
EF BB BF    UTF-8
FE FF     UTF-16/UCS-2, big endian
FF FE     UTF-16/UCS-2, little endian

没有做过.
不过微软的KB提供了代码,有兴趣的可以做一下.
http://support.microsoft.com/default.aspx?scid=kb;zh-cn;246335
有没有关于导入的测试?
当然啦,DataValueField是作为检索Key的
如果在windows 2000平台上该如何实现Oracle客户端穿过防火墙连接服务器呢?
不是博客园的.Text程序, 是CSDN的.Text程序。可能另外用了一些博客园.Text的代码, 搜索代码的确用的是博客园的。
re: 国内最大的IT门户-天极网也采用了博客园的.TEXT程序 unruledboy(灵感之源) 2004-11-24 22:18  
不知道跟dudu打招呼了没有
共2页: 1 2 下一页 

导航

统计

公告

对你说打错了 我不是你那个什么
你想找的那个 就算我跟她同名同姓又如何
都说你打错了 我要欺骗你干什么
你们多久没见连 我跟她的声音你都不认得
你怎么样过 什么样的生活 是否难耐寂寞
你到底是谁 总是阴差阳错 擦过我的耳朵
第几次打错了 这是注定还是巧合
谁是玛格列特 她知道你的着急一定很快乐
你们发生什么 还是你欠了她什么
有什么舍不得 她不住这里你却非找她不可
你怎么样过 什么样的生活 是否难耐寂寞
你到底是谁 总是阴差阳错 擦过我的耳朵
你怎么样过 什么样的生活 是否难耐寂寞
你到底是谁 总是阴差阳错 擦过我的耳朵
你们会讲什么口气会不会软软的
你紧张得想哭 多年后想起今天值得不值得

与我联系

搜索

 

常用链接

留言簿(4)

我参与的团队

我的标签

随笔分类

随笔档案

文章分类

文章档案

收藏夹

音乐

有价值的blog

最新评论

阅读排行榜

评论排行榜