星期四 五月 26, 2016

使用RMAN备份RAC本地目录中的archive log的第二种方案

有一部分RAC环境中的log_archive_dest_n设置到了本地的磁盘上,这在正常使用中并没有什么问题。而在备份的时候如果只从一个instance的channel发起的话,由于只能访问本节点的本地目录,所以在备份其他节点的archive log的时候会出现错误。而很多情况下,客户会使用NFS的方式,把本地节点的归档目录mount到其他的节点。这样配置,一个节点就可以访问所有其他节点的archive log了。但是此种方法也有一个问题:就是在某节点备份archive log的时候,如果备份的是其他节点生成archive log的时候,由于是通过NFS mount过来的目录,所以归档日志需要通过网络传输到本地然后再备份到磁带上。这样一来,增加的节点间文件传输既造成了对网络的影响,其本身的效率也受到网络带宽以及性能的制约。所以以下介绍一种通过每个节点开启通道,让每个节点的通道备份本节点archive log的方式(不使用NFS):

1. 在归档目录设置到本地的RAC中,检查现有的archive log

SQL> select name from v$archived_log;

NAME
--------------------------------------------------------------------------------












NAME
--------------------------------------------------------------------------------



/home/oracle/arch2/2_53_827893172.dbf
/home/oracle/arch2/2_54_827893172.dbf
/home/oracle/arch2/2_55_827893172.dbf
/home/oracle/arch1/1_122_827893172.dbf
/home/oracle/arch1/1_123_827893172.dbf
/home/oracle/arch1/1_124_827893172.dbf
/home/oracle/arch1/1_125_827893172.dbf
/home/oracle/arch1/1_126_827893172.dbf

NAME
--------------------------------------------------------------------------------
/home/oracle/arch2/2_56_827893172.dbf
/home/oracle/arch1/1_127_827893172.dbf
/home/oracle/arch2/2_57_827893172.dbf
/home/oracle/arch2/2_58_827893172.dbf
/home/oracle/arch2/2_59_827893172.dbf
/home/oracle/arch1/1_128_827893172.dbf

28 rows selected.


2. 尝试使用默认的本地channel去备份所有的归档:

RMAN> backup archivelog all;

Starting backup at 12-MAY-16
current log archived
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=60 instance=ora11g1 device type=DISK
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup command at 05/12/2016 09:40:46
RMAN-06059: expected archived log not found, loss of archived log compromises recoverability
ORA-19625: error identifying file /home/oracle/arch2/2_53_827893172.dbf <<<<<< 找不到节点2的archive log
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3


3. 分别启动本地以及另外一个instance的两个channel,然后备份所有的归档(这里面有一个可能的问题,就是oracle在把归档日志分配到channel的时候,会不会出现本地arhive log分到其他节点instance channel的疑问, 但是通过实验,oracle显然可以避免类似问题的发生):

RMAN> run {
allocate channel 'dev_0' type disk connect /;
allocate channel 'dev_1' type disk connect sys/oracle@ora11g_11;  <<<<<<此channel连接到节点2的instance上。
backup archivelog all;
release channel dev_0;
release channel dev_1;
}
2> 3> 4> 5> 6> 7>
released channel: ORA_DISK_1
allocated channel: dev_0
channel dev_0: SID=60 instance=ora11g1 device type=DISK

allocated channel: dev_1
channel dev_1: SID=32 instance=ora11g2 device type=DISK

