把Oracle数据库移植到Microsoft SQL Server 7.0(1)

关键词：Sql Server, Oracle

应用程序的移植似乎非常复杂。在不同的关系数据管理系统之间有太多的结构差异。用来描述Oracle结构的

用词和术语通常与该词在Microsoft SQL Server中的意思完全不同。另外，Oracle和SQL Server都对SQL-92

标准做了许多自有的扩展。

从一个应用程序开发人员的观点来看，Oracle和SQL Server是以相似的方法来管理数据的。在Oracle和SQL

Server之间有着重大的内部区别，但是如果管理得当，可以把这些区别对移植的影响减到最小。

SQL语言扩展

开发人员面临的最重要的移植问题是执行SQL-92语言标准和每一个关系数据管理系统提供的语言扩展。有一

些开发人员只使用标准的SQL语法，喜欢尽可能的保持他们的程序代码的普遍性。通常，这种方法把程序代

码限制在SQL-92标准的登录级别（entry-level）上，而这个级别是被许多的数据库产品实现了的，包括

Oracle和SQL Server。

这种方法将会产生一些不必要的程序代码复杂性而且还会对程序的性能造成很大的影响。例如，Oracle的

DECODE函数是一个非标准的SQL扩展。Microsoft SQL Server的CASE表达式是一个超越了登录级别的SQL-92

扩展，而且在所有其他的数据库产品中都没有实现。

Oracle的DECODE和SQL Server的CASE都是可选的，你可以不用这两个函数而实现它们的功能，而这需要从关

系数据管理系统中提取更多的数据。

还有，对SQL语言的程序扩展也会造成困难。Oracle的PL/SQL和SQL Server的Transact-SQL语言在函数上是

相似的，但是在语法上不同。在两种数据库和程序扩展中间没有明确的对称性。因此，你可能会决定不使用

想程序和触发器这样的存储的程序。这是很不幸的，因为它们提供了别的任何方式都无法实现的性能和安全

性上的优点。

私有开发接口的使用带来了新的问题。用Oracle OCI（Oracle Call Interface）进行程序转换通常需要很多

资源。开发一个可能用到多个关系数据管理系统的应用程序，最好是考虑使用开放数据库连接（Open

Database Connectivity，ODBC）接口。

ODBC

ODBC是为同多个数据库管理系统协同工作而设计的。ODBC提供了一个一致的应用程序编程接口（application

programming interface，API），该接口使用一个针对数据库的驱动程序同不同的数据库协同工作。

一致的应用程序编程接口意味着程序用来建立连接、执行命令以及获取结果的函数是一样的，无论该程序是和

Oracle还是SQL Server对话。

ODBC同时还定义了一个标准化的调用级别的接口并且针对那些不同数据库里完成同样任务但语法不同的SQL函

数使用标准的出口次序。ODBC驱动器可以自动的把这个ODBC语法转化为Oracle或者SQL Server的本地语法，

这个过程不需要对程序代码做任何的修订。在某些情况下，最好的方法是编写一个程序并且让ODBC在运行时

间执行转换处理。

ODBC并不是一个万能的可以针对任何数据库实现完全独立的、完整功能和高性能的解决方案。不同数据库和

第三方经销商提供了对ODBC不同级别的支持。一些驱动器仅仅实现了核心的API函数，这些函数映射了顶层或

者其他接口库。其他一些驱动器，例如Microsoft SQL Server的驱动器，在一个本地的、高性能的驱动器中

提供了完整的２级支持。

如果一个程序仅使用核心的ODBC API，它很可能会丢弃某些数据库的特征和性能。此外，并不是所有的本地

SQL扩展都可以在ODBC出口次序中描述的（例如Oracle的DECODE和SQL Server的CASE表达式）。

另外，书写SQL语句来利用数据库优化器是意见很自然的事情。但是在Oracle中用来扩展数据库性能的技术和

方法在Microsoft SQL Server 7.0中不一定是最好的。ODBC接口并不能把一个系统所用的技术翻译为另一个

系统的技术。

ODBC并不影响一个应用程序使用数据库专有的特征和调整来提高性能，但是应用程序需要某些数据库专有的

