当前位置: 56net亚洲必嬴 > 服务器&运维 > 正文

DSG在境内的多多使用案例和客户列表

时间:2019-11-01 11:47来源:服务器&运维
多么痛的会心:十八起惨重宕机案例,领会十六起案例 社区有不知凡几哥们分享惨重宕机案例,提示大家需警惕,以下介绍几起,满满都以血的教训…… (以下案例来自社区多位会员

多么痛的会心:十八起惨重宕机案例,领会十六起案例

社区有不知凡几哥们分享惨重宕机案例,提示大家需警惕,以下介绍几起,满满都以血的教训……

(以下案例来自社区多位会员共享,主要由社区读书人孙伟光、崔增顺编辑收拾)

**

01

AIX 下 NTP 设置不当形成的多少个集群宕机

事务时有爆发在后生可畏段时间在此以前,接到朋友电话,客商有三套 oracle rac 集群运维在 aix 小机上,本地两套,同城机房两套,做完设备搬迁后的一天夜间,在那之中本土和同城的两套 rac 乍然就全体重启了,并且爆发在同期点。

互连网、小机、存款和储蓄、数据库分属不一样的维保商家,那就从头了口角。各家就此前从友好的大势自证无过错。作者去后面内心也正如赞同于 oracle 的互连网心跳出了难点,crs 抢 vote disk 的时候接触了重启。但由于是小机方的代表,仅从 aix 层面做了逐个审查,未察觉分明原因。对各主机宕机的时刻做了二个梳理,去和 oracle 的事件日志去比对。前段时间没查到哪边东西。

宕机发生的 dump 发到了 IBM 原厂,IBM 后来出了个报告,根据 dump 内容定位触发宕机的进度为 cssd。oracle dba 着重看了丰富进度的日志,开掘宕机时间前后,时间猛然修改,提前了40多秒。dba 确认,时间改变过多,cssd 进度会导致系统重启,可疑和岁月同步有关。

经济检察查,3套 aix 的 rac 集群使用了同一个 ntp server,但有朝气蓬勃套没爆发难题。相比检查差别,开掘没难点的这套主机集群使用 xntpd 形式布置了岁月同步。出标题标主机则直接使用了 ntpdate 命令做时间更新,并写入了 crontab 定期实施。检查 /var/adm/cron/log 日志,发掘定时职分的施行时间和 cssd 故障时间毫发不爽。检查时间服务器,开掘搬迁后,时间服务器的光阴发出了非常大偏差,xntpd 格局的光阴协同在时光不是大时不会去强制同步,ntpdate 命令的章程未有这么些范围,会直接举行合营。最后导致了 cssd 进程检验到过大日子不是后触发了宕机。

**经验分享:安插时间协作时,提出接纳 xntpd 服务的措施,**不用间接在准时职分里写 ntpdate,因为 ntpdate 比较野蛮,发生故障时非常大的时刻不是会导致应用现身难点,触发不或者预言的结局。

由社区会员王巧雷分享

02

动用爱数备份意气风发体机导致宕机

二〇一八年大家适逢其时动手了黄金年代台爱数备份风姿浪漫体机,在测验阶段境遇了叁个小例子和豪门大吃大喝一下:

眼看测量检验各样数码的备份和效应,就在少年老成台系统上设置了爱数备份的代办客商端,客商端安装选项中有生龙活虎项安装 CDP 驱动。 那个时候并未有静心,后来提高客商端版本,其余做了后生可畏都部队分任何测量试验,就把代理客商端卸载了,然而并未先去卸载 CDP 驱动,重启后系统就径直起不来了,和爱数的工夫支持沟通后精晓,亟需先卸载CDP驱动,再卸载顾客端,不然CDP 驱动存在的时候,就能够导致系统运转失利。

由社区会员“pysx0503”分享

03

精粹双机双囤积,某晚主存储格外故障,业务马上行车制动器踏板

客商优异的双机双囤积高可用解决方案。IBM 2*P570 PowerHA6.1 两新北端存款和储蓄通过 lvm mirror 达成的多少镜像,上边跑着客户信贷系统,报表系统,存储压力比较繁忙。客户每年一次都会成功一回HA 切换演习保障工作高可用。某晚一回存款和储蓄电源故障,电源还未有出示急更动,此外二个电源也坏了。那样主存款和储蓄宕机了。无独有偶此时职业也及时终止了,客户电话里说刚做完的 Powerha 的排练,很顺遂。可几日前产生的那事却高深莫测。

新兴经过大批量的日志和与客商交换得到消息,客户从前的八个操作给此番的作业暂停埋下了贰个大大的”地雷”。

到底用户自个儿做的哪些操作导致的这次事件吧?

客户业务体系有一个文件系统存款和储蓄空间非常不足了,必要扩大体量,然而当前分享 vg 里的长空不能够满了,必要再行加新的磁盘到 vg 里,存款和储蓄管理员分配新的磁盘给两台主机,然后顾客通过 Powerha cspoc 去加盘,扩大容积 FS。就是那样四个操作变成的主题材料产生。

经验分享:lvm mirror 双存款和储蓄的情状下,大家扩 fs 要求静心先扩 LV,再扩 fs,那样能保险数据准确布满在2个存款和储蓄上,若是在客户这种景色新加磁盘后直接扩fs,那就能够促成数据拷贝是2份,不过不能够可信地确定保障遍布在多个存款和储蓄上,有异常的大希望存款和储蓄A布满七成存款和储蓄B布满1十分之一。那样生机勃勃台存款和储蓄故障,就能平素促成数据的缺损。

由社区会员孙伟光分享

04

HACMP NODE ID 一致导致故障宕机

故障描述:

前日在论坛闲逛,发掘一兄弟的帖子“Power HA 在那之中黄金年代台至极宕机”(发表者:yangming27),点进去后生可畏看,开掘故障描述和报错消息和本身事先蒙受的通通平等,依照提示和血的教诲,特将该难点编写成案例,希望我们前车可鉴!

咱俩生育碰着有 PowerVM 设想化后的 AIX 虚构机2台,灾备意况有 PowerVM 虚构化后 AIX 设想机1台,三台设想机通过 PowerHA XD(基于 SVC PPRC 远程复制)搭建了跨宗旨高可用意况,操作系统版本为7.1.2.3,HA 版本为7.1.2.6,搭建该情状此前,生产情状的两台 AIX 是经过 HAMCP 搭建了本地的高可用蒙受,为了灾备建设必要,将地点的1台主机通过 alt_disk_copy 的议程复制了风流倜傥份 rootvg 至外置存款和储蓄,并将该外置存款和储蓄通过 SVC PPRC 复制至灾备存款和储蓄卷在那之中,灾备的设想机再挂载该卷,并由此该卷运维操作系统。那样三台 AIX 设想机再另行搭建了PowerHA XD,实现跨大旨 HA 热备。

因此这种艺术,大家搭建了三套系统,均通过了 HA 切换测试,不过运维了意气风发段时间后,当中生龙活虎套系统的主机故障宕机(关机),能源组切向了备机,开掘难点后,第有时间查看 errpt 日志,如下(这里借用 yangming27帖子中的日志截图)

故障解析:

鉴于操作系统未有开 always allow dump,所以并从未发出 dump 文件,当时剖判了相当久日志,非凡纳闷不解,最后不能不交给给 IBM 后台举行解析,后台也是过多天都没有应答。过了贰个礼拜后,第二套系统也应时而生了同生机勃勃的现象,相像的故障,形成主备 HA 切换,小编起来狐疑是 HACMP XD 施行难题,立马翻阅了豆蔻梢头晃实施文档,发今后做 alt_disk_copy 时只用了 alt_disk_copy -d hdiskx,前面并不曾用-O -B -C参数,那么些参数首若是用来复制rootvg时,删除原操作系统的布署消息和 ODM 库的片段新闻,那样一来可能就能够招致生产主机和灾备备机的操作系统有些新闻相近。基于这种草木皆兵,小编复看了 errpt 报错记录,宕机的根本原因应该是以下多少个点:

IBM.StorageRM daemon has been stopped

Group Services daemon stopped

Group Services detected a failure

QUORUM LOST,VOLUME GROUP GROUP CLOSING

猜猜是不是是 QUORUM 中保存的五个主备节点新闻风姿浪漫致,导致 QUORUM 关闭。

随着在生育主机械运输维命令

odmget -q "attribute='node_uuid'" CuAt

输出:CuAt: name = "cluster0" attribute = "node_uuid" value = "673018b0-7a70-11e5-91fa-f9fe9b9bc3c6" type = "R" generic = "DU" rep = "s" nls_index = 3

在灾备主机运维命令 odmget -q "attribute='node_uuid'" CuAt

输出:CuAt: name = "cluster0" attribute = "node_uuid" value = "67301842-7a70-11e5-91fa-f9fe9b9bc3c6" type = "R" generic = "DU" rep = "s" nls_index = 3

生儿育女主机械运输维命令

/usr/sbin/rsct/bin/lsnodeid

灾备主机运行命令

/usr/sbin/rsct/bin/lsnodeid

以上开采五个节点的 CRUISERSCT NODE ID 完全大器晚成致

那就是引致新闻冲突的点,产生了主服务结束和 QUORUM 仲裁关闭的首恶。

故障肃清:

1.将 PowerHA XD 的 HA 服务整个闭馆,防止 HA 组服务的护卫,并运转命令

/usr/sbin/rsct/bin/hags_stopdms -s cthags

/usr/sbin/rsct/bin/hags_disable_client_kill -s cthags

2.停止 HA 的 ConfigRM 服务和 cthags 服务

stopsrc -s IBM.ConfigRM stopsrc -s cthags

3.重新配置 奥德赛SCT 节点

/usr/sbin/rsct/install/bin/recfgct

4.重启全数3台操作系统

shutdown -Fr

5.开发银行 HACMP 服务和财富组,并检查 LX570SCT NODE ID

经验分享:通过以上办法,深透清除了三套系统的 HACMP 主机宕机难点,提出之后做雷同 alt_disk_copy 时,应当要带上-B -C -O参数,保持新操作系统的整洁,防卫碰着相像的无缘无故的主题材料。

由社区会员“jxnxsdengyu”分享

05

Power 570/595 宕机

事情起因:

是因为机械宕机是在星期天,是顾客的着力应用,但周末客商未有人上班,当周意气风发上班的时候开掘具备的办公,邮件系统等四分之二的中心应用不能够访谈,经超过实际地机房管理职员的一时排查,发掘小机 Power595 前面全部的 I/O 柜掉电,Power570 黄灯亮起,绿灯慢闪。

程序员达到现场,根据与客商联系好结果,我们初叶职业,差不离折腾了6个钟头,Power595 依旧还没运转起来,但 power570 能够健康访谈了。为了赶紧让顾客生产能力,大家有时决定,用 power570 一时做个 lpar 让存款和储蓄链接过来,先拉起应用,再又煎熬了3个多小时现在,全数应用都得以健康访谈。我们继承逐个审查Power595,大家转移了 CEC DCA 内部存款和储蓄器板,CPU 都还没缓慢解决难题,最后改换了 pubook 难点一下子就解决了了,耗时3天。

难题由来:

电工资制度修正造线路,变成了机房断电,UPS 有的时候接管,由于电瓶放了太久,机器功率太大,产生低电压运转,形成设备不可能健康干活,更为关键的是电工现身难题以往未有马上检查电路,基于师傅的陈诉大致过了1分钟又把沟通电送出去,那一个电压冲击是非常屌的,经每一个考察此电工无证施工,顾客已经谈到诉讼。

由社区会员“shizhe1030”分享

06

ERP 备份导致的一齐宕机案例

气象回想:

某日上午,在这之中风流洒脱台 ERP 数据库主机宕机。AIX.5.3 HACMP RAC 数据库情状。

故障解析:

宕机时间点是在备份时期。通过深入分析数据库日志、系统日志、开采变成数据库停库的基本点原因是由于 HACMP 的一个照看进程 haemd 发生自动重启,由于 oracle 数据库和 haemd 进度之间关于联,由此数据库在开掘 haemd 重新启航后也自行终止。

经 IBM 工程师及实验室深入分析,Haemd 自动重新启航的案由是出于在任其自然时期内(参数为2分钟)未有给 HACMP 系统响应,其缘由之一是出于系统过于繁忙,未有响应 Haemd。

任何时候深入分析结果发现在备份时期,从存款和储蓄看系统不是很艰难;但 ERP 数据库服务器主机品质非常:有时会并发阶段性的不响应现象,同有的时候间系统 I/O 高。截止备份后,这种情景未有。

经 IBM 实验室帮忙,初阶经过深入分析:

1)AIX 系统内部存款和储蓄器分为总计类和非总结类内存。非计算类内部存款和储蓄器重要用来文书操作CACHE,以便进步公文再次读写的品质。方今ERP 生产数据库占用了近20G内存作为文件系统 CACHE。

