【感想】关于第二备库的一些

    入职三个月零六天了!其中搭建第二备库就消耗了一个月零4天的:9月6号提交需求!三分之一了。自己想想就表示对自己无语了!
   对上述事件做些技术性的总结:关于第二备库的其实是一个级联的dataguard系统,因为不能对主库做操作,所以只能对现有的第一,第二备库进行相关的操作。具体的实验步骤见:创建级联dataguard!(ps 实际生产环境做的时候,状况也层出不穷!)剖析整个事件:

   1 自己没有对整个需求实施将会遇到的问题有良好的预见性,包括对开放相关网络端口访问权限;磁盘空间是否充足(虽然机器不是我选型的,同事提醒的时候,未重视该问题!导致最后重新更换机器);11gr2 duplicate 复制standby 遇到bug;nfs 设置知识;磁带驱动的安装和使用遇到的问题;

   2 告知客户关于做项目进度问题,实际上就是沟通问题,  由于在生产库上进行实施之前,为整个实施过程搭建的仿真环境来模拟线上环境,耗费了一些时间,开始测试选择使用duplicate 复制数据库,遇到bug;换另一种利用现有的磁带备份,从磁带备份中恢复,来复制一个standby数据库,遇见stbinfo2 问题,和相关工程师沟通没有得到具体的解决方案;选择使用rman备份到NFS 上,然后再从异机使用rman 恢复;线上库操作的时候,申请变更流程。整个过程只是和对方的一个dba 做交接,未和提交需求的相关人员做直接沟通,导致一些误解。

    回顾整个过程发生的事情,发现自己有太多的不足,技术上的,工作态度上的,处事方面的。

    1 工作上每每做一件事情,似乎只能单线程的处理,导致时间分配不好,耗时没效率!

    2 态度问题,并没有自己想象对工作的认真或者对与工作中某一件事情的用心,比如对团队博客系统的管理,一直使用itpub的博客而少用团队的博客,没有用心管理博客,直到主管发现博客的url 不可访问了,才知道!想对自己说,工作无小事,每件简单的事情都做好了,就是不简单!用心经营自己也是用心做好工作上的每一件事情。

   3 关系技术的学习,开发dba,产品dba,对于这两个角色的概念随着自己的工作而变得有些生疏。数据库的管理,处理数据库报警,数据库变更,性能优化,多少感觉没有重点。

   4 盲动,没有思想;似乎工作只是工作;重复学习。。

     

时间: 2024-08-24 15:09:25

【感想】关于第二备库的一些的相关文章

【DataGuarad】逻辑迁移与standby备库

standby 库不支持expdp,可以使用exp代替 oracle@rac3:/home/oracle>expdp yang/yang directory=dump dumpfile=yang.dmp tables=yang                      Export: Release 11.2.0.1.0 - Production on Tue Sep 20 19:46:42 2011 Copyright (c) 1982, 2009, Oracle and/or its aff

一则备库CPU报警的思考

今天收到一封报警邮件,这引起了我的注意.当然过了一会,有收到了CPU使用率恢复的邮件. 报警邮件内容如下: ZABBIX-监控系统: ------------------------------------报警内容: Disk I/O is overloaded on ora_statdb2_s_xxx@xxxxx ------------------------------------报警级别: PROBLEM ------------------------------------监控项目:

mysql主键的缺少导致备库hang

最近线上频繁的出现slave延时的情况,经排查发现为用户在删除数据的时候,由于表主键的主键的缺少,同时删除条件没有索引,或或者删除的条件过滤性极差,导致slave出现hang住,严重的影响了生产环境的稳定性,也希望通过这篇博客,来加深主键在innodb引擎中的重要性,希望用户在使用RDS,设计自己的表的时候,一定要为表加上主键,主键可以认为是innodb存储引擎的生命,下面我们就来分析一下这个案例(本案例的生产环境的binlog为row模式,对于myisam存储引擎也有同样的问题): (1).现

mysql主键的缺少导致备库hang住_Mysql

最近线上频繁的出现slave延时的情况,经排查发现为用户在删除数据的时候,由于表主键的主键的缺少,同时删除条件没有索引,或或者删除的条件过滤性极差,导致slave出现hang住,严重的影响了生产环境的稳定性,也希望通过这篇博客,来加深主键在innodb引擎中的重要性,希望用户在使用RDS,设计自己的表的时候,一定要为表加上主键,主键可以认为是innodb存储引擎的生命,下面我们就来分析一下这个案例(本案例的生产环境的binlog为row模式,对于myisam存储引擎也有同样的问题):(1).现象

备库报警邮件的分析案例(二)

在第一篇中分享了关于备库报警邮件的分析,发现很多问题都是一环扣一环. 起初是通过监控主库中的v$dataguard_status发现备库中可能存在一些问题,结果逐步分析,发现是由备库的crontab触发了备库的定时read-only和online状态,(即只读和应用日志,10gR2的环境),而这些关键信息都是从数据库的alert日志中发现的,但是问题还没有完,才刚刚开始,因为发现备库中竟然有ORA-1652: unable to extend temp segment by 128 in tab

【DATAGUARD 学习】管理影响备库的主库事件

版本 11g 主库 ORCL  备库 TESTDG1添加数据文件或表空间2删除数据文件或表空间3使用可传输表空间4重命名数据文件5添加或删除重做日志6使用NOLOGGING或unrecoverable子句操作ddl或dml7更改初始化参数 一 添加数据文件或表空间1 standby_file_management =AUTO 时主库上的操作ORCL>ORCL>col tsname for a20ORCL>col dfname for a50ORCL>select ts.name t

由报警邮件分析发现的备库oracle bug

昨天到公司之后,收到两份封报警邮件,可以看到在早晨6:30左右主库的v$dataguard_status检查时发现了一个错误.然后再2分钟后就自动恢复了. 一般这种问题很自然想到可能是网络出现了一些问题.因为自动恢复了,所以也不同太着急处理,于是细细看了下.报警邮件如下: ZABBIX-监控系统: ------------------------------------ 报警内容: DG_issue ------------------------------------ 报警级别: PROBL

备库批量查询失败的原因分析

目前线上有一套环境是10gR2的,采用了一主两备的架构.在其中一个备库上每天凌晨会开放一个窗口运行一些批量的查询,目前使用dg broker会在指定的时间把备库置为read-only,查询完毕之后修改为online状态.但是近几天开发的同事突然找到我说,最近几天开始批量查询会频频报错,希望我帮忙查看一下.语句运行报错,听起来原因应该很简单吧,最大的可能就是备库没有打开,或者是ddl,dml语句之类的.但是看到错误日志,让我着实有些奇怪.错误日志如下,可以看到是一条查询语句. [2016.03.0

备库报警邮件的分析案例(三)

继前两篇分析了一个看似非常普通的报警邮件,结果在分析问题的时候八面玲珑,相关因素都给分析了一下,没想到还真是有不小的收获. 前两篇地址: http://blog.itpub.net/23718752/viewspace-1827685/ http://blog.itpub.net/23718752/viewspace-1829630/ 最后通过手工定位监控的方式终于把罪魁祸首揪了出来,为什么在备库使用ash无果,因为还是10g的库,还没有这个特性,在11g中才可以.这个也算是在10g中的一个监控