代码部分。ODBC使得在多个数据库间保持程序结构和多数程序代码一致变得容易。

OLE DB

OLE DB是下一代数据访问技术。Microsoft SQL Server 7.0利用包含在其自身的组件之中的OLE DB。这样，

应用程序开发人员可以考虑使用OLE DB来进行新的SQL Server 7.0开发。微软在SQL Server 7.0中还提供了

支持Oracle 7.3的OLE DB。

OLE DB是微软用来管理跨组织的数据的战略性的系统级编程接口。OLE DB是在ODBC特征上建立的具有开放性

的设计。ODBC是设计来访问相关的数据库的，而OLE DB则是设计来访问相关的或者不相关的信息源，例如主

机上的ISAM/VSAM和分层数据库，电子邮件和文件系统存储，文本、图像和地理数据以及定制的业务对象。

OLE DB了一组COM接口以压缩不同的数据库管理服务，同时还允许创建软件组件来实现这些服务．OLE DB组件

包含了数据提供者（保持和显露数据）、数据消费者（使用数据）以及服务组件（处理和传输数据，例如查

询处理器和光标引擎）。

OLE DB接口的设计目的是帮助实现组件的平滑集成，这样的话OLE DB组件提供商就可以迅速的向市场提供高

质量的OLE DB组件了。此外、OLE DB还包含一座连接ODBC的桥梁，如此就可以为今天可以得到的大量的ODBC

相关的数据库驱动程序继续提供支持了。

本文的组织方式

为了帮助你一步一步的实现从Oracle到SQL Server的转换，本文的每一部分都有一个关于Oracle7.3和

Microsoft SQL Server 7.0的不同之处的概述。同时还包括转换的考虑，SQL Server 7.0的优势以及多个实

例。

结构和术语

作为成功移植的开始，你应该掌握Microsoft SQL Server 7.0所用的基本的结构和术语。这一部分中的许多

例子都是从本文包含的Oracle和SQL Server应用程序中截取下来的。

数据库的定义

在Oracle中，数据库是指整个Oracle RDBMS环境，并且包含以下组件。

Oracle数据库处理过程和数据缓存（实例）。

包含一个集中的系统目录的SYSTEM表空间。

DBA定义的其它表空间（可选的）。

两个或者多个Redo日志。

存档的Redo日志（可选）

各种其它文件（控制文件、Init.ora等等）。

一个Microsoft SQL Server数据库提供了数据、应用程序以及安全机制的逻辑区分，更像一个表空间（

tablespaces）。正如Oracle支持多个表空间，SQL Server也支持多个数据库。表空间也用来提供数据的物

理放置，SQL Server通过文件组（filegroups）来提供同样的功能。

Microsoft SQL Server将缺省的安装下列数据库。

model数据库是所有新建用户数据库的模板。

Tempdb数据库跟Oracle中的临时表空间很相象，都是用来进行临时的工作储存以及排序操作。不同的是，当

用户退出登录时，Microsoft SQL Server自动删除其创建的临时表空间。

Msdb数据库支持SQL Server代理以及其预定的工作、警报和复制信息。

Northwind和pubs数据库是用于培训的实例数据库。

如果想获得缺省数据库的更多信息，请参看SQL Server联机图书。

数据库系统目录

每个Oracle数据库都在一个集中系统目录（或者是数据字典（data dictionary））上运行，该目录存在于

SYSTEM表空间中。而每个Microsoft SQL Server 7.0数据库都维护一个自己的系统目录，该目录包含下列

信息：

数据库对象（表、索引、存储程序、视图、触发器等等）。

约束（Constraints）。

用户和许可。

用户定义数据类型。

复制定义。

数据库所用的文件。

SQL Server同时在master数据库中保存一个集中系统目录，该目录包含系统目录和每个数据库的某些信息：

数据库名和每个数据库的初始文件位置。

SQL Server登录账号。

系统消息。

数据库配置值。

远程和／或已连接的服务器。

当前活动信息。

系统存储过程。

像Oracle中的SYSTEM表空间一样，SQL Server的master数据库也必须能访问任何其他数据库。同样，对数