2)当文件系统 CACHE 有空间时,写文件操作将不会产生鸿沟,当文件系统 CACHE 无空间时,系统将会基于在那之中政策,挤出一些 CACHE。当不可能找到空闲的 CACHE 时,会等待系统调动出空闲的 CACHE。当现身大批量守候时,系统大概现身无响应的景观。

消除方案:

杜撰到明日数据量的扩展,要是不可能消释异常的大 I/O 对系统的熏陶过大的标题,那一个灾患将一向留存。

调节该备份文件系统的性质,在该文件系统的 I/O 诉求到达一定值的图景下,阻塞对该文件系统的读写 I/O,进而保障预先流出丰盛的能源给系统。具体参数为 马克斯pout、Minpout。

经验分享:马克斯pout、Minpout 参数的精选,是和切实遭受殃及池鱼的,未有一个合并的提出值。若该参数设置不创立,大概会潜移暗化到文件系统的读写操作。而适度的参数须求通过设置、观望来明确。

由社区会员孙伟光分享

07

weblogic 宕机难题排查

主题素材现象:

系统相连运作2-3天,中间件现身宕机

系统运作时期只要访谈 weblogic 调控台,操作四遍后中间件宕机

报错日志:

分析:

透过报错日志解析,为内部存款和储蓄器溢出,且为非堆内部存储器溢出,这种情景相近须求调动:PermSize 的高低。

缓和进度:

调解 weblogic 配置参数:setDomainEnv.sh 设置 setDomainEnv.sh 为512。

调动后重启系统,开掘难点依旧,并未缓慢解决宕机难点。

认可校订参数是不是看到成效:生成 javacore 来剖析(kill -3 进度ID)截图如下:

我们开掘参数并从未奏效。继续深入分析参数为何没有收效。

Weblogic 中的 commEnv.sh ,发现 JAVA_VENDOR 为 N/A

而 setDomainEnv.sh 中 PermSize 的安装为:

这里的参数并从未 设置咱们要求的 Open JDK的 JAVA_VENDO凯雷德 的 N/A 的赋值,所以非堆内存的安装未有生效。

注意:正常 open jdk 的 JAVA_VENDO君越 为 Oracle 的,然而配置文件却为:N/A,恐怕是 weblogic 的宽容性难点,也许人工资制度改善变导致,找到原因了,那几个主题材料就从未有过细究。

应用方案:

修改 commEnv.sh , JAVA_VENDO奥迪Q7 为 Oracle、HP、IBM、Apple 中的任何八个

在 startWeblogic 中,单独定义:MEM_ARGS="-Xms2048m -Xmx2048m -XX:PermSize=1024m"

证实方案:

应用第两种方案:

1)在原本默许碰到,举办10个钟头的轮回操作,并不停访问 weblogic 调整台。

