SQL Server数据库体系结构(非常清晰)

服务器结构

SQL Server服务器可以看成是由实例及数据库构成。实例包括SQL Server占用的内存及后台线程。

与Oracle显著不同的是,SQL Server服务器的数据库是多个,其中包括5个系统数据库及若干个用户数据库(其中的resource数据库存储系统数据,对用户不可见)。每个数据库包括数据文件及重做日志文件,SQL Server数据库不包含控制文件。

Oracle服务器 = 一个Oracle实例+一个数据库

SQL Server服务器 = 一个SQL Server实例+多个数据库

数据库相关文件

SQL Server的数据库文件包括:

数据文件:存放数据库中的数据。

重做日志文件:存放用户对数据库的操作记录,用于实例恢复或介质恢复。

SQL Server中的数据文件

数据文件与重做日志文件的作用与Oracle对应的文件相同,只是SQL Server的重做日志文件除了包含重做数据外,还包含回滚事务所用的undo数据,Oracle的重做日志文件只包含重做数据,undo数据存储在undo表空间。

SQL Server中的“控制文件”

SQL Server没有控制文件,实例中的各个数据库文件信息存储在master系统数据库以及用户数据库的primary文件组的主数据文件中。

SQL Server中的“初始化参数文件”

SQL Server没有初始化参数文件(初始化参数文件用于保存实例启动及运行时各种参数配置),实例的配置信息保存在master系统数据库中,数据库的配置信息保存在各自数据库的primary文件组的主数据文件中。

SQL Server中的“口令文件”

Oracle中的口令文件保存sys用户及具备sysdba系统权限的用户的口令,其他用户的口令保存在数据库中,这是因为sys用户除了在数据库中拥有管理权限外,还拥有启动和关闭数据库等特殊权限,如果sys用户的口令也与其他用户的口令一样存储在数据库中,显然在数据库打开之前,就无法验证其口令的正确性。但是SQL Server没有口令文件,启动SQL Server各种服务都是由操作系统行号完成的,其口令由操作系统维护。

归档日志文件

SQL Server没有归档日志文件,Oracle归档日志的功能通过事务日志文件备份实现。

SQL Server中的错误日志

Oracle中的警告文件记录着数据库运行的信息,根据这个文件我们可以知道发生了什么内部错误,什么时候创建了表空间,什么时候把表空间或数据文件脱机、联机,数据库启动关闭等信息。出现错误时,如果不能确定原因,应该首先查看经该文件的内容,以得到解决问题的线索,警告文件从数据库创建开始一直到被删除。Oracle数据库的警告文件在SQL Server中称为错误日志(Errorlog),是实例范围的,而不是针对某个数据库的,与Oracle的警告文件类似,由SQL Server错误日志可以查看在实例运行过程中出现的错误。SQL Server的错误日志文件的位置为:\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Log。

注意区分这里的SQL Server错误日志与数据库重做日志文件,SQL Server错误日志时文本文件,是提供给数据库管理员用来查看服务器运行过程中的问题的,SQL Server数据库正常运行并不需要错入日志文件,而数据库的重做日志文件是数据库必须的,其目的是为了在出现故障时,恢复数据库。

服务器启动时,会创建新的错误日志文件ERRORLOG,上一次的ERRORLOG被重命名为ERRORLOG.1,ERRORLOG.1被重命名为ERRORLOG.2,依次类推,一直到ERRORLOG.5,被重命名为ERRORLOG.6,而ERRORLOG.6被删除,这样,错误日志最多保留6个备份。执行sp_cycle_errorlog系统存储过程可以自动创建新的ERROR文件并执行上述修改名称的过程,而不必重启服务器。

可以使用任何文本编辑器在操作系统上查看其内容,也可以在Management Studio中通过“管理——>SQL Server日志”查看其内容,如下图所示。

内存结构

1.内存构成

SQL Server的内存主要由两部分构成:buffer cache及其他部分。

buffer cache也称为buffer pool,是SQL Server占用内存的主要部分,其作用类似于Oracle的SGA。buffer cache中的主要部分为data cache,相当于Oracle实例SGA中的database buffer cache部分,用于存放由磁盘读取的数据,再次读取时不必从磁盘读取。一般情况下,这是buffer cache中最大的一个区域。

buffer cache中的另外一个重要部分为plan cache,用于存放编译过的执行计划,相当于Oracle实例shared pool中的library cache部分。