Starting backup at 12-MAY-16
current log archived
channel dev_1: starting archived log backup set
channel dev_1: specifying archived log(s) in backup set
input archived log thread=2 sequence=53 RECID=21 STAMP=881588641
channel dev_1: starting piece 1 at 05-JUN-15
channel dev_0: starting archived log backup set
channel dev_0: specifying archived log(s) in backup set
input archived log thread=1 sequence=122 RECID=24 STAMP=911640813
channel dev_0: starting piece 1 at 12-MAY-16
channel dev_0: finished piece 1 at 12-MAY-16
piece handle=+DATA/ora11g/backupset/2016_05_12/annnf0_tag20160512t093710_0.261.911641035 tag=TAG20160512T093710 comment=NONE
channel dev_0: backup set complete, elapsed time: 00:00:03
channel dev_1: finished piece 1 at 05-JUN-15
piece handle=+DATA/ora11g/backupset/2015_06_05/annnf0_tag20160512t093710_0.262.911617575 tag=TAG20160512T093710 comment=NONE
channel dev_1: backup set complete, elapsed time: 00:00:04
channel dev_1: starting archived log backup set
channel dev_1: specifying archived log(s) in backup set
input archived log thread=2 sequence=54 RECID=22 STAMP=881588646
input archived log thread=2 sequence=55 RECID=23 STAMP=881588647
input archived log thread=2 sequence=56 RECID=29 STAMP=881588655
channel dev_1: starting piece 1 at 05-JUN-15
channel dev_0: starting archived log backup set
channel dev_0: specifying archived log(s) in backup set
input archived log thread=1 sequence=123 RECID=25 STAMP=911640816
input archived log thread=1 sequence=124 RECID=26 STAMP=911640816
input archived log thread=1 sequence=125 RECID=27 STAMP=911640817
input archived log thread=1 sequence=126 RECID=28 STAMP=911640818
input archived log thread=1 sequence=127 RECID=30 STAMP=911640818
channel dev_0: starting piece 1 at 12-MAY-16
channel dev_0: finished piece 1 at 12-MAY-16
piece handle=+DATA/ora11g/backupset/2016_05_12/annnf0_tag20160512t093710_0.259.911641039 tag=TAG20160512T093710 comment=NONE
channel dev_0: backup set complete, elapsed time: 00:00:02
channel dev_1: finished piece 1 at 05-JUN-15
piece handle=+DATA/ora11g/backupset/2015_06_05/annnf0_tag20160512t093710_0.260.911617565 tag=TAG20160512T093710 comment=NONE
channel dev_1: backup set complete, elapsed time: 00:00:03
channel dev_1: starting archived log backup set
channel dev_1: specifying archived log(s) in backup set
input archived log thread=2 sequence=57 RECID=31 STAMP=881588658
channel dev_1: starting piece 1 at 05-JUN-15
channel dev_0: starting archived log backup set
channel dev_0: specifying archived log(s) in backup set
input archived log thread=1 sequence=128 RECID=34 STAMP=911640825
channel dev_0: starting piece 1 at 12-MAY-16
channel dev_0: finished piece 1 at 12-MAY-16
piece handle=+DATA/ora11g/backupset/2016_05_12/annnf0_tag20160512t093710_0.257.911641041 tag=TAG20160512T093710 comment=NONE
channel dev_0: backup set complete, elapsed time: 00:00:02
channel dev_1: finished piece 1 at 05-JUN-15
piece handle=+DATA/ora11g/backupset/2015_06_05/annnf0_tag20160512t093710_0.258.911614343 tag=TAG20160512T093710 comment=NONE
channel dev_1: backup set complete, elapsed time: 00:00:02
channel dev_1: starting archived log backup set
channel dev_1: specifying archived log(s) in backup set
input archived log thread=2 sequence=58 RECID=32 STAMP=881588659
input archived log thread=2 sequence=59 RECID=33 STAMP=881588660
input archived log thread=2 sequence=60 RECID=36 STAMP=881588866
channel dev_1: starting piece 1 at 05-JUN-15
channel dev_0: starting archived log backup set
channel dev_0: specifying archived log(s) in backup set
input archived log thread=1 sequence=129 RECID=35 STAMP=911641027
channel dev_0: starting piece 1 at 12-MAY-16
channel dev_0: finished piece 1 at 12-MAY-16
piece handle=+DATA/ora11g/backupset/2016_05_12/annnf0_tag20160512t093710_0.263.911641045 tag=TAG20160512T093710 comment=NONE
channel dev_0: backup set complete, elapsed time: 00:00:01
channel dev_1: finished piece 1 at 05-JUN-15
piece handle=+DATA/ora11g/backupset/2015_06_05/annnf0_tag20160512t093710_0.256.911613925 tag=TAG20160512T093710 comment=NONE
channel dev_1: backup set complete, elapsed time: 00:00:02
Finished backup at 12-MAY-16