2)在修正后的条件,持续访谈 weblogic 调节台,生成 javacore 文件看参数是或不是见效。并举行53人高强度的现身测量试验19个钟头,看是或不是会复发宕机难题。

在方案的率先步,系统运作2小时,访谈调节台,中间件宕机,系统不能访谈。

在方案的第二步,系统在52人高强度的产出测量检验20钟头的情状下,响应符合规律。频仍拜候调节台并未开采其他极度。通过转换javacore 开采非堆内部存款和储蓄器不奇怪生效。

由社区会员“gu y 011”分享

08

P550/P570 宕机案例

某星期日,客商致电,说基本专门的学业不可能访谈。程序员到达现场,开采顾客碰到(P550/P570--HACMP)P550 两台小机均关机。开掘顾客现场有局地服务器也已处于关机掉电状态。此时客商才发觉,市电星期五夜间断电过,可是客户机房配备有2台 UPS,机房设备五成伍分之七分别收到2台 UPS上。排查核对发掘里头黄金年代台 UPS不恐怕供电。而两台小机均有一起电源接到该 UPS,导致市电断电后,间接宕机。

后将小机通电开机,发掘P550不能够开机,CPU VRM 稳压模块报错,由于顾客专业较为关键,将 P570 已经拉起来,计划将 HA 集群在 IBM P570 单节点运营。却发掘 HA 不能够将 Oracle 数据库拉起。由于岁月迫比不上待,手动在 P570 网卡上加多 IP 别名后,手动挂载 VG,恢复职业。

承袭,将 P550 稳压模块实行调换后,发现仍然不能开机,又冒出新的报错:11002630,再一次转移 CPU 板后,P550 小机平常开机。布置停机窗口实行各种审核恢复生机。在管理进程中,集群出现意外,在 HA 拉起来后,经职业测量检验,开采/orafile丢失风流浪漫部分数码,这时备份数据最新的为前一天晚间23点,单天的数目未做备份,只好使用数据苏醒,最后成功将数据苏醒回来。重新配置 HA,模拟故障切换,测验专门的学问,验证数据完整性,业务恢复生机平常!

由社区会员“AC丹特”分享

09

AIX6100-06-06系统 bug 引起 down 机

某机器操作系统版本6100-06-06,系统 down 机,生成 dump 文件。

Problem:

System crash with following stack

CRASH INFORMATION:

CPU 3 CSA F00000002FF47600 at time of crash, error code

for

LEDs: 30000000

pvthread+02BD00 STACK:

[00009500].simple_lock+000000 ()

[00450E24]netinfo_unixdomnlist+000824 (??, ??, ??, ??,

??, ??)

[0451214C]netinfo+00006C (??, ??, ??, ??, ??, ??)

[004504DC]netinfo+0000FC (??, ??, ??, ??)

[00003850]ovlya_addr_sc_flih_main+000130 ()

[kdb_get_virtual_memory] no real storage @

FFFFFFFFFFFEF20

[100002640]0000000100002640 ()

[kdb_read_mem] no real storage @ FFFFFFFFFFF5E30

bug原因:

File lock is taken before checking whether the file type is socket.

该故障因 netstat -f unix 命令引起系统 crash, 是 IBM bug 引起

提出单独提高 bos.mp64包补丁包只怕完全升高到6100-06-12-1339(SP12)

官方网站解释:

IV09793: SYSTEM CRASH IN NETINFO_UNIXDOMNLIST APPLIES TO AIX 6100-06

File lock is taken before checking whether the file type is socket.

由社区会员“qb306”分享

10

P570 宕机案例

IBM 570 意外宕机,管理进度如下:

1、首先查看 asmi 日志,电源微电扇故障,退换了2个电源和1个电风扇后,能够运转到 standby 方式。可是超级多的 firmware 报错。

2、进级微码到 sf240-417后,微码报错消失。

3、激活分区失利,hmc 终端晤面世几秒的”ide inited failed“提示,然后消失。接着卡死,报找不到硬盘。

4、观看外观,开掘后端的光导纤维卡灯特别弱,不时会不亮。

5、查了下570的白皮书结构图,开采 ide controller(红线圈住部分)同一时候管理pci 设备和硬盘背板设备过来的 io,遵照现成故障现象,判别 ide controller 有故障。

6、通过 ibm system information center,定位到 ide controller 的 location code 为p1-15,不是一个可替换的 FRU,必得会同 IO backbone(就是主板)一同改变。

7、改变 io backbone 后,系统常规运行,步向系统微调后,一切符合规律。

由社区会员王巧雷分享

11

某商城 HACMP 软件,在网络交流机改换时引起 down 机

某集团 HA cluster log, IP switch down 时引起双节点 halt,系统版本7100-03-03,HA 版本6.1sp13

Error description

In HACMP 6 with rsct.core.utils 3.1.4.9 or higher, if all

IP networks are lost and at least one non-IP network is

functioning, the Group Services subsystem will core dump when

trying to send packets to be routed through Topology Services

(across the non-IP connection). This will cause a node halt.

Customers with PowerHA 7, or HACMP 6 customers with no non-IP

networks (such as rs232 or disk) are not in danger. Also this

will not happen if only one node is still running, since there

will be no other cluster members to send messages to.

日记如下:

缘由是补丁 IV55293: HAGSD CORE DUMP WHEN IP NETWOENVISIONKS LOST, 须求进步rsct 文件集。

官方网址解释:

由社区会员“qb306”分享

12

巡检不密切 Power595 宕机

事件起因,本来巡检已经意识中间的叁个 I/O 柜电源故障,在线退换走脚步的时候,脚步执行到八分之四挑起该 I/O 柜忽地掉电,重启了该 I/O 柜。

原因:一线程序猿巡检时候非常不足细致,因为该同一个 I/O 其实坏了2个电源,只但是此外三个从未有过报出来具体的岗位,但早就报出来该 I/O 的预制构件号,但也证实了 IBM 小机未有完全报错具体槽位,只报错了大致的地点。

解决方法:器材下电,改造五个 I/O DCA,然后设备开机,难点一挥而就。

由社区会员“shizhe1030”分享

13

X86 史上最离谱的宕机事件

硬件: IBM的X3650 操作系统: suse 9

linux 系统不可能远程登入,用 KVM 登陆上去看开掘定在操作系统页面不可能动。

重启操作系统后,在操作系统 message 日志里面查见到如下错误:

经过咨询 novell 和 IBM 程序员,结论是 IBM 那类服务器在装 linux 系统的时候,要是光驱反常实乃会形成宕机。

经硬件程序员检查,是光驱坏了……坏了……

编者按:宕机原因千万种,那么些宕机有一些冤

由社区会员“hp_hp”分享

正文转发自公众号: talkwithtrend

越多相关小说阅读

一个运营怎样从尾巴部分走上人生巅峰

运营无间:Alibaba运行保险类别的生龙活虎种精品实践

芳华永在!叁个老运营的20年奋漫不经心史

饿了么异乡双活数据库实战

Python 编制程序中常用的12种基础知识计算

青铜到王者,火速进步你 MySQL 数据库的段位!

有赞数据库自动化运行实行之路

运营版《安特卫普》,听哭了有一点人...

同等会 Python,他的薪水比你高意气风发倍

Ali万亿交易额级下的秒级监察和控制

IT 运行的救赎——顺丰运营的精美实施

学好 Python、拿高薪、竟是如此简约

快步向高维学院直通车成为说明运营开采技术员

只需要5天!

在5天内聚集向你教学面向 DevOps 的运转开荒技术员所急需调控的装有精髓。

更有含金量的是,学习结束你还将持有一张【运行开荒技术员认证证书】

那份含金量超级高的证书:

如能被推举步入上述大厂,您的培养锻练费将被退后八分之四!!

更加多厂家直通车,正在路上。

也应接公司和大家关系:

刘琳,微信/电话:13910952502