据库做了任何重大的改变以后，通过备份master数据库来防止失败是很重要的。数据库管理员也应该能够

为组成master数据库的文件做镜象。

物理和逻辑存储结构（Physical and Logical Storage Structures）

Oracle RDBMS是由表空间组成的，而表空间又是由数据文件组成的。表空间数据文件被格式化为内部的块

单位。块的大小，是由DBA在Oracle第一次创建的时候设置的，可以在512到8192个字节的范围内变动。当

一个对象在Oracle表空间中创建的时候，用户用叫做长度的单位（初始长度（(initial extent)、下一个

长度（next extent）、最小长度（min extents）、以及最大长度（max extents））来标明该对象的空间

大小。一个Oracle长度的大小可以变化，但是要包含一个由至少五个连续的块构成的链。

Microsoft SQL Server在数据库级别使用文件组来控制表和索引的物理放置。文件组是一个或者多个文件的

逻辑容器，一个文件组中的数据按比例填充属于该文件组的全部文件。

如果没有显明的定义和使用文件组，数据库对象将放置在一个缺省的文件组中，该文件组是在数据库的创建

过程中隐含定义的。文件组允许你进行下列操作：

把大的表分布在多个文件中以提高I/O吞吐量。

把索引存储在不同的文件中，而不是放在各自的表中，再一次提高I/O吞吐量以及实现磁盘并行操作。

把text、ntext、和image columns（大对象）储存在一个表的不同文件中。

把数据库对象放置在特定的磁盘锭（disk spindles）上。

在一个文件组中备份和恢复个别表和表的设置。

SQL Server把文件格式化为叫做页（pages）的单位。页的大小固定为8192字节（即8K）。页按固定为8个

连续页大小的格式组织为长度。当创建表或者索引时，SQL Server自动为其分配一页，比起分配一个长度

来说，储存较小的表和索引，这种方法要更有效些。

标记数据（Striping Data）

（译注：Strip--在海量存储系统(MSS)中,可由给定磁头位置访问的数据盒式磁带中的那部分）

Oracle类型的段对于大多数Microsoft SQL Server安装来说都不需要。取而代之的是，SQL Server可以利

用基于硬件的RAID或者Windows NT软件RAID来较好的完成数据的分布或者标记。基于硬件的RAID或者Windows

NT软件RAID可以设置一个由多个硬盘组成的标记装置，使它们看起来就像一个逻辑驱动器一样。如果数据库

文件是在这个标记装置上创建的，磁盘子系统就假定为负责通过多个磁盘来进行分布式的I/O装载。建议管理

员使用RAID来将数据分布在多个物理磁盘上。

针对SQL Server的RAID推荐配置是RAID 1（镜象）或者RAID 5（拥有一个作为冗余的额外的驱动器的标记

设备）。RAID 10（对有奇偶的标记设备的镜象）也是推荐的，但它比起前两个来要昂贵的多。标记设备在

分散数据库文件上通常的随机I/O来说是很好的。

如果不能使用RAID，文件组就是一个很有吸引力的选择了，它提供了RAID可以提供的某些同样的好处。此外，

对于那些可能跨越多个物理RAID阵列的非常大的数据库来说，文件组可能是一个很好的选择，它可以通过一

种受控制的方式将I/O分布在多个RAID阵列上。

必须优化事务日志文件（Transaction log files），使之适应连续的I/O，并且必须保护该文件以防止单点

失败。因此，建议采用RAID1（镜象）来做事务日志。该驱动器的大小至少应该和在线恢复日志（online

redo logs）以及反转段表空间两者加起来的大小一样才行。创建一个或者更多个日志文件，把逻辑驱动器

上定义的空间占满。和存储在文件组中的数据不同，事务日志条目总是按顺序写入的，而不是按比例填充的。

欲获得关于RAID的更多信息，请参看SQL Server联机图书，你的Windows NT服务器文档，以及Microsoft

Windows NT资源指南。

事务日志和自动恢复（Transaction Logs and Automatic Recovery）

Oracle RDBMS在每次启动时执行自动修复。它检查表空间文件的目录与在线恢复日志文件中的目录是否一样。

