本篇内容介绍了“sqlserver关于mirror镜像的知识点有哪些”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
mirror镜像的基本原理：主服务器上的主体数据库执行的增、删、改、查操作以日志的方法在镜像服务器的镜像数据库中重做。主体数据库创建镜像后，会启动一个单独的事务日志发送线程，维护一个虚拟的发送队列，然后读取事务日志，将其进行压缩，然后发送给 mirror 节点，mirror 节点接收到以后，会将其写入本地在磁盘上的一个重做队列文件中，然后再通过另外的一个线程异步的方式，从重做队列中获取事务日志，然后分发给应用线程(process unit)进行回放。
数据镜像的两种模式
同步镜像操作：在事务传送中，主服务器必须等待镜像服务器返回成功接收日志的消息后，主服务器才继续下一事务日志到磁盘的写入与提交到镜像服务器。这种镜像不会造成数据丢失，但是存在镜像操作的事务延迟。
异步镜像操作：在事务传送中，主服务器不等待镜像服务器返回日志的接收情况，继续写下一事务日志到物理磁盘并提交给镜像服务器，这种镜像操作性能较高，但是主服务器宕机后可能造成镜像服务器数据丢失。
1、搭建mirror，必须先对主库进行全备和日志备份，并且要以norecovery方式把全备和日志恢复到从库，之后再在主库右键数据库-->properties-->mirror，参考图形界面一步步来搭建，如下是主库搭建mirror的报错,因为从库恢复的时候只恢复了数据库没有恢复日志导致
The mirror database, "XX", has insufficient transaction log data to preserve the log backup chain of the principal database. This may happen if a log backup from the principal database has not been taken or has not been restored on the mirror database.
2、图形界面搭建镜像过程中，跳出的端点名称会自动创建好，不需要手工先去创建，跳出的端点名称和端口可以自己定义，默认的是Mirroring和5022
3、搭建好后，监控mirror的工具，右键数据库-->Tasks-->Launch Database Mirroring Monitor,这个工具主库从库都有，效果一样，这点和log shipping的Transaction Log Shipping Status主库只负责主库，从库只负责从库不一样。
4、搭建好后，主库后面状态显示(Principal,Synchronized)，从库后面状态显示(Mirror,Synchronized/Restoring..)
5、搭建好后，主库和从库都有一个job名字是“Database Mirroring Monitor Job”，就算拆掉数据库的mirror，主从上该job还在，新增一个数据库的mirror，主备还是该job，没新增job，该job删除后，就算还有数据库的mirror，该job也不会自动重建，但是下次新增数据库的mirror时，该job会重建
6、因为从库的镜像数据库无法读，所以可以在从库创建快照数据库来读，来确定mirror是否真正的同步
7、如果想实现主从自动切换，即自动故障转移功能，必须要有见证服务器
8、如果主库故障了，从库状态变成(Mirror,Disconnected/In Recovery)，执行如下语句，恢复从库的读写状态(必须先执行第二条语句删除从库的快照，否则第三条语句无法执行)
ALTER DATABASE testdb SET PARTNER OFF;
drop database testdb_snapshot;
RESTORE DATABASE testdb WITH RECOVERY;
9、如果主库执行了移除remove镜像操作后需要删除从库再重新搭建主库从库的镜像，但是从库仍然显示(Mirror,Disconnected/In Recovery)，导致从库无法删除，且从库执行ALTER DATABASE testdb SET PARTNER OFF后状态仍是(Mirror,Disconnected/In Recovery)，则需要先在主库配置一下镜像，然后会报错镜像搭建不成功，这个时候从库状态显示(In Recovery),从库这时候可以直接删除。如果从库还是无法删除，就先在主库配置一下镜像，然后会报错镜像搭建不成功，再重启从库实例，从库状态一般会显示为(suspect),这时从库也可以直接删除了。
10、手动故障转移需要将事务安全设置为 FULL，且当伙伴连接在一起并且数据库已同步时即数据库处于 SYNCHRONIZED 状态时，才支持手动故障转移，登录主库执行如下语句，上面8非手动故障转移，因为数据库不是同步状态而是Disconnected/In Recovery
USE master;
ALTER DATABASE testdb SET PARTNER FAILOVER;
11、如果从库使用主库的全备和日志备份进行restore norecovery后，开始搭建mirror，但是这个过程中，mirror还没有搭建好，主库又备份了日志，mirror无法成功搭建，会有如下报错，只能把主库备份的日志再restore norecovery到从库，才可以正常搭建mirror
The remote copy of database <DatabaseName> has not been rolled forward to a point in time that is encompassed in the local copy of the database log
12、从库无法直接delete删除，这点和logshipping不一样
13、镜像故障查找，可以从主库和从库的日志中找相关信息
14、mirror数据库升级后，无法修改数据库版本COMPATIBILITY_LEVEL，因为mirror是只读的，暂停mirror也无法修改，因为数据库是restoring状态
15、mirror相关信息，可以参考视图sys.database_mirroring
16、mirror的从库，不能执行backup
17、主库升级后可以修改level，从库升级后无法修改level，如果主库修改了level一旦主库的日志同步到从库后，从库对应的数据库的level会和主库一样
18、主库新增datafile后，从库也会新增datafile，并且路径和主库的路径一样
19、mirror主库增加了文件，但是从库没有相应的目录，则同步会suspend挂起，就算从库有默认的datafile和logfile路径。在从库的数据库日志里面可以看到报错信息:CREATE FILE encountered operating system error 3(The system cannot find the path specified.) while attempting to open or create the physical file 'E:\XX\YY.ndf'.
20、FILETABLE的数据库无法搭建mirror，会报错A database cannot be enabled for both Database Mirroring and FILESTREAM or for both Database Mirroring and MEMORY_OPTIMIZED_DATA storage
21、搭建mirror时遇到一个怪异报错Database 'mirror_1' cannot be opened. It is in the middle of a restore。最后发现是因为数据库实例的版本是2016，而搭建mirror时使用的SSMS版本是2017，把SSMS换成2016就没有再报这个错误了，这个算是sqlserver的bug了
22、在从库创建镜像数据库mirror1的快照数据库mirror_snapshot，NAME必须等于等于主库里面的数据文件相同的逻辑名称，filename自己随意定义，指快照数据库的filename
create database mirror_snapshot on
(NAME=mirror1,filename='G:\DEFAULT.DATA\mirror_snapshot')
as snapshot of mirror1;
23、监控mirror数据库Db1最近的同步情况，可以参考如下语句（2表示最后4小时的行，如果把2改成1表示最后2小时的行）
USE msdb;
EXEC sp_dbmmonitorresults Db1,2, 0;
24、主库的状态一直是(Principal,Suspend),右键主库--属性--Mirroring--Resume后，主库的状态是(Principal,Synchronizing),过一会主库状态还是(Principal,Suspend),查看从库实例的日志有如下内容
The instance of the SQL Server Database Engine cannot obtain a LOCK resource at this time. Rerun your statement when there are fewer active users. Ask the database administrator to check the lock and memory configuration for this instance, or to check for long-running transactions.
解决方法：右键主库--属性--Mirroring--Remove Mirroring，从库状态变成(Mirror,Disconnected/In Recovery),再在主库创建Mirror，这时会报错，从库状态变成(restoring),这个时候，把主库备份的日志拿到从库去手工restore，所有日志都restore完了后，再在主库创建Mirror就正常了。
25、8核CPU，数据库最大内存16GB环境，发现Database1在15分钟内产生的日志达到500MB以上时，mirror很容易出现suspend的状态，查看日志发现信息如下，就算你重启数据库，还是解决不了这个问题，只能移除mirror，在从库上再手工restore这些日志，再搭建mirror
The instance of the SQL Server Database Engine cannot obtain a LOCK resource at this time. Rerun your statement when there are fewer active users. Ask the database administrator to check the lock and memory configuration for this instance, or to check for long-running transactions.
Database mirroring will be suspended. Server instance 'Instance1' encountered error 1204, state 4, severity 19 when it was acting as a mirroring partner for database 'Database1'. The database mirroring partners might try to recover automatically from the error and resume the mirroring session. For more information, view the error log for additional error messages.
26、关于mirror和logshipping的选择，遇到数据库在短时间内产生的日志很大，比如15分钟内产生了500MB，那么mirror不如logshipping，因为mirror需要消耗更多的内存，mirror很容易出现suspend的状态
27、搭建mirror时遇到错误：服务器网络地址 “TCP://dbalias:5022″ 无法访问或不存在。请检查网络地址名称，并检查本地和远程端点的端口是否正常运行。 (Microsoft SQL Server，错误: 1418)。
解决思路
27.1、telnet dbalias:5022 是否通
27.2、检查主备机器的sqlserver启动账号是否有权限访问对方实例
27.3、以上两点都正常的情况下，重启备机
27.4、以上步骤3也做过还是不行的话，重启主机(自己就遇到一个这样的问题，直到这第四步做完才能正常搭建mirror)
28、监控mirror同步更新状态可以结合使用存储过程msdb.sys.sp_dbmmonitorupdate和系统表msdb.dbo.dbm_monitor_data
“sqlserver关于mirror镜像的知识点有哪些”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注亿速云网站，小编将为大家输出更多高质量的实用文章！