参与注脚运营开采程序员学科报名、详细的情况请点击阅读原来的作品链接

服务器才能早就蜕变四十几年,但随着互连网消息技能的向上。云本领和移动平台成为新的技巧标准。为了使终端更简便,客户端会接收手持式移动设备和浏览器,并必要有关的数据和次序须保留在“云”端。随着云技能和平运动动平台的衍变,服务器的数目和层面一定成几何级数的进步。故障和主题素材也会成倍增加。但和在个人利用的情事不豆蔻梢头,互联网化的服务器由于同不常间帮忙广大的操我。运营区别的互连网应用程序。管理众多的地点和远程设备。其设备的故障会诊就相对复杂。

内容简要介绍

1    DSG在境内的关键利用顾客

UNIX自己是为复杂性网络化意况设计的操作系统,而AIX操作系统是最大的种类集成商IBM开采的第二代UNIX,具有品质康健,使用方便,扩充性强,切合公司第风姿洒脱业务等风味,所以本文实例均在AIX情状下完毕。

  《Oracle DBA实战计谋:运营管理、检查判断优化、高可用与最棒施行》是方今Oracle数据库运行领域满腹珠玑的一本作品,也是为数十分少的既有雅量施行应用案例又带有实战方法论的编写。作者依据其多年的运营检查判断经验,从数据库怎样创设起来,按部就班地介绍了数据库的起步关闭进度,怎么着陈设监听并连接到数据库,如何对数据库空间实行田间管理和督查,SGA的调度和优化措施,CHECKPOINT和SCN主旨机制,数据库的备份与还原,数据库品质优化的方法论以致Oracle Data Guard的配置和管理等内容。书中小编结合了大气的忠实案例,把温馨多年的可贵经验融合此中,通过有个别繁琐案例的确诊进度来证实那几个回顾的准绳和知识点,同一时候,小编并从未轻巧地停留在案例检查判断深入分析的框框上,而是基于大量案例的经验汇总,把题指标优化、检查判断和缓和进步到了方法论的范围上,进一步援助读者知其然,知其所以然。

ü  中国际联盟通:邮电通讯根据地、北方邮电通信9省、四川邮电通讯、黑龙江电信、特古西加尔巴邮电通讯、山东邮电通讯、西藏邮电通讯、xinjiang邮电通信、广东邮电通讯、江苏邮电通信、四川邮电通讯、台湾邮电通讯、宁夏邮电通讯、浙江邮电通讯、圣萨尔瓦多邮电通讯;

1、故障概述

图片 1

ü  中国电信:浙江活动、湖北移动、四川移动、xinjiang移动、吉林运动;

服务器的在线情势故障是指服务器爆发了平凡错误。这几个错误纵然不一定系统崩溃。但潜移暗化系统的常规运行,影响多少的强壮性,并有更上一层楼扩展危机的或者。系统的难点和故障应该尽快开掘。并立刻进行拍卖和清除,制止进一步的风险,引起严重后果。及早的预判。及早的意识。及早的排查是故障检查判断的基本点。

小编简单介绍

ü  中华夏儿女民共和国网通:广西网通、宿州通讯、驻马店通讯;

2、系统故障剖析和判别

  周亮,拉脱维亚里加美创科学技术Oracle本领服务团队领导,Oracle 10g OCM。精通Oracle数据库原理,对于数据库架构设计、运行、调优、排故有着丰富的实战经验。指点Oracle技能服务组织,为铺面客户提供数不清套数据库维护专业。顾客涉及政坛、通讯、金融、公安、电力、交通、医治、创设等行业。

ü  中国电信:浙江联通、新疆联通、蒙Trey联通、吉林联通、西藏联通、海南联通、江西联通、青海联通、加纳阿克拉联通、福建联通;

系统硬件故障深入分析能够使用diag命令举办解析和决断。

目录

ü  股票(stock)行当:银河股票(stock)、华泰股票、刚果河股票、国际联盟股票(stock)、民族股票(stock)、金通证券;

在系统管理员状态下运作命令#diag举行硬件会诊程序。检查评定主机内硬件存在的标题。

推荐序生机勃勃
引入序二
推荐序三
前言

ü  市直机关:四川省级地区级方税务总部、xinjiang电力、新加坡市松江区财政总局、圣菲波哥伦比亚大学公安、江苏公安、波尔图电力、西安社会养老保险、江汉油田、广东交通厅、利物浦钢铁总公司等

图片 2

第1章 数据库故障的确诊方法与深入分析思路
1.1 数据库安装类故障
1.1.1 安装数据库时轻便犯的失实
1.1.2 不能够起动安装分界面包车型大巴缓解办法
1.1.3 安装数据库的特等实施
1.2 数据库连接类故障
1.2.1 检查是还是不是由网络故障引起
1.2.2 检查是或不是由主机财富引起
1.2.3 检查是还是不是由监听故障引起
1.2.4 检查是还是不是由数据库故障引起
1.3 数据库HANG类故障
1.3.1 数据库全局性HANG的管理进程
1.3.2 数据库局地性HANG管理进度
1.4 数据库质量类故障
1.4.1 品质类故障的拍卖思路
1.4.2 怎样快捷稳固财富持有者
1.5 数据误操作类故障的管理思路
1.6 数据库坏块类故障
1.6.1 数据库对象坏块的拍卖思路
1.6.2 SYSTEM/UNDO表空间损坏的拍卖思路
1.6.3 数据库在线日志文件损坏的管理思路
1.6.4 调节文件损坏的拍卖思路
1.7 总结

ü  军队及此外:海军某部、火箭商量院、陆军某部、新闻行业部(含江西、湖北、山西、尼罗河、浙江、吉林、江苏、湖北、宁夏和洛桑等信产部直属机构);

1)基本种类

第2章 监听的配置和拘留
2.1 简析监听连接暗中提示图
2.2 浓烈解析监听配置文件
2.2.1 叁个第一名的监听配置模板
2.2.2 监听的常用命令
2.2.3 配置监听外号
2.2.4 配置文件中的关键字解析
2.3 tnsping命令的功效和适用场景
2.4 监听的静态注册
2.4.1 静态注册的安插内容
2.4.2 监听状态中劳动名和实例名
2.5 监听的动态注册
2.5.1 动态注册的内容
2.5.2 监听状态中的服务名和实例名
2.5.3 监听动态注册时的实例状态
2.5.4 动态注册的时刻点
2.5.5 实例不能够动态注册的拍卖思路
2.5.6 追踪实例的动态注册进程
2.6 巧用SSH的端口转发成效
2.7 追踪监听的干活进度
2.8 监听的优化思路
2.9 会诊案例之大器晚成:RAC 某节点宕机之后的监听故障处理
2.10 检查判断案例之二:使用顾客端追踪数据库连接难点
2.11 会诊案例之三:本地sqlplus连接HANG的确诊和分析

 

2)I/O设备

第3章 命令行创立和删除数据库
3.1 创设数据库的光景流程
3.2 理解Oracle SID
3.3 检查操作系统境况
3.4 规划数据库文件系统
3.5 创造Oracle日志文件目录和密码文件
3.6 创造Oracle参数文件
3.6.1 设置内存相关参数
3.6.2 设置进程有关参数
3.6.3 设置DB_FILES参数
3.6.4 设置BLOCK_SIZE和DB_FILE_MULTIBLOCK_READ_COUNT参数
3.6.5 设置参数OPEN_CURSORS和SESSION_CACHED_CURSORS
3.6.6 五个第一名的数据库参数文件
3.7 制造数据库
3.7.1 数据库的成立脚本
3.7.2 使用OMF天性创立数据库
3.8 创制数量字典
3.8.1 执行catalog.sql
3.8.2 执行catproc.sql
3.8.3 执行utlrp.sql
3.8.4 执行pupbld.sql
3.9 命令行创制RAC数据库
3.10 如何通透到底删除数据库

2     DSG在周边项指标名利双收轨范和连锁经历

