DB 시스템 정보
OCI(Oracle Cloud Infrastructure)는 가상 머신에서 DB 시스템을 제공합니다.
가상 시스템에는 두 가지 유형의 데이터베이스 시스템(DB 시스템)이 있습니다.
- 단일 노드 DB 시스템: 1노드 DB 시스템은 하나의 가상 머신으로 구성됩니다.
- 다중 노드 RAC DB 시스템: 2노드 DB 시스템은 2개의 가상 머신으로 구성됩니다.
개발 또는 테스트 목적으로 DB 시스템을 프로비저닝해야 하는 경우 특수한 빠른 프로비저닝 단일 노드 DB 시스템을 사용할 수 있습니다.
DB 시스템을 생성할 때 해당 DB 시스템의 데이터베이스에 적용되는 Oracle AI Database 에디션 및 버전을 선택합니다. 선택한 에디션을 변경할 수 없습니다. 선택한 Oracle AI Database 에디션 및 버전에 따라 DB 시스템은 여러 PDB(플러거블 데이터베이스)를 지원할 수 있습니다. 선택한 Oracle AI Database 버전에 사용할 수 있는 최대 플러거블 및 컨테이너 데이터베이스(CDB) 수에 대한 자세한 내용은 다음 Oracle AI Database 라이선스 항목을 참조하십시오.
- Oracle Database 19c: Oracle AI Database 오퍼링별 허용되는 기능, 옵션, 관리 팩
DB 시스템에는 하나의 데이터베이스 홈이 하나만 있을 수 있고, 결국에는 단일 데이터베이스만 있을 수 있습니다. DB 시스템 데이터베이스는 로컬 스토리지 대신 OCI 블록 스토리지를 사용합니다. DB 시스템을 생성할 때 스토리지 크기를 지정하고 필요에 따라 언제든지 스토리지를 확장할 수 있습니다. 기존 DB 시스템의 CPU 코어 수를 변경하려면 해당 DB 시스템의 구성을 변경해야 합니다. 자세한 내용은 DB 시스템의 구성 변경을 참조하십시오.
주: 구성 변경 작업은 다중 노드 RAC DB 시스템에 대해 롤링 방식으로 수행되므로 데이터베이스 작동 중지 시간 없이 구성을 변경할 수 있습니다.
사용 가능한 구성 및 할당된 리소스를 결정하는 방법
DB 시스템을 생성할 때 DB 시스템에 할당된 리소스를 결정하는 구성을 선택합니다. DB 시스템을 생성한 후 새 처리 용량 요구사항에 맞게 구성을 변경할 수 있습니다. 사용 가능한 구성은 다음과 같습니다.
참고:
Oracle Base Database Service는 2026년 7월 31일부터 VM.Standard.x86 셰이프, Enterprise Edition - Extreme Performance(EE-EP) 소프트웨어 에디션 및 OCPU 종량제 서비스 SKU의 폐기를 발표했습니다. 기존 배포는 계속 실행되지만 새 프로비저닝 및 계약 갱신에 영향을 줍니다.
EE-EP 작업 로드에 대해 ECPU 측정항목을 사용하거나 Oracle Exadata Database Service on Exascale Infrastructure(ExaDB-XS)로 VM.BaseDB.x86으로의 이전을 계획합니다(해당하는 경우). 영향을 받는 SKU, 고객 영향 및 마이그레이션 지침에 대한 자세한 내용은 My Oracle Support Article KB921246을 참조하십시오.
가변 셰이프
유연한 구성을 통해 컴퓨트 리소스(인스턴스에 할당된 ECPU 또는 OCPU)를 사용자정의할 수 있습니다. 가변적 구성을 사용하여 인스턴스를 생성할 때 인스턴스에서 실행되는 작업 로드에 필요한 컴퓨트 리소스를 선택합니다. 이러한 유연성을 통해 워크로드에 맞는 인스턴스를 구축하여 성능을 최적화하고 비용을 최소화할 수 있습니다. 허용되는 메모리 양은 선택한 ECPU 또는 OCPU 수를 기준으로 하며, ECPU 또는 OCPU에 대한 메모리 비율은 구성에 따라 다릅니다.
Ampere, AMD 및 Intel 프로세서에서 유연한 구성을 사용할 수 있습니다. 다음 표에서는 사용 가능한 구성을 보여줍니다.
| 구성 | 컴퓨트 | 메모리 |
|---|---|---|
| VM.BaseDB.x86 | 최소값은 4개 ECPU이고 최대값은 256개 ECPU입니다. 4씩 증분해야 합니다. |
8GB - 4개 ECPU당 최소 메모리는 8GB이고 최대 메모리는 총 512GB입니다. |
| VM.Standard.x86 | 최소값은 4 ECPU이고 최대값은 252 ECPU입니다. 4씩 증분해야 합니다. |
8GB - 4개 ECPU당 최소 메모리는 8GB이고 최대 메모리는 총 504GB입니다. |
| 암페어 VM.Standard.A1. 가변 | 최소값은 1 OCPU이고 최대값은 57 OCPU입니다. | OCPU당 8GB 최소 메모리는 8GB이고 최대 메모리는 총 456GB입니다. |
| AMD VM.Standard.E5 가변 | 최소값은 1 OCPU이고 최대값은 64 OCPU입니다. | OCPU당 16GB. 최소 메모리는 16GB이고 최대 메모리는 총 1024GB입니다. |
| AMD VM.Standard.E4 가변 | 최소값은 1 OCPU이고 최대값은 64 OCPU입니다. | OCPU당 16GB. 최소 메모리는 16GB이고 최대 메모리는 총 1024GB입니다. |
| Intel X9 VM.Standard3입니다. 가변 | 최소값은 1 OCPU이고 최대값은 32 OCPU입니다. | OCPU당 16GB. 최소 메모리는 16GB이고 최대 메모리는 총 512GB입니다. |
참고:
- Arm 기반 Ampere A1 구성은 23.7.0.0, 19.19.0.0 및 이후 릴리스 업데이트(RU)부터 Oracle AI Database 버전 26ai 및 19c에 대해서만 사용할 수 있습니다.
- AMD E5 구성은 23.4.0.24.05, 19.21.0.0 및 이후 릴리스 업데이트(RU)부터 Oracle AI Database 버전 26ai 및 19c에 대해서만 사용할 수 있습니다.
- AMD E4 구성은 23.4.0.24.05, 21.6.0.0, 19.15.0.0 및 RU(릴리스 업데이트)가 포함된 Oracle AI Database 버전 26ai, 21c 및 19c에서만 사용할 수 있습니다.
- Intel X9 구성은 23.4.0.24.05, 21.8.0.0, 19.17.0.0 및 이후 RU(릴리스 업데이트)가 포함된 Oracle AI Database 버전 26ai, 21c 및 19c에서만 사용할 수 있습니다.
- 다중 노드 RAC DB 시스템에는 노드당 최소 2개의 OCPU가 필요합니다.
세대 예측형 X86 구성
VM.BaseDB.x86 구성 및 VM.Standard.x86 구성은 DB 시스템에 할당된 ECPU 수를 사용자정의할 수 있는 생성에 구애받지 않고 유연한 x86 구성입니다. 이러한 구성은 지원되는 x86 인프라 세대에 걸쳐 일관된 경험을 제공하는 동시에 워크로드 요구사항에 따라 컴퓨트 리소스를 확장할 수 있습니다.
x86 구성에는 다음과 같은 특성이 있습니다.
- ECPU 기반 청구를 사용하여 보다 세분화된 사용량 기반 가격을 제공합니다.
- VM.BaseDB.x86은 Oracle AI Database 26ai 및 Oracle Database 19c를 지원합니다.
- VM.Standard.x86은 Oracle AI Database 26ai만 지원합니다.
-
다음과 같은 Oracle AI Database 소프트웨어 에디션을 지원합니다.
- Standard Edition
- Enterprise Edition
- Enterprise Edition - 고성능
- 스토리지 관리를 위해 Logical Volume Manager를 지원합니다.
- 단일 노드 DB 시스템만 지원합니다.
주: x86 구성은 결함 도메인을 지원하지 않습니다.
팔 근거한 암페어 A1 모양
Arm 기반 Ampere A1 구성은 유연하며 인스턴스에 할당된 OCPU 수를 사용자정의할 수 있게 해줍니다. 다음은 Ampere A1 구성에 대한 몇 가지 추가 세부 사항입니다.
- Ampere A1 구성은 Logical Volume Manager에서만 지원됩니다.
- Ampere A1 구성은 단일 노드 DB 시스템에서만 지원됩니다.
- Oracle AI Database Standard Edition은 Ampere A1 구성 기반 DB 시스템에서 지원되지 않습니다.
- 데이터베이스 소프트웨어 이미지는 Ampere A1 구성 기반 DB 시스템에서 데이터베이스를 생성하는 데 사용할 수 없습니다.
- 데이터베이스의 백업 대상이 자율운영 복구 서비스인 경우 Ampere A1 구성 기반 DB 시스템 프로비저닝 및 복원은 지원되지 않습니다.
- OCI 저장소 암호화를 사용하는 데이터베이스에는 Ampere A1 구성이 지원되지 않습니다.
- Ampere A1 구성 기반 DB 시스템의 구성은 Intel 또는 AMD 구성 기반 DB 시스템으로 변경할 수 없으며 그 반대의 경우도 마찬가지입니다.
- Ampere A1 구성 기반 데이터베이스의 백업은 Intel 또는 AMD 구성 기반 DB 시스템에서 복원할 수 없으며 그 반대의 경우도 마찬가지입니다.
- Ampere A1 구성 기반 DB 시스템은 Intel 또는 AMD 구성 기반 DB 시스템과의 Data Guard 연관을 지원하지 않습니다.
표준 구성
표준 구성은 Intel 프로세서에서 사용할 수 있습니다.
다음 표는 X7 시리즈에서 사용 가능한 구성을 보여줍니다.
| 구성 | CPU 코어 | 메모리 |
|---|---|---|
| VM.Standard2.1 | 1 | 15 GB |
| VM.Standard2.2 | 2 | 30 GB |
| VM.Standard2.4 | 4 | 60 GB |
| VM.Standard2.8 | 8 | 120 GB |
| VM.Standard2.16 | 16 | 240 GB |
| VM.Standard2.24 | 24 | 320 GB |
참고:
- Intel X7 구성은 Oracle AI Database 버전 26ai, 21c 및 19c에서만 사용할 수 있습니다.
- VM.Standard2.1 구성은 다중 노드 RAC DB 시스템에 사용할 수 없습니다.
사용 가능한 데이터베이스 버전
OCI는 다음과 같은 구성 요구 사항에 따라 이전 데이터베이스 버전을 사용한 DB 시스템 생성을 지원합니다.
승인된 최신 릴리즈 업데이트는 기본적으로 제공됩니다. 표시된 메시지를 확인한 후 앞의 두 릴리스 업데이트(N-1 또는 N-2) 중 하나를 선택할 수도 있습니다. N-2보다 오래된 릴리스 업데이트를 사용하려면 서비스 요청을 제출해야 합니다.
- Arm 기반 Ampere A1 구성은 23.7.0.0, 19.19.0.0 및 이후 릴리스 업데이트(RU)부터 Oracle AI Database 버전 26ai 및 19c에 대해서만 사용할 수 있습니다.
- AMD E5 구성은 23.4.0.24.05, 19.21.0.0 및 이후 릴리스 업데이트(RU)부터 Oracle AI Database 버전 26ai 및 19c에 대해서만 사용할 수 있습니다.
- AMD E4 구성은 23.4.0.24.05, 21.6.0.0, 19.15.0.0 및 RU(릴리스 업데이트)가 포함된 Oracle AI Database 버전 26ai, 21c 및 19c에서만 사용할 수 있습니다.
- Intel X9 구성은 23.4.0.24.05, 21.8.0.0, 19.17.0.0 및 이후 RU(릴리스 업데이트)가 포함된 Oracle AI Database 버전 26ai, 21c 및 19c에서만 사용할 수 있습니다.
- Intel X7 구성은 Oracle AI Database 버전 26ai, 21c 및 19c에서만 사용할 수 있습니다.
- Intel X9 구성에서 AMD E4 및 E5 구성으로의 마이그레이션은 지원되지 않습니다.
- AMD E4 구성으로의 마이그레이션은 21.6.0.0, 19.15.0.0 및 이후 릴리스 업데이트가 있는 기본 이미지를 사용하는 인스턴스에 대해서만 지원됩니다. 해당 릴리스 업데이트 이전에 생성된 인스턴스의 경우 기본 이미지 자체가 이전을 지원하지 않으므로 업데이트 및 이전이 불가능합니다.
- Intel X9 구성으로의 마이그레이션은 21.8.0.0, 19.17.0.0 및 이후 릴리스 업데이트가 있는 기본 이미지를 사용하는 인스턴스에 대해서만 지원됩니다. 해당 릴리스 업데이트 이전에 생성된 인스턴스의 경우 기본 이미지 자체가 이전을 지원하지 않으므로 업데이트 및 이전이 불가능합니다.
이전 데이터베이스 버전으로 DB 시스템을 생성해야 하는 경우 선택한 데이터베이스 버전의 알려진 보안 문제에 대한 자세한 내용은 Critical Patch Updates를 참조하십시오. 또한 이전 데이터베이스 버전에 포함된 운영 체제에 대해 알려진 보안 문제를 분석하고 패치를 적용해야 합니다. OCI의 데이터베이스에 대한 보안 모범 사례에 대한 자세한 내용은 데이터베이스 보안을 참조하십시오.
다양한 구성이 사용 가능한 스토리지에 미치는 영향
DB 시스템은 OCI 블록 스토리지를 사용합니다. 다음 표는 사용 가능한 스토리지 옵션의 세부 정보를 보여줍니다. 총 스토리지에는 사용 가능한 스토리지와 복구 로그가 포함됩니다.
일반 정보
- 데이터 스토리지와 복구 스토리지를 별도로 확장할 수 있습니다. Oracle은 전체 스토리지의 20% 이상으로 복구 스토리지를 유지할 것을 권장합니다.
- 다중 노드 RAC DB 시스템의 경우 노드 간에 스토리지 용량이 공유됩니다.
- Recovery Area 저장 영역은 선택한 저장 영역에 따라 결정됩니다. 그러나 프로비저닝 후 Recovery Area 저장 영역을 독립적으로 변경할 수 있습니다.
- 총 스토리지는 사용 가능한 데이터 스토리지, Recovery Area 스토리지 및 DB 시스템 소프트웨어용으로 예약된 200GB의 합계입니다.
유연한 구성을 위한 사용 가능한 데이터 스토리지
| 사용 가능한 데이터 스토리지(GB) | 복구 영역 스토리지(GB) | 총 스토리지(GB) |
|---|---|---|
| 256 | 256 | 712 |
| 512 | 256 | 968 |
| 1024 | 512 | 1736 |
| 2048 | 512 | 2760 |
| 4096 | 1024 | 5320 |
| 8192 | 2048 | 10440 |
| 12288 | 4096 | 16584 |
| 16384 | 4096 | 20680 |
| 24576 | 8192 | 32968 |
| 32768 | 8192 | 41160 |
| 40960 | 10240 | 51400 |
| 49152 | 12288 | 61640 |
| 57344 | 14336 | 71880 |
| 65536 | 16384 | 82120 |
| 73728 | 18432 | 92360 |
| 81920 | 20480 | 102600 |
표준 구성에 사용 가능한 데이터 스토리지
| 사용 가능한 데이터 스토리지(GB) | 복구 영역 스토리지(GB) | 총 스토리지(GB) |
|---|---|---|
| 256 | 256 | 712 |
| 512 | 256 | 968 |
| 1024 | 256 | 1480 |
| 2048 | 408 | 2656 |
| 4096 | 820 | 5116 |
| 6144 | 1228 | 7572 |
| 8192 | 1640 | 10032 |
| 10240 | 2048 | 12488 |
| 12288 | 2456 | 14944 |
| 14336 | 2868 | 17404 |
| 16384 | 3276 | 19860 |
| 18432 | 3688 | 22320 |
| 20480 | 4096 | 24776 |
| 22528 | 4504 | 27232 |
| 24576 | 4916 | 29692 |
| 26624 | 5324 | 32148 |
| 28672 | 5736 | 34608 |
| 30720 | 6144 | 37064 |
| 32768 | 6552 | 39520 |
| 34816 | 6964 | 41980 |
| 36864 | 7372 | 44436 |
| 38912 | 7784 | 46896 |
| 40960 | 8192 | 49352 |
서비스 제한
다음 제한이 기준 데이터베이스 리소스에 적용됩니다.
| 리소스 | Oracle Universal 크레딧 | Pay As You Go 또는 체험판 |
|---|---|---|
| 총 VM DB 블록 스토리지 | 150TB | 2TB |
| VM.Standard1 - 총 OCPU | 300 코어 | 2 코어 |
| VM.Standard2 - 총 OCPU | 미국 서부 코어 300개(피닉스), 미국 동부 코어 300개(애슈번), 독일 중부 코어 50개(프랑크푸르트), 영국 남부 코어 50개(런던) |
2 코어 |
주: 총 VM DB 블록 스토리지에는 모든 VM.Standard1 및 VM.Standard2 가상 머신 데이터베이스에 대한 블록 스토리지가 포함됩니다.
빠른 프로비저닝 옵션
단일 노드 DB 시스템의 경우 OCI는 스토리지 관리 소프트웨어로 LVM(논리적 볼륨 관리자)을 사용하여 DB 시스템을 생성할 수 있는 "빠른 프로비저닝" 옵션을 제공합니다. 표준 방식("표준 프로비저닝")은 자동 저장 영역 관리(ASM)를 사용하여 프로비저닝하는 것입니다.
다음 세부 사항은 빠른 프로비저닝 옵션에 적용됩니다.
- 빠른 프로비저닝 옵션을 사용하는 경우 프로비저닝 중에 지정된 블록 볼륨의 수와 크기에 따라 확장을 통해 사용할 수 있는 최대 총 스토리지가 결정됩니다.
- 다중 노드 RAC DB 시스템에는 ASM이 필요하며 빠른 프로비저닝 옵션을 사용하여 생성할 수 없습니다.
- 빠른 프로비저닝 옵션을 사용하여 생성된 DB 시스템을 복제할 수 있습니다.
- LVM으로 DB 시스템을 프로비전할 때는 사용자정의 데이터베이스 소프트웨어 이미지를 사용할 수 없습니다.
자세한 내용은 다음을 참조하십시오.
빠른 프로비저닝을 사용하는 동안 스토리지 확장 고려 사항
주: 이 항목은 단일 노드 DB 시스템에만 적용됩니다.
빠른 프로비저닝 옵션을 사용하여 DB 시스템을 프로비저닝하는 경우 프로비저닝 중에 지정한 사용 가능한 스토리지(GB) 값에 따라 스케일링을 통해 사용할 수 있는 최대 총 스토리지가 결정됩니다. 다음 표에서는 프로비저닝 워크플로우에서 제공되는 각 설정의 크기 조정을 통해 사용할 수 있는 최대 스토리지 값에 대해 자세히 설명합니다.
| 프로비전 중 지정된 초기 스토리지(GB) | 스케일링을 통해 사용 가능한 최대 스토리지(GB) |
|---|---|
| 256 | 2560 |
| 512 | 2560 |
| 1024 | 5120 |
| 2048 | 10240 |
| 4096 | 20480 |
| 8192 | 40960 |
다중 노드 RAC DB 시스템에 대한 결함 도메인 고려 사항
다중 노드 RAC DB 시스템을 프로비전할 때 시스템은 기본적으로 각 노드를 다른 결함 도메인에 지정합니다. 프로비저닝 대화 상자의 고급 옵션 링크를 사용하여 다중 노드 RAC DB 시스템에 사용할 결함 도메인을 선택할 수 있으며 시스템에서 선택된 결함 도메인에 노드를 지정합니다. Oracle은 다중 노드 RAC DB 시스템의 각 노드를 다른 결함 도메인에 배치할 것을 권장합니다.
장애 도메인에 대한 자세한 내용은 지역 및 가용성 도메인을 참조하십시오.
계획된 유지보수를 위해 DB 시스템 노드 재부트
DB 시스템 노드는 주기적으로 유지 관리를 수행해야 하는 기본 물리적 호스트를 사용합니다. 해당 유지보수가 필요한 경우 OCI는 DB 시스템 노드 재부팅 일정을 잡고 예정된 재부팅을 통지합니다. 재부팅하면 DB 시스템 노드를 유지 관리가 필요하지 않은 새 물리적 호스트로 마이그레이션할 수 있습니다. 노드를 중지하고 시작하면 새 물리적 호스트로 마이그레이션됩니다. DB 시스템 노드에는 재부팅 자체만 적용됩니다. 원래 물리적 하드웨어의 계획된 유지 관리는 노드가 새 호스트로 마이그레이션된 후 수행되며 DB 시스템에 영향을 주지 않습니다.
DB 시스템 노드가 유지보수 재부팅 일정이 잡혀 있는 경우 콘솔 또는 API를 사용하여 노드를 정지했다가 시작하여 사전에 재부팅할 수 있습니다. 이를 통해 노드의 작동 중지 시간이 발생하는 방법과 시기를 제어할 수 있습니다. 일정이 잡힌 시간 전에 재부팅하지 않도록 선택하면 OCI가 재부팅되고 일정이 잡힌 시간에 노드가 이전됩니다.
사전 재부트할 수 있는 DB 시스템 노드를 식별하려면 콘솔에서 시스템의 DB System Details 페이지로 이동하여 Node maintenance reboot 필드를 확인합니다. 인스턴스에 유지보수 재부팅 일정이 잡혀 있고 사전에 재부팅할 수 있는 경우 이 필드에는 재부팅에 대한 날짜 및 시작 시간이 표시됩니다. 유지 관리 재부트 필드에 날짜가 표시되지 않으면 DB 시스템에 일정이 잡힌 노드 유지 관리 이벤트가 없는 것입니다.
API를 사용하여 일정이 잡힌 유지보수 이벤트를 확인하려면 GetDbNode 작업을 사용하여 DbNode 리소스의 timeMaintenanceWindowEnd 필드를 확인하십시오. 이 필드는 시스템에서 다음 예약된 노드 재부트를 시작할 시기를 지정합니다.
유지보수 재부팅 일정이 잡힌 노드를 찾으려면 미리 정의된 질의와 함께 서비스 검색을 사용하여 일정이 잡힌 유지보수 재부팅이 있는 모든 DB 시스템을 찾을 수 있습니다.
콘솔을 사용하여 노드를 재부트하는 방법에 대한 자세한 내용은 Reboot a DB System을 참조하십시오.
DB 시스템용 보안 강화 툴
Oracle Linux 7을 사용하여 프로비저닝된 DB 시스템에는 DB 시스템에 대한 보안 강화를 수행하는 데 사용할 수 있는 STIG(Security Technical Implementation Guide) 도구라고 하는 Python 스크립트가 포함되어 있습니다.
자세한 내용은 다음을 참조하십시오.
- DB 시스템용 STIG(Security Technical Implementation Guide) 도구
- DB 시스템 구성요소에서 FIPS, SE Linux 및 STIG를 사용으로 설정합니다.
부트 볼륨 백업
Oracle은 심각한 오류 또는 시스템 오류 발생 시 시스템을 쉽게 복원할 수 있도록 DB 시스템의 주별 부트 볼륨 백업을 유지 관리합니다. 부트 볼륨 백업은 현재 사용자가 액세스할 수 없으며(DB 시스템 부트 볼륨 백업에 대한 콘솔, API 또는 CLI 액세스가 없음), Oracle은 백업 유지 및 유지 관리 비용을 부담합니다. 시스템 장애가 발생하는 경우 My Oracle Support에 문의하여 Oracle이 부팅 볼륨 백업에서 DB 시스템 복원을 수행하도록 요청하십시오.