当前位置:  数据库>其它

[1]Sql Developer 使用问题与解决方法汇总

[2]Configure Oracle Dataguard Primary-ASM to Physical-ASM

     在生产环境中的DBA，往往都是面对几十上百G的数据，甚至可能是T级别的，文件系统存储数据文件在这些场合下的I/O问题就会逐渐暴露，因而在生产环境中的数据存储一般都使用ASM，或者裸设备，oracle 11g开始就不支持裸设备存储数据了，因而本讲主要介绍在ASM环境下配置Data guard物理备库！

环境介绍：
主库IP：192.168.227.20/24
主库SID: orcl
主库DB_NAME：orcl
主库DB_UNIQUE_NAME:primary
主库SERVICES_NAME: primary.yang.com

备库IP：192.168.227.30/24
备库SID: orcl
备库DB_NAME：orcl
备库DB_UNIQUE_NAME:physical
备库SERVICES_NAME: physical.yang.com

一：主库准备工作 

1：配置ASM环境
[root@primary ~]# /u01/app/oracle/product/10.2.0/db_1/bin/localconfig add
[root@primary ~]# ps -ef |grep css
root 4180 1 0 13:07 ? 00:00:00 /bin/su -l oracle -c sh -c 'cd /u01/app/oracle/product/10.2.0/db_1/log/primary/cssd;ulimit -c unlimited;

exec /u01/app/oracle/product/10.2.0/db_1/bin/ocssd '
oracle 4332 4180 0 13:08 ? 00:00:00 /u01/app/oracle/product/10.2.0/db_1/bin/ocssd.bin
root 4682 4265 0 13:17 pts/1 00:00:00 grep css

[root@primary ~]# cd /u01/app/oracle/product/10.2.0/db_1/bin/
[root@primary bin]# ./crsctl check crs
CSS appears healthy
Cannot communicate with CRS
Cannot communicate with EVM

[oracle@primary ~]# ps -ef |grep -i asm
oracle 4459 1 0 13:10 ? 00:00:00 asm_pmon_+ASM
oracle 4461 1 0 13:10 ? 00:00:00 asm_psp0_+ASM
oracle 4463 1 0 13:10 ? 00:00:00 asm_mman_+ASM
oracle 4465 1 0 13:10 ? 00:00:00 asm_dbw0_+ASM
oracle 4467 1 0 13:10 ? 00:00:00 asm_lgwr_+ASM
oracle 4469 1 0 13:10 ? 00:00:00 asm_ckpt_+ASM
oracle 4471 1 0 13:10 ? 00:00:00 asm_smon_+ASM
oracle 4473 1 0 13:10 ? 00:00:00 asm_rbal_+ASM
oracle 4475 1 0 13:10 ? 00:00:00 asm_gmon_+ASM
oracle 4665 5702 0 13:16 pts/2 00:00:00 grep -i asm

[oracle@primary ~]$ export ORACLE_SID=+ASM
[oracle@primary ~]$ sqlplus /nolog
SQL> conn /as sysdba
SQL> select instance_name,status from v$instance;

INSTANCE_N STATUS
---------- ------------------------------------
+ASM STARTED

SQL> create diskgroup data normal redundancy
2 failgroup fg1 disk
3 '/dev/raw/raw1' name asmdisk1,
4 '/dev/raw/raw2' name asmdisk2
5 failgroup fg2 disk
6 '/dev/raw/raw3' name asmdisk3,
7 '/dev/raw/raw4' name asmdisk4;
Diskgroup created.

SQL> create diskgroup fraexternal redundancy
2 disk '/dev/raw/raw5' name asmdisk5;
Diskgroup created.

SQL> select name,path,failgroup from v$asm_disk;

NAMEPATH FAILGROUP
---------- ---------------------------------------- --------------------
ASMDISK5 /dev/raw/raw5 ASMDISK5
ASMDISK4 /dev/raw/raw4 FG2
ASMDISK3 /dev/raw/raw3 FG2
ASMDISK2 /dev/raw/raw2 FG1
ASMDISK1 /dev/raw/raw1 FG1

SQL> select name,total_mb,free_mb,usable_file_mb from v$asm_diskgroup;

NAMETOTAL_MB FREE_MB USABLE_FILE_MB
---------- ---------- ---------- --------------
DATA 81920 8181430667
FRA 58368 5831858318

