데이터 베이스 MySQL 튜토리얼 聊聊RMAN的ARCHIVELOG DELETION参数

聊聊RMAN的ARCHIVELOG DELETION参数

Jun 07, 2016 pm 02:54 PM

RMAN是Oracle推出的官方备份还原工具。经过几个大版本的发展,RMAN已经支持多种备份介质和恢复策略的主要工具,也是业界普遍认可

RMAN是Oracle推出的官方备份还原工具。经过几个大版本的发展,RMAN已经支持多种备份介质和恢复策略的主要工具,也是业界普遍认可是Oracle备份还原官方策略。

Archivelog是Oracle备份还原策略的重要组成元素,不完全备份+连续的归档日志可以让我们将数据库恢复到发生故障点,实现数据的无损失恢复。但是,现实生活中archive log给没有经验的运维人员也带来了不少的问题,归档空间占满引起Hang住、瞬间归档日志过多生成引起问题等。一些前辈也在不断强调“归档模式不美好”。

在RMAN工作参数中,针对archive log,是可以设置专门的删除策略(Deletion)。在实践领域中,已经备份过或者确保安全传输的归档日志,其实就可以删除了,特别是在有限的Fast Recovery Area管理模式下。对于自动删除archive log的策略,比较常见的是applied to standby和shipped to standby,也就是Data Guard场景下。

本篇介绍简单的backed up参数使用情况,并通过一系列实验去研究该参数影响下Oracle和RMAN的工作行为特性。

1、基本参数和实验环境

笔者使用Oracle 11gR2进行测试,具体版本编号为11.2.0.4。

SQL> select * from v$version;

BANNER

--------------------------------------------------------------------------------

Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production

PL/SQL Release 11.2.0.3.0 - Production

CORE    11.2.0.3.0    Production

TNS for Linux: Version 11.2.0.3.0 - Production

NLSRTL Version 11.2.0.3.0 – Production

默认情况下,archivelog deletion policy参数为NONE。

RMAN> show all;     

RMAN configuration parameters for database with db_unique_name XXXXDB are:

CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default

(篇幅原因,有省略……)

CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default

该参数常见的集中取值如下:

configure archivelog deletion policy to backed up 2 times to sbt;

configure archivelog deletion policy to backed up 1 times to device type disk;

configure archivelog deletion policy to applied on standby;  --DG专用

configure archivelog deletion policy to shipped on standby;  --DG专用

configure archivelog deletion policy clear;

研究archivelog行为最好的工具视图是v$archived_log。很多DBA喜欢从操作系统层面删除归档日志,但是这种方式是不会直接被Oracle控制文件认可,所以建议使用RMAN或者官方工具来做。

--已归档未删除日志

SQL> select count(*) from v$archived_log where archived='YES' and deleted='NO';

COUNT(*)

----------

13

2、第一轮备份测试实验

首先我们修改archivelog deletion policy参数,设置为“两次备份后即可以删除”。

RMAN> configure archivelog deletion policy to backed up 2 times to device type disk;

new RMAN configuration parameters:

CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 2 TIMES TO DISK;

new RMAN configuration parameters are successfully stored

手工备份数据库和归档日志,不进行删除动作。

RMAN> backup database plus archivelog;

Starting backup at 21-SEP-15

current log archived

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=16 device type=DISK

channel ORA_DISK_1: starting archived log backup set

channel ORA_DISK_1: specifying archived log(s) in backup set

input archived log thread=1 sequence=100 RECID=12 STAMP=890690423

input archived log thread=1 sequence=101 RECID=13 STAMP=890712061

input archived log thread=1 sequence=102 RECID=14 STAMP=890727732

input archived log thread=1 sequence=103 RECID=15 STAMP=890776815

input archived log thread=1 sequence=104 RECID=16 STAMP=890776833

input archived log thread=1 sequence=105 RECID=17 STAMP=890805616

input archived log thread=1 sequence=106 RECID=18 STAMP=890814181

input archived log thread=1 sequence=107 RECID=19 STAMP=890820201

input archived log thread=1 sequence=108 RECID=20 STAMP=890859629

input archived log thread=1 sequence=109 RECID=21 STAMP=890892046

input archived log thread=1 sequence=110 RECID=22 STAMP=890900632