3)异步设备

第4章 SCN和CHECKPOINT
4.1 SCN
4.1.1 SCN的作用
4.1.2 SCN和时间里面的转移
4.2 SCN的最大阈值
4.3 三种不认为奇的SCN
4.3.1 调整文件中的SCN
4.3.2 数据文件头中的SCN
4.3.3 数据块中的SCN
4.3.4 日志文件头中的SCN
4.3.5 事务起首时的SCN
4.3.6 数据库的CU福特ExplorerRENT SCN
4.4 CHECKPOINT
4.4.1 CHECKPOINT的作用
4.4.2 全量CHECKPOINT和增量CHECKPOINT
4.4.3 CHECKPOINT和REDOLOG
4.4.4 影响数据库张开速度的因素
4.4.5 CHECKPOINT的优化思路

2.1  成功案例的列表

4)图形设备

第5章 数据库的启航与关闭
5.1 实例与数据库
5.2 数据库参数文件
5.2.1 参数文件的体系
5.2.2 参数设置
5.2.3 参数文件之间的类型转变
5.3 简述数据库的启航步骤
5.4 数据库的起步步骤之生机勃勃:NOMOUNT
5.4.1 连接至空闲实例
5.4.2 读取数据库参数文件
5.4.3 分配SGA内存
5.4.4 派生后台进程
5.4.5 检查判断案例:主机内部存储器的使用率高达99%
5.5 数据库的起步步骤之二:MOUNT
5.5.1 读取调节文件
5.5.2 校验调控文件
5.5.3 MOUNT数据库
5.5.4 调控文件损坏的拍卖思路
5.6 数据库的启航步骤之三:OPEN
5.6.1 详解CRASH RECOVERY
5.6.2 CRASH RECOVE奥迪Q5Y的故障管理思路
5.6.3 详解CACHE RECOVERY
5.6.4 CACHE RECOVEPRADOY的故障管理思路
5.6.5 详解TX RECOVERY
5.6.6 TX RECOVE瑞鹰Y的故障处理思路
5.7 数据库展开HANG的故障处理思路
5.8 如何强制展开数据库
5.9 如何高效关闭数据库
5.9.1 影响数据库关闭速度的成分
5.9.2 数据库不可能关闭的会诊方法

DSG从2003年在神州确立以来,在RealSync这几个数据库复制产品的连串实行方面也经过了很短的少年老成段路。DSG始终以“客商需求为导向”的尺码升高和谐的制品,到近年来停止,DSGRealSync产品早就在电信、政党、政券和市肆利用,首要不外乎:

5)SCSI设备

第6章 数据库空间的保管与监督检查
6.1 数据库的上空管理
6.2 表空间管理
6.2.1 区管理和段管理
6.2.2 不时段管理
6.2.3 回滚段管理
6.2.4 表空间的监察脚本
6.2.5 维护表空间的注意事项
6.3 数据文件管理
6.3.1 裸设备头上的保存消息
6.3.2 浅析数据文件的操作系统头
6.3.3 破解数据文件头内容
6.3.4 维护数据文件的注意事项
6.4 在线日志文件管理
6.4.1 破解日志文件头音讯
6.4.2 LGW奥迪Q3进程在日记文件中的写进程
6.4.3 维护日志文件的注意事项
6.5 归档日志管理
6.5.1 开启和停业归档方式步骤
6.5.2 归档日志的命名参数
6.5.3 查看归档日志的多少个剧本
6.5.4 使用LO克拉霉素NKuga开掘归档日志
6.5.5 开启归档格局的专一点
6.5.6 开启归档情势的低价
6.6 闪回日志管理
6.6.1 数据库闪回相关的视图和参数
6.6.2 数据库等级的闪回连串
6.6.3 闪回日志空间的释放
6.7 调节文件管理
6.7.1 经常见到的调节文件故障管理
6.7.2 维护调控文件的注意事项
6.8 追踪文件管理

Realsync数据复制容灾软件前段时间占到国内集镇占有率的八成,客商富含: 

6)存款和储蓄设备

第7章 Oracle质量优化方法论
7.1 数据库品质优化的对象
7.2 营造数据库品质基线
7.3 搜索关键变化
7.4 定位首要影响因素
7.5 检查操作系统财富
7.5.1 查看CPU资源
7.5.2 查看内部存储器财富
7.5.3 查看I/O资源
7.5.4 查看网络能源
7.6 不足为道的数据库质量故障
7.7 数据库质量优化的例行情势
7.7.1 数据库性能调解的骨干流程
7.7.2 调度Oracle内部存款和储蓄器参数
7.7.3 调解数据库在线日志
7.7.4 调度SQL的推行布署
7.7.5 优化对象的I/O读取
7.7.6 裁减CU汉兰达SOTucson分析成本
7.7.7 其余数据库品质调治手腕
7.8 利用OWI监察和控制数据库质量
7.8.1 OWI的基本原理
7.8.2 等待事件的意思
7.8.3 监察和控制数据库的手腕
7.9 利用时间模型监察和控制数据库质量

邮电通讯行当: 

7)通讯设备

第8章 SGA的属性调度和优化思路
8.1 BUFFE瑞鹰 CACHE的内部结构
8.1.1 BUFFER HEADER
8.1.2 HASH CHAIN和HASH BUCKET
8.1.3 LATCH:CACHE BUFFERS CHAINS
8.1.4 LATCH:CACHE BUFFERS LRU CHAIN
8.1.5 FREE BUFFER WAITS
8.1.6 BUFFER BUSY WAITS
8.2 BUFFE库罗德 CACHE的优化目标
8.2.1 BUFFE奥迪Q5 CACHE的命中率
8.2.2 AWKoleos报告中BUFFE奥迪Q7 CACHE的一些争用目的
8.2.3 BUFFE奥迪Q3 CACHE大小的提议值
8.3 BUFFE汉兰达 CACHE的优化思路
8.3.1 BUFFE奥德赛 CACHE内部存款和储蓄器不足的优化思路
8.3.2 BUFFEENVISION CACHE的多少块争用的优化思路
8.3.3 别的有关BUFFE奥迪Q3 CACHE的优化思路
8.4 SHARED POOL的内部结构
8.4.1 堆管理
8.4.2 CHUNK
8.4.3 FREE LIST
8.4.4 LRU LIST
8.4.5 RESERVED FREE LIST
8.4.6 SHARED POOL的SUB POOL技术
8.4.7 关于SGA内部存款和储蓄器抖动
8.5 LIBRARAV4Y CACHE的内部结构及等候事件
8.5.1 LATCH:LIBRARY CACHE
8.5.2 LIBRARY CACHE LOCK/PIN
8.5.3 LIBRARY CACHE OBJECT
8.6 浅析SQL的解析进度
8.6.1 软解析
8.6.2 硬解析
8.6.3 软软解析
8.7 ROW CACHE上的故障会诊方法
8.7.1 ROW CACHE的大小
8.7.2 ROW CACHE上的LATCH
8.7.3 检查判断案例:LATCH:ROW CACHE OBJECTS故障管理
8.7.4 建设构造测量检验景况再次出现难题
8.8 SHARED POOL上的优化思路
8.9 LOG BUFFE卡宴上的优化思路
8.9.1 LOG BUFFER的大小
8.9.2 浅析REDO WASTAGE
8.9.3 LOG FILE SYNC等待事件
8.9.4 裁减日志量的办法

京城活动、广西活动、海南移动、安徽移动、辽宁移动、江西邮电通信、河北邮电通讯、江苏邮电通信、辽宁邮电通讯、吉林邮电通讯、湖北邮电通信、辽宁邮电通信、广东邮电通讯、宁夏邮电通讯、广西邮电通讯、克利夫兰电信、娄底邮电通讯、伯明翰邮电通讯、莆田邮电通讯、西藏网通、湖北联通、福建联通、台湾联通、广东联通、青海联通、辽宁维埃社会主义共和国缔盟通、辽宁联通、湖北联通、湖北联通、黑龙江联通、内蒙联通、黑龙江联通、湖北联通…