如果不一样，Oracle就使用在线恢复日志文件覆盖表空间文件（roll forward、前滚），然后去掉它在后滚

段中发现的所有未完成的事务（roll back，后滚）。如果Oracle不能从在线恢复日志中得到需要的信息，则

Oracle就求助于存档的恢复日志文件。

Microsoft SQL Server 7.0同样在每次启动时通过检查系统中的每个数据库来执行自动恢复。它首先检查

master数据库，然后启动线程以覆盖系统中的所有数据库。对于每一个SQL Server数据库，自动修复机制将

检查事务日志。如果事务日志中包含任何未完成的事务，则该事务后滚。然后自动修复机制再检查事务日志

以找出那些还没有写入数据库的未完成事务。如果找到，则执行该事务，前滚。

SQL Server事务日志包含了Oracle后滚段和Oracle在线恢复日志两者总的功能。每个数据库都有自己的事务

日志，该日志记录了数据库发生的任何改变，并且日志由数据库的所有用户共享。当一个事务开始并且发生

一次数据修改，则一个BEGIN TRANSACTION事件（同modification事件一样）被记录在日志中。在自动恢复的

过程中使用该事件来确定事务的起始点。每收到一个数据修改事件，改变都被记入事务日志中，优先写入其

数据库中。欲了解更多信息，请参看本章后面的"事务、锁定和并行"部分。

SQL Server有一个自动检查点机制，该机制确保完成了的事务规则的从SQL Server磁盘缓存中写入事务日志

文件。从数据库的上一个检查点算起，任何修改过的缓存页将被写入一个检查点。向数据库上的这些缓存页

（dirty pages，污损页）写入检查点，确保了所有已完成的事务被写到磁盘上。该过程缩短了发生失败（例

如能量损耗，power outage）时修复系统的所花的时间。该设置可以用SQL Server Enterprise Manager修改

，还可以用Transact-SQL修改（sp_configure系统存储程序）。

备份和恢复数据

Microsoft SQL Server提供了几种备份数据的选择：

完全的数据库备份

要进行完全的数据库备份，使用BACKUP DATABASE语句或者"备份向导"（Backup Wizard）。

微分备份（Differential backup）

在经过完全的数据库备份以后，定期使用BACKUP DATABASE WITH DIFFERENTIAL语句或者"备份向导"来备份改

变过的数据和索引页。

事务日志备份

Microsoft SQL Server中的事务日志有一个独立的数据库。该数据库仅在备份或者被删除以后才填充。SQL

Server 7.0中的缺省设置是事务日志自动增长，直到它用完了所有的可用空间或者达到其设置的最大空间。

当事务日志过满时，它会生成一个错误并且阻止任何的数据修改，直到该日志被备份或者被删除。其他的数

据库不会受到影响。可以用BACKUP LOG语句或者"备份向导"进行事务日志备份。

文件或者文件组备份

SQL Server可以备份文件或者文件组。欲知详情，请参看SQL Server联机图书。

备份可以在数据库正在使用的时候进行，这样就可以使那些必须不断运行的系统进行备份。SQL Server 7.0

的备份过程和数据结构已经大大的改进，可以使备份在对事务吞吐量影响最小的情况下达到最大的数据传输

率。

Oracle和SQL Server都需要一个特殊的日志文件格式。在SQL Server中，这些叫做备份设备的文件是用SQL

Server Enterprise Manager、Transact-SQL的sp_addumpdevice存储程序或者等价的SQL-DMO命令创建的。

虽然备份可以通过手工操作进行，但是建议你使用SQL Server Enterprise Manager和／或者"数据库维护计

划向导"进行定期的备份，或者基于数据库活动进行备份。

应用事务日志备份和／或者微分备份，一个数据库可以按时储存在一个完全备份数据库（设备）的特定的点

上。数据库使用备份中包含的信息恢复数据。可以用SQL Server Enterprise Manager、Transact-SQL （

RESTORE DATABASE）或者SQL-DMO进行恢复。

就像你可以关掉Oracle存档器以跳过备份一样，在Microsoft SQL Server中，db_owner组中的成员可以强制

