db2的灾备大家都怎么做的？（立项调研）
对于db2 9.5、9.7、10.5这些版本的db2，大家都是如何考虑的灾备的哪？
如何实现的哪？
【调研背景】：
目前生产系统db2有很多版本，包括9.5、9.7、10.5三个版本。以9.7居多。现在想要考虑这些数据库的灾备建设方面，之前都是通过HA方式搭建的灾备方案。对HADR没有使用过。
1：单机db2如何考虑灾备
2：dpf数据库一般采用什么方式灾备
3：非gdpc模式的purescale如何考虑灾备
【市场上的灾备方案】：
1：hadr（同步、异步模式）
2：HA架构
3：存储复制
【问题汇总】
1：对于众多版本的db2，大家一般采用什么方式做灾备，都考虑什么方面的要素哪？
2：hadr大家在生产上一般用同步模式还是异步模式，如果异步模式，他的延迟是多少（80公里左右的同城灾备，系统是比较重要的业务系统）
hadr在灾难发生的时候，切换的时候，ip是自动切换成原来的主服务器对应的ip吗？还是需要应用服务器方面修改相应配置？
3：ha架构是实现了服务器的灾备，存储方面的灾备是不是没有实现？
4：存储方面的灾备，那如果异常发生时，如何切换成生产哪？ip怎么切换哪？
5：虽然数据库方面可以利用hadr做灾备，那应用服务器如何做灾备哪？灾难发生时，应用该如何切换那？
如何实现的哪？
【调研背景】：
目前生产系统db2有很多版本，包括9.5、9.7、10.5三个版本。以9.7居多。现在想要考虑这些数据库的灾备建设方面，之前都是通过HA方式搭建的灾备方案。对HADR没有使用过。
1：单机db2如何考虑灾备
2：dpf数据库一般采用什么方式灾备
3：非gdpc模式的purescale如何考虑灾备
【市场上的灾备方案】：
1：hadr（同步、异步模式）
2：HA架构
3：存储复制
【问题汇总】
1：对于众多版本的db2，大家一般采用什么方式做灾备，都考虑什么方面的要素哪？
2：hadr大家在生产上一般用同步模式还是异步模式，如果异步模式，他的延迟是多少（80公里左右的同城灾备，系统是比较重要的业务系统）
hadr在灾难发生的时候，切换的时候，ip是自动切换成原来的主服务器对应的ip吗？还是需要应用服务器方面修改相应配置？
3：ha架构是实现了服务器的灾备，存储方面的灾备是不是没有实现？
4：存储方面的灾备，那如果异常发生时，如何切换成生产哪？ip怎么切换哪？
5：虽然数据库方面可以利用hadr做灾备，那应用服务器如何做灾备哪？灾难发生时，应用该如何切换那？
16同行回答
浏览1131
谢谢！收起
浏览1167
NBU 备份DB2数据库， 报错 SQL2062N 其日志报错为：
bphdb do_backup: ERR - Script exited with status = 4
10:00:51.428 [435082] <16> bphdb Exit: ERR - bphdb exit status = 6: the backup failed to back up the requested files
------------------------------------------------------------
SQL2062N An error occurred while accessing media "VENDOR". Reason code:
"518".
如何解决收起
bphdb do_backup: ERR - Script exited with status = 4
10:00:51.428 [435082] <16> bphdb Exit: ERR - bphdb exit status = 6: the backup failed to back up the requested files
------------------------------------------------------------
SQL2062N An error occurred while accessing media "VENDOR". Reason code:
"518".
如何解决收起
浏览1204
9.7以后，HADR就支持备机可读，隔离级别是UR，即会出现脏读。
一般HADR都是近同步模式，主备机日志多少有点差距的，所以实际用当中，一般都是用来生成报表，数据仓库抽数等。
10.1以后，还支持多备机模式，最多支持3个备机。收起
一般HADR都是近同步模式，主备机日志多少有点差距的，所以实际用当中，一般都是用来生成报表，数据仓库抽数等。
10.1以后，还支持多备机模式，最多支持3个备机。收起
浏览1134
HADR在非purescale环境下的备机可读吗？读是否有限制？例如必须脏读？收起
浏览1130
一般的大型灾备都是使用存储级的复制技术，而HADR 在此环境中作为次要的灾备方案使用。一旦存储快照失效则启用HADR。我看到的HADR 都是是用异步方式，这样不会再日志归档出现问题时对primary 节点造成影响。收起
浏览1340
关于这个问题楼上回答的非常详细了,在这里补充的是
1) 灾备方案要根据应用系统要求和环境距离要采取多级灾备方案。 DB2除了HADR外，还有SQL复制，Q复制可以选择，后面两种都是利用日志分析，SQL重演的方式在数据级别的灾备方案，很多环境都在使用。无论乃种灾备，都无法保证数据完全不丢失的风险，所以对于非常关键的系统，要采取多级灾备结合的方案。
2) HA 其实对于数据库来讲，已经是一种过时的灾备方案了，但对于应用服务器来讲仍然是切实可行的
3) 存储复制确实可以起到灾备的效果，非常多案例中，可能数据快速迁移、复制的意义更大一点收起
1) 灾备方案要根据应用系统要求和环境距离要采取多级灾备方案。 DB2除了HADR外，还有SQL复制，Q复制可以选择，后面两种都是利用日志分析，SQL重演的方式在数据级别的灾备方案，很多环境都在使用。无论乃种灾备，都无法保证数据完全不丢失的风险，所以对于非常关键的系统，要采取多级灾备结合的方案。
2) HA 其实对于数据库来讲，已经是一种过时的灾备方案了，但对于应用服务器来讲仍然是切实可行的
3) 存储复制确实可以起到灾备的效果，非常多案例中，可能数据快速迁移、复制的意义更大一点收起
浏览1361
对会员提出的新问题进行补充回答，可能比较简略。
1. 如果单从DB2数据库层面上来，HADR适合各个版本，尤其对9.7及之前的，其实在这个层面没有太多别的选择，也有使用数据库复制方案的，但是有好处也有弊端。DPF不支持HADR，所以可以使用TSA或其他第三方的灾备方案。非GDPC的pureScale也同样可以考虑HADR，新版本已经支持并做过测试。
2. HADR有多种同步模式，采用完全同步和异步的不多见，多数用NEARSYNC模式，即接近SYNC但是通信开销少，对主机性能影响也小。去除网络因素，延迟很大程度上跟业务量有关系，但是基本不影响主机，主要是备机catch up的时间，如果短时间业务量不是非常大的话基本都能跟上。（这点跟GDPC不一样，因为主机不用等待备机完全落实即可继续业务，所以HADR的支撑距离可以相当大）。
ip切换可以采用虚拟IP或自动路由，不用更改应用。
3. HADR就是等于复制了一套数据库在备机上，所以存储是双份的，从这个角度上存储的灾备是实现了。（类比操作系统层面的HA，多数是共享存储）
4. HADR可以借用TSA进行自动切换，也可以自己手动切换，都有对应的命令。ip上面提到过了。
5. 应用服务器可以用多种方案，比如中间件层面WAS和SAP都可以做自己的集群；OS层面可以采用类似HACMP的HA方案等；存储也可以使用flashcopy。具体切换策略按照实际情况来制定，可以采用脚本或工具来实现自动或半自动切换。
希望这些有帮助，建议需要的话可以随时联系我们，来做有针对性的深入交流。收起
1. 如果单从DB2数据库层面上来，HADR适合各个版本，尤其对9.7及之前的，其实在这个层面没有太多别的选择，也有使用数据库复制方案的，但是有好处也有弊端。DPF不支持HADR，所以可以使用TSA或其他第三方的灾备方案。非GDPC的pureScale也同样可以考虑HADR，新版本已经支持并做过测试。
2. HADR有多种同步模式，采用完全同步和异步的不多见，多数用NEARSYNC模式，即接近SYNC但是通信开销少，对主机性能影响也小。去除网络因素，延迟很大程度上跟业务量有关系，但是基本不影响主机，主要是备机catch up的时间，如果短时间业务量不是非常大的话基本都能跟上。（这点跟GDPC不一样，因为主机不用等待备机完全落实即可继续业务，所以HADR的支撑距离可以相当大）。
ip切换可以采用虚拟IP或自动路由，不用更改应用。
3. HADR就是等于复制了一套数据库在备机上，所以存储是双份的，从这个角度上存储的灾备是实现了。（类比操作系统层面的HA，多数是共享存储）
4. HADR可以借用TSA进行自动切换，也可以自己手动切换，都有对应的命令。ip上面提到过了。
5. 应用服务器可以用多种方案，比如中间件层面WAS和SAP都可以做自己的集群；OS层面可以采用类似HACMP的HA方案等；存储也可以使用flashcopy。具体切换策略按照实际情况来制定，可以采用脚本或工具来实现自动或半自动切换。
希望这些有帮助，建议需要的话可以随时联系我们，来做有针对性的深入交流。收起
浏览1366
回复 6# wangzk0206
在所有DB2相关的灾备方案里面，HADR由于采用log shipping的机制，对网络的依赖相对是比较小的，我们见过多个数千公里的案例，有些当年还做成IBM官方参考案例。但相应的，HADR不是active-active的方案。
灾备是个大话题了，跟你采用的数据库架构，硬件，存储，网络都有关系，主要还是看具体需求，要根据客户对恢复时间、成本、灾备层级等多不同方面的要求和取舍来判断。在这些年中，中国银行业的两地三中心是我们见到的对高可用和灾备最高点要求。从DB2数据库角度来看，由于版本功能不同是会带来不同选择的，几个常见的方向：
1）DB2 从早期版本就开始使用的HADR方案，成熟且成本低廉，支持多种同步模式，但是是active-standby模式，当前也只支持两点之间，备机的利用率不高。适合比较基础的灾备方式。
2）pureScale可以通过GDPC做到active-active，但只能同城，搭建也较为复杂，个别银行在用。新版本的pureScale对HADR也开始支持。
3）数据库/数据复制的方案。
4）TSA或者OS/存储级别的灾备方案。
如前面所说的，灾备方案很难一概而论，要根据实际情况来分析判断，找到最经济有效且符合核心需求的方案。收起
在所有DB2相关的灾备方案里面，HADR由于采用log shipping的机制，对网络的依赖相对是比较小的，我们见过多个数千公里的案例，有些当年还做成IBM官方参考案例。但相应的，HADR不是active-active的方案。
灾备是个大话题了，跟你采用的数据库架构，硬件，存储，网络都有关系，主要还是看具体需求，要根据客户对恢复时间、成本、灾备层级等多不同方面的要求和取舍来判断。在这些年中，中国银行业的两地三中心是我们见到的对高可用和灾备最高点要求。从DB2数据库角度来看，由于版本功能不同是会带来不同选择的，几个常见的方向：
1）DB2 从早期版本就开始使用的HADR方案，成熟且成本低廉，支持多种同步模式，但是是active-standby模式，当前也只支持两点之间，备机的利用率不高。适合比较基础的灾备方式。
2）pureScale可以通过GDPC做到active-active，但只能同城，搭建也较为复杂，个别银行在用。新版本的pureScale对HADR也开始支持。
3）数据库/数据复制的方案。
4）TSA或者OS/存储级别的灾备方案。
如前面所说的，灾备方案很难一概而论，要根据实际情况来分析判断，找到最经济有效且符合核心需求的方案。收起
浏览1333