8)多媒体设备

第9章 数据库的轮廓备份与回复
9.1 物理备份与回复的基本概念
9.1.1 物理备份的基本概念
9.1.2 物理备份时的注目点
9.1.3 物理苏醒的基本概念
9.1.4 物理苏醒时的瞩目点
9.2 数据库的冷备份和回复
9.2.1 冷备份数据库步骤
9.2.2 冷备份下的数据库复苏
9.3 数据库手动热备份和苏醒
9.3.1 手动热备份
9.3.2 热备份下的数据库苏醒
9.4 使用RMAN备份和回复数据库
9.4.1 RMAN的结构
9.4.2 RMAN占用的内部存款和储蓄器
9.4.3 RMAN备份与还原示例
9.5 数据库闪回
9.5.1 数据库闪回和平常闪回点
9.5.2 强制闪回点

金融行当: 

#diag —S

第10章 物理Data Guard的计划与管理
10.1 Data Guard的原理
10.1.1 解析Data Guard原理图
10.1.2 Data Guard常常运作的前提
10.2 Data Guard的爱护格局
10.2.1 最大爱惜形式
10.2.2 最大可用情势
10.2.3 最大质量格局
10.2.4 切换尊崇情势
10.3 配置物理Data Guard
10.3.1 配置Data Guard简要流程
10.3.2 配置Data Guard相关参数
10.4 管理物理Data Guard
10.4.1 配置Data Guard的注目点
10.4.2 管理Data Guard的注意点

广发银行、中华夏儿女民共和国证券保险金监察和控制中央、北冰洋保险公司、中国金融期交所、华夏基金、易方达基金、招引客户基金、南方基金、鲁证证券、中国际清算银行行股票、东吴股票(stock)、国泰君安股票、中大证券、银河股票、民族期货(Futures)、宏源股票、新时期股票、香港证券、远东期货、印度洋股票(stock)、东兴股票、万联期货、金元期货、信达证券、江南证券、华泰证券、阿塞拜疆巴库股票、信泰股票(stock)、东吴股票、多瑙河股票、国联股票(stock)、南海股票(stock)、西北股票(stock)、湖北股票、金通期货(Futures)、中原股票(stock)、财达股票、北部股票、国盛股票(stock)、国海股票(stock)、华福股票(stock)、恒泰股票、湘财股票(stock)、华鑫股票、财富股票、中天证券、财通股票、中投期货(Futures)…

在颇负财富上运维会诊。

百度网盘免费下载地址:

内阁行当: 

3、查看系统的大谬不然日志

------------------------------------------分割线------------------------------------------

首都电力、江西电力、西藏电力、新疆电力、亚马逊河电力、宁夏电力、天富热电、重庆电力、湖南省级地区级税、杜阿拉财政、东京松江财政、湖南省交通厅 、台湾省征收稽查局、蛇口码头、阿瓜斯卡连特斯港、河北公安、娄底公安、日内瓦交通警务人员、维尔纽斯有线、淮安社会养老保险、中夏族民共和国邮政、金斯敦FAW、利马索尔强项、日内瓦中华通公司、阿里Baba(Alibaba)、江苏省级地区级税11地市征收和管理数据汇总容灾备份系统、台湾省电力12地市经营发卖数据聚焦容灾备份…

在系统运作时,一些种类错误会记录在errlog中,此中多少错误还可能会在顶峰上展现。检查错误日志可用以下命令

FTP地址:ftp://ftp1.linuxidc.com

 

图片 3

用户名:ftp1.linuxidc.com

那些系统都为DSG RealSync的实行储存了难得的经历。

4、DUMP

密码:www.linuxidc.com

当系统一发布出软硬件故障导致宕机时,系统将搜集故障发生时系统的内部存储器和Computer状态等音信,发生DUMP文件,何况在液晶屏上显得888上马的代码。记录第二段起初的故障码,并深入分析DUMP状态码有利于分析故障原因,找到难题所在。

在 2014年LinuxIDC.com7月Oracle DBA实战战术:运转管理、会诊优化、高可用与超级执行

 

5、常常检查服务器状态的品种及其有关命令

下载方式见 http://www.linuxidc.com/Linux/2013-10/91140.htm

2.2  成功案例的概况

作为帮助。依期运转检查服务器品质的相干工具和下令,有协理控克制务器状态,预测故障点,相关命令富含:

------------------------------------------分割线------------------------------------------

序号

客户名称

实施日期

系统情况及需求

实施后情况

1

长江证券股份有限公司

2004.12.31

系统环境:集中交易系统分布在两台HP安腾服务器上,服务器分别配备4CPU和8G内存。数据库版本为Oracle9i,组成RAC。数据量为100GB左右,每天日志量为10-20GB左右。异地网络链路2M。                                       应用需求:1.本地数据库复制一份Oracle数据库副本,实现本地数据查询,业务分担以及本地业务接管功能;2.异地容灾通过窄带宽链路将数据复制到上海灾备中心提供异地容灾功能; 

1.满足设计方案的目标,实现1:2的容灾复制模式;                                     

2.本地数据库副本实现查询业务分担,提高主应用的处理能力和查询响应速度,客户满意度上升;                           

3.低带宽情况能够保证数据复制传输的应用要求;                                               4.异地容灾系统演练成功; 

2

华泰证券股份有限公司

2006.02.15

系统环境:集中交易系统分布在两台IBM S80服务器上。数据库版本为Oracle9i,组成RAC。数据量为80GB左右,每天日志量为10-20GB左右。异地网络链路2M。                  应用需求:异地容灾通过窄带宽链路将数据复制到异地灾备中心提供异地容灾功能; 

1.满足设计方案的目标,实现1:1的容灾复制模式;                                                            

2.低带宽情况能够保证数据复制传输的应用要求;                                                           

3.异地容灾系统演练成功; 

3

中国移动通信集团广西公司

2005.12.30

系统环境:营业数据库布放在两台IBM P690服务器上,数据量有1.1TB左右;客服数据库布放在另外一套HA环境下,数据量有100GB左右。数据库版本为Oracle9i,组成RAC。每天日志量为300GB左右,出账高峰期每天日志量达到600GB左右。本地网络链路1000M。应用需求:1.将两个应用数据库数据复制到1个Oracle数据库副本中,实现本地数据查询系统优化部署、业务负载分担等功能;2.提高容灾系统接管成功率,保证100%的业务连续性要求; 

1.满足设计方案的目标,实现2:1的容灾复制模式;                                                           

2.集中数据库副本实现查询业务分担,提高主应用的处理能力和查询响应速度,客户满意度上升;                                                           

3.利用数据库副本Open机制,保证容灾切换可靠性,提供100%的容灾切换支持;                                              

4.应急容灾系统演练成功; 

4

河北省地方税务局信息中心

2005.12.27

系统环境:11个地市税务征管系统布放在两台IBM服务器上,组成HA双机环境。地市税务征管系统数据量有50GB左右;数据库版本为Oracle9i,异地网络链路2M。                                                     应用需求:1.将11个地市税务征管数据库数据分别复制各本地1个Oracle数据库副本中,实现本地数据查询系统优化部署、业务负载分担等功能;2.将11地市税务征管数据库数据复制到省中心1个Oracle数据库副本,作为全省税务征管系统的集中容灾系统;3.省中心Oracle容灾数据库可为数据仓库提供数据抽取功能。 

1.满足设计方案的目标,实现11:1:1的容灾复制模式;                                                      

2.本地数据库副本实现查询业务分担,提高主应用的处理能力和查询响应速度,客户满意度上升;                                                           

 3.全省税务征管系统集中容灾的目标实现;                                                   

4.低带宽情况能够保证数据复制传输的应用要求;                                                              

