该内存不能为read修复工具（内存不能为read修复工具有用吗）

全表扫描和等待时间相关联，往往伴随着“db file scattered read”等待。区分大小表是因为全表扫描可能引起buffer cache抖动。默认情况下，大表的全表扫描会处于LRU末端，以期尽早老化，减少buffer的占用。从8i开始，Oracle提供了多缓冲区技术，给我们提供了另一种选择。针对不同的表，我们可以采取不同策略，使内存使用更加有效。

在11g中是否对表执行直接路径读的全表扫描，是由优化器根据表的大小进行判断。主要受限于两个参数：一个是_small_table_threshold，它代表一个小表的阀值（如果表大于5倍的小表限制，则自动使用直接路径读，代替传统读的方式）；另一个是_very_large_object_threshold，当表大于0.8倍的这个参数时，也会使用直接路径读。

32位的VB使用64位DLL，系统本身就支持哦！

1、笔者在前几篇中讨论VB在64位Win中如何充分利用Win的兼容特性时，提到了一款开源32位DLL（wow64ext），可供VB完成诸如Hook注入64位进程、64位进程地址空间的内存分配及读写，使用64位库资源从而实现充分利用新硬件资源等。

2、在网友的提示下，笔者去看了下64位Win下32位地址空间载入的Ntdll.dll，发现有很多跟WOW64兼容层有关的函数。比如ZwWow64CallFunction64，ZwWow64QueryVirtualMemory64，ZwWow64ReadVirtualMemory64，ZwWow64WriteVirtualMemory64，ZwWow64QueryInformationProcess64等。

3、这说明，系统实际上提供了32位访问64位库的API，谁说VB死了呢！就是不知那句『32位与64位互不能加载』是何用意了？只不过，这些函数均未文档化，在官网上查不到相关函数原型。

关注BtOfficer呀，更多精彩仍在继续哦，有严肃的技术，也有轻松的唠嗑，期待你的加入！