input archived log thread=1 sequence=111 RECID=23 STAMP=890906655

input archived log thread=1 sequence=112 RECID=24 STAMP=890942416

input archived log thread=1 sequence=113 RECID=25 STAMP=890990204

channel ORA_DISK_1: starting piece 1 at 21-SEP-15

channel ORA_DISK_1: finished piece 1 at 21-SEP-15

piece handle=/u01/app/oracle/fast_recovery_area/XXXXDB/backupset/2015_09_21/o1_mf_annnn_TAG20150921T091644_bzypmwty_.bkp tag=TAG20150921T091644 

(篇幅原因,省略部分……)

Finished Control File and SPFILE Autobackup at 21-SEP-15

此时,归档日志被备份,并且没有删除。

--多出来的两个是由于进行备份时候自动会有switch log

SQL> select count(*) from v$archived_log where archived='YES' and deleted='NO';

COUNT(*)

----------

15

下面进行第二次实验。

RMAN> backup database plus archivelog;

Starting backup at 21-SEP-15

current log archived

using channel ORA_DISK_1

channel ORA_DISK_1: starting archived log backup set

channel ORA_DISK_1: specifying archived log(s) in backup set

input archived log thread=1 sequence=100 RECID=12 STAMP=890690423

input archived log thread=1 sequence=101 RECID=13 STAMP=890712061

input archived log thread=1 sequence=102 RECID=14 STAMP=890727732

input archived log thread=1 sequence=103 RECID=15 STAMP=890776815

input archived log thread=1 sequence=104 RECID=16 STAMP=890776833

input archived log thread=1 sequence=105 RECID=17 STAMP=890805616

input archived log thread=1 sequence=106 RECID=18 STAMP=890814181

input archived log thread=1 sequence=107 RECID=19 STAMP=890820201

input archived log thread=1 sequence=108 RECID=20 STAMP=890859629

input archived log thread=1 sequence=109 RECID=21 STAMP=890892046

input archived log thread=1 sequence=110 RECID=22 STAMP=890900632

input archived log thread=1 sequence=111 RECID=23 STAMP=890906655

input archived log thread=1 sequence=112 RECID=24 STAMP=890942416

input archived log thread=1 sequence=113 RECID=25 STAMP=890990204

input archived log thread=1 sequence=114 RECID=26 STAMP=890990263

input archived log thread=1 sequence=115 RECID=27 STAMP=890990391

channel ORA_DISK_1: starting piece 1 at 21-SEP-15

channel ORA_DISK_1: finished piece 1 at 21-SEP-15

piece handle=/u01/app/oracle/fast_recovery_area/XXXXDB/backupset/2015_09_21/o1_mf_annnn_TAG20150921T091951_bzypsqj3_.bkp tag=TAG20150921T091951 

(篇幅原因,有省略……)

Finished Control File and SPFILE Autobackup at 21-SEP-15

第二次备份,之前备份过的日志还出现在自动备份的列表中。但是,在第二次备份的时候,已经备份过两次(deletion policy)的日志并没有自动删除。

SQL> select count(*) from v$archived_log where archived='YES' and deleted='NO';

COUNT(*)

----------

17

归档日志还在fast recovery area中。

[oracle@Databaseintrawebpro fast_recovery_area]$ du -h

19M    ./XXXXDB/autobackup/2015_09_21

9.4M    ./XXXXDB/autobackup/2015_09_17

29M    ./XXXXDB/autobackup

151M    ./XXXXDB/onlinelog

6.0G    ./XXXXDB/backupset/2015_09_21

108K    ./XXXXDB/backupset/2015_09_17

6.0G    ./XXXXDB/backupset

125M    ./XXXXDB/archivelog/2015_09_19

27M    ./XXXXDB/archivelog/2015_09_21

4.0K    ./XXXXDB/archivelog/2015_09_15

127M    ./XXXXDB/archivelog/2015_09_18

121M    ./XXXXDB/archivelog/2015_09_20

4.0K    ./XXXXDB/archivelog/2015_09_16

32M    ./XXXXDB/archivelog/2015_09_17

431M    ./XXXXDB/archivelog

9.4M    ./XXXXDB/controlfile

