验证DG最大性能模式下使用ARCH/LGWR及STANDBY LOG的不同情况
总结: --两台单实例数据库做DG,数据库版本10.2.0.1.0
1.主库配置为:arch async,备库无STANDBY LOG。
日志中会有:RFS[4]: No standby redo logfiles created
2.主库配置为:arch async,备库有STANDBY LOG,日志中未显示使用。
特殊情况:主库配置为:arch async,,备库有STANDBY LOG,备库未打开日志应用 ,日志中有:RFS[8]: Successfully opened standby log 4: '/u01/app/Oracle/prod/disk1/standbylog1.log'
3.主库修改参数为:lgwr async,备库有STANDBY LOG,日志如下:
RFS[10]: Successfully opened standby log 4: '/u01/app/oracle/prod/disk1/standbylog1.log'
4.主库修改参数为:log_archive_dest_2 == SERVICE=PROD,只写SERVICE=PROD主库归档不能传送到备库。
1.主库配置及日志:
主库:
SQL> select protection_mode,database_role,protection_level from v$database;
PROTECTION_MODE DATABASE_ROLE PROTECTION_LEVEL
-------------------- ---------------- --------------------
MAXIMUM PERFORMANCE PRIMARY MAXIMUM PERFORMANCE
15:47:43 SQL> show parameter log_archive_dest_2
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_2 string SERVICE=prod1 arch async VALI
D_FOR=(ONLINE_LOGFILES,PRIMARY
_ROLE) DB_UNIQUE_NAME=prod1
15:47:49 SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
27
备库:
SQL> select protection_mode,database_role,protection_level from v$database;
PROTECTION_MODE DATABASE_ROLE PROTECTION_LEVEL
-------------------- ---------------- --------------------
MAXIMUM PERFORMANCE PHYSICAL STANDBY MAXIMUM PERFORMANCE
03:48:02 SQL> select group#,thread#,bytes/1024/1024 mb,status from v$standby_log;
no rows selected
03:48:05 SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
27
####################
2.主库做REDO日志切换并查看日志:
15:48:18 SQL> alter system switch logfile;
System altered.
15:49:33 SQL> alter system switch logfile;
System altered.
15:50:11 SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
29
备库已经接收:
03:49:48 SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
29
主库日志:
[oracle@ocm1 ~]$ tail -f alert_PROD.log
Sun Apr 20 15:49:33 2014
Thread 1 advanced to log sequence 29
Current log# 2 seq# 29 mem# 0: /u01/app/oracle/prod/disk1/redo02.log
Current log# 2 seq# 29 mem# 1: /u01/app/oracle/prod/disk2/log2b.log
Sun Apr 20 15:50:11 2014
Thread 1 advanced to log sequence 30
Current log# 3 seq# 30 mem# 0: /u01/app/oracle/prod/disk1/redo03.log
Current log# 3 seq# 30 mem# 1: /u01/app/oracle/prod/disk2/log3b.log
备库日志:
[oracle@ocm2 ~]$ tail -f alert_PROD1.log
RFS[4]: Archived Log: '/u01/app/oracle/prod/arch/1_28_844894247.arc'
Sun Apr 20 03:49:30 2014
Media Recovery Log /u01/app/oracle/prod/arch/1_28_844894247.arc
Media Recovery Waiting for thread 1 sequence 29
Sun Apr 20 03:50:07 2014
RFS[4]: No standby redo logfiles created
RFS[4]: Archived Log: '/u01/app/oracle/prod/arch/1_29_844894247.arc'
Sun Apr 20 03:50:10 2014
Media Recovery Log /u01/app/oracle/prod/arch/1_29_844894247.arc
Media Recovery Waiting for thread 1 sequence 30
##########################################################
主库配置不变。
备库增加STANDBY LOG:
03:55:04 SQL> alter database recover managed standby database cancel;
Database altered.
03:56:39 SQL> alter database add standby logfile '/u01/app/oracle/prod/disk1/standbylog1.log' size 100m;
Database altered.
03:56:50 SQL> alter database add standby logfile '/u01/app/oracle/prod/disk1/standbylog2.log' size 100m;
Database altered.
03:56:55 SQL> alter database add standby logfile '/u01/app/oracle/prod/disk1/standbylog3.log' size 100m;
Database altered.
03:57:00 SQL> alter database add standby logfile '/u01/app/oracle/prod/disk1/standbylog4.log' size 100m;
Database altered.
03:57:05 SQL> select group#,thread#,bytes/1024/1024 mb,status from v$standby_log;
GROUP# THREAD# MB STATUS
---------- ---------- ---------- ----------
4 0 100 UNASSIGNED
5 0 100 UNASSIGNED
6 0 100 UNASSIGNED
7 0 100 UNASSIGNED
04:13:33 SQL> alter database recover managed standby database disconnect from session;
Database altered.
04:14:12 SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
38
###在主库切换日志:
16:15:40 SQL> alter system switch logfile;
System altered.
16:15:53 SQL> alter system switch logfile;
System altered.
16:16:10 SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
40
备库查询:
04:02:47 SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
32
04:02:49 SQL>
############################
第二次正常时的日志:
[oracle@ocm1 ~]$ tail -f alert_PROD.log
Sun Apr 20 16:18:21 2014
Thread 1 cannot allocate new log, sequence 42
Checkpoint not complete
Current log# 2 seq# 41 mem# 0: /u01/app/oracle/prod/disk1/redo02.log
Current log# 2 seq# 41 mem# 1: /u01/app/oracle/prod/disk2/log2b.log
Thread 1 advanced to log sequence 42
Current log# 3 seq# 42 mem# 0: /u01/app/oracle/prod/disk1/redo03.log
Current log# 3 seq# 42 mem# 1: /u01/app/oracle/prod/disk2/log3b.log
Sun Apr 20 16:19:08 2014
Thread 1 cannot allocate new log, sequence 43
Checkpoint not complete
Current log# 3 seq# 42 mem# 0: /u01/app/oracle/prod/disk1/redo03.log
Current log# 3 seq# 42 mem# 1: /u01/app/oracle/prod/disk2/log3b.log
Thread 1 advanced to log sequence 43
Current log# 1 seq# 43 mem# 0: /u01/app/oracle/prod/disk1/redo01.log
Current log# 1 seq# 43 mem# 1: /u01/app/oracle/prod/disk2/log1b.log
Sun Apr 20 16:20:41 2014
Expanded controlfile section 11 from 56 to 112 records
Requested to grow by 56 records; added 2 blocks of records
备库:
[oracle@ocm2 ~]$ tail -f alert_PROD1.log
Sun Apr 20 04:20:36 2014
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[8]: Assigned to RFS process 16069
RFS[8]: Identified database type as 'physical standby'
RFS[8]: Archived Log: '/u01/app/oracle/prod/arch/1_40_844894247.arc'
RFS[8]: Archived Log: '/u01/app/oracle/prod/arch/1_41_844894247.arc'
RFS[8]: Archived Log: '/u01/app/oracle/prod/arch/1_42_844894247.arc'
Sun Apr 20 04:20:37 2014
Media Recovery Log /u01/app/oracle/prod/arch/1_40_844894247.arc
Media Recovery Log /u01/app/oracle/prod/arch/1_41_844894247.arc
Media Recovery Log /u01/app/oracle/prod/arch/1_42_844894247.arc
Media Recovery Waiting for thread 1 sequence 43
更多详情见请继续阅读下一页的精彩内容:

