SQL Server常规升级 :
在正式环境中,服务器的操作系统、SQL Server及其他应用程序可能会定期打补丁,这时候就涉及重启机器或者SQL Server的工作,如果搭建了镜像环境,这个操作就会稍微变得复杂了。因为为了高可用的稳定运行,不仅主体服务器要打补丁,镜像服务器甚至见证服务器也要打补丁。本部分包含两个情况:
安装常规补丁 升级SQL Server或为SQL Server打补丁安装常规补丁:
这里指的补丁不是SQL Server的补丁,在镜像环境中,如果打了补丁并且需要重启,尽可能避免镜像环境的所有伙伴服务器都同时重启,毕竟搭建高可用的原因是为了加大业务连续性。常规做法是:先对一台服务器打补丁,重启这台服务器(如果需要重启),确保这台机已经正常运行之后,以相同步骤处理下一台。镜像环境中重启顺序没有强制规定,按照实践,通常是:见证→镜像→主体服务器。
升级SQL Server或为SQL Server打补丁:
针对SQL Server打补丁,必须更加谨慎,特别是镜像环境出现了见证服务器。如果带有见证服务器,首先要移除见证服务器,并在打完补丁之后把见证服务器加回去。见证服务器可以在任何时候进行升级。可以在主体服务器上运行:
ALTER DATABASE [DatabaseName] SET WITNESS OFF;--移除见证服务器 ALTER DATABASE [DatabaseName] SET WITNESS = 'TCP://WitnessServer.FQDN.com:Port#';.--添加见证服务器
对于运行模式,建议先设为异步模式,然后再打补丁,在准备Failover时,改为同步模式,使其同步信息之后再Failover。
在正式打补丁时,先对镜像服务器打补丁,最主要的原因是可以验证补丁是否有效,并且打完之后是否可以安全Failover。当镜像服务器已经打完补丁并且Failover成主体服务器时,由于补丁的级别不一致,SQL Server会挂起镜像会话,这时候应该尽快对原主体服务器打补丁,否则挂起太久会引起很多后患。
故障转移后恢复原有主体服务器 :
在镜像环境中,人为或者自动故障转移都会使镜像服务器变成主体服务器,如果这不是你希望的,那么你就需要想办法把现在的主体服务器变回镜像服务器,其中一个原因是如果不这样做,你必须准备一个新的镜像服务器以便下一次故障转移。这里分两步介绍:
恢复原有主体服务器的原因 实现原有主体服务器的恢复恢复原有主体服务器的原因:
恢复原有主体服务器有很多原因,但是比较重要的原因是:镜像不同步作业、维护计划、SSIS等。如果是非人为Failover,会导致这些组件失败、重试,而有些系统中,这些组件是至关重要的,尽快联机并切换回原有状态是首要任务,另外,镜像服务器往往性能没有主体服务器强,长时间接管业务可能导致镜像服务器面临压力。
实现原有主体服务器的恢复:
可以使用这个脚本进行恢复:
CREATE PROCEDURE dbo.dba_FailoverMirrorToOriginalPrincipal
-- database to fail back; all applicable databases if null
@DBName SYSNAME = NULL ,
-- 0 = Execute it, 1 = Output SQL that would be executed
@Debug BIT = 0
AS
DECLARE @SQL NVARCHAR(200) ,
@MaxID INT ,
@CurrID INT
DECLARE @MirrDBs TABLE
(
MirrDBID INT IDENTITY(1, 1)
NOT NULL
PRIMARY KEY ,
DBName SYSNAME NOT NULL
)
SET NOCOUNT ON
-- If database is in the principal role
-- and is in a synchronized state,
-- fail database back to original principal
INSERT INTO @MirrDBs
( DBName
)
SELECT DB_NAME(database_id)
FROM sys.database_mirroring
WHERE mirroring_role = 1
AND -- Principal partner
mirroring_state = 4
AND -- Synchronized
( database_id = DB_ID(@DBName)
OR @DBName IS NULL
)
SELECT @MaxID = MAX(MirrDBID)
FROM @MirrDBs
WHILE @CurrID <= @MaxID
BEGIN
SELECT @DBName = DBName
FROM @MirrDBs
WHERE MirrDBID = @CurrID
SET @SQL = 'Alter Database ' + QUOTENAME(@DBName)
+ ' Set Partner Failover;'
IF @Debug = 1
BEGIN
EXEC sp_executesql @SQL;
END
ELSE
BEGIN
PRINT @SQL;
END
SET @CurrID = @CurrID + 1
END
数据库配置 :
数据库配置中有两个选项可以用于镜像,一个是数据库拥有者(database owner)和Trustworthy 数据库属性。当备份一个数据库是,SQL Server会重置Trustworthy ,这个属性搞熟SQL Server可以信任这个数据库中包含的对象。可以使用:ALTER DATABASE [库名] SET TRUSTWORTHY ON; 来设置。
在还原数据库或者创建新库时,SQL Server会把你操作的账号作为数据库的拥有者,这可能因为你这个账号的权限不足以完成你所需的任务而导致数据库在运行过程中报错。可以使用下面语句来查看数据库的拥有者:
SELECT P.name
FROM sys.databases D LEFT JOIN
sys.server_principals P
ON P.sid = D.owner_sid
WHERE D.name = '数据库名'
如果数据库onwer为null或者不是期望的,可以用下面语句修改:
EXEC 库名.sys.sp_changedbowner @loginame = 'sa' --2005 ALTER AUTHORIZATION ON DATABASE::库名TO sa; --2008
控制故障转移 :
Failover一般有两种:自动转移和手动转移,手动转移可以很简单地使用下面语句实现:
ALTER DATABASE [DatabaseName] SET PARTNER FAILOVER --在主体服务器上执行
在Failover过程中,你可以会遇到一些问题,毕竟现实总不是太理想的,如果在异步模式下执行Failover命令,会报错,需要在Failover之前把数据库设为同步,下面提供一个控制Failover的存储过程,常见的问题已经在里面得到处理:
CREATE PROCEDURE dbo.dba_ControlledFailover
-- database to fail back; all applicable databases if null
@DBName SYSNAME = NULL ,
-- @MaxCounter = max # of loops, ea