事务日志在检查点发生的时候抹去目录。可以用SQL Server Enterprise Manager（删除检查点上的日志），

Transact-SQL（sp_dboption存储过程）或者SQL-DMO来完成。

网络

Oracle SQL*Net支持Oracle数据库和其客户端的网络连接。它们通过透明网络层数据流协议进行通信，并且

允许用户运行许多不同的网络协议，而不需要编写任何特殊的代码。SQL*Net未包含在核心Oracle数据库软件

产品中。

在Microsoft SQL Server中，Net库（网络库）支持客户端和服务器的连接，它们通过列表数据流协议进行通

信。这使得可以同时和运行名字管道（Named Pipes）、TCP/IP套接字或者其他交互处理机制（Inter-Process

Communication、IPC）的客户端连接。SQL Server CD-ROM包含了所有的客户端Net库，不需要另外购买这些

产品了。

SQL Server Net库选项可以在安装后修改。客户端网络工具为运行Windows NT、Windows 95、 或者Windows

98的客户端配置缺省的Net库和服务器连接信息。除非在ODBC数据源的安装过程中改变或者在ODBC连接字串中

显式的标明，所有的ODBC客户端也使用同样的Net库和服务器连接信息。欲了解关于Net库的更多信息，请参

看SQL Server联机手册。

数据库安全性和角色（Database Security and Roles）

为了把你的Oracle应用程序完整的移植到Microsoft SQL Server 7.0上，你需要明白SQL Server是如何实现

数据库的安全性和角色的。

登录账号

登录账号允许一个用户访问SQL Server数据或者管理选项。登录账号允许用户仅仅是登录到SQL Server上并

且显示那些可以让访客（guest）访问的数据库。（guest账号不是缺省设置的，必须创建）

SQL Server提供了两种类型的登录安全性。Windows NT验证模式（也称为集成的）和SQL Server验证模式（

也称为标准的）。SQL Server 7.0还支持标准的和集成的安全性的联合使用，称为混合的。

Windows NT验证模式在检验登录连接时使用Windows NT内建的安全机制，并且依赖用户的Windows NT安全信

任。用户不需要为SQL Server输入登录ID和口令--其登录信息直接从网络连接上截取。当发生连接时，一个

条目就被写入syslogins表，并且在Windows NT和SQL Server之间加以验证。这种方式叫做可信连接，其工作

原理同两台Windows NT服务器之间的可信关系是一样的。此功能同Oracle中用于用户账号的IDENTIFIED

EXTERNALLY选项是类似的。

SQL Server验证模式在用户请求访问SQL Server时要求用户输入登录ID和口令。这种方式又叫做不信任连接。

此功能同Oracle中用于用户账号的IDENTIFIED BY PASSWORD选项是类似的。使用标准安全模式，登录仅仅提

供用户访问SQL Server数据库引擎的能力，不允许用户访问用户数据库。

欲了解关于安全机制的更多信息，请参看SQL Server联机手册。

组、角色和许可（Groups, roles, and permissions）

Microsoft SQL Server和Oracle都使用许可来加强数据库安全性。SQL Server用语句级的许可来限制创建新

的数据库对象的能力。（同Oracle一样）

SQL Server还提供了对象级的许可。像Oracle一样，对象级所有权是分配给对象的创建者的，并且不能过户。

在其他用户可以访问对象之前必须给予他们对象级的许可。sysadmin 固定服务器角色、db_owner 固定数据

库角色、或者db_securityadmin 固定数据库角色的成员同样可以给予其他用户对某个用户对象的许可。

SQL Server语句级和对象级的许可可以直接赋予数据库用户账号。但是，通常更简单的方法是赋予数据库角

色管理员许可。SQL Server角色用来赋予或者撤消数据库用户组的特权（同Oracle角色非常相象）。角色（

Roles）是一个带有特殊数据库的数据库对象。每次安装都有一些固定的服务器角色，这些角色在数据库之上

工作。一个固定服务器角色的例子是sysadmin。Windows NT组也可以作为SQL Server登录，就像数据库用户

一样。许可可以赋予一个Windows NT组或者一个Windows NT用户。