released channel: dev_0

released channel: dev_1

通过以上实验,我们可以看出来,只要开启到RAC所有节点的channel,在做所有归档备份的时候,oracle会自动将本地归档目录中的archive log分配给本地的channel。这样既可以将备份的负载分配到所有的节点中,又可以避免使用NFS方式在单节点备份的网络传输问题。

星期四 五月 19, 2016

如何准确查询表空间文件具体使用信息的问题

悉数表空间的计算情况,也许碰到查看EM时,某个表空间的使用超过90%, 进入的数据库发现查看不同的视图又得到不同的结果。



接下来我们详细解释每个视图的空间用途和区别:

1. EM 是从dba_tablespace_usage_metrics获取的数据,自动扩展(autoextensible)的情况下,这个视图中的tablespace_size是dba_data_files的最大的块数
   也就是dba_tablespace_usage_metrics的tablespace_size是datafile能增长到的最大值。
   dba_tablespace_usage_metrics的used_space是已经分配的空间,对应v$filespace_usage的allocated_space字段
   而对于非自动扩展的表空间,使用DBA_TABLESPACE_USAGE_METRICS视图,与传统脚本使用的DBA_DATA_FILE和DBA_FREE_SPACE查询的结果是一致的。

   具体请参考:Difference in Tablespace Size Values From dba_data_files and dba_tablespace_usage_metrics/V$Filespace_usage (Doc ID 455715.1)

2. 关于临时表空间的使用,也许会碰到v$temp_space_header的temp usage怎么大于v$tempseg_usage(或v$sort_usage)的值呢?
   视图v$sort_usage或者v$tempseg_usage(和v$sort_segment)给出了sort segment分配的正确信息,我们应该通过使用这三个表来查询当前临时空间的确切使用情况的。

   但是,v$temp_space_header则是当临时空间使用最高的时候每个临时文件的多少块数,事实上,它展示了每个临时文件初始块的个数并非实际分配的块。
   v$sort_usage/v$tempseg_usage确切的反映了初始块中对每个事务分配了多少实际的sort extent。

   另外,v$temp_space_header的信息是持久化的,即便重启也不会改变;而V$sort_segment and v$sort_usage不是持久的。


    $sqlplus / as sysdba

    -----------------------<
    set lines 500
    set long 9999
    set pages 999
    set serveroutput on size 1000000
    set feedback off
    SET MARKUP HTML ON SPOOL ON HEAD "<TITLE>SQL*Plus Report</title><STYLE TYPE='TEXT/CSS'><!--BODY {background: ffffc6} --></STYLE>"
    spool query_result.html
    set echo off
    select TABLESPACE_NAME,TOTAL_BLOCKS,USED_BLOCKS,FREE_BLOCKS from v$sort_segment;
    SELECT a.username, a.sid, a.serial#, a.osuser,a.schemaname,a.program,a.type,b.tablespace, to_char(trunc((b.blocks * d.value) / 1024 /1024)) || ' MB' siz
    , b.segtype , c.sql_text
    FROM v$session a, v$tempseg_usage b, v$sqlarea c
    , (select value from v$parameter where name = 'db_block_size') d
    WHERE a.saddr = b.session_addr
    AND c.address= a.sql_address
    AND c.hash_value = a.sql_hash_value
    ORDER BY b.tablespace, b.blocks;
    spool off
    SET MARKUP HTML OFF
    set echo on
    ----------------------->


   具体请参考:Mismatch Between V$TEMP_SPACE_HEADER and V$TEMPSEG_USAGE/V$SORT_USAGE (Doc ID 2095211.1)


正确的查看空间使用情况的脚本是:Script to Monitor Tablespace Usage and Information (Doc ID 1902106.1)

  下载TSINFO.sql脚本,在执行:

   @<Complete path of the .sql file> Tablespace name
   i.e
   @"C:\Users\administrator\Desktop\TSINFO.sql USERS"