5.省中心Oracle集中容灾数据库能够为数据仓库提供数据来源,满足数据抽取功能;                                                  

6.异地容灾系统业务接管及数据修复成功;

5

江西省电力公司

2007.12.18

系统环境:12个地市电力营销系统布放在两台HP安腾服务器上,组成高可用架构。地市电力营销系统数据量有10-50GB左右;数据库版本为Oracle9i,异地网络链路100M(2M冗余)。                                                          应用需求:1.将12地市电力营销数据库数据复制到省中心1个Oracle数据库副本,作为全省电力营销系统的集中容灾系统;2.省中心Oracle集中容灾数据库提供决策分析、网上营业厅、监控中心和查询系统的应用功能; 

1.满足设计方案的目标,实现12:1的容灾复制模式;                                              

2.省中心容灾数据库副本实现查询应用功能,提高主应用的处理能力,客户满意度上升;                                                     

3.全省电力营销系统集中容灾的目标实现;                                                   

4.低带宽情况能够保证数据复制传输的应用要求;                                                                                                        5.异地容灾系统业务接管及数据修复成功;

6

中国电信股份有限公司福建分公司

2006.12.14

系统环境:计费数据库布放在两台IBM P595服务器上,14CPU,数据量有2.2TB左右;统计数据库布放在另外两台IBM P595服务器上,数据量有1.5TB左右。数据库版本为Oracle9i,组成RAC。每天日志量各为110GB左右,本地网络链路1000M。                                                       应用需求:1.将两个应用数据库数据复制到1个Oracle数据库副本中,实现本地数据查询系统优化部署、业务负载分担等功能;2.提供24个月的话单数据保存和对外查询业务; 

1.满足设计方案的目标,实现2:1的容灾复制模式;                                                           

2.集中数据库副本实现查询业务分担,提高主应用的处理能力和查询响应速度,客户满意度上升;                                           

7

上海市松江区财政

2005.10.12

系统环境:国库支付数据库布放在两台IBM 服务器上,数据量80GB左右;数据库版本为Oracle8i,组成RAC。异地网络链路100M。                                                            应用需求:1.将区属所有机关单位的财政数据复制到财政数据中心的1个Oracle数据库副本,作为国库支付系统的集中容灾;2.一期将三个应用数据库数据复制到1个Oracle数据库副本中,实现容灾和数据仓库抽取等功能; 

1.满足一期设计方案的目标,实现3:1的容灾复制模式;                                                                                         

2.国库支付系统财政数据集中容灾的目标实现;                                                     

3.低带宽情况能够保证数据复制传输的应用要求;                                                    

5.Oracle集中容灾数据库能够为数据仓库提供数据来源,满足数据抽取功能;                                                  

6.集中容灾系统业务接管演习及数据修复成功;

8

中国联通有限公司湖北分公司

2007.03.19

系统环境:营业、账务和入库数据库布放在四台IBM P690服务器上,每台服务器22CUP、18GB内存,配置成集群。每个数据库数据量分别有800GB-1.4TB左右。数据库版本为Oracle10g,组成RAC。每天日志量为300GB左右。本地网络链路1000M。                                               应用需求:将三个应用数据库数据复制到本地1个Oracle数据库副本中,实现本地数据查询系统优化部署、业务负载分担等功能; 

1.满足设计方案的目标,实现3:1的容灾复制模式;                                                           

2.集中数据库副本实现查询业务分担,提高主应用的处理能力和查询响应速度,客户满意度上升;                                           

9

中国网通(集团)有限公司辽宁省分公司

2004.03.11

系统环境:六大数据库各布放在两台IBM P690服务器上,总数据量有35TB左右。数据库版本为Oracle9i,分别组成RAC。本地网络链路1000M。                                                        应用需求:1.将六大应用数据库数据复制到1个Oracle数据库副本中,实现本地数据整合,消除分散系统的信息孤岛;2.提供六大业务系统数据库关键数据的集中容灾,保证100%的业务连续性要求; 

1.满足设计方案的目标,实现6:1的容灾复制模式;                                                                                         

2.六大业务系统关键数据集中容灾的目标实现;                                                                                                           3.完成六大业务数据整合和优化过程;                                                  

4.集中容灾系统数据修复成功;

10

中国联通有限公司福建分公司

2008.01.03

系统环境:营业和计费数据库布放在四台IBM P690服务器上,配置成高可用架构。每个数据库数据量分别有600GB-1.2TB左右。数据库版本为Oracle9i,组成RAC。每天日志量为150GB左右。本地网络链路1000M。                                               应用需求:将两个应用数据库数据复制到本地1个Oracle数据库副本中,实现本地数据查询系统优化部署、业务负载分担等功能; 

1.满足设计方案的目标,实现2:1的容灾复制模式;                                                           

2.集中数据库副本实现查询业务分担,提高主应用的处理能力和查询响应速度,客户满意度上升;               

11

中国联通有限公司山东分公司

2008.02.19

系统环境:计费数据库各布放在四台HP RP8400服务器上,复制数据量有2TB左右。数据库版本为Oracle9i,分别组成RAC。本地网络链路1000M。                                    应用需求:1.将4个本地数据库复制一份Oracle数据库副本,实现本地数据查询,业务分担以及本地业务接管功能;2.对4个本地数据库的关键数据提供应急容灾功能; 

1.满足设计方案的目标,实现4:1的容灾复制模

式;                                                            

2.集中数据库副本实现查询业务分担,提高主应用的处理能力和查询响应速度,客户满意度上升;                                                            

3.利用数据库表级复制功能,对关键数据实现容灾保护;                                               

4.Oracle容灾数据库数据恢复演练成功;

13

深圳蛇口集装箱码头

2008.03.16

系统环境:生产数据库布放在Compaq的服务器上,操作系统为TRU64,8G内存的两台Compaq组成的RAC。数据库版本为Oracle10g,数据量为50GB。网络链路带宽为100M。                                                       应用需求:1.实现关键生产数据库的数据容灾;2.提高容灾系统接管成功率,保证100%的业务连续性要求; 

1.满足设计方案的目标,实现1:1的容灾复制模式;                                                            

2.满足关键数据库的数据容灾要求;                                                     

3.异地容灾系统演练成功;

14

中国电信股份有限公司贵州分公司

2008.04.07

系统环境:帐务数据库布放在HP-IA64 服务器上,26CPU/20G,配置成高可用架构。数据库版本为Oracle9.2.0.5,实际复制数据量为120GB左右; 97系统数据库布放在IBM服务器上, 28CPU/20G,数据库版本为Oracle9.2.0.5,实际复制数据量为280GB左右。本地网络链路1000M。                          应用需求:1.将两个应用数据库关键数据表复制到目标数据库副本,实现本地数据查询,业务分担功能。2.替换现在已有的利用Oracle高级复制模式复制数据,减少对生产数据库的压力; 

1.满足设计方案的目标,实现2:1的容灾复制模式;                                                           

2.数据库副本实现查询业务分担,提高主应用的处理能力和查询响应速度,客户满意度上升;                                                    

3.完全替换Oracle高级复制,减少了生产端数据库的压力;                                                 

4.实现查询业务完全从生产库剥离,实现业务优化部署;

15

东兴证券股份有限公司

2008.04.08

系统坏境:集中交易系统布放在两台HP580-G4服务器上,分别配备8CPU和32G内存。数据库版本为Oracle10g,组成RAC。数据量目前为100G左右。每天日志量为10-20GB左右。异地网络链路为4M。
应用需求:1.本地数据库复制一份Oracle数据库副本,实现本地数据查询,业务分担以及本地业务接管功能;2.异地容灾通过窄带宽链路将数据复制到北京灾备中心提供异地容灾功能; 

1.满足设计方案的目标,实现1:2的容灾复制模式;                                                           

2.本地数据库副本实现查询业务分担,提高主应用的处理能力和查询响应速度,客户满意度上升;                                                           

