SAP HANA 故障恢复处理.docx
- 文档编号:10863664
- 上传时间:2023-02-23
- 格式:DOCX
- 页数:18
- 大小:553.45KB
SAP HANA 故障恢复处理.docx
《SAP HANA 故障恢复处理.docx》由会员分享,可在线阅读,更多相关《SAP HANA 故障恢复处理.docx(18页珍藏版)》请在冰豆网上搜索。
SAPHANA故障恢复处理
(一)、SAPHANA数据库的恢复技术:
系统故障恢复
众所周知,SAPHANA是内存数据库,很多人会有疑问,内存是断电就会丢失数据的设备,SAPHANA是怎样保证数据在内存中并且断电不会丢失的呢?
此问题涉及到概念叫数据库保护:
排除和防止各种对数据库的干扰破坏,确保数据安全可靠,以及在数据库遭到破坏后尽快地恢复。
而数据库的恢复技术是数据库保护的重要手段。
还要介绍一个概念:
事务:
一个不可分割的操作序列,其中的操作要么都做,要么都不做。
举个例子:
银行转帐:
A帐户转帐到B帐户100元。
该处理包括了两个更新步骤
∙A=A-100
∙B=B+100
这两个操作是不可分的:
要么都做,要么都不做。
事务的状态在日志中包含三种:
∙
∙
∙
数据库的故障分为三类:
∙事务故障:
单个事务的内部故障,不会影响其他事务;
∙介质故障:
硬故障:
如磁盘损坏,磁盘已满等;
∙系统故障:
软故障,如停电、死机等,这些故障会导致内存数据丢失,影响当前的全部事务。
数据库对系统故障的恢复主要目的是恢复到故障发生之前的状态,即尚未完成的事务进行回滚,已完成的事务要确保其完成。
1、系统故障恢复验证
在SAPHANA中,这些概念同样适用,下面对SAPHANA的系统故障的恢复进行验证。
本文的测试案例所使用的SAPHANA版本为SAPHANASPS7Revision70.00。
首先修改savepoint时间,在savepoint过程中,SAPHANA会把内存页持久化在硬盘上,而SAPHANA的默认savepoint间隔为300s,将其改为3000s。
开启两个SQL窗口,将SQL 窗口的autocommit属性设置为off。
在sql窗口1中执行
1.insert into "LOGTEST"."TEST" values(1,'欢迎大家一起来学习SAP HANA知识,分享SAP HANA知识。
');
在sql窗口2中执行
1.insert into "LOGTEST"."TEST" values(2,'欢迎大家一起来学习SAP HANA知识,分享SAP HANA知识。
');
2.
3.
mit;
将SAPHANA进行断电处理。
开机重启SAPHANA,查看此表内容。
我们可以认为窗口1和窗口2是两个事务T1和T2,事务T1执行一条修改后,没有commit,因此故障之后回滚到事务T1执行前。
事务T2已经commit,虽然SAPHANA尚未把数据持久化到硬盘上(未做savepoint),但是由于事务日志的存在,数据库被成功恢复到了故障点。
2、系统故障的恢复策略
如上图所示,当发生故障时,若是介质故障,则首先重装副本(系统故障省略此步骤),然后利用日志进行事务故障恢复和系统故障恢复,一直恢复到故障发生点。
3、事务日志
事务日志是用来管理数据库系统中记录的变化,记录了所有更新操作的具体细节。
为了让一个事务持久化不丢失,我们不必在事务提交时就把完整的数据内容持久化在硬盘中,只需要持久化事务日志就足够了。
当系统崩溃后,数据库中的最近的一致性状态可以通过回放事务日志来恢复。
因此日志文件的记录严格按照事务的执行时间次序。
事务日志主要包含三种:
Undo日志、Redo日志、Undo/Redo日志。
而在SAPHANA中,只有两种日志:
Undo日志、Redo日志。
日志文件的内容主要包含以下三方面:
∙事务的开始标记(
∙事务的结束标记(
∙事务的更新操作记录,一般包括以下内容
其中,一条更新操作记录包括:
执行操作的事务标识,操作对象,更新前值(Undo)或者更新后值(Redo)或者更新前值和更新后值(Undo/Redo)。
4、Redo日志
Redo日志的特点是,在修改数据写入数据库之前,对应该修改的Redo日志记录必须已被写到磁盘上。
日志中数据修改记录的格式为
如下图所示,事务T1的操作是A=A-100,B=B+100,图左方为数据库中的T1具体步骤,图中间为T1对应的Redo日志内容,图右方标识A和B的初始值分别为1000,2000。
Redo日志的恢复过程如下:
1.从头扫描日志,找出所有有
2.从首部开始扫描日志记录
∙write(X,v)(将新值赋给X)
∙output(X)(将X写入数据库)
1.ForeachT不属于 Ldo
∙write
这种恢复方式的理论基础是没有
而有
SAPHANA的Redo日志是与事务处理的过程同步的写到磁盘中的。
当数据库遇到崩溃后重启,需要对持久化的日志进行处理,为了提高日志处理的速度,系统会定期的进行savepoints(保存点,类似于传统数据库中的checkpoint)。
在一个savepoint的过程中,系统确保在上一个savepoint后所有在内存中的数据改变都被持久化在硬盘中。
因此,当启动系统后,只有最后一次savepoint之后的redo日志才需要被处理。
当日志备份后,savepoint之前的过时的redo日志可以被删除。
5、Undo日志
SAPHANA不仅仅持久化committed的改变记录,它还可能持久化未committed的改变记录(注:
此改变记录并非log,而是data),例如:
在savepoint过程中,最近版本的的改变过的页都会被写到磁盘中,无论这个改变是否已commit。
因此Undo日志需要被持久化在硬盘中。
Undo日志的记录格式为
如下图所示事务T1的操作是A=A-100,B=B+100,图左方为数据库中的T1具体步骤,图中间为T1对应的Undo日志内容,图右方标识A和B的初始值分别为1000,2000。
Undo日志的恢复过程如下:
1.从头扫描日志,找出所有没有
2.从尾部开始扫描日志记录
∙write(X,v) (将旧值赋给X)
∙output(X) (将X写入数据库)
1.ForeachT属于Ldo
∙write
在SAPHANA中,与Redo日志不同,Undo日志持久化时不放在日志区,而是放在数据区,在savepoint时才会被持久化。
这样做的原因是系统重启后可以自动恢复到最近一次savepoint的状态,在这此savepoint后的事务如果已经commit,则可以通过redo日志进行回放,如果未commit,也不需要undolog进行回滚,因此,此savepoint的之后的undolog是没有用的。
这样做带来的好处:
∙更少的log记录在事务提交时被持久化。
∙减缓Log区硬盘使用量的增长。
∙数据库可以只从数据区就可以恢复到一致性状态。
(不需要日志区)
6、Savepoint
当系统发生故障时,必须扫描整个日志来确定undo列表和redo列表,这样会带来问题是:
这个搜索过程太耗时,因为日志文件增长很快;会导致最后产生的Redo列表很大,使恢复过程变得很长。
因此SAPHANA会定期的做savepoint,在savepoint过程中主要做以下工作:
1.不再接受新的事务
2.把undo信息写到磁盘(data区)
3.把内存中修改过的数据页写到磁盘
4.在log文件中写入 savepoint标记(log区)
如下图所示,savepoint技术保证了savepoint之前所有的commit操作已被写到磁盘,在恢复时不需要进行redo操作。
(二)、SAPHANA数据恢复技术:
数据库备份
Tweet
1、SAPHANA数据库的备份
为了保证最佳的性能,SAPHANA把数据存储在内存中,然而,SAPHANA也使用持久化的存储系统来进行故障的恢复。
上一篇文章讲过,数据库进行正常操作时,数据和undo日志在保存点(Savepoint)过程中会自动地持久化到硬盘中,数据的变化被记录在redo日志中。
Savepoint和写日志操作可以防止突然的断电对数据库的影响,但是当持久性存储设备(如硬盘)发生故障后,它们就无能为力了。
为了防止硬件故障导致的数据丢失,数据库备份是必须的。
备份操作过程对SAPHANA的性能影响是可以忽略不计的,用户可以继续正常工作。
数据库从备份中恢复和重启系统是相似的,都是从硬盘中读取数据和日志。
但是它们的差别是,数据库从备份中恢复需要的是外部备份文件。
由于SAPHANA中数据和日志(redo)存储在不同的分区中,因此数据库的备份也分为日志备份和数据备份两个部分,这两个部分的过程是相互独立的。
SAPHANA的备份需要注意一下几点:
1.SAPHANA的备份所需要的授权见下表。
授权名称
注释
BACKUPADMIN
执行备份的授权
CATALOGREAD
备份时搜集信息的授权
1.在SAPHANA进行第一次数据备份以前,日志备份是不会进行的(logmode处于overwrite模式)。
2.备份和恢复都是应用于整个数据库的,不可以备份和恢复数据库中的某一个对象。
3.SAPHANA可以通过第三方备份工具进行备份。
4.最好使用共享存储设备进行备份,因为它不仅可以让所有节点访问到备份数据,而且系统更容易管理共享设备。
2、日志的备份
在SAPHANA中,默认情况下,系统自动备份日志,前提必须是做过一次数据备份。
在自动备份的模式下,三种情况会触发一个logsegment备份:
1.Logsegment满了。
2.超过log备份timeout设置时间,logsegment关闭。
3.数据库启动。
系统用户可设置备份模式,设置 HANAstudio中Configuration->golobal.ini->persistence->log_mode和enable_auto_log_backup,如下图所示:
Logmode有两种模式可选:
1.Normal(默认),在该模式下,如果enable_auto_log_backup=yes,logsegment会被自动的备份,这种方式的好处是:
备份后的logsegment文件可以被重新利用,从而避免了logvolume慢导致数据库崩溃。
下一篇将讲述硬盘满后的恢复工作。
2.Overwrite,在该模式下,logsegment不会被进行备份,进行了savepoint之后,free状态的logsegment会被直接覆盖。
由于没有日志的备份,这种模式不推荐在生产系统中使用。
如果使用Overwrite模式,数据将只能通过数据备份进行恢复了,不能达到恢复到point-in-time的效果,只能恢复到某个savepoint。
我们也可以设定log备份的时间间隔,Configuration->golobal.ini->persistence->log_backup_timeout_s。
系统默认时间间隔为900s,如果发生介质故障需要从备份恢复且日志日志区不能被用来进行恢复,这段时间内的系统数据改变将会丢失。
如果此处设为0,那么系统只有在logsegment满或者系统重启时才会备份log。
3、数据的备份
SAPHANA数据区的备份包含了数据库的所有内容:
事务数据已经管理数据(例如:
用户,角色,模型和视图)。
只有真正的数据会被备份,数据库中未使用的空间不会被备份。
数据区进行备份时,会备份每一个SAPHANA服务的数据。
如果SAPHANA运行在多个主机上,那么数据备份会包含所有主机上的以服务为单位的备份。
默认情况下,SAPHANA的数据备份目录为$DIR_INSTANCE/backup/data。
注意这个目录以及日志备份目录$DIR_INSTANCE/backup/log与SAPHANA的日志区和数据区要放在不同的硬盘上,这样即使SAPHANA系统发生介质故障,也不会影响日志硬盘。
数据备份可通过三种工具进行备份:
SAPHANAstudio,SQL命令,批处理模式。
使用 SAPHANAStudio进行备份
1.右击系统,选择BackUp…,弹出窗口如下图所示,选择Backup类型,如果安装了第三方备份工具,则可选择其他类型,本文不介绍。
2.设定备份的目标目录以及该备份的前缀名。
此时应确保指定的备份目标目录有足够的空间进行备份。
3.点击Next,显示备份设置的总结。
4.点击Finish,备份开始。
视图会显示所有服务的备份进程。
使用SQL命令进行备份
管理用户可以在SAPHANAStudio中的SQL 控制台或者hdbsql中使用SQL命令进行备份。
推荐在批处理情况下,才使用SQL命令进行备份。
SQL 命令为:
BACKUPDATAUSINGFILE('
其中
例如:
BACKUPDATAUSINGFILE('/backup/data/MONDAY/COMPLETE_DATA_BACKUP')
该语句会在/backup/data/MONDAY中创建
COMPLETE_DATA_BACKUP_databackup_0_1(nameservertopology)
COMPLETE_DATA_BACKUP_databackup_1_1(nameserver)
COMPLETE_DATA_BACKUP_databackup_2_1(forexample,indexserver)
...
批处理模式进行备份
用户可以在操作系统级别使用SAPHANA的命令行工具HDBSQL进行备份。
HDBSQL可以让用户通过crontab来让数据库在固定时间固定间隔进行备份。
1.安装SAPHANAClient,该客户端软件可以让用户使用hdbuserstore,从而避免直接在命令行中输入密码:
hdbinst–aclient(defaultlocation:
/usr/sap/hdbclient)
1.创建一个用户钥匙:
/usr/sap/hdbclient/hdbuserstoreset
3
例如:
/usr/sap/hdbclient/hdbuserstoresetBACKUPvebwtests1:
30015userpassword
1.在crontab中,执行:
/usr/sap/hdbclient/hdbsql–U
例如:
/usr/sap/hdbclient/hdbsql-UBACKUP"BACKUPDATAUSINGFILE('MONDAY')"
(三)、SAPHANA数据恢复技术:
数据库恢复
Tweet
SAPHANA数据库的恢复主要应用在以下场景中:
∙数据区硬盘无法使用
∙日志区硬盘无法使用
∙逻辑错误导致数据库需要被重置到一个特定的时间点
∙数据库拷贝
1、数据区不可用
若数据区不可用,并且在上一次数据备份之后所有数据改变的log备份和log区文件都可用,那我们可以恢复到数据库失效的时间点,已提交的数据不会丢失。
对于此情况的数据库恢复,数据备份或者存储快照,日志备份以及日志区都是需要的,当数据库成功的从数据备份或者数据快照恢复后,会使用log备份和log区的日志进行回放。
2、Log区不可用
若log区不可用,只需要回放log备份。
这样的结果是任何log备份之后的改变都会丢失。
除此之外,所有在log备份时未commit的事务都会被回滚。
对于此情况的数据库恢复,数据备份或者存储快照,日志备份会被使用。
当数据库成功的从数据备份或者数据快照恢复后,会使用log备份日志进行回放。
再恢复时需要指定Initializelogarea选项以避免从不可用的log区恢复。
3、逻辑错误—时间点恢复
若需要恢复到某个时间点,管理员需要这个时间点前的一个数据备份或者一个存储快照,以及日志备份和日志区的一部分。
由于此种方式会将时间点后的改变全部丢失,从安全考虑来讲,推荐用户在另一个系统进行恢复。
恢复流程
∙在SAPHANASystem视图,右键点击要恢复的系统,选择“Recovery…”
∙点击OK以关闭系统。
∙根据下表选择一种恢复方式。
选项
描述
恢复数据库到最近的状态
此选项将恢复数据库到离当前最近的状态,需要以下数据:
1.最近的数据备份(File,Backint, 或存储快照)
2.数据备份后的日志备份
3.日志区数据
恢复数据库到指定时间点
需要以下数据:
1.最近的数据备份(File,Backint, 或存储快照)
2.数据备份后的日志备份(包括此时间点之后的日志备份)
3.日志区数据
恢复数据库到指定数据备份或者存储快照
需要以下数据:
1.指定数据备份(File,Backint, 或存储快照)
恢复数据库到某个log位置
此选项是用来处理之前的恢复失败的情况,需要以下数据:
1.Log位置之前的数据备份(File,Backint, 或存储快照)
2.数据备份后的日志备份
3.日志区数据
∙选择一项后点击“Next”。
∙若需要日志备份,则指定日志备份的位置。
∙由于系统会根据备份目录以失败备份的位置,因此不需要指定恢复哪个备份,点击Next。
∙根据需要选择额外的选项,点击“next”。
∙恢复总结显示出来,如果设置正确,选择“Finish”,恢复开始。
4、使用备份和恢复拷贝数据库
用户可以使用恢复的方式来从源数据库拷贝到目标数据库。
这种方式可以很大程度减少实施消耗(TCD)。
用户可以选择两种方式拷贝数据库:
∙使用源数据库的数据备份和日志备份文件来拷贝。
∙只使用数据备份文件进行拷贝。
使用备份来拷贝数据库的具体流程与上文恢复数据库的流程相同,但需注意:
1.如果目标系统主机数少于源系统主机数量时,必须配置目标系统,使错个indexserver服务运行在一个主机上。
如果其他多个服务存在,则需要每个服务运行在单独的主机上。
可通过
ALTERSYSTEMALTERCONFIGURATION('daemon.ini','system')set('indexserver.c','instanceids')='
来添加额外的indexserver到一个主机的系统。
1.如果目标系统的主机数多于源系统主机数,则必须移除多余的主机。
2.在源数据库建立snapshot
5、使用存储快照拷贝数据库
BACKUPDATACREATESNAPSHOT(或使用HANAStudio)
1.关闭目标数据库,拷贝源数据库的data区到目标数据库的data区
2.在源数据库确认或放弃snapshot
SNAPSHOTBACKUP_ID
其中
SELECT*FROM"SYS"."M_BACKUP_CATALOG"WHEREENTRY_TYPE_NAME='datasnapshot'
1.在目标数据库中,删除备份文件,如果$DIR_INSTANCE/../SYS/global/hdb/metadata 中存在BackupCatalog.xml文件,删除掉。
2.在目标数据库用户环境下执行以下命令:
(或使用HANAStudio)
hdbnsutil-useSnapshot
hdbnsutil–convertTopology
1.启动目标数据库
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- SAP HANA 故障恢复处理 故障 恢复 处理