RMan

Oracle 存储坏块处理方法-基于RMAN实现坏块介质恢复(blockrecover)

独自空忆成欢 提交于 2020-11-13 12:59:23
对于物理损坏的数据块,在有备份的情况下,我们可以通过RMAN块介质恢复(BLOCK MEDIA RECOVERY)功能来完成受损块的恢复, 而不需要恢复整个数据库或所有文件来修复这些少量受损的数据块。但前提条件是你得有一个可用的RMAN备份存在, 因此,无论何时备份就是一切。本篇我们来模拟产生一个坏块,然后使用RMAN实现坏块恢复。 说明: 一般出现坏块的时候,都是业务访问到这个坏块的时候报如下的错误: ERROR at line 1: ORA-01578: ORACLE data block corrupted (file # 18, block # 130) ORA-01110: data file 18: '/ora11gSource/ora11g/tbs_tmp.dbf' 操作: 1 创建用于演示的表空间 create tablespace tbs_tmp datafile '/ora11gSource/ora11g/tbs_tmp.dbf' size 10m autoextend on; 2 基于新的数据文件创建对象tb_tmp conn scott/tiger; create table tb_tmp tablespace tbs_tmp as select * from dba_objects; SQL> col file_name format a60 SQL>

PG启动恢复机制

有些话、适合烂在心里 提交于 2020-10-27 14:07:51
生产一个pg库停了后,起库的时候则需要很长时间,记录一下相应的原理。 如backup_label文件不存在(当前没有在做备份), 正情况情况下, 在恢复的开始, 服务器首先读取 pg_control ,然后读取检查点记录; 接着它通过从检查点记录里标识的日志位置开始向前扫描执行 REDO操作。 因为数据页的所有内容都保存在检查点之后的第一个页面修改的日志里(假设 full_page_writes 没有被禁用), 所以自检查点以来的所有变化的页都将被恢复到一个一致的状态 数据库正做备份,pg库宕机了,此时数据目录会生成backup_label 文件,则会读取backup_lable 中的check_point 点,以及备份期间记录的相应日志,对于这个文件的描述如下: 见 src/backend/access/transam/xlog.c /* * read_backup_label: check to see if a backup_label file is present * * If we see a backup_label during recovery, we assume that we are recovering * from a backup dump file, and we therefore roll forward from the checkpoint

灵备CDM系统介绍

你说的曾经没有我的故事 提交于 2020-10-24 09:41:17
第一章 背景及概述 随着云计算、虚拟化、大数据等一系列技术的不断发展,为企业及政府单位的数字化转型奠定了扎实的技术基础。通过数字化转型,能够打造灵活高效的业务流程、创新的商业模式,实现降低人力资本投入、增加营收等目标。一般来讲核心业务应用多数运行在PC Server、小型机、虚拟机上,但是在没有任何应急预案防护措施下,企业的信息化系统可能面临着严重的威胁和风险,如病毒感染破坏、******、软件故障、误操作、硬盘故障或人为破坏等,由此会造成系统失常、文件损坏或丢失、运营中断,更有甚者会引起数十台至数百台主机系统崩溃,导致所有系统信息和用户数据丢失的严重后果。此外,数字化转型所带来的更复杂的 IT 架构,更庞大的数据量,更智能化的 IT 管理等趋势也给企业在数据管理及保护方面带来了更多挑战。目前主要的数据管理保护及应用难题包括如下几个方面: ■ 数据量激增,传统备份效率低下,占用生产资源高,占用空间大,数据还原出错概率大 ■ 备份数据恢复时间长,且无法有效验证备份数据可用性 ■ 误操作、误删除等逻辑错误的防范 ■ 勒索病毒等安全威胁 ■ 开发环境、测试环境的搭建耗费大量人力物力 ■ 数据合规检查、数据抽取平台、报表统计分析影响生产环境 灵备CDM一体机利用“副本管理”技术来解决上述问题。灵备CDM系统通过原生格式数据捕获、永久增量等备份等技术,提升备份效率,节约存储资源

Oracle 数据库知识汇总篇

|▌冷眼眸甩不掉的悲伤 提交于 2020-10-16 13:24:19
Oracle 数据库知识汇总篇(更新中..) 1.安装部署篇 2.管理维护篇 3.数据迁移篇 4.故障处理篇 5.性能调优篇 6.SQL PL/SQL篇 7.考试认证篇 8.原理体系篇 9.架构设计篇 1.安装部署篇 参考随笔: Oracle安装部署,版本升级,应用补丁快速参考 2.管理维护篇 参考随笔: Oracle基础维护01-常用管理命令总结 Oracle基础维护02-表、主键、索引、表结构维护手册 主机、数据库日志收集 巡检脚本OS+Oracle ORACLE 11gR2 DG(Physical Standby)日常维护01 3.数据迁移篇 参考随笔: Oracle简单常用的数据泵导出导入(expdp/impdp)命令举例(上) Oracle简单常用的数据泵导出导入(expdp/impdp)命令举例(下) Oracle逻辑迁移某业务用户及数据 Oracle数据逻辑迁移综合实战篇 Oracle数据加载之sqlldr工具的介绍 Oracle数据加载之外部表的介绍 Oracle迁移:Linux->Windows 实验:Oracle直接拷贝物理存储文件迁移 Oracle数据库文件路径变更 EXP/IMP 导出生产库表的指定数据到测试库一例 Linux同平台数据库整体物理迁移 Oracle冷备迁移脚本(文件系统) RMAN异机恢复快速参考 Oracle从文件系统迁移到ASM存储

在Linux如何搭建Oracle11g Data Guard

吃可爱长大的小学妹 提交于 2020-10-04 03:28:58
RHEL6/CentOS6搭建Oracle Data Guard 一、工作原理 Oracle Data Guard是甲骨文推出的一种高可用性数据库方案,Data Guard确保企业数据的高可用性,数据保护和灾难恢复,Data Gurad 通过冗余数据来提供数据保护,通过日志同步机制保证冗余数据和主数之前的同步,这种同步可以是实时,延时,同步,异步多种形式。在Data Gurad环境中,至少有两个数据库,一个处于Open状态对外提供服务,这个数据库叫作Primary Database。第二个处于恢复状态,叫作Standby Database。运行时primary Database对外提供服务,用户在Primary Database上进行操作,操作被记录在联机日志和归档日志中,这些日志通过网络传递给Standby Database。这个日志会在Standby Database上重演,从而实现Primary Database和Standby Database的数据同步。 Data Guard 允许定义3种数据保护模式,分别是最大保护(Maximum Protection),最大可用(Maximum Availability)和最大性能(Maximum Performance)。 1.最大保护(Maximum Protection) 这种模式主备库之间数据是同步的。即主库提交的同时

Rman的format格式参数说明

生来就可爱ヽ(ⅴ<●) 提交于 2020-10-01 14:58:47
Rman的format格式参数说明 %c 备份片的拷贝数 %d 数据库名称 %D 位于该月中的第几天 (DD) %M 位于该年中的第几月 (MM) %F 一个基于DBID唯一的名称,这个格式的形式为c-IIIIIIIIII-YYYYMMDD-QQ,其中IIIIIIIIII为该数据库的DBID,YYYYMMDD为日期,QQ是一个1-256的序列 %n 数据库名称,向右填补到最大八个字符 %u 一个八个字符的名称代表备份集与创建时间 %p 该备份集中的备份片号,从1开始到创建的文件数 %U 一个唯一的文件名,代表%u_%p_%c %s 备份集的号 %t 备份集时间戳 %T 年月日格式(YYYYMMDD) 来源: oschina 链接: https://my.oschina.net/u/4127369/blog/4521625

核心系统Oracle 19c数据库迁移方式对比与实践

◇◆丶佛笑我妖孽 提交于 2020-09-30 12:00:47
本文根据梁铭图老师在8月21日〖Oracle ACE巅峰之夜〗线上分享演讲内容整理而成。 (文末有获取本期PPT&回放的方式,不要错过) 迁移背景 随着Oracle数据库19c在去年的发布,越来越多之前的数据库版本走入其生命周期的末期。企业中原来应用甚广如Oracle 11gR2目前已经退出支持,只为某些特殊客户提供有限并且是付费式的技术支持。客户需要将老旧的数据库迁移到19c等较新版本的数据库来获得Oracle官方的支持。 另外,IT技术的发展使客户的IT架构逐步走向云化和微服务化。许多客户的采购部门已经开始停止采购IBM、EMC之类的国外的硬件设备,转而大量采购国产的x86架构甚至是ARM架构的PC服务器。这个变化也极大的推动了企业数据库迁移。 最后,Oracle 19c及前面版本中引入的许多新特性以及增强属性,例如12c中引入的cdb与pdb,19c中引入的自动化索引(Automatic indexing)等全新特性也吸引着企业逐步将老旧数据库升级迁移到新版本,以应用全新的数据库特性。 以上三个因素是企业Oracle数据库升级迁移的主要动力。 方案选择 最近,我们协助了一个电信行业的客户将其核心系统的数据库,按不同的地市分三次迁移到Oracle 19c的数据库中。整个数据库迁移环境前后的对比如下: 源数据库主机平台:IBM小型机(PowerPC架构) 源库操作系统:AIX

数据库周刊33丨Oracle7月CPU安全预警;腾讯Tbase新版本发布;“2020数据技术嘉年华”有奖话题遴选;阿里云技术面试题;APEX 实现数据库自动巡检;MYSQL OCP题库……

江枫思渺然 提交于 2020-08-18 07:45:51
热门资讯 1、中国移动国产OLTP数据库中标公告:南大金仓阿里,万里开源中兴 分获大单 【摘要】近日,中国移动公布了 OLTP 自主可控数据库联合创新项目中标公告。公告显示:国产数据库中,南大通用、阿里巴巴、中兴通讯、人大金仓、万里开源 ,五大数据库产品榜上有名。 2、Oracle发布2020年7月CPU安全预警 奇安信贡献大量漏洞 【摘要】Oracle于今日发布了最新的 CPU 安全预警,CPU 全名是 Critical Patch Update,每个季度发布一次,用于提醒用户那些安全相关的已知漏洞。本次发布共有 27 个和数据库相关的安全漏洞。其中的主要漏洞是和各类组件相关,大多数用户无需关注。其中最核心的一个漏洞是 CVE-2016-9843 是和Core RDBMS (zlib) 相关,只影响到 18c 版本。 3、腾讯Tbase数据库新版本重磅发布:多活能力再上层楼 【摘要】2020年7月13日,腾讯自研的分布式HTAP数据库TBase正式发布了开源V2.1.0版本,作为开源后的首次重大版本升级,TBase开源V2.1.0版本提供了许多令人兴奋的新特性,同时,致力于更大限度地节省系统运行中的资源消耗,此外,TBase面向多中心多活架构的能力也进一步增强了。本文将对TBase开源V2.1.0版本的一些新特性及功能优化进行概括性解读。 4、【2020数据技术嘉年华

Oracle RAC 12.2.0.1打补丁Patch 30920127(Apr 2020)

筅森魡賤 提交于 2020-08-18 06:32:32
Oracle RAC 12.2.0.1打补丁Patch 30920127(Apr 2020) 环境介绍: Oracle RAC版本:12.2.0.1(两节点) 操作系统版本:CentOS7.4 64bit 一、补丁环境准备 1.1 上传安装包 p6880880_122010_Linux-x86-64 p30920127_122010_Linux-x86-64 1.2 确保OPatch utility版本 Patch 30920127要求Opatch工具为12.2.0.1.19及更高(gird和Oracle用户均需要确认) 1.2.1备份原来的OPatch utility root用户执行,两节点均需执行 mv /u01/app/12.2.0/grid/OPatch /u01/app/12.2.0/grid/OPatch_bak mv /u01/app/oracle/product/12.2.0/db_1/OPatch /u01/app/oracle/product/12.2.0/db_1/OPatch_bak 1.2.2 安装新的OPatch utility root用户执行,两节点均需执行 unzip /tmp/p6880880_122010_Linux-x86-64.zip -d /u01/app/12.2.0/grid unzip /tmp/p6880880_122010

ExaGrid就戴尔对ExaGrid备份存储技术的定位澄清事实

老子叫甜甜 提交于 2020-08-17 17:28:12
马萨诸塞州马尔伯勒--(美国商业资讯)--领先的分层备份存储提供商 ExaGrid ®今天就其与Dell EMC Data Domain重复数据删除设备竞争的产品做出事实澄清。在近期对经销商渠道的简报中,戴尔(Dell)讨论到ExaGrid备份存储产品线,而根据ExaGrid表示,简报的信息中有些显然过时或者不准确。尽管ExaGrid尊重戴尔的专业水准和技术水平,但有些陈述与ExaGrid的事实不符。 以下是 8 个值得注意的纠正: - ExaGrid独特的自适应重复数据删除过程与备份同时提供重复数据删除功能,从而使备份速度比其他解决方案快三倍,而且无需后期处理。 - ExaGrid系统可以横向扩展至2PB全备份,在单个系统中最多可容纳32台设备,每小时备份资料处理速率为432TB。 -在相同的1.5PB 情况下,ExaGrid的每小时数据吞吐量超过300TB,采用DD Boost的Dell DD9900为94/TB。 - 凭借将所有备份的最新副本存储在独特的ExaGrid磁盘缓存停放区中,虚拟机(VM)启动和数据还原的速度比其他解决方案快20倍。 - ExaGrid的横向扩展架构可增加计算能力,以随着数据的增加保持备份窗口定长。 - ExaGrid横向扩展技术将自动负载平衡和全局重复数据删除与单个UI相整合,易于进行备份管理。 - ExaGrid具有Veeam SOBR