2.配置内存大小

与SQL Server内存分配相关的服务器参数有两个:

阅读更多

windows2012 下sqlserver2012 AwaysOn 集群环境虚拟机下载

本博主配置好的windows2012 下sqlserver2012 AwaysOn 集群环境虚拟机下载,链接:https://pan.baidu.com/s/1KS5P8XFUsCj-t2rjHqO9sA
提取码:gpn3 下载后,用Vmware workstation打开 即可以使用。

SQL Server2012所支持的AlwaysOn技术集中了故障转移群集、数据库镜像和日志传送三者的优点,但又不相同。故障转移群集的单位是SQL实例,数据库镜像和日志传送的单位是单个用户数据库,而AlwaysOn支持的单位是可用性组,每个组中可以包括一个或者是多个用户数据库。也就是说,一旦发生切换,则可用性组中的所有数据组会作为一个整体进行切换。

AlwaysOn底层依然采用Windows 故障转移群集的机制进行监测和转移,因此也需要先建立Windows Cluster,只不过可用性组中的数据库不一定非要再存放在共享存储上了。可以是存储在本地磁盘上。

下面,先看一下AlwaysOn的关键特性:

1. 同故障转移群集一样,也需要一个虚拟网络名称用于客户端的统一连接。

2.一个主服务器可以最多对应四个辅助服务器,总数达到五个,而且辅助服务器支持只读功能。

3.辅助服务器可以独立执行备份和DBCC维护命令。通过配置,可以实现客户端的只读请求可以被自动定向到辅助服务器。

4.主服务器和辅助服务器之间的数据会被加密和压缩,以提高安全性和网络传输效率。

5..支持自动、手动和强制三种故障转移方式。

6.有仪表盘用于监控AlwaysOn的运行状态。

7.可以实现多站点的部署,即主站点和辅助站点可以跨物理网络。

AlwaysOn的基本架构

在Windows MSCS故障转移群集的基础上部署AlwaysOn高可用组,用户可以在群集节点上安装SQL Server单机实例,也可以安装SQL Server群集实例,AlwaysOn仅要求所有SQL Server实例都运行在同一个MSCS中,但SQL Server实例本身是不需要群集模式的,这与SQL Server2008 群集的实例完全不同。在此推荐使用单机模式的SQL Server,好处是:可用性副本是个单机实例,那么数据库副本就存放在该运行该实例节点的本地磁盘上;如果可用性副本是个群集实例,那么数据库副本就存放在共享磁盘上。

可用性组从Windows群集角度来看,就是一个群集资源,其中的所有数据库作为一个整体在节点间进行故障转移,当然这不包括系统数据库,系统数据库是不能加入高可用性组中的。

因为需要借助Windos群集实现监控和转移,所以AlwaysOn会受到一些限制:

一个可用性组中的所有可用性副本必须运行在单一的Windows群集上,跨不同Windows群集的SQL Server实例不能配置成一个AlwaysOn可用性组。

一个可用性组的所有可用性副本必须运行在Windows群集的不同节点上。运行在同一个节点上的两个不同实例不能用作同一个可用性组的副本。

如果某个可用性副本实例是一个SQL群集实例,那同一个SQL群集的其他非活跃节点上安装的任何其他SQL实例都不能作为它的辅助副本。

一个数据库只能属于一个可用性组。

AlwaysOn最多可以支持五个副本,但只有一个可用性副本上运行的数据库是处于可读写状态。这个可读写的数据库被称为主数据库(PrimaryDatabase),同时这个可用性副本被称为主副本(primaryreplica)。其余的副本都被称为辅助副本(secondaryreplica),辅助副本上的数据库可能是不可访问的,或者是只能接受只读操作(取决于可用性组的配置),这些数据库被称为辅助数据库。一但发生故障转移,任何一个辅助副本都可以成为新的主副本实例。主副本会不断地将主数据库上的数据变化发送到辅助副本,来实现副本间的数据库同步。下图就显示了一个可用性组中各副本之间的关系。

p_w_picpath

本博主配置好的windows2012 下sqlserver2012 AwaysOn 集群环境虚拟机下载,链接:https://pan.baidu.com/s/1KS5P8XFUsCj-t2rjHqO9sA
提取码:gpn3 下载后,用Vmware workstation打开 即可以使用。

阅读更多