6.6G    ./XXXXDB

6.6G    .

此时,归档日志和备份次数,在v$archived_log中可以方便的找出来。

SQL> alter system switch logfile;

System altered

SQL> select count(*) from v$archived_log where archived='YES' and deleted='NO';

COUNT(*)

----------

18

--注意这些已经备份过两次的recid编号

SQL> select recid, sequence#, archived, deleted, backup_count from v$archived_log where backup_count>1;

RECID  SEQUENCE# ARCHIVED DELETED BACKUP_COUNT

---------- ---------- -------- ------- ------------

12        100 YES      NO                2

13        101 YES      NO                2

14        102 YES      NO                2

15        103 YES      NO                2

16        104 YES      NO                2

17        105 YES      NO                2

18        106 YES      NO                2

19        107 YES      NO                2

20        108 YES      NO                2

21        109 YES      NO                2

22        110 YES      NO                2

23        111 YES      NO                2

24        112 YES      NO                2

25        113 YES      NO                2

26        114 YES      NO                2

15 rows selected

进行第三次备份。

RMAN> backup database plus archivelog;

Starting backup at 21-SEP-15

current log archived

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=498 device type=DISK

skipping archived logs of thread 1 from sequence 100 to 114; already backed up

channel ORA_DISK_1: starting archived log backup set

channel ORA_DISK_1: specifying archived log(s) in backup set

input archived log thread=1 sequence=115 RECID=27 STAMP=890990391

input archived log thread=1 sequence=116 RECID=28 STAMP=890990481

input archived log thread=1 sequence=117 RECID=29 STAMP=890990667

input archived log thread=1 sequence=118 RECID=30 STAMP=890993128

channel ORA_DISK_1: starting piece 1 at 21-SEP-15

channel ORA_DISK_1: finished piece 1 at 21-SEP-15

piece 

(篇幅原因,有省略…….)

Finished Control File and SPFILE Autobackup at 21-SEP-15

注意:备份过两次的日志,没有出现在RMAN自动备份的列表中。这里我们定义到了删除策略的一个行为:当满足删除条件的时候,归档日志是不会进入备份集合列表的。

归档日志信息:

SQL> select recid, sequence#, archived, deleted, backup_count from v$archived_log where backup_count>1;

RECID  SEQUENCE# ARCHIVED DELETED BACKUP_COUNT

---------- ---------- -------- ------- ------------

12        100 YES      YES                2

13        101 YES      YES                2

14        102 YES      YES                2

15        103 YES      YES                2

16        104 YES      YES                2

17        105 YES      YES                2

18        106 YES      YES                2

19        107 YES      YES                2

20        108 YES      YES                2

21        109 YES      YES                2

22        110 YES      YES                2

23        111 YES      YES                2

24        112 YES      YES                2

25        113 YES      YES                2

26        114 YES      NO                2

27        115 YES      NO                2

28        116 YES      NO                2

17 rows selected

注意:一部分归档日志被删除,但是并没有所有上次备份过两次的日志都删除掉了,比如recid=26的日志。此时,备份fast recovery area空间情况发生了变化。

[oracle@Databaseintrawebpro fast_recovery_area]$ du -h

29M    ./XXXXDB/autobackup/2015_09_21

4.0K    ./XXXXDB/autobackup/2015_09_17

29M    ./XXXXDB/autobackup

151M    ./XXXXDB/onlinelog

5.5G    ./XXXXDB/backupset/2015_09_21

4.0K    ./XXXXDB/backupset/2015_09_17

5.5G    ./XXXXDB/backupset

4.0K    ./XXXXDB/archivelog/2015_09_19

2.5M    ./XXXXDB/archivelog/2015_09_21

4.0K    ./XXXXDB/archivelog/2015_09_15

4.0K    ./XXXXDB/archivelog/2015_09_18

4.0K    ./XXXXDB/archivelog/2015_09_20

4.0K    ./XXXXDB/archivelog/2015_09_16

4.0K    ./XXXXDB/archivelog/2015_09_17

2.6M    ./XXXXDB/archivelog

9.4M    ./XXXXDB/controlfile

5.7G    ./XXXXDB

5.7G    .

在alert log中,我们看到了Oracle自动删除的动作。

