改善了可伸缩性和与Windows NT服务器的兼容性。
对于大型I/O有更好的性能。
稳定的记录位置允许更多的索引 。
查询能够被更多的索引判断所支持。
简化的数据结构提供更好的质量 。
更好的可扩展性。今后的版本能够有完善的发展，并且能够更迅速的利用新的特
性。 数据库、文件和文件组
SQL Server 7.0能够与Windows NT服务器更好地兼容。现在数据库直接存储在 Windows NT服务器的文件里。旧的UNIX的数据库设备和分段被一个简单的系统所替换，它把每个数据库映射到自己的文件集。 SQL Server 7.0使用一个操作系统文件集来创建数据库，每个数据库分别使用不同的 文件。在同一个文件中不再有多个数据库。这种简化有几个重要的优点。现在文件是可以增大和缩减的，并且空间管理也有很大程度的简化。 数据库中的所有数据和对象，例如表、存储进程、触发器和视图，都只存储在这些操作系统文件里（见表1）。
在创建一个数据库的时候，所有包含数据库的文件都要零化（用零填充），以清除磁盘上已经被删文件所留下的数据。尽管这意味着文件的创建要花费更长的时间，但是能够防止Windows NT在正常的数据库操作期间，当数据被首次写入文件时还要先清除该文件（由于它们已经被零化）。这样就改善了日常操作的性能。 一个数据库由一个或者多个数据文件，以及一个或者多个日志文件所组成。数据文件可以被分为用户定义的文件组。表和索引也可以映射到不同的文件组，以控制物理磁盘上文件放置的位置。 文件组是一个方便的管理单位，能够大大提高灵活性。对于一个TB级的数据库，既使 不考虑备份的速度，要在一个window里备份整个数据库也是不可能的。SQL Server 7.0使 你能够用轮换的方案每个晚上备份数据库的不同部分。
对于那些知道在何处放置索引和表的熟练用户来说，文件组的运做将非常有效。SQL Server 7.0能够非常高效地工作而不需要文件组，所以许多系统就不需要指定用户定义的 文件组。在这种情况下，所有的文件都包含在缺省的文件组里，SQL Server 7.0能够在数 据库中迅速地分配数据。 日志文件不是文件组的一部分。日志空间的管理与数据空间的管理是分离的。 使用文件和文件组能够通过多个磁盘、多个磁盘控制器或者RAID系统创建一个数据库， 从而改善数据库的性能。例如，如果你的计算机有四个磁盘，你就能够创建一个由三个数据 文件和一个日志文件所组成的数据库，每个磁盘上放一个文件。访问数据的时候，四个读写 头都能够同时地并行访问数据，这样就加速了数据库的操作。
另外，由于可以在指定的文件组里创建一个表，所以文件和文件组能够促成更好的数据 放置。由于一个特定表的所有I/O都可以在指定的磁盘上直接控制，从而能够改善性能。例 如一个频繁使用的表可以被放置在某个文件组的某个文件里，位于某个磁盘，而数据库中其 他较少访问到的表就可以放置在位于另一个磁盘的另一个文件组。
对于文件和文件组有一些通用的建议：
大多数只有单个文件和单个日志文件的数据库运作很好。 如果你计划使用多个文件，请把主文件用于系统表和系统对象，并且至少创建一个 从文件来存储用户数据和对象。 为了尽可能地提高性能，请把文件和文件组尽量创建在不同的本地物理磁盘上，并 且把对于空间竞争最为激烈的对象放置在不同的文件组里。 使用文件组，把对象放置在指定的物理磁盘上。 把同一个连接查询中用到的不同的表放置在不同的文件组里。这样磁盘I/O能够并 行地查找连接的数据，从而可以改善性能。 把频繁访问的表和属于这些表的非聚集索引放置在不同的文件组里。如果文件位于 不同的物理磁盘，磁盘I/O就能够并行，从而可以改善性能。 不要把日志文件放置在与其他文件和文件组相同的物理磁盘上。 文件的空间分配和空间管理有了许多改进，记录从页面到对象关系的数据结构也被重新 设计了。取代链接页表的是位图的使用，因为它们更简洁，并且利于并行查找。现在每个文 件都更加独立，所包含的自己的数据也更多了。这样拷贝或者邮寄数据库文件时就更容易。 现在的SQL Server有一个更有效的系统用于跟踪表空间。这一变化利于：
文件的增长和缩减。
对于大型I/O的更好支持
一个表内的行空间管理
更便宜的分区分配
在SQL Server的早期版本中，当增加大量数据的时候，分配可能导致阻塞。新的分配 算法和数据结构非常简单有效，不会导致阻塞。SQL Server 7.0会跟踪一个页面上的空闲 空间。当从一个没有聚集索引的表里删除一行时，能够把这个空间用于新的插入，这样就能 更有效的利用磁盘空间，同时数据存放更加密集以加速表的查询。 SQL Server在把页面迅速地分配给对象以及重用被删行所释放的空间方面引进了一些 重要的变动。这些操作是系统内部的，所使用的数据结构也是用户看不见的。
笔记本和桌面系统可能局限于磁盘空间，SQL Server 7.0允许自动缩减数据库文件的 大小。服务器周期性地检查每个数据库的空间使用情况。如果发现一个数据库有大量的空闲 空间，就会减少该数据库中文件的大小。数据文件和日志文件都可以缩减。这个操作是在后 台执行的，不会影响数据库里用户的行为。你还可以使用SQL Server 7.0的Enterprise Manager或者DBCC单个地或者成组地缩减文件。 缩减的进行是通过把行从文件末尾的页面移到文件中更早分配的页面上，或者在一个索 引里，把节点从文件的末尾移到文件的起始处。在这两种情况下，文件末尾的页面都会被释 放，然后被返回给文件系统。数据库可以缩减到没有剩余的空闲空间的程度，在这里，没有 数据的压缩。
文件的自动增长大幅度地减少了对于数据库管理的需要，并消除了当日志或者数据库空 间不够时会出现的许多问题。在创建一个数据库的时候，必须指定文件的初始大小。SQL Server 7.0根据数据库创建者提供的大小创建数据文件，然后数据就被增加到由这些文件 所组成的数据库中。根据缺省值，允许数据文件任意增长，直到磁盘空间耗尽。也可以把数 据文件配置为填充数据时自动地增长，但是只适用于预先定义了最大大小的情况。这样就避 免了磁盘驱动器耗尽空间。 在创建一个数据库的时候，应该根据该数据库中预计的最大数据量，使数据文件尽可能 地大。要允许数据文件自动地增长，但是对于增长要给出一个限制。如果超出了初始的数据 文件大小，并且文件开始自动地增长，就要重新估算数据库的预计大小，并据此增加更多的 磁盘空间（如果有必要的话），在数据库中创建和增添更多的文件和文件组。
SQL Server 7.0可以防止数据库的增长超出它们的初始大小，如果文件填满了数据， 就只能通过创建更多的数据文件来增加数据。如果大量的文件共享着同一个磁盘，允许文件 自动地增长可能导致文件碎片的产生。因此，建议尽可能在不同的本地物理磁盘上创建文件 或者文件组。把对于空间竞争最为激烈的对象放置在不同的文件组里。
物理数据库的体系结构
SQL Server 7.0在数据的物理存储方式上引进了重要的改进。这些变化对于用户是高 度透明的，而且并不影响SQL Server数据库的设置和管理。 SQL Server基本的数据存储单元是“页面”。在SQL Server 7.0里，页面的大小是8K ， 这是从2K增长而来的。每个页面的开始是一个96字节的页面头，用于存储系统信息，例如 页面的类型、页面上的空闲空间量以及该页面所属对象的对象ID。 一个SQL Server 7.0数据库的数据文件有七种类型的页面。类型如表2所示： 数据页面包含了数据行中除了文本、n文本和图象数据以外的所有数据，它们分别存储 在不同的页面。 数据行紧跟着页面头串行地放置在页面上。一个行偏移量表（A row offset table）从页面的末尾开始。行偏移量表包含每行在页面上的一个入口，每个入口记录着该 行的第一个字节与该页面起始处的距离。行偏移量表中的入口的顺序是与页面上各行的顺序 相反的。
在SQL Server 7.0里，行是不能跨页的，一行中所能包含的最大数据量是8,060字节， 这里不包括文本、n文本和图象数据。 “分区”（Extent）是为表和索引分配空间的基本单位。一个分区是8个相邻的页面， 或者说是64K。为了使它的空间分配更加高效，SQL Server 7.0并不把整个的分区分配给那 些数据量较小的表。 SQL Server 7.0有两种类型的分区。一个单个的对象拥有统一的分区，分区中的8个 页面只能被所属的对象使用。同时，SQL Server 7.0引进了一个混合分区的新概念，非常 适用于小型的应用。在SQL Server 7.0和所有的早期版本里，给表增加空间只能一次一个 分区。既然页面的大小是8K，这么做对于较小的表来说就导致了相当大的开销。一个混合 分区允许把一个单个的页面分配给较小的表或者索引。只有当一个表或者索引获得了大于 8K 的页面，它才会开始分配统一的分区。混合分区可以被多达8个的对象所共享。一个新的表 或者索引从混合分区获得页面分配。当页面或者索引增长到拥有8个页面的时候，它就转换 到统一的分区。
SQL Server 7.0把一个数据库映射到一个操作系统文件集。数据和日志信息从不混杂 在同一个文件中，而且单个的文件只能被一个数据库所使用。这样就消除了管理逻辑设备的 需要，为数据库文件的的放置提供了灵活性，并且提高了备份和恢复能力。 SQL Server 7.0数据库有三种类型的文件：
主数据文件(Primary Data File)是数据库的起始点，以及数据库中其他文件的起始 点。每个数据库都有一个主数据文件。主数据文件的文件扩展名是 .mdf。 从数据文件(Secondary Data File)包含了除主数据文件以外的所有数据文件。某些 数据库可能没有从数据文件，而另一些数据库却有多个从数据文件。从数据文件的文件扩展 名是 .ndf。 日志文件(Log Data File)包含所有用于恢复数据库的日志信息。每个数据库必须至 少拥有一个日志文件，也可以拥有多个日志文件。日志文件的扩展名是 .ldf。
SQL Server 7.0的文件能够从它们最初被指定的大小开始自动地增长。当你定义一个 文件的时候，你可以指定一个增长量。每当文件被填满的时候，文件就根据这个增长量增加 它的大小。如果在一个文件组里有多个文件，在所有的文件都被填满之前，它们都不会自动 地增长。增长使用的是round-robin算法。 每个文件还可以指定最大的大小。如果没有指定这个值，文件就可以不断地增长，直到 用完磁盘上的所有空间为止。当SQL Server被用作一个应用数据库，用户不能很方便地以 数据库管理员的身份访问数据库时，这个特性就非常有用。用户可以根据需要自动地增长文 件，以减少监控数据库中空闲空间量和手工分配附加空间的管理负担。 碎页面的检测有助于确保数据库的一致性。在SQL Server 7.0里，页面是8K的，而 Windows NT的I/O是以512字节的分段而进行的。这个差异使得一个页面可能被分离开来。 如果在写头一个512字节的段和完成8K I/O的时间之间出现了电源故障或者其他的事故， 就可能出现这个问题。如果写完头一个512字节的段，看起来页面已经被修改了，而事实上 还不是这样（页面的时间戳在该页面的开头96字节的页面头里）。有多种办法用于处理这类 情况。一个办法是使用后备电池或带高速缓存的I/O设备，以保证I/O要么全做，要么就都 不做。如果你拥有这些系统中的一个，就不必进行碎页面检测了。 SQL Server 7.0能够通过创建一个位掩码，检查未完成的I/O，每位都来自于页面中的 一个段。每次写一个页面的时候，该位就从它原来的状态进行翻转（就像它在磁盘上一样）， 而实际状态被保存在该页面的页面头里。如果要读取一个页面，而该位处于错误的状态，就 表示有一个I/O尚未完成，存在着一个碎页面。这个机制比计算一个校验和的开销要小很多。
由于在位进行翻转的时候，对页面头也作了标志，所以你可以打开或者关闭碎页面检查。 如果碎页面检查是打开的，然后又关上了，那么就可以观察到进行过位翻转的页面状态，在 下一次读取时，可以进行修改。
锁的增强
SQL Server 6.5在插入中引进了行级加锁。现在的SQL Server 7.0支持数据行和索引 入口的完全行级加锁。事务能够修改单个记录，而不会阻塞页面。这使得许多OLTP应用程 序能够应付日益增长的并发需求，尤其是当应用程序把新数据行添加到表中或者索引中的时 候，行级锁会大大提高效率。 锁管理器会动态地调整它用于大型数据库的的资源，减少手工调整锁服务器配置选项的 需要。它在页面加锁（适用于表查询）和行级加锁（适用于插入、修改、以及删除数据）之 间自动地进行选择。 SQL Server 7.0拥有一个在数据库行业中独一无二的高级加锁机制。在运行的时候， 存储引擎动态地与查询处理器相协作，根据查询计划和查询的特点，选择开销最低的加锁策 略。
动态加锁有以下优点：
由于数据库管理员再也不需要关心调整锁的增长极限，因而简化了数据库管理。 由于SQL Server通过使用与任务相适合的锁，使系统开销降至最低，因而提高了性 能。 由于SQL Server对加锁进行自动调整，因而应用的开发人员能够致力于开发。 多粒度加锁允许一个事务对不同类型的资源进行加锁。为了把加锁的开销降至最低， SQL Server在一个与任务相适合的级别，自动地加锁资源。以较小的粒度进行加锁，例如行级 锁，会增加并发度，但是由于在许多行都加了锁的时候，必须要处理较多的锁，因此开销也 就更大。以较大的粒度进行加锁，例如表级锁，由于在整个表加锁就限制了其他事务对表中 任何部分的访问，所以从并发方面而言，开销较大，但是由于需要维护的锁少了，因此整个 开销也就小了。 SQL Server 能够为表3中资源加锁（根据粒度的增加）。
事务日志管理
事务日志有助于在发生系统故障时恢复数据库的完整性。每个数据库的日志记录由一个 或者多个称作日志文件的操作系统文件来维护。这是一个串行的记录，记录着对数据库所做 的所有修改，以及每次修改的执行事务。 日志随着对数据库的操作而持续增长。对于那些大的操作，它只记录操作的发生。日志 记录每个事务的提交或者回滚。这就使得SQL Server能够恢复或者撤消每个事务： 当撤消了一个未完成的事务时，要回滚这个事务。SQL Server通过按修改顺序倒退执 行，把数据库恢复到事务开始时间之前的状态。 当恢复一个事务日志时，要前滚这个事务。对于数据库的修改，执行顺序与本来的顺序 相同。在这个过程最后，数据库的状态就是日志备份时间所处的状态。
SQL Server 7.0的日志管理器作了如下改进：
不与数据竞争缓冲区页面
不会跨越一个或者多个物理文件
自动地增长或者缩减
允许快速及无干扰的截断
支持大型I/O
SQL Server 7.0的日志由一个或者多个只包含日志条目的物理文件所组成。从前，日 志是一个使用普通数据库页面的系统表。这些日志页面的分配和收集就像其他表的页面一 样，它们与数据页面共同竞争内存的高速缓冲区。 每个日志文件逻辑上被分成称作虚日志文件的小段。虚日志文件是事务日志的截断单 位。当一个虚日志文件不再包含活动事务的日志记录时可以被截断，它的空间就可以用于新 的事务记录日志。 SQL Server会尽量避免制造大量小的虚日志文件。虚日志文件的数量的增长比它们文 件大小的增长要慢。如果一个日志文件以较小的增量进行增长，它会导致许多小的虚日志文 件。如果一个日志文件以较大的增量进行增长，SQL Server创建的大的虚日志文件就会比 较少。
随着记录不断地写入日志，日志的末尾就从一个虚日志文件增长到下一个虚日志文件。 如果一个数据库中有不只一个物理的日志文件，那么日志的末尾就会沿着每个物理文件中的 虚日志文件增长，直到回到了第一个物理文件里的第一个虚日志文件。 一个最小的虚日志文件是256 K。一个事务日志的最小大小是512 K，为你提供两个 256 K大小的虚日志文件。一个事务日志中虚日志文件的数量和大小随着日志文件大小的增长而 增长。一个小的日志文件可能有较少的虚日志文件。而一个非常大的日志文件会有较大的虚 日志文件。 日志允许自动地增长或者缩减。如果没有有效的可重用空间，可以通过增加逻辑日志文 件块来扩展文件。如果需要更多的空间，就再增加一个逻辑日志文件。日志管理器从内部把 物理日志文件分为逻辑日志文件。可以认为逻辑文件是活动的，或者说是可以重用的。如果 一个逻辑日志文件没有包含活动日志的任何部分，就可以备份该文件。一个文件在备份之后 就可以被重用。
内存、缓冲和预取
SQL Server会根据有效的系统资源动态地更改它的内存需求（或者说，如果需要的话， 它可以手工地进行修改）。这个机制有助于充分利用系统资源。 在SQL Server中有数个必须竞争共享有效内存的子系统。日志和恢复系统需要内存读 取和撤消页面，查询处理器使用内存执行散列和排序。其他使用内存的子系统是进程高速缓 存、缓冲池、一个锁管理器以及数据结构。在SQL Server 7.0里，这些系统动态地分割它 们所需要的内存，并且能够在不需要内存的时候，把所占的内存释放掉。 SQL Server以缺省的内存值启动。随着启动的应用越来越多，会周期性地查询内存， 判断有效的空闲物理内存量。SQL Server会增长或者缩减高速缓冲，保持空闲物理内存大 约有5 MB，避免Windows NT进行分页。如果空闲物理内存小于5 MB，SQL Server就把内 存释放给Windows NT。如果物理内存超出了5 MB，SQL Server就把内存重新提交给高速缓 存。当SQL Server的工作负载需要更多内存的时候，它就会把内存添加到高速缓存里，一 个静止的服务器不会增长它的高速缓存。
创新和进步
总地说来，SQL Server 7.0包含了以下的创新和进步。 第一个从桌面版到企业版共享同样的代码，并提供100%代码兼容性的具有伸缩性的 数据库。 第一个支持自动配置和自动调节的数据库。 第一个带完整的OLAP服务器的数据库。 第一个带完整的数据转换服务的数据库。 首次充分利用数据仓库框架解决元数据问题。 第一个为大量服务器提供多服务器管理的数据库。 在所有数据库中有最广泛的复制选项。 与Windows NT服务器、Microsoft Office和BackOffice的最佳兼容。 通用的Data Access，是微软对于各种信息资源的高性能访问策略。
微软希望充分了解客户对于数据库新特性和增强特性的需求，设计新的存储引擎结构就是为了支持直到下一世纪的客户应用。SQL Server的设计队伍致力于实现完善的子系统，以便进一步改善部件性能，并且在一段时期之后，能够很方便地进行更新