이 기사는 Docker에서 MySQL 메모리 사용을 최적화합니다. 모니터링 기술 (Docker Stats, Performance Schema, 외부 도구) 및 구성 전략에 대해 설명합니다. 여기에는 Docker 메모리 제한, 스와핑 및 CGroups와 함께 포함됩니다

이 기사에서는 MySQL의 "공유 라이브러리를 열 수 없음"오류를 다룹니다. 이 문제는 MySQL이 필요한 공유 라이브러리 (.so/.dll 파일)를 찾을 수 없음에서 비롯됩니다. 솔루션은 시스템 패키지 M을 통한 라이브러리 설치 확인과 관련이 있습니다.

이 기사는 MySQL의 Alter Table 문을 사용하여 열 추가/드롭 테이블/열 변경 및 열 데이터 유형 변경을 포함하여 테이블을 수정하는 것에 대해 설명합니다.

이 기사는 Linux에 MySQL을 직접 설치하는 것과 Phpmyadmin이없는 Podman 컨테이너 사용을 비교합니다. 각 방법에 대한 설치 단계에 대해 자세히 설명하면서 Podman의 격리, 이식성 및 재현성의 장점을 강조하지만 또한

이 기사는 자체 포함 된 서버리스 관계형 데이터베이스 인 SQLITE에 대한 포괄적 인 개요를 제공합니다. SQLITE의 장점 (단순성, 이식성, 사용 용이성) 및 단점 (동시성 제한, 확장 성 문제)에 대해 자세히 설명합니다. 기음

이 안내서는 Homebrew를 사용하여 MacOS에 여러 MySQL 버전을 설치하고 관리하는 것을 보여줍니다. 홈 브루를 사용하여 설치를 분리하여 갈등을 방지하는 것을 강조합니다. 이 기사에는 설치, 서비스 시작/정지 서비스 및 Best Pra에 대해 자세히 설명합니다

기사는 인증서 생성 및 확인을 포함하여 MySQL에 대한 SSL/TLS 암호화 구성에 대해 설명합니다. 주요 문제는 자체 서명 인증서의 보안 영향을 사용하는 것입니다. [문자 수 : 159]

기사는 MySQL Workbench 및 Phpmyadmin과 같은 인기있는 MySQL GUI 도구에 대해 논의하여 초보자 및 고급 사용자를위한 기능과 적합성을 비교합니다. [159 자].


핫 AI 도구

Undresser.AI Undress
사실적인 누드 사진을 만들기 위한 AI 기반 앱

AI Clothes Remover
사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool
무료로 이미지를 벗다

Clothoff.io
AI 옷 제거제

AI Hentai Generator
AI Hentai를 무료로 생성하십시오.

인기 기사

뜨거운 도구

ZendStudio 13.5.1 맥
강력한 PHP 통합 개발 환경

Eclipse용 SAP NetWeaver 서버 어댑터
Eclipse를 SAP NetWeaver 애플리케이션 서버와 통합합니다.

에디트플러스 중국어 크랙 버전
작은 크기, 구문 강조, 코드 프롬프트 기능을 지원하지 않음

DVWA
DVWA(Damn Vulnerable Web App)는 매우 취약한 PHP/MySQL 웹 애플리케이션입니다. 주요 목표는 보안 전문가가 법적 환경에서 자신의 기술과 도구를 테스트하고, 웹 개발자가 웹 응용 프로그램 보안 프로세스를 더 잘 이해할 수 있도록 돕고, 교사/학생이 교실 환경 웹 응용 프로그램에서 가르치고 배울 수 있도록 돕는 것입니다. 보안. DVWA의 목표는 다양한 난이도의 간단하고 간단한 인터페이스를 통해 가장 일반적인 웹 취약점 중 일부를 연습하는 것입니다. 이 소프트웨어는

Atom Editor Mac 버전 다운로드
가장 인기 있는 오픈 소스 편집기