Mon Sep 21 09:24:27 2015

Expanded controlfile section 11 from 28 to 56 records

Requested to grow by 28 records; added 1 blocks of records

Archived Log entry 29 added for thread 1 sequence 117 ID 0x774e158c dest 1:

Mon Sep 21 10:05:28 2015

ALTER SYSTEM ARCHIVE LOG

Mon Sep 21 10:05:28 2015

Thread 1 advanced to log sequence 119 (LGWR switch)

Current log# 2 seq# 119 mem# 0: /u01/app/oracle/oradata/XXXXDB/onlinelog/o1_mf_2_bxzzjj5w_.log

Current log# 2 seq# 119 mem# 1: /u01/app/oracle/fast_recovery_area/XXXXDB/onlinelog/o1_mf_2_bxzzjj80_.log

Archived Log entry 30 added for thread 1 sequence 118 ID 0x774e158c dest 1:

Mon Sep 21 10:05:47 2015

Deleted Oracle managed file /u01/app/oracle/fast_recovery_area/XXXXDB/backupset/2015_09_17/o1_mf_annnn_TAG20150917T195557_bzoblfck_.bkp

Deleted Oracle managed file /u01/app/oracle/fast_recovery_area/XXXXDB/archivelog/2015_09_17/o1_mf_1_100_bzokvqj0_.arc

Deleted Oracle managed file /u01/app/oracle/fast_recovery_area/XXXXDB/autobackup/2015_09_17/o1_mf_s_890682958_bzoblglw_.bkp

Deleted Oracle managed file /u01/app/oracle/fast_recovery_area/XXXXDB/archivelog/2015_09_18/o1_mf_1_101_bzp6zx31_.arc

Deleted Oracle managed file /u01/app/oracle/fast_recovery_area/XXXXDB/archivelog/2015_09_18/o1_mf_1_102_bzpp9nln_.arc

Deleted Oracle managed file /u01/app/oracle/fast_recovery_area/XXXXDB/archivelog/2015_09_18/o1_mf_1_103_bzr67h1h_.arc

Deleted Oracle managed file /u01/app/oracle/fast_recovery_area/XXXXDB/archivelog/2015_09_18/o1_mf_1_104_bzr6812s_.arc

Deleted Oracle managed file /u01/app/oracle/fast_recovery_area/XXXXDB/archivelog/2015_09_19/o1_mf_1_105_bzs2cj5y_.arc

Deleted Oracle managed file /u01/app/oracle/fast_recovery_area/XXXXDB/archivelog/2015_09_19/o1_mf_1_106_bzsbq54p_.arc

Deleted Oracle managed file /u01/app/oracle/fast_recovery_area/XXXXDB/archivelog/2015_09_19/o1_mf_1_107_bzsjm99v_.arc

Deleted Oracle managed file /u01/app/oracle/fast_recovery_area/XXXXDB/archivelog/2015_09_19/o1_mf_1_108_bztq3f2v_.arc

Deleted Oracle managed file /u01/app/oracle/fast_recovery_area/XXXXDB/archivelog/2015_09_20/o1_mf_1_109_bzvprgf1_.arc

Deleted Oracle managed file /u01/app/oracle/fast_recovery_area/XXXXDB/archivelog/2015_09_20/o1_mf_1_110_bzvz4rj7_.arc

Deleted Oracle managed file /u01/app/oracle/fast_recovery_area/XXXXDB/archivelog/2015_09_20/o1_mf_1_111_bzw50zmb_.arc

Deleted Oracle managed file /u01/app/oracle/fast_recovery_area/XXXXDB/archivelog/2015_09_20/o1_mf_1_112_bzx7yj9g_.arc

Deleted Oracle managed file /u01/app/oracle/fast_recovery_area/XXXXDB/archivelog/2015_09_21/o1_mf_1_113_bzypmw8c_.arc

Deleted Oracle managed file /u01/app/oracle/fast_recovery_area/XXXXDB/backupset/2015_09_21/o1_mf_annnn_TAG20150921T091644_bzypmwty_.bkp

Mon Sep 21 10:05:58 2015

Deleted Oracle managed file /u01/app/oracle/fast_recovery_area/XXXXDB/backupset/2015_09_21/o1_mf_nnndf_TAG20150921T091647_bzypn055_.bkp

Mon Sep 21 10:06:15 2015

ALTER SYSTEM ARCHIVE LOG

Mon Sep 21 10:06:15 2015

Thread 1 advanced to log sequence 120 (LGWR switch)

Current log# 3 seq# 120 mem# 0: /u01/app/oracle/oradata/XXXXDB/onlinelog/o1_mf_3_bxzzjl0z_.log

Current log# 3 seq# 120 mem# 1: /u01/app/oracle/fast_recovery_area/XXXXDB/onlinelog/o1_mf_3_bxzzjl35_.log

Archived Log entry 31 added for thread 1 sequence 119 ID 0x774e158c dest 1:

본 웹사이트의 성명
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.

핫 AI 도구

Undresser.AI Undress

Undresser.AI Undress

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

AI Clothes Remover

AI Clothes Remover

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

Undress AI Tool

Undress AI Tool

무료로 이미지를 벗다

Clothoff.io

Clothoff.io

AI 옷 제거제

Video Face Swap

Video Face Swap

완전히 무료인 AI 얼굴 교환 도구를 사용하여 모든 비디오의 얼굴을 쉽게 바꾸세요!

뜨거운 도구

메모장++7.3.1

메모장++7.3.1

사용하기 쉬운 무료 코드 편집기

SublimeText3 중국어 버전

SublimeText3 중국어 버전

중국어 버전, 사용하기 매우 쉽습니다.

스튜디오 13.0.1 보내기

스튜디오 13.0.1 보내기

강력한 PHP 통합 개발 환경

드림위버 CS6

드림위버 CS6

시각적 웹 개발 도구

SublimeText3 Mac 버전

SublimeText3 Mac 버전

신 수준의 코드 편집 소프트웨어(SublimeText3)

MySQL에서 인덱스를 사용하는 것보다 전체 테이블 스캔이 더 빠를 수 있습니까? MySQL에서 인덱스를 사용하는 것보다 전체 테이블 스캔이 더 빠를 수 있습니까? Apr 09, 2025 am 12:05 AM

전체 테이블 스캔은 MySQL에서 인덱스를 사용하는 것보다 빠를 수 있습니다. 특정 사례는 다음과 같습니다. 1) 데이터 볼륨은 작습니다. 2) 쿼리가 많은 양의 데이터를 반환 할 때; 3) 인덱스 열이 매우 선택적이지 않은 경우; 4) 복잡한 쿼리시. 쿼리 계획을 분석하고 인덱스 최적화, 과도한 인덱스를 피하고 정기적으로 테이블을 유지 관리하면 실제 응용 프로그램에서 최상의 선택을 할 수 있습니다.

InnoDB 전체 텍스트 검색 기능을 설명하십시오. InnoDB 전체 텍스트 검색 기능을 설명하십시오. Apr 02, 2025 pm 06:09 PM

InnoDB의 전체 텍스트 검색 기능은 매우 강력하여 데이터베이스 쿼리 효율성과 대량의 텍스트 데이터를 처리 할 수있는 능력을 크게 향상시킬 수 있습니다. 1) InnoDB는 기본 및 고급 검색 쿼리를 지원하는 역 색인화를 통해 전체 텍스트 검색을 구현합니다. 2) 매치 및 키워드를 사용하여 검색, 부울 모드 및 문구 검색을 지원합니다. 3) 최적화 방법에는 워드 세분화 기술 사용, 인덱스의 주기적 재건 및 캐시 크기 조정, 성능과 정확도를 향상시키는 것이 포함됩니다.

Windows 7에 MySQL을 설치할 수 있습니까? Windows 7에 MySQL을 설치할 수 있습니까? Apr 08, 2025 pm 03:21 PM

예, MySQL은 Windows 7에 설치 될 수 있으며 Microsoft는 Windows 7 지원을 중단했지만 MySQL은 여전히 ​​호환됩니다. 그러나 설치 프로세스 중에 다음 지점이 표시되어야합니다. Windows 용 MySQL 설치 프로그램을 다운로드하십시오. MySQL의 적절한 버전 (커뮤니티 또는 기업)을 선택하십시오. 설치 프로세스 중에 적절한 설치 디렉토리 및 문자를 선택하십시오. 루트 사용자 비밀번호를 설정하고 올바르게 유지하십시오. 테스트를 위해 데이터베이스에 연결하십시오. Windows 7의 호환성 및 보안 문제에 주목하고 지원되는 운영 체제로 업그레이드하는 것이 좋습니다.

InnoDB에서 클러스터 된 인덱스와 비 클러스터 된 인덱스 (2 차 지수)의 차이. InnoDB에서 클러스터 된 인덱스와 비 클러스터 된 인덱스 (2 차 지수)의 차이. Apr 02, 2025 pm 06:25 PM

클러스터 인덱스와 비 클러스터 인덱스의 차이점은 1. 클러스터 된 인덱스는 인덱스 구조에 데이터 행을 저장하며, 이는 기본 키 및 범위별로 쿼리에 적합합니다. 2. 클러스터되지 않은 인덱스는 인덱스 키 값과 포인터를 데이터 행으로 저장하며 비 예산 키 열 쿼리에 적합합니다.

MySQL : 쉽게 학습하기위한 간단한 개념 MySQL : 쉽게 학습하기위한 간단한 개념 Apr 10, 2025 am 09:29 AM

MySQL은 오픈 소스 관계형 데이터베이스 관리 시스템입니다. 1) 데이터베이스 및 테이블 작성 : CreateAbase 및 CreateTable 명령을 사용하십시오. 2) 기본 작업 : 삽입, 업데이트, 삭제 및 선택. 3) 고급 운영 : 가입, 하위 쿼리 및 거래 처리. 4) 디버깅 기술 : 확인, 데이터 유형 및 권한을 확인하십시오. 5) 최적화 제안 : 인덱스 사용, 선택을 피하고 거래를 사용하십시오.

다양한 유형의 MySQL 인덱스 (B-Tree, Hash, Full-Text, Spatial)를 설명하십시오. 다양한 유형의 MySQL 인덱스 (B-Tree, Hash, Full-Text, Spatial)를 설명하십시오. Apr 02, 2025 pm 07:05 PM

MySQL은 B-Tree, Hash, Full-Text 및 Spatial의 4 가지 인덱스 유형을 지원합니다. 1.B- 트리 색인은 동일한 값 검색, 범위 쿼리 및 정렬에 적합합니다. 2. 해시 인덱스는 동일한 값 검색에 적합하지만 범위 쿼리 및 정렬을 지원하지 않습니다. 3. 전체 텍스트 색인은 전체 텍스트 검색에 사용되며 다량의 텍스트 데이터를 처리하는 데 적합합니다. 4. 공간 지수는 지리 공간 데이터 쿼리에 사용되며 GIS 응용 프로그램에 적합합니다.

MySQL 사용자와 데이터베이스의 관계 MySQL 사용자와 데이터베이스의 관계 Apr 08, 2025 pm 07:15 PM

MySQL 데이터베이스에서 사용자와 데이터베이스 간의 관계는 권한과 테이블로 정의됩니다. 사용자는 데이터베이스에 액세스 할 수있는 사용자 이름과 비밀번호가 있습니다. 권한은 보조금 명령을 통해 부여되며 테이블은 Create Table 명령에 의해 생성됩니다. 사용자와 데이터베이스 간의 관계를 설정하려면 데이터베이스를 작성하고 사용자를 생성 한 다음 권한을 부여해야합니다.

MySQL과 Mariadb가 공존 할 수 있습니다 MySQL과 Mariadb가 공존 할 수 있습니다 Apr 08, 2025 pm 02:27 PM

MySQL 및 MariaDB는 공존 할 수 있지만주의해서 구성해야합니다. 열쇠는 각 데이터베이스에 다른 포트 번호와 데이터 디렉토리를 할당하고 메모리 할당 및 캐시 크기와 같은 매개 변수를 조정하는 것입니다. 연결 풀링, 애플리케이션 구성 및 버전 차이도 고려해야하며 함정을 피하기 위해 신중하게 테스트하고 계획해야합니다. 두 개의 데이터베이스를 동시에 실행하면 리소스가 제한되는 상황에서 성능 문제가 발생할 수 있습니다.

See all articles