程序是用DELPHI XE2+SQL2000个人版在XP环境下开发的老板带了个笔记本过来，让我把程序拷贝上去他带到新疆去给客户演示。我看到他的笔记本上的操作系统是WIN7心里咯噔了一下。拷贝仩去可是连接数据库时报错：通讯模块无效,驱动程序安装不正确。

    郁闷啊立即百度，说是少了dbNET什么的DLL按照网友的说法去做了，故障依旧怎么办？老板明天就要去演示了该试的方法都尝试了，不行于是我让他去网上下载一个SQL2005(64位)的开发版，因为他的机子是64位旗舰版嘚WIN7现在还在下载中。

    各位同行老大根据我这描述的情况，你们有什么高招请指点一下，不胜感谢！！！

   最近我在SQL Server6.5下开发的一个程序（假设为程序A)经常“死锁”，经过分析发现是由于该程序调用的一个存储过程将一个表锁住，但是该表也就是该存储过程单独使用另外，该死锁的进程不管是在SQL Server还是NT下都无法Kill掉结果，只能在备份完数据库后采取重起机器，机器重起并且SQL Server服务也启动后发现相应的应用數据库整个变灰，然后SQL Server自动进行Recovering操作等恢复完成后，再次启动A程序程序能正常运行。

  最后一次由于忘了备份，结果等我重起机器后SQL Server的服务可以Start，但是所有的数据库都打不开了，包括系统数据库如Master等

        使SQL Server在Linux上运行涉及将所谓的平台抽潒层（“PAL”）引入SQL Server该层用于在一个位置对齐所有操作系统或平台特定代码，并允许其余代码库保持与操作系统无关由于SQL Server在单一操作系統Windows上的悠久历史，它从不需要PAL实际上，SQL Server数据库引擎代码库对Windows上流行的库提供了许多引用以提供各种功能。在将SQL Server引入Linux时我们为自己设置了严格的要求，以便将SQL Server RDBMS的全部功能性能和规模价值带到Linux。这包括能够在Windows上的SQL Server上运行良好的应用程序在Linux上对SQL Server同样有效的能力用SQL Server现有的岼台层（SOS）来创建我们称之为SQLPAL的东西。为了安全容器的目的Drawbridge项目提供了底层操作系统和应用程序之间的抽象，SOS提供了强大的内存管理線程调度和IO服务。创建SQLPAL使得现有的Windows依赖项可以在Linux上使用借助Drawbridge设计的一部分，专注于操作系统抽象同时将关键的OS服务留给SOS。我们还在更妀SQL Server数据库引擎代码以绕过Windows库并直接调用SQLPAL以获得资源密集型功能

SQL Server是微软的旗舰数据库产品，其背后有近30年的发展历史在较高的层次上，丅面的列表代表了我们的要求因为我们设计了使SQL Server RDBMS在多个平台上可用的解决方案：

1. 质量和安全性必须符合我们在Windows上为SQL Server设置的相同高标准
2. 在功能，性能和规模方面提供相同的值
3. 在SQL Server代码库中实现持续快速的创新并确保跨平台立即显示新功能和修复

为了使SQL Server支持多个平台，工程任務本质上是删除或抽象其在Windows上的依赖项可以想象，经过数十年针对单个操作系统的开发代码库中存在大量特定于操作系统的依赖关系。此外代码库是巨大的。SQL Server中有数千万行代码

SQL Server依赖于Windows开发中常用的各种库及其功能和语义，分为三类：

您可以将它们视为核心库函数咜们中的大多数与操作系统内核无关，只能在用户模式下执行

虽然SQL Server依赖于Win32和Windows内核，但最复杂的依赖是多年来为了提供新功能而添加的Windows应鼡程序库这里有些例子：

• SQLCLR承载两种系统类型的公共语言运行时（）以及用户定义的类型和CLR存储过程。
• SQL Server有一些用编写的比如用于备份的接ロ
• 通过Microsoft分布式事务处理协调器（MS ）控制异构分布式事务

这些依赖关系是我们克服的最大挑战，以实现我们的目标即在Windows和Linux上实现相同的價值和SQL Server之间的高度兼容性。例如重新实现像SQLXML这样的东西需要花费大量的时间，并且存在不能提供与以前相同的语义的高风险并且可能會破坏应用程序。完全删除这些依赖项的选项意味着我们还必须删除它们在Linux上从SQL Server提供的功能如果依赖关系是边缘情况并且仅影响很少的愙户可见特征，我们可以考虑它事实证明，删除它们会导致我们不得不从Linux上的SQL Server中删除大量功能这违反了我们关于跨操作系统的兼容性囷价值的目标。

我们可以采取逐步实现这种重新实施的方法一点一点地带来价值。虽然这是可能的但它也会违背要求，因为这意味着Linux囷Windows上的SQL Server之间会存在很大的差距解决方案在于正确的平台抽象层。

跨多个操作系统支持的软件总是具有某种平台抽象層（PAL）的实现。PAL层负责从软件本身抽象底层操作系统及其库的调用和语义接下来的几节将我们研究的一些技术作为构建PAL for SQL Server的解决方案。

在SQL Server 2005發行版中在SQL Server引擎和Windows之间创建了一个称为SQL操作系统（SOS）的平台层。该层负责用户模式线程调度内存管理和同步（请参阅以供参考）。创建SOS的一个关键原因是它允许向客户和支持（动态管理视图/ DMV和扩展事件/ XEvent的子集）提供集中的低级管理和诊断功能该层允许我们通过非抢先運行并让SQL Server自己进行资源管理来最小化调度执行所涉及的系统调用数。虽然SOS提高了性能并极大地帮助了可支持性和调试但它没有从上面描述的OS依赖性中提供适当的抽象层，即Windows语义通过SOS进行并暴露给数据库引擎

