维护SQL SERVER SAP系统最佳实践

https://blogs.msdn.microsoft.com/saponsqlserver/2015/04/21/best-practices-for-maintaining-sql-server-sap-systems/

总结：

1、执行规律性的全备份

2、执行周期性的事务日志备份

3、验证你的灾难恢复计划

4、运行CHECKDB

5、保持当前版本的软件补丁

6、确保系统运行良好

7、检查和熟悉掌握SAP Note 555223

8、建立标准的操作流程

9、维护一个可操作性的日志簿

10、检查错误日志

11、基线性能管理

12、理解你所选择的HA和灾难恢复解决方案

13、Truly Mimic PRD with QA and/or Stress Testing Servers

14、在配置改变后备份系统数据库

15、获取终端用户反馈

16、使用云虚拟化技术

1、执行规律性的全备份

• For ABAP stack Netweaver systems, everything that is required for SAP (business data, metadata and ABAP applications etc) is included in one “<SID>” database
• When backups are executed using a single process, without parallel targets, and without compression the use of CPU resources is quite light.   But when it is executed in parallel, with multiple targets, and using compression to save space then the impact to CPU resources will be quite significant.
• SQL Server offers interfaces for SAN vendors to perform a Snapshot Backup or to create clones of a SQL Server database.
• a cloud based backup strategy：https://blogs.msdn.microsoft.com/saponsqlserver/2014/11/19/protecting-sap-solutions-with-azure-site-recovery/
• System databases are helpful to backup, but not entirely critical for SAP systems.   Should a disaster happen, a fresh SQL Server instance can be installed, the operational database SID restored, users manually created, and msdb jobs rebuilt.   It is easier if you have backups of the master database and msdb, but the critical thing is the operational database.    The msdb system database can be important from a maintenance standpoint if you are using SQL Server’s online backup functionality, for it would contain the history of the FULL and LOG backup events.   The catalog of backups can be resynthesized manually, but that could call for a large amount of work if there is no systematic operational practice that is used for backup tape management.   In either case it is important to validate your Disaster Recovery plan using whatever backup strategy is in place and to understand what is needed to return to normal operations.
• More information on Backup Strategies can be found in SAP Note 1878886.

2、执行周期性的事务日志备份

• All data modifying statements must be recorded first in the transaction log before the changes are persisted to the data rows inside of the data files.
• In case of a disaster happening on the production server, it is vital that the most recent status can be restored using full or differential database backups plus a series of TLog backups which ideally cover as close as possible to the time of the disaster and is roughly described here.
• Backing up the transaction log frees up the internal Virtual Log Files so that the size can be managed and avoid the log file from becoming full. If the SID database is set to operational mode FULL, as it should be, the only way that the transaction log size can be reduced is by backing up the log.

3、验证你的灾难恢复计划

• In order to validate your Disaster Recovery Plan (DRP), you need to have one first!   Do you have one?   You should.   A DRP can be created for anything of operational significance to a business.   It is appropriate that all critical SAP systems have DRPs established for what will happen in the event of a disaster.   A disaster being anything from acts of nature (fire, lightning strike, flooding) to manmade (terrorists, disgruntled employees, or simply gross human error). 
• Test It.   Testing a DRP is the only way to confirm that it works and to learn of weaknesses in the plan. 
• Time it.   This is helpful information to be able to communicate when a Disaster is being experienced.   It is very calming to be able to state, “The system should be up and running again in about X minutes.”  That message typically lands much better than, “We aren’t certain, but we’re working hard, and it will be up as soon as it can be.”
• Check it.   As part o 5b4 f your DRP validation efforts, since there is a viable second instance where the testing is happening, use that system to also run CHECKDB to check the physical consistency of BOTH the source SID and the backup image too.   Doing this on a second, separate system will not impact the I/O subsystem of the production system and is an additional side benefit.
• Document it.   Quality DRPs are written documents to move the DR expertise toward something that the entire IT organization is responsible for.  KEEP THIS DOCUMENT UP TO DATE.  The document needs to be a living document that all changes get recorded for all potential DRP users to be made aware.   The DRP (and its validation) should be driven through the written document. 
• Teach it.  A good DRP is able to be spread across multiple individuals to avoid any individual being a single point of vulnerability (vacation, sickness, etc.).  It can also be used as a great teaching tool for less experienced IT staff to learn operational procedures.
• What is involved with a complete Disaster Recovery Plan varies along with the extensibility that SAP provides through its software.   If customers are unfamiliar with this area they should pursue outside expertise to assist them.  
• If you are working with Azure, then you can also leverage Azure Site Recovery (ASR) to help you with this effort as Cameron describes HERE.

对关系型数据库系统备份和恢复的理解：

一个灾难后，数据是否能恢复到故障点，完全依赖于备份点和事务日志，一个成功的备份是截断事务日志的最佳做法，也是保证数据连续性的唯一办法；

一个规律性的全备，周期性的差异备份和事务日志备份计划，是能保证快速恢复的最佳实践；怎样恢复到故障点，需要按照恢复计划，恢复到离故障点最近的前置时间点，在前置时间点-故障点之间发生的数据改变，完全依赖事务日志的redo操作，可以恢复到故障点。保证数据的完整性。

截断和缩小日志文件的方法：

1、最近成功的日志备份，将使日志文件变小；

2、简单恢复模式，不得已就不用去做，一定会丢失数据，只有一种情况不丢失数据，事务日志完成写入了数据库文件，这个情况一般很少；

3、如果是日志文件不断的增长，或者超大，一定是备份出了问题。

4、运行CHKDB