星期三 五月 04, 2016

Oracle数据库技术支持通讯2016年4月版已发布

您可以收藏或访问 Note 1529795.1 来阅读最新内容,它包含了当前的技术通讯和历史版本的链接。

2016年4月版:




星期六 四月 09, 2016

Oracle数据库技术支持通讯2016年3月版已发布

您可以收藏或访问 Note 1529795.1 来阅读最新内容,它包含了当前的技术通讯和历史版本的链接。

2016年3月版:






星期二 四月 05, 2016

记一个12c的chm bug导致的ORA-01017

通过此文,记录一个12c新特性bug引起的service被抢注、节点service连接报ORA-01017的问题。

[Read More]

星期五 三月 25, 2016

使用12c 的 ping target 功能解决虚拟机环境外部公网网线断开不能正常触发failove的问题

在虚拟机环境如果物理主机的公网网线断开的时候,虚拟机内部对应的公网网卡并不知晓物理网线的断开,RAC也不会检测到这种物理网线的断开,VIP等资源 也不会做failover。这实际导致rac 的VIP Listener 在公网故障时的 failover 功能失效。

具体环境:
软件环境:Oracle VM 3 + Oracle Linux 6+ Oracle RAC Cluster 11.2.0.4
架构环境:两节点RAC集群,集群节点分别运行在Oracle VM虚拟机上,RAC的private network和public network分别桥接在OVM Server不同的物理网卡上,物理网卡均为OVM的VM Network。

[Read More]

星期六 三月 19, 2016

expdp导出表数量接近但是时间差距明显原因

为什么有时候两个表数量接近但是导出时间却差距明显?

日前接到一个case,用户反映一个表导出时间特别长,因为担心影响第二天业务,不得不放弃继续导出,但是另外一个表比这个问题表数量更大,但是反而顺利导出,用户在相同版本测试环境上也能顺利导出,当然测试环境和生产环境还是有差异的,客户说那个环境是用两个月前的备份恢复而成的,但是数据量差距并不十分明显,但是导出时间却天壤之别,于是让客户对expdp进行trace,因为导出时间特别长,所以只做了30min的,通过tkprof 查看,时间基本都是io操作,但是因为另外一个表比这个数据量还大却能顺利导出,所以可以排除是IO瓶颈问题,于是查看原始trace文件,大量的db file sequential read,统计了一下,数量非常之多,接近了blocks数量,随便查找了一个block#,居然发现有多条记录。

[Read More]

星期五 三月 11, 2016

一个"间歇性物理IO缓慢"导致log file sync问题的案例

根据 Note 1626301.1 - 故障排除:"log file sync"等待 中提到的 "间歇性物理IO缓慢对 'log file sync' 等待事件的影响":
“如果你发现系统的'log file sync'很高,但是'log file parallel write'是处于正常的范围,那么这可能是由于间歇性物理IO缓慢导致的。你需要使用一些像OSWatcher一样的工具(参照 Document 301137.1)来确定是否系统中存在间歇性物理IO缓慢。”

日前我们就碰到了这么一例,这里给大家分享一下分析的过程。

[Read More]

星期一 三月 07, 2016

便捷的日志收集和分析工具TFA

之前我写了一篇关于Oracle GI 日志收集工具 TFA 的介绍,其中讲解了TFA的安装方法和命令。在本篇博客中我们来详细了解一下TFA的功能,以及如何利用它的便捷之处。

1. 便捷的日志收集和分析工具Trace File Analyzer

客户在和技术支持的工程师解决GI(RAC)问题的时候,一个最大的问题就是及时的收集各个节点上和问题相关的日志和诊断数据,特别是收集的数据还有跨节 点。另外,RAC里的trace日志文件是轮循使用的,如果发生问题之后不及时收集日志就会被覆盖。对于单机的环境ADR(Automatic Diagnostic Repository)虽然可以很好的避免这个问题,它会对故障发生后对故障生成的文件进行打包,但是ADR并不能收集RAC的日志。