一个数据库可以有任意数量的角色或者Windows NT组。缺省的public角色总是可以在任何一个数据库上找到，

这些角色不能被清除。public角色的功能很像Oracle中的PUBLIC账号。每个数据库用户都是public角色的成

员。在public角色之外，一个数据库用户还可以是任意数量角色的成员。Windows NT用户或组也可以是任意

数量角色的成员，同样，他们也是public角色的成员。

数据库用户和Guest账号（Database users and the guest account）

在Microsoft SQL Server中，一个用户登录账号必须被授权使用一个数据库和它的对象。登录账号可以用下

面方法中的一种来访问数据库：

登录账号可以被设定为数据库用户。

登录账号可以在数据库中使用访客（Guest）账号。

一个Windows NT组登录可以被映射为一个数据库角色。作为该组成员的单个Windows NT账号就可以连接到数

据库上。

db_owner或者db_accessadmin角色或者sysadmin固定服务器角色的成员可以创建数据库用户账号角色。一个

账号可以包含一些参数：SQL Server登录ID，数据库用户名（可选）、以及一个角色名（可选）。数据库用

户名不一定要和用户登录ID一样。如果未提供一个数据库用户名，则用户的登录ID和数据库用户名就是一样

的。如果未提供一个角色名，则该数据库用户就仅是public角色的成员。在创建了数据库用户之后，用户可

以根据需要分配任意的角色。db_owner或者db_accessadmin角色的成员也可以创建一个guest账号。guest账

号允许任意有效的SQL Server

登录账号访问一个数据库，甚至不需要有数据库用户账号。缺省情况下，guest账号继承了分配给public角色

的特权；但是，这些特权可以修改为多于或者少于public账号的特权。

一个Windows NT用户或者一个组的账号可以被赋予访问数据库的权利，就像SQL Server登录所能做的一样。

如果一个Windows NT组的一个成员连接数据库，该用户会收到分配给这个组的许可。如果该用户是不止一个

Windows NT组的成员，则他会收到所有这些组对数据库的权限的集合。

Sysadmin角色（The sysadmin role）

Microsoft SQL Server sysadmin固定服务器角色中的成员拥有与Oracle DBA组中的成员相似的权限。在SQL

Server 7.0中，如果SQL Server是安装在一台Windows NT计算机上，那么以sa SQL Server验证模式登录的

账号缺省为该角色的成员，也就是本地Administrator组中的成员。一个sysadmin角色中的成员可以增加或者

删除Windows NT用户和组，以及SQL Server登录账号。典型的该角色中的成员有以下职责：

安装SQL Server。

配置服务器和客户端。

创建数据库。*

设立登录权限和用户许可。*

将数据导入或者导出SQL Server数据库。*

备份和恢复数据库。*

执行和维护复制。

安排无人值守的操作。*

监视和调试SQL Server的性能。*

诊断系统问题。

*这些项目可以委派给其他安全性角色和用户。

在SQL Server 7.0中，对于sysadmin固定服务器角色中的成员能干什么是没有限制的。因此，该角色中的成

员可以通过一个特殊的SQL Server实例访问任何数据库、所有的对象（包括数据）。像一个Oracle DBA一样，

有一些命令和系统程序是只有sysadmin角色中的成员才能使用的。

db_owner角色

虽然Microsoft SQL Server数据库在使用上和Oracle表空间很相似，但是它们在管理上是不一样的。每个SQL

Server数据库都是一个自持的管理域。每个数据库都标明了数据库所有者（dbo）。该用户总是db_owner固定

数据库角色的成员。其他用户也可以是db_owner角色的成员。该角色中的所有成员都可以管理与他的数据库

相关的管理任务。（不象在Oracle中，DBA管理所有数据库的管理任务）。这些管理任务包括：

管理数据库访问。

修改数据库设置（只读，单用户，等等）。

备份和恢复数据库目录。

授予和取消数据库许可。

创建和删除数据库对象。

db_owner角色中的成员可以在他们的数据库上做任何事情。分配给该角色的大多数权利被分给一些固定数据

库角色，或者也可以赋予数据库用户。在数据库上行使db_owner特权并不需要赋予sysadmin服务器范围特权。