[3]Oracle Data Guard 理论知识

        RAC， Data Gurad， Stream 是Oracle 高可用性体系中的三种工具，每个工具即可以独立应用，也可以相互配合。 他们各自的侧重点不同，适用场景也不同。

        RAC 它的强项在于解决单点故障和负载均衡，因此RAC 方案常用于7*24 的核心系统，但RAC 方案中的数据只有一份，尽管可以通过RAID等机制可以避免存储故障，但是数据本身是没有冗余的，容易形成单点故障。

        Data Gurad 通过冗余数据来提供数据保护，Data Gurad 通过日志同步机制保证冗余数据和主数据之前的同步，这种同步可以是实时，延时，同步，异步多种形式。DataGurad常用于异地容灾和小企业的高可用性方案，虽然可以在Standby机器上执行只读查询，从而分散Primary 数据库的性能压力，但是DataGurad决不是性能解决方案。

        Stream 是以Oracle Advanced Queue为基础实现的数据同步，提供了多种级别的灵活配置，并且Oracle提供了丰富的API等开发支持，Stream更适用在应用层面的数据共享。

      在Data Gurad 环境中，至少有两个数据库，一个处于Open 状态对外提供服务，这个数据库叫作PrimaryDatabase。第二个处于恢复状态，叫作StandbyDatabase。 运行时primary Database对外提供服务，用户在PrimaryDatabase 上进行操作，操作被记录在联机日志和归档日志中，这些日志通过网络传递给StandbyDatabase。 这个日志会在StandbyDatabase上重演，从而实现Primary Database和Standby Database 的数据同步。

       Oracle Data Gurad 对这一过程进一步的优化设计，使得日志的传递，恢复工作更加自动化，智能化，并且提供一系列参数和命令简化了DBA工作。

       如果是可预见因素需要关闭Primary Database，比如软硬件升级，可以把Standby Database 切换为Primary Database 继续对外服务，这样即减少了服务停止时间，并且数据不会丢失。如果异常原因导致Primary Database不可用，也可以把StandbyDatabase强制切换为Primary Database继续对外服务，这时数据损失程度和配置的数据保护级别有关系。因此Primary和Standby只是一个角色概念，并不固定在某个数据库中。

 一． Data Guard 架构

      DG架构可以按照功能分成3个部分：

            1） 日志发送（Redo Send）

            2） 日志接收（Redo Receive）

            3） 日志应用（Redo Apply）

       1. 日志发送（Redo Send）

       Primary Database 运行过程中，会源源不断地产生Redo 日志，这些日志需要发送到StandyDatabase。这个发送动作可以由PrimaryDatabase 的LGWR 或者ARCH进程完成， 不同的归档目的地可以使用不同的方法，但是对于一个目的地，只能选用一种方法。选择哪个进程对数据保护能力和系统可用性有很大区别。

      1.1 使用ARCH进程

1）Primary Database 不断产生Redo Log，这些日志被LGWR 进程写到联机日志。

2）当一组联机日志被写满后，会发生日志切换（Log Switch），并且会触发本地归档，本地归档位置是采用 LOG_ARCHIVE_DEST_1='LOCATION=/path'这种格式定义的。

如：alter system set log_archive_dest_1 = 'LOCATION=/u01/arch'scope=both;

3）完成本地归档后，联机日志就可以被覆盖重用。

4）ARCH 进程通过Net 把归档日志发送给Standby Database的RFS（RemoteFileServer）进程。

5）Standby Database 端的RFS 进程把接收的日志写入到归档日志。

6）Standby Database 端的MRP(Managed Recovery Process)进程（RedoApply）或者LSP进程（SQLApply）在StandbyDatabase上应用这些日志，进而同步数据。

         用ARCH模式传输不写Standby Redologs，直接保存成归档文件存放于Standby端。

 说明：

        逻辑Standby接收后将其转换成SQL语句，在Standby数据库上执行SQL语句实现同步，这种方式叫SQLApply。

        物理Standby接收完Primary数据库生成的REDO数据后，以介质恢复的方式实现同步，这种方式也叫RedoApply。

 注意：创建逻辑Standby数据库要先创建一个物理Standby数据库，然后再将其转换成逻辑Standby数据库。

        使用ARCH进程传递最大问题在于： Primary Database只有在发生归档时才会发送日志到StandbyDatabase。 如果Primary Database 异常宕机，联机日志中的Redo内容就会丢失，因此使用ARCH进程无法避免数据丢失的问题，要想避免数据丢失，就必须使用LGWR，而使用LGWR又分SYNC（同步）和ASYNC（异步）两种方式。

        在缺省方式下，Primary Database使用的是ARCH进程，参数设置如下：

alter system set log_archive_dest_2 = 'SERVICE=ST' scope=both;

        1.2 使用LGWR 进程的SYNC 方式

1）Primary Database 产生的Redo 日志要同时写道日志文件和网络。也就是说LGWR进程把日志写到本地日志文件的同时还要发送给本地的LNSn进程（NetworkServerProcess），再由LNSn（LGWRNetworkServerprocess）进程把日志通过网络发送给远程的目的地，每个远程目的地对应一个LNS进程，多个LNS进程能够并行工作。

2）LGWR 必须等待写入本地日志文件操作和通过LNSn进程的网络传送都成功，Primary Database 上的事务才能提交，这也是SYNC的含义所在。

3）Standby Database的RFS进程把接收到的日志写入到Standby Redo Log日志中。

4）Primary Database的日志切换也会触发Standby Database 上的日志切换，即Standby Database 对Standby Redo Log的归档，然后触发Standby Database 的MRP或者LSP进程恢复归档日志。

因为Primary Database 的Redo 是实时传递的，于是Standby Database 端可以使用两种恢复方法：

           实时恢复（Real-Time Apply）： 只要RFS把日志写入StandbyRedoLog就会立即进行恢复；

           归档恢复： 在完成对Standby Redo Log 归档才触发恢复。

           Primary Database默认使用ARCH进程，如果使用LGWR进程必须明确指定。使用LGWRSYNC方式时，可以同时使用NET_TIMEOUT参数，这个参数单位是秒，代表如果多长时间内网络发送没有响应，LGWR进程会抛出错误。示例如下：

alter system set log_archive_dest_2 = 'SERVICE=ST LGWR SYNC NET_TIMEOUT=30' scope=both;

       1.3 使用LGWR进程的ASYNC 方式

       使用LGWR SYNC方法的可能问题在于，如果日志发送给Standby Database过程失败，LGWR进程就会报错。也就是说PrimaryDatabase的LGWR进程依赖于网络状况，有时这种要求可能过于苛刻，这时就可以使用LGWRASYNC方式。 它的工作机制如下：

1