[Read More]

Oracle数据库技术支持通讯2016年2月版已发布

您可以收藏或访问 Note 1529795.1 来阅读最新内容,它包含了当前的技术通讯和历史版本的链接。
2016年2月版:

RAT 数据库重放工具…
Oracle 数据库技术更新 …
支持提示 …
补丁更新 …

星期五 三月 04, 2016

从一个递归sql导致大量trace的案例来看只读备库禁用系统触发器的必要性

我们知道,如果在只读备库上进行DML操作,会报出ORA-16000错误。然而,很多时候并没有发起DML操作,却一样出现报错。本文对隐式的递归sql导致的这种情况进行分析。其中只对某个oracle函数的某个error code来做errorstack的方法值得借鉴。

[Read More]

主机os重装的节点加回RAC集群步骤示例

很多客户遇到过这样的情况:由于RAC其中一个节点的主机OS损坏,需要重装。而重装后怎样把节点加回集群呢?


这里将涉及的步骤整理如下:

[Read More]

硬件改变导致Osysmond.bin产生Core Dump

Osysmond.bin是Cluster Health Check的组件,其功能是监控和收集操作系统级的统计信息,并把它发送给ologgerd记录。硬件变更(如扩充CPU、添加硬盘等)可能导致OSYSMOND无法识别新硬件,从而产生core dump。本文就该问题给出了相应的解决方案。

[Read More]

星期四 三月 03, 2016

为什么我们应在外键上创建索引

在外键上不创建索引,可能会引发死锁的问题。我将通过一些简单的案例,展示在不同情境下,索引的有无对锁状态的影响。
测试的数据库版本是11.2.0.2,所使用的表emp、dept与scott用户下的表相同。

[Read More]

星期二 二月 23, 2016

又有新的数据库中文文档添加到 My Oracle Support 中了! (2016年2月)

又有新的数据库中文文档添加到 My Oracle Support 中了! (2016年2月)
最新翻译的文档列表:

Note 2101974.1 Datapatch:数据库 12c 补丁后期 SQL 自动化
Note 2101982.1 常见问题:在 Windows 平台的 Oracle 12.1 数据库版本上的 Oracle Home 用户
Note 2102453.1 EM Express 常见问题
Note 2102856.1 12c 新后台进程
Note 2102464.1 Oracle NET 12c 新特性
Note 2102447.1 Database 12c 可以在 Solaris 上使用 Optimized Shared Memory 特性
Note 2102499.1 当在 Oracle 12c 上设置 RESULT_CACHE_MODE = MANUAL 时发生'Result Cache: RC Latch'类型的”Latch Free”等待
Note 2102495.1 Oracle 12C 扩展统计信息是否自动收集?
Note 2102859.1 12c – 使用跨平台增量备份来减少传输表空间的停机时间
Note 2108887.1 12C 基于 RMAN 备份集进行跨平台(different Endian)数据传输
Note 2102854.1 在 12c 上配置 Create Dataguard Broker - DGMGRL
Note 2103317.1 如何在 oracle 集群环境下修改私网信息
Note 2102514.1 常见问题:Oracle Flex ASM 12c / 12.1

完整的列表请点击这里
或登录 My Oracle Support 并查找:
中文文档列表 - Oracle Database (文档 ID 1533057.1)

About

本博客由Oracle全球技术支持中国区的工程师维护。为中文用户提供数据库相关的技术支持信息,包括常用的诊断工具、诊断方法、产品新特性、案例分析等。此外,MOS也陆续推出各类中文内容:技术通讯统一发布在Note 1529795.1 中,中文文档列表更新在Note 1533057.1 中,网上讲座请查看MOS文档 1456176.1,在"Archived"中可以下载历史的录音和文档。

Search

Archives
« 五月 2016
星期日星期一星期二星期三星期四星期五星期六
1
2
3
5
6
7
8
9
10
11
12
13
14
15
16
17
18
20
21
22
23
24
25
27
28
29
30
31
    
       
今天