在我们将从数据库引擎中完全删除底层操作系统依赖关系的场景Φ，最好的选择是将SOS扩展到适当的平台抽象层（PAL）  所有对Windows API的调用都将通过SOS中的一组新等效API进行路由，并且将在SOS底部添加一个新的主机扩展层以便与操作系统进行交互。虽然这会解决系统调用依赖性但它对较高级库的依赖性没有帮助。

Drawbridge是一个微软研究项目（见供参考）專注于大幅减少在同一硬件上托管许多虚拟机时产生的虚拟化资源开销该研究涉及两个想法。第一个想法是“picoprocess”它包括一个空地址空間，一个代表picoprocess与主机操作系统交互的监视器进程以及一个允许驱动程序在启动时填充地址空间并实现一个内核驱动程序的内核驱动程序。主机应用程序二进制接口（ABI）允许picoprocess与主机交互。第二个想法是用户模式库操作系统有时也称为LibOS。Drawbridge提供了一个可用的Windows库操作系统可鼡于在Windows主机上运行Windows程序。

我们的需求与Drawbridge研究的最初目标不一致例如，picoprocess的想法不是将SQL Server移动到其他平台所需要的然而，有一些突出的协同莋用：

1. 库操作系统在用户模式下实现了大多数1500多个Windows ABI只需要45-50个ABI即可与主机进行交互。这些ABI用于地址空间和内存管理主机同步和IO（网络和磁盘）。这使得需要实现非常小的表面区域以与主机交互从平台抽象的角度来看，这非常有吸引力
2. Library OS能够托管其他Windows组件。已经实现了足夠的Win32和NT层来托管CLRMSXML和SQL套件所依赖的其他API。这意味着我们可以在不重写整个功能的情况下获得更多功能

还有一些风险和回报权衡：

1. Microsoft Research项目已唍成，并且不支持Drawbridge因此，我们需要获取源快照并根据我们的目的修改代码风险是围绕在操作系统库上增加团队成本，将其修改为适合SQL Server并使其与Windows相媲美的成本。从积极的方面来说这意味着一切都处于用户模式，我们将拥有堆栈中的所有代码性能关键代码可以进行优囮，因为我们可以根据需要修改堆栈的所有层包括SQL Server，库操作系统和主机接口以使SQL Server执行。由于进程中没有真正的边界因此SQL Server可以调用Linux。
2. 朂初的Drawbridge项目是在Windows上构建的并使用了内核驱动程序和监视器进程。这将需要被删除以支持仅用户模式的架构。在新架构中Windows上的主机扩展（在Drawbridge设计中称为PAL）将从内核驱动程序转移到用户模式程序。有趣的是其中一位研究人员为Linux开发了一个粗略的原型，证明它可以完成
3. 甴于这些技术是独立创建的，因此存在大量重叠功能SOS具有用于对象管理，内存管理线程/调度，同步和IO（磁盘和网络）的子系统库OS和主机扩展也具有类似的功能。这些系统需要合理化为单一实施

经过调查，我们决定采用混合策略我们将从Drawbridge合并SOS和Library OS来创建SQL PAL（SQL平台抽象层）。对于SQL Server不需要的库OS的区域我们将删除它们。要合并这些体系结构需要在堆栈的所有层中进行更改。

新架构由一组SOS直接API组成这些API不通过任何Win32或NT系统调用。对于没有SOS直接API的代码他们将通过托管的Windows API（如MSXML）或NTUM（NT用户模式API - 这是1500+ Win32和NT系统调用）。所有子系统（如存储网络或资源管理）都将基于SOS，并将在SOS direct和NTUM API之间共享

该架构提供了一些有趣的特性：

• 正在运行的所有内容归结为相同的平台汇编代码。CPU无法区分提供Win32功能的代码与SQL Server或本机Linux代码之间的区别
• 尽管架构显示了分层，但在流程中没有真正的界限如果在SQL Server中运行的性能至关重要的代码需要调用Linux，它可以通过SOS直接API直接使用极少量的汇编程序来正确设置堆栈并处理结果完成此操作的示例是磁盘IO路径。还有少量转换代码可以从Windows分散/聚集输入结构转换为Linux向量IO结构其他磁盘IO类型不需要任何转换或分配。
• 可以通过SQLPAL管理进程中的所有资源在SQL Server中，在SQLPAL之前大多数资源（如內存和线程）都受到控制，但是有一些东西可以控制一些库和Win32 / NT API将自己创建线程并在不使用SOS API的情况下进行内存分配。使用这种新架构即使Win32和NT API也将基于SQLPAL，因此每个内存分配和线程都将由SQL

下图显示了运行时地址空间的外观主机扩展只是一个本机Linux应用程序。当主机扩展启动时它会加载并初始化SQLPAL，然后SQLPAL会启动SQL ServerSQLPAL可以启动软件隔离的进程，这些进程只是在同一地址空间内运行的线程和分配的集合我们将它用于SQLDumperの类的东西，SQLDumper是一个在SQL Server遇到问题时运行的应用程序用于收集启发的崩溃转储。

需要重申的一点是即使这可能看起来像很多层，但SQL Server和主機之间没有任何硬边界

在项目开始时，SQL Server建立在SOS上而Library OS是独立的。最终的目标是将合并的SOS和库操作系统作为SQL PAL的核心对于公开预览，此合並尚未完全完成但SQLPAL的核心已被SOS取代。例如线程和内存已经使用SOS功能而不是原始的Drawbridge实现。

现在我们正在努力从SQL Server中删除SOS实例我们正在从SQLPAL公开SOS API。一旦完成一切都将流经单个SQLPAL SOS实例。