3.低带宽情况能够保证数据复制传输的应用要求;                                                           

4.异地容灾系统演练成功;

16

信达证券股份有限公司

2008.04.16

系统环境:集中交易数据库为Oracle10G RAC,布放在两台IBM P570上,配置成高可用架构。实际复制数据量有100GB左右,本地和同城灾备中心网络链路均为1000M。                        应用需求:1.将集中交易数据库复制到同在证通机房的灾备中心数据库上,该数据库为Oracle10G主机为IBM P570,实现本地数据查询,业务分担以及本地业务接管功能;2.将集中交易数据库复制到同城的华侨城容灾机房,以适应同机房内出现灾难的情况,该灾备中心数据库为Oracle10G主机为IBM P570。 

1.满足设计方案的目标,实现1:2的容灾复制模式;                                                           

2.本地数据库副本实现查询业务分担,提高主应用的处理能力和查询响应速度,客户满意度上升;                                                           

3.实现同城异地的容灾要求;                                                           

Iostat

越多Oracle相关音信见Oracle 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=12

 

翻看系统I/O状态。分析CPU对各端口的劳务占比,理解硬盘swap空间和内部存款和储蓄器的数据比例关系。

正文永世更新链接地址:http://www.linuxidc.com/Linux/2014-07/104100.htm

 

Vmstat

图片 4

2.3  广东活动营业和客服数据库数据复制救急查询平台

查看系统设想内部存款和储蓄器状态音信。

  作业需要

Sar

将湖北移动在白沙机房(BOSS1.5机房)新建三个基于SAN情况的微管理器种类,有6个数据库(Oracle9i RAC),当中的2个数据库(三个是Oracle 9iRAC,四个节点,此外二个是双机互备形式)依照作业供给各自复制到救急数据库(Oracle 9i Single)的2个实例,由此需购买相应的复制软件举办数据库的复制。

Sat查看系统活动状态消息。

本工程是对中间的运转数据库和客服数据库进行复制,复制到应急数据库。

Topas

数据库复制系统的确立应达成将营业库和客服库的数据变化分别复制到救急库,使得救急营业库和应急客服库的数量和生育系统的营业库及客商库的数目同步。并能在生养种类的营业库大概客商库有故障时,代替故障库,接管应用。当故障库修复之后,能立刻将救急库中的数据同步到修复后的生育数据库。

Topas可以监督系统内部存款和储蓄器,CPU,I/O端口,swap空间的情事

  方案设计 

no 命令用来修正内核参数。调解系统本性。

听大人讲福建移动数据复制系统的事体要求,选择DSG RealSync软件完毕多少复制:系统一整合体布局如下图所示:

Svmon

 图片 5

svm on 命令用来查阅系统当下的内部存储器的求实应用。

 

6、结论

ü 生产类别

其它完好的系统它都不恐怕一点破绽百出或故障都并未有,互连网服务器系统在运维时连连会或多或少的标题应时而生,即便AIX系统有着电动会诊错误和故障的技巧,但客户领会系统,并定时监视检查判断系统的运市价况,方可制止不供给故障的发生。本文相关保证方法在IBVCD20服务器,AIX 6.1操作系统下促成通过。

湖北运动BOSS 1.5系统中需求本期工程开展复制的业务种类首要富含三种:

...

客服:系统的数据量约为100GB

帐务:系统的数据量约为800GB

运转:系统的数据量约为500GB

客性格很顽强在艰难险阻或巨大压力面前不屈数据库单独运维,运营在两台IBM P690服务器上,组成RAC遇到;

帐务和营业多个工作运转在一个ORACLE DATABASE的两个USETiggo上,运转在两台IBM P690服务器上,组成RAC景况;

在容灾系统上安装五个ORACEL INSTANCE,运营多少个ORACEL DATABASE。分别对应生产系统的客服数据库和营业帐务数据库中的三个顾客。

  属性参考

ü  全同步

DSG RealSync提供了不停机的第一回全同台功能,该意义支撑数据库在正规工作时间不中断的景观下进展全同台。幸免了接收积存拷贝情势张开全同台时不能缺少须求的工作暂停。

对此广东运动的数据量,七个顾客数据量约为800GB,接受11个冒出职分实行全同台,同步时间总共约5钟头左右。

ü  日志解析速度

系统每一天管理的日志量达到400GB左右.

ü  CPU能源速度

源端日志剖判CPU占用量为单个CPU的一成,高峰期可直达单个CPU的百分之二十一.

  消除方案特点

容灾与别的任何保管政策同样,当未有患难现身时,大家根本不可能意识到容灾系统所起到的功能,无法回笼容灾系统建设所需的大气入股。但从系统安全性角度思考,大家又必得为重大的事务支撑体系建设最实惠的横祸恢复生机建设方案。不过在大许多气象下,当未现身天灾人祸时,我们的容灾端系统总是处于空闲状态,费用大批量入股买来的种类根本无法有效应用。这一个题目直接烦恼着客户。

为此我们利用双active的结构,让容灾系统的数据库也处于OPEN状态,那样其实青海洋运输动就有所了第二数目焦点,而不只是三个苦难备份系统,通过第二数额主导可以兑现如下效果:

ü  宗旨工作的灾备平台 

由此数据同步创设的第二数量主导能够达成对专业重要数据的容灾及保险,在不影响生产数据库品质的同一时候为生育数据库在地点或异地创立风华正茂份准实时镜像,以管教在生产数据库发生魔难时可应用容灾数据库进行业务接管和数据复苏。

ü  业务负载分担 

其次数据基本的数据处于实时可读取状态,数据库处于OPEN状态,达成BOSS系统业务模块的重新铺排。

通过第二多少核心完毕对BOSS主旨系统的事人体模型块进行负荷分担,将那个只对数码进行读取操作的模块都迁移到第二数目大旨上来,首要不外乎:

ü  地市总括报表

ü  地市职业查询

ü  提供任何系统的数目访谈接口;

那般作将高达八个好处:

ü  进步多少访谈的功用,进步外围系统布置的左右逢源;

ü  升高大旨系统的运维功能,提升宗旨系统运作的安定团结和可相信性;

 

2.4  湖北邮电通信的计费查询平台利用

本项目标建设供给是:为山西邮电通讯聚焦计费系统上线后,创立二个独门的查询系统,将计费数据库和总结数据库上的数码同步到三个科学的查询数据库中,通过该查询数据库达成27个月的计费话单数据保存、对外数据接口、以致对外查询业务。

  系统方案

基于海南邮电通讯数据复制系统的事情必要,接纳DSG RealSync软件将生产连串上的数据复制到历史查询系统上来。系统结构图为:

 图片 6

数据复制的数据源由计费数据库和总括数据库三个系统组合: 

l  Bill数据库(计费数据库):

由两台IBM P595(14*2GHzcpu)组成,采用Oracle RAC模式;

话单数据库上的数目包蕴话单数据和总括数据:话单数据保存3+5月;

数据库大小体量为:2233.69434;

每一天发生的Log日志量大致为122GB。

l  Stat.数据库(总括数据库):

由两台IBM P595组成,采用Oracle RAC模式;

积累长时间的总结数据;

数据库大小布置体量为:1500GB;

每一日产生的Log日志量安插为100GB左右。

l  查询服务器

利用IBM中高级UNIX服务器和高质量磁盘阵列,安装一个Oracle数据库系统。在数据库中开创八个User,一个User对应Billing数据库,一个User对应Stat.数据库。

  首要品质和指标参数:

在数码同步进度中,DSG RealSync表现出了十三分刚劲的系统脾气:

l  全同台质量:360GB/时辰(46GB在440s全同台导出结束);

l  实时同步品质:每一日发生100GB的ArchiveLog境况下未现身日志深入分析和装载的延迟,完全能够跟得上系统的日志产生速度。

编辑:服务器&运维 本文来源:DSG在境内的多多使用案例和客户列表

关键词: