Dav*_*ton 16
现有的每个数据库引擎都需要定期维护操作,以优化数据存储并恢复松弛空间.回到xBase时代,您运行了一个PACK命令来删除已删除的行.在SQL Server上,您运行脚本以缩小实际数据文件的原因相同.
为什么每个数据库引擎都这样做？
因为如果每次写入数据库都必须按优化顺序重写整个文件,那将是一个巨大的性能损失.考虑将每个数据表存储在单独文件中的数据库.如果一个表有10000条记录,并且你删除了第5000条记录,为了摆脱松弛空间,你必须重写整个数据文件的后半部分.相反,每个数据库都使用某种形式标记用作未使用的空间,并在下次在数据表上运行优化操作时丢弃.
Jet/ACE在这方面与任何其他数据库引擎没有什么不同,使用Jet/ACE数据库作为数据存储的任何应用程序都应该安排定期维护操作,包括备份和紧凑.
Jet/ACE中存在一些在服务器数据库引擎中不存在的问题.具体而言,除非所有用户都已关闭与数据文件的连接,否则无法压缩.在服务器数据库中,用户连接到数据库引擎的服务器端进程,并且该服务器端恶魔是存储数据的实际数据文件的唯一"用户".因此,服务器恶魔可以决定何时执行优化和维护例程,因为它完全控制数据文件何时在使用中.
Access应用程序的一个常见问题是,用户将在他们的计算机上打开他们的应用程序并离开办公室,这意味着当您运行紧凑操作时,例如在凌晨2:00,文件仍处于打开状态,您可以'运行它(因为compact替换原始文件).遇到此问题的Access应用程序的大多数程序员要么容忍偶尔的这种隔夜维护失败(卷影复制仍然允许备份文件,尽管不能保证备份副本将处于100%内部一致的状态)或者他们将设计他们的Access应用程序,以便在适当的时间终止,以便进行隔夜维护操作.我自己也做过这两件事.
在非Access应用程序中,存在同样的问题,但必须以不同方式解决.对于Web应用程序来说,这是一个问题,但总的来说,我会说任何一个足以搅拌数据的Web应用程序,需要一个紧凑的Jet/ACE数据存储是完全不合适的.
现在,关于COMPACT ON CLOSE的主题:
任何人都不应该使用它.
永远.
当它真正开始时,它是无用且彻头彻尾的危险.
它没用,因为没有正确构建的生产环境,用户可以在其中打开后端 - 如果它是一个Access应用程序,它应该被拆分,用户只打开前端,如果它是一个Web应用程序,用户不会直接与数据文件进行交互.所以在这两种情况下,没有人会触发COMPACT ON CLOSE,所以你浪费了你的时间来打开它.
其次,即使有人偶尔会触发它,但只有当用户是唯一一个打开数据库的用户时,它才会起作用.正如我上面所说,如果有其他用户打开它就无法压缩,所以这也行不通 - COMPACT ON CLOSE只能在触发它的用户具有独占访问权限时运行.
但最糟糕的是,COMPACT ON CLOSE是危险的,如果确实运行会导致实际的数据丢失.这是因为某些状态可能存在Jet/ACE数据库,其中内部结构不合适,但数据仍可访问.在该状态下运行压缩/修复操作时,数据可能会丢失.这是极其罕见的情况,但这是一个非常遥远的可能性.
关键是COMPACT ON CLOSE不是有条件的,并且没有提示询问您是否要运行它.你没有机会在它运行之前进行备份,所以如果你打开它并且当你的数据库处于这种非常罕见的状态时它会启动,那么你可能会丢失你能够恢复的数据.你没有运行紧凑的操作.
因此,简而言之,任何对Jet/ACE和压缩有任何理解的人都不会打开COMPACT ON CLOSE.
对于单个用户,您可以根据需要进行压缩.
对于共享应用程序,某种预定维护脚本是最好的,通常在文件服务器上运行一夜.该脚本将备份该文件,然后运行压缩文件.这是一个非常简单的脚本,可以用VBScript编写,并且可以轻松安排.
最后,如果您的应用程序经常删除大量记录,在大多数情况下,这表示设计错误.在常规生产使用中添加和删除的记录是TEMPORARY DATA,并且在逻辑上和实际上都不属于主数据文件.
我的所有生产应用程序都有一个临时数据库作为体系结构的一部分,所有临时表都存储在那里.我从不打算压缩临时数据库.如果出于某种原因由于临时数据库中的膨胀导致性能陷入困境,我只是将临时数据库的原始空副本复制到旧数据库的顶部,因为其中没有任何数据是临时的.这减少了前端或后端的流失和膨胀,并大大降低了后端数据文件中必要压缩的频率.
关于如何压缩的问题,有很多选择:
在Access UI中,您可以压缩当前打开的数据库(TOOLS | DATABASE UTILITIES).但是,这不允许您作为过程的一部分进行备份,并且在压缩之前备份总是一个好主意,以防出现问题.
在Access UI中,您可以压缩未打开的数据库.这个从现有文件压缩到新文件,因此当您完成后,您必须重命名原始文件和新压缩文件(以获得新名称)."文件打开"对话框询问您要压缩的文件允许您在该点重命名文件,因此您可以在手动过程中执行此操作.
在代码中,您可以使用DAO DBEngine.CompactDatabase方法来完成这项工作.这可以从Access VBA,VBScript或任何可以使用COM的环境中使用.您负责执行备份和重命名文件等的代码.
代码中的另一个选项是JRO(Jet和复制对象),但它没有提供DAO尚未拥有的紧凑操作.JRO是作为一个单独的库创建的,用于处理ADO本身不支持的Jet特定功能,因此如果您使用ADO作为接口,MS推荐的压缩库将是JRO.在Access中,JRO不适合压缩,因为您已经拥有CompactDatabase方法,即使您没有DAO引用(无论您是否具有DAO引用,DBEngine始终在Access中可用).换句话说,DBEngine.CompactDatabase可以在Access中使用,而无需DAO或ADO引用,因为JRO CompactDatabase方法仅适用于JRO引用(或使用后期绑定).从Access外部,
让我强调备份的重要性.你不会需要999次(甚至更少),但是当你需要它时,你需要它很糟糕!因此,如果事先没有备份就永远不紧凑.
最后,在任何压缩之后,检查压缩文件以查看是否存在名为MSysCompactErrors的系统表是个好主意.该表将列出在压缩过程中遇到的任何问题,如果有的话.
这就是我现在能想到的关于契约的全部内容.
打开mdb并执行"压缩和修复".这将减小mdb的大小.
您还可以将"Compact on Close"选项设置为on(默认情况下为off).
以下是一些其他信息的链接:http: //www.trcb.com/computers-and-technology/data-recovery/ways-to-compact-and-repair-an-access-database-27384.htm
| 归档时间： |
|
| 查看次数： |
31451 次 |
| 最近记录： |