# Amazon RDS for Microsoft SQL Server
Amazon RDS는 Microsoft SQL Server의 여러 버전 및 에디션을 지원합니다. 다음 테이블은 각 메이저 버전에서 지원되는 최신 마이너 버전을 보여 줍니다. 지원되는 버전, 에디션 및 RDS 엔진 버전의 전체 목록은 [Amazon RDS의 Microsoft SQL Server 버전](SQLServer.Concepts.General.VersionSupport.md) 섹션을 참조하십시오.
| 메이저 버전 | 서비스 팩/GDR | 누적 업데이트 | 마이너 버전 | 기술 자료 문서 | 릴리스 날짜 |
| --- | --- | --- | --- | --- | --- |
| SQL Server 2022 | 해당 사항 없음 | CU23 | 16.0.4236.2 | [KB5078297](https://learn.microsoft.com/en-us/troubleshoot/sql/releases/sqlserver-2022/cumulativeupdate23) | 2026년 1월 29일 |
| SQL Server 2019 | GDR | CU32 GDR | 15.0.4455.2 | [KB5068404](https://support.microsoft.com/en-us/topic/kb5068404-description-of-the-security-update-for-sql-server-2019-cu32-november-11-2025-c203bfbf-036e-46d2-bc10-6c01200dc48a) | 2025년 11월 11일 |
| SQL Server 2017 | GDR | CU31 GDR | 14.0.3515.1 | [KB5068402](https://support.microsoft.com/en-us/topic/kb5068402-description-of-the-security-update-for-sql-server-2017-cu31-november-11-2025-1be08efe-ad14-4b95-a0de-ecbbf2703114) | 2025년 11월 11일 |
| SQL Server 2016 | SP3 GDR | 해당 사항 없음 | 13.0.6475.1 | [KB5068401](https://support.microsoft.com/en-us/topic/kb5068401-description-of-the-security-update-for-sql-server-2016-sp3-gdr-november-11-2025-59a59fc0-f673-45c2-b8de-492b95c0e423) | 2025년 11월 11일 |
SQL Server 라이선스에 대한 자세한 내용은 [Amazon RDS의 Microsoft SQL Server 라이선싱](SQLServer.Concepts.General.Licensing.md) 섹션을 참조하십시오. SQL Server 빌드에 대한 자세한 내용은 [최신 SQL Server 빌드에 대한 정보를 찾을 수 있는 위치](https://support.microsoft.com/en-us/topic/kb957826-where-to-find-information-about-the-latest-sql-server-builds-43994ba5-9aed-2323-ea7c-d29fe9c4fbe8)에 대한 Microsoft 지원 문서를 참조하세요.
Amazon RDS를 통해 DB 인스턴스 및 DB 스냅샷, 특정 시점으로 복구 및 자동 또는 수동 백업을 만들 수 있습니다. SQL Server를 실행 중인 DB 인스턴스를 VPC 내에서 사용할 수 있습니다. 보안 소켓 계층(SSL)을 사용하여 SQL 서버를 실행하는 DB 인스턴스에 연결할 수도 있고 투명 데이터 암호화(TDE)를 사용하여 유휴 데이터를 암호화할 수도 있습니다. Amazon RDS는 현재 SQL Server 데이터베이스 미러링(DBM) 또는 상시 가용성 그룹(AG)을 고가용성의 장애 조치 솔루션으로 사용하여 SQL Server용 다중 AZ 배포를 지원합니다.
관리되는 서비스 환경을 제공하기 위해 Amazon RDS는 DB 인스턴스에 대해 셸 액세스를 제공하지 않으며, 고급 권한을 필요로 하는 특정 시스템 절차와 테이블에 대한 액세스를 제한합니다. Amazon RDS는 Microsoft SQL Server Management Studio와 같은 표준 SQL 클라이언트 애플리케이션을 사용하여 DB 인스턴스에서 데이터베이스에 대한 액세스를 지원합니다. Amazon RDS에서는 Telnet, SSH(Secure Shell) 또는 Windows 원격 데스크톱 연결을 통해 DB 인스턴스에 대한 직접 호스트 액세스를 허용하지 않습니다. DB 인스턴스를 생성할 때 마스터 사용자는 해당 인스턴스의 모든 사용자 데이터베이스에 대한 *db\$1owner* 역할을 할당받으며, 백업에 사용된 권한을 제외한 모든 데이터베이스 수준의 권한을 갖습니다. Amazon RDS는 백업을 관리합니다.
첫 번째 DB 인스턴스를 생성하기 전에 이 설명서의 설정 섹션에 나오는 단계를 완료해야 합니다. 자세한 내용은 [Amazon RDS 환경 설정](CHAP_SettingUp.md) 섹션을 참조하세요.
**Topics**
+ [Amazon RDS에서 Microsoft SQL Server에 대한 공통 관리 작업](#SQLServer.Concepts.General)
+ [Microsoft SQL Server DB 인스턴스의 한도](#SQLServer.Concepts.General.FeatureSupport.Limits)
+ [Microsoft SQL Server를 위한 DB 인스턴스 클래스 지원](SQLServer.Concepts.General.InstanceClasses.md)
+ [SQL Server 라이선스가 포함된 RDS 인스턴스의 CPU를 최적화합니다.](SQLServer.Concepts.General.OptimizeCPU.md)
+ [Microsoft SQL Server 보안](SQLServer.Concepts.General.FeatureSupport.UnsupportedRoles.md)
+ [Microsoft SQL Server DB 인스턴스에 대한 규정 준수 프로그램 지원](#SQLServer.Concepts.General.Compliance)
+ [Amazon RDS의 Microsoft SQL Server 버전](SQLServer.Concepts.General.VersionSupport.md)
+ [Amazon RDS의 Microsoft SQL Server 기능](SQLServer.Concepts.General.FeatureSupport.md)
+ [Microsoft SQL Server 데이터베이스 미러링 또는 상시 가동 가용성 그룹을 사용하여 다중 AZ 배포](#SQLServer.Concepts.General.Mirroring)
+ [Transparent Data Encryption을 사용하여 유휴 데이터 암호화](#SQLServer.Concepts.General.Options)
+ [Amazon RDS for Microsoft SQL Server에 대한 함수 및 저장 프로시저](SQLServer.Concepts.General.StoredProcedures.md)
+ [Microsoft SQL Server DB 인스턴스의 현지 시간대](SQLServer.Concepts.General.TimeZone.md)
+ [Amazon RDS의 Microsoft SQL Server 라이선싱](SQLServer.Concepts.General.Licensing.md)
+ [Microsoft SQL Server DB 인스턴스에 연결](USER_ConnectToMicrosoftSQLServerInstance.md)
+ [RDS for SQL Server에서 SQL Server Developer Edition 작업](sqlserver-dev-edition.md)
+ [RDS for SQL Server를 사용하여 Active Directory 작업](User.SQLServer.ActiveDirectoryWindowsAuth.md)
+ [Microsoft SQL Server DB 엔진 업그레이드](USER_UpgradeDBInstance.SQLServer.md)
+ [RDS for SQL Server에서 스토리지 작업](Appendix.SQLServer.CommonDBATasks.DatabaseStorage.md)
+ [기본 백업 및 복원 기능을 사용하여 SQL Server 데이터베이스 가져오기 및 내보내기](SQLServer.Procedural.Importing.md)
+ [Amazon RDS에서 Microsoft SQL Server용 읽기 전용 복제본 작업](SQLServer.ReadReplicas.md)
+ [Amazon RDS for Microsoft SQL Server의 다중 AZ 배포](USER_SQLServerMultiAZ.md)
+ [Amazon RDS의 Microsoft SQL Server 추가 기능](User.SQLServer.AdditionalFeatures.md)
+ [Microsoft SQL Server 데이터베이스 엔진의 옵션](Appendix.SQLServer.Options.md)
+ [Amazon RDS for Microsoft SQL Server에 대한 일반 DBA 작업](Appendix.SQLServer.CommonDBATasks.md)
## Amazon RDS에서 Microsoft SQL Server에 대한 공통 관리 작업
다음은 Amazon RDS for SQL Server DB 인스턴스로 수행하는 일반적인 관리 작업과 각 작업에 해당하는 문서 링크입니다.
****
| 작업 영역 | 설명 | 관련 설명서 |
| --- | --- | --- |
| **인스턴스 클래스, 스토리지 및 PIOPS** | 프로덕션 목적으로 DB 인스턴스를 만들 경우에는 Amazon RDS에서 인스턴스 클래스, 스토리지 유형 및 프로비저닝된 IOPS이 작동하는 방식을 이해해야 합니다. | [Microsoft SQL Server를 위한 DB 인스턴스 클래스 지원](SQLServer.Concepts.General.InstanceClasses.md) [Amazon RDS 스토리지 유형](CHAP_Storage.md#Concepts.Storage) |
| **다중 AZ 배포** | 프로덕션 DB 인스턴스에서는 다중 AZ 배포를 사용해야 합니다. 다중 AZ 배포는 DB 인스턴스를 위해 향상된 가용성, 데이터 내구성 및 내결함성을 제공합니다. SQL Server용 다중 AZ 배포는 SQL Server의 기본 DBM 또는 AG 기술을 사용하여 구현됩니다. | [Amazon RDS에 대한 다중 AZ 배포 구성 및 관리](Concepts.MultiAZ.md) [Microsoft SQL Server 데이터베이스 미러링 또는 상시 가동 가용성 그룹을 사용하여 다중 AZ 배포](#SQLServer.Concepts.General.Mirroring) |
| **Amazon Virtual Private Cloud(VPC)** | AWS 계정에 기본 VPC가 있는 경우에는 DB 인스턴스가 기본 VPC 내부에 자동으로 생성됩니다. 계정에 기본 VPC가 없는데 VPC 안에 DB 인스턴스를 만들려면 VPC와 서브넷 그룹을 만든 후 DB 인스턴스를 만들어야 합니다. | [VPC에서 DB 인스턴스를 사용한 작업](USER_VPC.WorkingWithRDSInstanceinaVPC.md) |
| **보안 그룹** | 기본적으로, DB 인스턴스와 함께 인스턴스에 대한 액세스를 막는 방화벽도 생성됩니다. 따라서 DB 인스턴스에 액세스하기 위한 알맞은 IP 주소와 네트워크 구성으로 보안 그룹을 만들어야 합니다. | [보안 그룹을 통한 액세스 제어](Overview.RDSSecurityGroups.md) |
| **파라미터 그룹** | DB 인스턴스에 특정 데이터베이스 파라미터가 필요할 경우, 파라미터 그룹을 만든 후 DB 인스턴스를 만들어야 합니다. | [Amazon RDS의 파라미터 그룹](USER_WorkingWithParamGroups.md) |
| **옵션 그룹 수** | DB 인스턴스에 특정 데이터베이스 옵션이 필요할 경우, 옵션 그룹을 만든 후 DB 인스턴스를 만들어야 합니다. | [Microsoft SQL Server 데이터베이스 엔진의 옵션](Appendix.SQLServer.Options.md) |
| **DB 인스턴스에 연결** | 보안 그룹을 만들고 이를 DB 인스턴스에 연결한 후, Microsoft SQL Server Management Studio와 같은 표준 SQL 클라이언트 애플리케이션을 사용하여 DB 인스턴스에 연결할 수 있습니다. | [Microsoft SQL Server DB 인스턴스에 연결](USER_ConnectToMicrosoftSQLServerInstance.md) |
| **백업 및 복원** | DB 인스턴스를 생성할 때 자동 백업을 하도록 구성할 수 있습니다. 또한 전체 백업 파일(.bak 파일)을 사용하여 데이터베이스를 수동으로 백업 및 복원할 수도 있습니다. | [백업 소개](USER_WorkingWithAutomatedBackups.md) [기본 백업 및 복원 기능을 사용하여 SQL Server 데이터베이스 가져오기 및 내보내기](SQLServer.Procedural.Importing.md) |
| **모니터링** | CloudWatch Amazon RDS 측정치, 이벤트 및 향상된 모니터링 기능을 통해 SQL Server DB 인스턴스를 모니터링할 수 있습니다. | [Amazon RDS 콘솔에서 지표 보기](USER_Monitoring.md) [Amazon RDS 이벤트 보기](USER_ListEvents.md) |
| **로그 파일** | SQL Server DB 인스턴스의 로그 파일에 액세스할 수 있습니다. | [Amazon RDS 로그 파일 모니터링](USER_LogAccess.md) [Amazon RDS for Microsoft SQL Server 데이터베이스 로그 파일](USER_LogAccess.Concepts.SQLServer.md) |
SQL Server DB 인스턴스 작업을 위한 고급 관리 작업도 있습니다. 자세한 내용은 다음 설명서를 참조하세요.
+ [Amazon RDS for Microsoft SQL Server에 대한 일반 DBA 작업](Appendix.SQLServer.CommonDBATasks.md).
+ [RDS for SQL Server를 사용하여 AWS 관리형 Active Directory 작업](USER_SQLServerWinAuth.md)
+ [tempdb 데이터베이스에 액세스](SQLServer.TempDB.md)
## Microsoft SQL Server DB 인스턴스의 한도
DB 인스턴스에서 Amazon RDS의 Microsoft SQL Server를 구현하려면 다음과 같은 몇 가지 제한 사항을 정확히 파악하고 있어야 합니다.
+ DB 인스턴스에 지원되는 최대 데이터베이스 수는 인스턴스 클래스 유형과 가용성 모드—단일 AZ, 다중 AZ 데이터베이스 미러링(DBM) 또는 다중 AZ 가용성 그룹(AG)에 따라 다릅니다. Microsoft SQL Server 시스템 데이터베이스는 이 제한에 포함되지 않습니다.
다음 표는 각 인스턴스 클래스 유형 및 가용성 모드에 대해 지원되는 최대 데이터베이스 수를 보여 줍니다. 이 표를 사용하면 하나의 인스턴스 클래스 유형에서 다른 유형으로 또는 한 가용성 모드에서 다른 모드로 이동할 수 있는지 알 수 있습니다. 원본 DB 인스턴스에 대상 인스턴스 클래스 유형이나 가용성 모드에서 지원할 수 있는 것보다 많은 데이터베이스가 있으면 DB 인스턴스 수정에 실패합니다. **이벤트** 창에서 요청 상태를 확인할 수 있습니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html)
\$1서로 다른 인스턴스 클래스 유형을 나타냅니다.
예를 들어 DB 인스턴스가 단일 AZ를 사용한 db.\$1.16xlarge에서 실행되고 76개의 데이터베이스가 있다고 가정해봅시다. 다중 AZ 상시 가동 AG를 사용하여 업그레이드할 DB 인스턴스를 수정합니다. DB 인스턴스에 대상 구성에서 지원할 수 있는 것보다 많은 데이터베이스가 포함되어 있으므로 이 업그레이드는 실패합니다. 대신 인스턴스 클래스 유형을 db.\$1.24xlarge로 업그레이드하면 수정이 완료됩니다.
업그레이드에 실패하면 다음과 유사한 이벤트 및 메시지가 표시됩니다.
+ 데이터베이스 인스턴스 클래스를 수정할 수 없습니다. 인스턴스에는 76개의 데이터베이스가 있지만 변환 후에는 75개만 지원됩니다.
+ DB 인스턴스를 다중 AZ로 변환할 수 없습니다. 인스턴스에 76개의 데이터베이스가 있지만 변환 후에는 75개만 지원합니다.
특정 시점으로 복구 또는 스냅샷 복원에 실패하면 다음과 유사한 이벤트 및 메시지가 표시됩니다.
+ 데이터베이스 인스턴스가 복원 호환 장애 상태로 전환됩니다. 인스턴스에는 76개의 데이터베이스가 있지만 변환 후에는 75개만 지원됩니다.
+ 다음 포트는 Amazon RDS용으로 예약되어 있고 DB 인스턴스 `1234, 1434, 3260, 3343, 3389, 47001,` 및 `49152-49156`을 생성할 때 사용할 수 없습니다.
+ 169.254.0.0/16 범위의 IP 주소에서 클라이언트 연결은 허용되지 않습니다. 이는 로컬 링크 주소 지정에 사용되는 APIPA(Automatic Private IP Addressing) 범위입니다.
+ DB 인스턴스에 소프트웨어 제한(24코어, 4소켓 및 128GB RAM)보다 많은 프로세서가 있는 경우 SQL Server Standard Edition은 사용 가능한 프로세서의 하위 집합만 사용합니다. 이러한 예로는 db.m5.24xlarge 및 db.r5.24xlarge 인스턴스 클래스가 있습니다.
자세한 내용은 Microsoft 설명서의 [SQL Server 2019(15.x)의 버전과 지원하는 기능](https://docs.microsoft.com/en-us/sql/sql-server/editions-and-components-of-sql-server-version-15)에서 확장 제한 표를 참조하세요.
+ Amazon RDS for SQL Server는 msdb 데이터베이스로 데이터 가져오기를 지원하지 않습니다.
+ SQL Server 다중 AZ 배포의 DB 인스턴스에 있는 데이터베이스의 이름은 바꿀 수 없습니다.
+ RDS for SQL Server에서 다음 DB 파라미터를 설정할 때 다음 지침을 따라야 합니다.
+ `max server memory (mb)` >= 256MB
+ `max worker threads` >= (논리적 CPU 수 \$1 7)
DB 파라미터 설정에 대한 자세한 내용은 [Amazon RDS의 파라미터 그룹](USER_WorkingWithParamGroups.md) 섹션을 참조하세요.
+ SQL Server DB 인스턴스를 위한 최대 스토리지 크기는 다음과 같습니다.
+ 범용(SSD) 스토리지 – 모든 에디션에서 16TiB
+ 프로비저닝된 IOPS 스토리지 – 모든 에디션에서 64TiB
+ 마그네틱 스토리지 – 모든 에디션에서 1TiB
대량의 스토리지가 필요한 상황에서는 여러 DB 인스턴스에서 샤딩을 사용하여 이 제한을 우회할 수 있습니다. 이 접근 방식에서는 샤딩된 시스템에 연결하는 애플리케이션에 데이터 종속적인 라우팅 논리가 필요합니다. 기존 샤딩 프레임워크를 사용하거나 샤딩을 활성화하는 사용자 지정 코드를 작성할 수 있습니다. 기존 프레임워크를 사용하는 경우, 이 프레임워크는 DB 인스턴스와 같은 서버에 어떤 구성 요소도 설치할 수 없습니다.
+ SQL Server DB 인스턴스를 위한 최소 스토리지 크기는 다음과 같습니다.
+ 범용(SSD) 스토리지 – Enterprise, Standard, Web 및 Express Edition의 경우 20GiB
+ 프로비저닝된 IOPS 스토리지 – Enterprise, Standard, Web 및 Express Edition의 경우 20GiB
+ 마그네틱 스토리지 – Enterprise, Standard, Web 및 Express Edition의 경우 20GiB
+ Amazon RDS는 RDS DB 인스턴스와 동일한 서버에서 이러한 서비스를 실행하는 것을 지원하지 않습니다.
+ 데이터 품질 서비스
+ 마스터 데이터 서비스
이러한 기능을 사용하려면 Amazon EC2 인스턴스에 SQL Server를 설치하거나 온프레미스 SQL Server 인스턴스를 사용하는 것이 좋습니다. 이러한 경우 EC2 또는 SQL Server 인스턴스는 Amazon RDS에서 SQL Server DB 인스턴스의 마스터 데이터 서비스 서버 역할을 합니다. Microsoft 라이선싱 정책에 따라 SQL Server를 Amazon EBS 스토리지가 포함된 Amazon EC2 인스턴스에 설치할 수 있습니다.
+ Microsoft SQL Server의 제한 사항 때문에, `DROP DATABASE`의 성공적인 실행 이전의 시점으로 복원해도 해당 시점에서 해당 데이터베이스의 상태가 반영되지 않을 수 있습니다. 예를 들어, 삭제된 데이터베이스는 일반적으로 `DROP DATABASE` 명령이 실행되기 전 최대 5분까지의 상태로 복원됩니다. 이 유형의 복원은 끊긴 데이터베이스에서 몇 분 동안 수행 된 트랜잭션을 복원할 수 없음을 뜻합니다. 이 문제를 피하려면 복원 작업이 완료된 후 `DROP DATABASE` 명령을 다시 실행할 수 있습니다. 데이터베이스를 삭제하면 그 데이터베이스에 대한 트랜잭션 로그가 삭제됩니다.
+ SQL Server의 경우, DB 인스턴스를 만든 후에 데이터베이스를 만듭니다. 데이터베이스 이름은 일반적인 SQL Server 명명 규칙을 따르지만 다음과 같은 차이점이 있습니다.
+ `rdsadmin`로 시작할 수 없습니다.
+ 공백 또는 탭으로 시작하거나 끝날 수 없습니다.
+ 새로운 줄을 생성하는 문자가 포함될 수 없습니다.
+ 작은 따옴표(`'`)가 포함될 수 없습니다.
+ SQL Server Web Edition에서는 새 RDS for SQL Server DB 인스턴스를 생성할 때만 **개발 및 테스트** 템플릿을 사용할 수 있습니다.
+ SQL Server Web Edition은 웹 호스트 및 웹 VAP 인터넷에 액세스할 수 있는 퍼블릭 웹 페이지, 웹 사이트, 웹 애플리케이션 및 웹 서비스를 호스팅하도록 설계되었습니다. 자세한 내용은 [Amazon RDS의 Microsoft SQL Server 라이선싱](SQLServer.Concepts.General.Licensing.md) 섹션을 참조하세요.
# Microsoft SQL Server를 위한 DB 인스턴스 클래스 지원
DB 인스턴스의 계산 및 메모리 용량은 해당 DB 인스턴스 클래스에 의해 결정됩니다. 필요한 DB 인스턴스 클래스는 DB 인스턴스의 처리력 및 메모리 요구 사항에 따라 다릅니다. 자세한 내용은 [DB 인스턴스 클래스](Concepts.DBInstanceClass.md) 섹션을 참조하세요.
편의를 위해 Microsoft SQL Server에 지원되는 다음 DB 인스턴스 클래스 목록이 여기에서 제공됩니다. 최신 목록은 RDS console: [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)를 참조하세요.
지원되는 SQL Server 마이너 버전에서 일부 DB 인스턴스 클래스는 사용할 수 없습니다. 예를 들어 db.r6i와 같은 일부 최신 DB 인스턴스 클래스는 이전 마이너 버전에서는 지원되지 않습니다. [describe-orderable-db-instance-options](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/describe-orderable-db-instance-options.html) AWS CLI 명령을 사용하여 SQL Server 에디션 및 버전에 사용할 수 있는 DB 인스턴스 클래스를 확인할 수 있습니다.
****
| SQL Server Edition | 2022 지원 범위 | 2019 지원 범위 | 2017 및 2016 지원 범위 |
| --- | --- | --- | --- |
| Enterprise Edition | `db.t3.xlarge`–`db.t3.2xlarge``db.r5.xlarge`–`db.r5.24xlarge``db.r5b.xlarge`–`db.r5b.24xlarge``db.r5d.xlarge`–`db.r5d.24xlarge``db.r6i.xlarge`–`db.r6i.32xlarge`db.r7i.xlarge–db.r7i.48xlarge`db.m5.xlarge`–`db.m5.24xlarge``db.m5d.xlarge`–`db.m5d.24xlarge``db.m6i.xlarge`–`db.m6i.32xlarge``db.m7i.xlarge`–`db.m7i.48xlarge``db.x2iedn.xlarge`–`db.x2iedn.32xlarge``db.z1d.xlarge`–`db.z1d.12xlarge` | `db.t3.xlarge`–`db.t3.2xlarge` `db.r5.xlarge`–`db.r5.24xlarge` `db.r5b.xlarge`–`db.r5b.24xlarge` `db.r5d.xlarge`–`db.r5d.24xlarge` `db.r6i.xlarge`–`db.r6i.32xlarge` `db.r7i.xlarge`–`db.r7i.48xlarge` `db.m5.xlarge`–`db.m5.24xlarge` `db.m5d.xlarge`–`db.m5d.24xlarge` `db.m6i.xlarge`–`db.m6i.32xlarge` `db.m7i.xlarge`–`db.m7i.48xlarge` `db.x2iedn.xlarge`–`db.x2iedn.32xlarge` `db.z1d.xlarge`–`db.z1d.12xlarge` | `db.t3.xlarge`–`db.t3.2xlarge` `db.r5.xlarge`–`db.r5.24xlarge` `db.r5b.xlarge`–`db.r5b.24xlarge` `db.r5d.xlarge`–`db.r5d.24xlarge` `db.r6i.xlarge`–`db.r6i.32xlarge` `db.r7i.xlarge`–`db.r7i.48xlarge` `db.m5.xlarge`–`db.m5.24xlarge` `db.m5d.xlarge`–`db.m5d.24xlarge` `db.m6i.xlarge`–`db.m6i.32xlarge` `db.m7i.xlarge`–`db.m7i.48xlarge` `db.x2iedn.xlarge`–`db.x2iedn.32xlarge` `db.z1d.xlarge`–`db.z1d.12xlarge` |
| Standard Edition | `db.t3.xlarge`–`db.t3.2xlarge``db.r5.large`–`db.r5.24xlarge``db.r5b.large`–`db.r5b.8xlarge``db.r5d.large`–`db.r5d.24xlarge``db.r6i.large`–`db.r6i.8xlarge`db.r7i.large–db.r7i.12xlarge`db.m5.large`–`db.m5.24xlarge``db.m5d.large`–`db.m5d.24xlarge``db.m6i.large`–`db.m6i.8xlarge``db.m7i.large`–`db.m7i.12xlarge``db.x2iedn.xlarge`–`db.x2iedn.8xlarge``db.z1d.large`–`db.z1d.12xlarge` | `db.t3.xlarge`–`db.t3.2xlarge` `db.r5.large`–`db.r5.24xlarge` `db.r5b.large`–`db.r5b.24xlarge` `db.r5d.large`–`db.r5d.24xlarge` `db.r6i.large`–`db.r6i.8xlarge` `db.r7i.large`–`db.r7i.12xlarge` `db.m5.large`–`db.m5.24xlarge` `db.m5d.large`–`db.m5d.24xlarge` `db.m6i.large`–`db.m6i.8xlarge` `db.m7i.large`–`db.m7i.12xlarge` `db.x2iedn.xlarge`–`db.x2iedn.32xlarge` `db.z1d.large`–`db.z1d.12xlarge` | `db.t3.xlarge`–`db.t3.2xlarge``db.r5.large`–`db.r5.24xlarge``db.r5b.large`–`db.r5b.24xlarge``db.r5d.large`–`db.r5d.24xlarge``db.r6i.large`–`db.r6i.8xlarge``db.r7i.large`–`db.r7i.12xlarge``db.m5.large`–`db.m5.24xlarge``db.m5d.large`–`db.m5d.24xlarge``db.m6i.large`–`db.m6i.8xlarge`db.m7i.large–db.m7i.12xlarge`db.x2iedn.xlarge`–`db.x2iedn.32xlarge``db.z1d.large`–`db.z1d.12xlarge` |
| Web Edition | `db.t3.small`–`db.t3.xlarge``db.r5.large`–`db.r5.4xlarge``db.r5b.large`–`db.r5b.4xlarge``db.r5d.large`–`db.r5d.4xlarge`db.r6i.large–db.r6i.4xlarge`db.r7i.large`–`db.r7i.4xlarge``db.m5.large`–`db.m5.4xlarge``db.m5d.large`–`db.m5d.4xlarge``db.m6i.large`–`db.m6i.4xlarge``db.m7i.large`–`db.m7i.4xlarge``db.z1d.large`–`db.z1d.13xlarge` | `db.t3.small`–`db.t3.2xlarge``db.r5.large`–`db.r5.4xlarge``db.r5b.large`–`db.r5b.4xlarge``db.r5d.large`–`db.r5d.4xlarge``db.r6i.large`–`db.r6i.4xlarge`db.r7i.large–db.r7i.4xlarge`db.m5.large`–`db.m5.4xlarge``db.m5d.large`–`db.m5d.4xlarge``db.m6i.large`–`db.m6i.4xlarge`db.m7i.large–db.m7i.4xlarge`db.z1d.large`–`db.z1d.3xlarge` | `db.t3.small`–`db.t3.2xlarge``db.r5.large`–`db.r5.4xlarge``db.r5b.large`–`db.r5b.4xlarge``db.r5d.large`–`db.r5d.4xlarge``db.r6i.large`–`db.r6i.4xlarge`db.r7i.large–db.r7i.4xlarge`db.m5.large`–`db.m5.4xlarge``db.m5d.large`–`db.m5d.4xlarge``db.m6i.large`–`db.m6i.4xlarge`db.m7i.large–db.m7i.4xlarge`db.z1d.large`–`db.z1d.3xlarge` |
| Express Edition | `db.t3.micro`–`db.t3.xlarge` | `db.t3.micro`–`db.t3.xlarge` | `db.t3.micro`–`db.t3.xlarge` |
| Developer Edition | `db.m6i.xlarge`–`db.m6i.32xlarge``db.r6i.xlarge`–`db.r6i.32xlarge` | | |
**참고**
7세대 인스턴스 클래스부터 인스턴스 크기가 2xlarge 이상인 RDS SQL Server에서는 하이퍼 스레딩이 비활성화됩니다. 이로 인해 사용 가능한 총 vCPU 수가 [해당 EC2 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/cpu-options-supported-instances-values.html)에서 지원하는 vCPU 수의 절반이 됩니다. 예를 들어 EC2 인스턴스 유형 `m7i.2xlarge`는 기본적으로 4개의 코어와 2개의 threadsPerCore를 지원하므로 총 8개의 vCPU가 생성됩니다. 반대로 하이퍼 스레딩이 비활성화된 RDS for SQL Server `db.m7i.2xlarge` 인스턴스는 코어 4개와 threadsPerCore 1개, 총 vCPU 4개를 생성합니다.
7세대 인스턴스부터 청구서를 통해 RDS DB 인스턴스 및 타사 라이선스 요금을 자세히 확인할 수 있습니다. 자세한 내용은 [RDS SQL Server 요금](https://aws.amazon.com/rds/sqlserver/pricing/)을 참조하세요.
# SQL Server 라이선스가 포함된 RDS 인스턴스의 CPU를 최적화합니다.
RDS for SQL Server를 사용하면 프로세서 기능을 지정하여 CPU 최적화를 사용함으로써 동일한 메모리와 IOPS를 유지하면서 DB 인스턴스에서 vCPU 수를 구성할 수 있습니다. 특정 데이터베이스 워크로드 요구 사항에 대해 원하는 메모리 대 CPU 수를 기반으로 하는 Microsoft Windows OS 및 SQL Server의 라이선스 비용을 줄일 수 있습니다.
프로세서 기능을 지정하려면 다음 파라미터를 사용합니다.
```
--processor-features "Name=coreCount,Value=value" \
"Name=threadsPerCore,Value=value"
```
+ **coreCount** - DB 인스턴스의 라이선스 비용을 최적화하기 위해 DB 인스턴스의 CPU 코어 수를 지정합니다. 선택한 인스턴스 유형의 코어 수에 허용되는 값을 찾으려면 [CPU 최적화를 지원하는 DB 인스턴스 클래스DB 인스턴스 클래스 지원](SQLServer.Concepts.General.OptimizeCPU.Support.md) 섹션을 참조하세요.
+ **threadsPerCore** - 코어당 스레드를 지정하여 CPU 코어당 스레드 수를 정의합니다. 선택한 인스턴스 유형에 대해 코어당 스레드에 허용되는 값을 찾으려면 [CPU 최적화를 지원하는 DB 인스턴스 클래스DB 인스턴스 클래스 지원](SQLServer.Concepts.General.OptimizeCPU.Support.md) 섹션을 참조하세요.
CPU 설정 최적화를 사용하여 RDS for SQL Server 인스턴스를 생성하는 샘플 명령:
```
aws rds create-db-instance \
--engine sqlserver-ee \
--engine-version 16.00 \
--license-model license-included \
--allocated-storage 300 \
--master-username myuser \
--master-user-password xxxxx \
--no-multi-az \
--vpc-security-group-ids myvpcsecuritygroup \
--db-subnet-group-name mydbsubnetgroup \
--db-instance-identifier my-rds-instance \
--db-instance-class db.m7i.8xlarge \
--processor-features "Name=coreCount,Value=8" "Name=threadsPerCore,Value=1"
```
이 예제에서는 기본적으로 coreCount가 16인 `db.m7i.8xlarge` 인스턴스를 생성합니다. CPU 최적화를 사용하는 경우 coreCount를 8로 선택하면 유효 vCPU 수가 8이 됩니다.
`--processor-features` 파라미터 없이 인스턴스를 생성하는 경우 코어 수는 16으로 설정되고 코어당 스레드는 기본적으로 1로 설정되므로 기본 vCPU 수는 16입니다.
프로세서 기능을 지정할 때 유의해야 할 몇 가지 고려 사항은 다음과 같습니다.
+ **생성** - 허용된 값에서 `processor-features` 파라미터에 대해 `coreCount` 및 `threadsPerCore`를 모두 지정합니다. [CPU 최적화를 지원하는 DB 인스턴스 클래스DB 인스턴스 클래스 지원](SQLServer.Concepts.General.OptimizeCPU.Support.md)을(를) 참조하세요.
+ **수정** – CPU 최적화 설정이 적용된 인스턴스 클래스에서 CPU 최적화 설정을 지원하는 다른 인스턴스 클래스로 수정할 때는 `--use-default-processor-features` 파라미터를 사용하여 기본 프로세서 설정을 지정하거나 수정 요청 중에 옵션을 명시적으로 정의해야 합니다.
**참고**
vCPU 수를 변경하면 DB 인스턴스와 관련된 라이선스 요금 비용에 영향을 미칠 수 있습니다.
+ **스냅샷 복원** - 스냅샷을 소스와 동일한 인스턴스 유형으로 복원할 때 복원된 DB 인스턴스는 스냅샷에서 CPU 최적화 설정을 상속합니다. 다른 인스턴스 유형으로 복원하는 경우 대상 인스턴스에 대한 CPU 최적화 설정을 정의하거나 `--use-default-processor-features` 파라미터를 지정해야 합니다.
+ **특정 시점 복원** 특정 시점 복원(PITR)에는 PITR에 지정된 시간을 기준으로 특정 스냅샷을 복원한 다음 해당 스냅샷에 모든 트랜잭션 로그 백업을 적용하여 인스턴스를 지정된 시점으로 가져오는 작업이 포함됩니다. PITR 요청 중에 사용자 지정 값을 지정하지 않는 한, PITR의 경우 CPU 최적화 설정 `coreCount` 및 `threadsPerCore`는 소스 스냅샷(특정 시점 아님)에서 파생됩니다. 사용 중인 소스 스냅샷이 CPU 설정 최적화로 활성화되어 있고 PITR에 다른 인스턴스 유형을 사용하는 경우, 대상 인스턴스에 대한 CPU 최적화 설정을 정의하거나 `—-use-default-processor-features` 파라미터를 지정해야 합니다.
## 제한 사항
CPU 최적화를 사용할 때 다음과 같은 제한 사항이 적용됩니다.
+ CPU 최적화는 Enterprise, Standard 및 Web Edition에서만 지원됩니다.
+ 일부 인스턴스에서 CPU 최적화를 사용할 수 있습니다. [CPU 최적화를 지원하는 DB 인스턴스 클래스DB 인스턴스 클래스 지원](SQLServer.Concepts.General.OptimizeCPU.Support.md)을(를) 참조하세요.
+ CPU 코어 수 사용자 지정은 `2xlarge` 이상의 인스턴스 크기에서 지원됩니다. 이러한 인스턴스 유형의 경우 CPU 최적화에 지원되는 최소 vCPCU 수는 4개입니다.
+ CPU 최적화는 CPU 최적화를 지원하는 7세대부터는 하이퍼스레딩이 비활성화되므로 코어당 1개의 스레드만 허용합니다.
# CPU 최적화를 지원하는 DB 인스턴스 클래스
RDS for SQL Server는 7세대 인스턴스 클래스 유형부터 CPU 최적화를 지원합니다. 또한 RDS는 CPU 최적화 기능의 활성화 여부에 관계없이 7세대 인스턴스 클래스 유형부터 시작하여 RDS DB 인스턴스 및 타사 라이선스 요금에 대한 세부 결제 내역을 제공합니다.
RDS for SQL Server는 특정 인스턴스 크기에서 CPU 최적화를 지원하며, 지원되는 가장 작은 인스턴스 크기는 `2xlarge`입니다. 지원되는 최소 구성은 vCPU 4개입니다. 아래 표는 CPU 최적화 기능을 지원하는 DB 인스턴스 클래스와 해당 클래스의 CPU 코어 수, 코어당 CPU 스레드 수, vCPU 수에 대한 기본값 및 유효값을 보여 줍니다.
**범용 인스턴스**
| 인스턴스 유형 | 기본 vCPU | 기본 CPU 코어 | 유효한 CPU 코어 수 | 코어당 유효한 스레드 수 |
| --- | --- | --- | --- | --- |
| `m7i.large` | 2 | 1 | 1 | 2 |
| `m7i.xlarge` | 4 | 2 | 2 | 2 |
| `m7i.2xlarge` | 4 | 4 | 1,2,3,4 | 1 |
| `m7i.4xlarge` | 8 | 8 | 1,2,3,4,5,6,7,8 | 1 |
| `m7i.8xlarge` | 16 | 16 | 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16 | 1 |
| `m7i.12xlarge` | 24 | 24 | 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24 | 1 |
| `m7i.16xlarge` | 32 | 32 | 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32 | 1 |
**메모리 최적화 인스턴스**
| 인스턴스 유형 | 기본 vCPU | 기본 CPU 코어 | 유효한 CPU 코어 수 | 코어당 유효한 스레드 수 |
| --- | --- | --- | --- | --- |
| `r7i.large` | 2 | 1 | 1 | 2 |
| `r7i.xlarge` | 4 | 2 | 2 | 2 |
| `r7i.2xlarge` | 4 | 4 | 1,2,3,4 | 1 |
| `r7i.4xlarge` | 8 | 8 | 1,2,3,4,5,6,7,8 | 1 |
| `r7i.8xlarge` | 16 | 16 | 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16 | 1 |
| `r7i.12xlarge` | 24 | 24 | 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24 | 1 |
| `r7i.16xlarge` | 32 | 32 | 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32 | 1 |
# DB 인스턴스 클래스의 CPU 코어 및 CPU 코어당 스레드 설정
다음 작업을 수행할 때 DB 인스턴스 클래스의 CPU 코어 및 코어당 스레드 수를 구성할 수 있습니다.
+ [Amazon RDS DB 인스턴스 생성](USER_CreateDBInstance.md)
+ [Amazon RDS DB 인스턴스 수정](Overview.DBInstance.Modifying.md)
+ [DB 인스턴스 복원](USER_RestoreFromSnapshot.md)
+ [Amazon RDS에서 DB 인스턴스를 지정된 시간으로 복원](USER_PIT.md)
**참고**
DB 인스턴스의 CPU 코어 수 또는 코어당 스레드 수를 구성하기 위해 인스턴스를 수정하면 인스턴스 클래스를 수정할 때와 유사하게 짧은 서비스 중단이 발생합니다.
AWS Management Console, AWS CLI 또는 RDS API를 사용하여 CPU 코어를 설정합니다.
## 콘솔
**코어 설정**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. **데이터베이스 생성**을 선택합니다.
1. **인스턴스 구성** 옵션을 설정할 때 다음을 수행합니다.
1. **CPU 최적화** 옵션을 선택합니다.
1. 코어 수를 선택하여 **vCPU** 옵션을 설정합니다.
![\[OCPU 설정 시 데이터베이스 생성 페이지\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/OCPU-screenshot.png)
1. 다른 선택을 완료한 후 **데이터베이스 생성**을 선택합니다.
## AWS CLI
**코어 설정**
1. AWS CLI를 사용하여 CPU 최적화를 구성하려면 명령에 `--processor-features` 옵션을 포함합니다. `coreCount` 및 `threadsPerCore`를 사용하여 CPU 코어 수를 `1`로 지정합니다.
1. 다음 구문을 사용합니다.
```
aws rds create-db-instance \
--engine sqlserver-ee \
--engine-version 16.00 \
--license-model license-included \
--allocated-storage 300 \
--master-username myuser \
--master-user-password xxxxx \
--no-multi-az \
--vpc-security-group-ids myvpcsecuritygroup \
--db-subnet-group-name mydbsubnetgroup \
--db-instance-identifier my-rds-instance \
--db-instance-class db.m7i.4xlarge \
--processor-features "Name=coreCount,Value=6" "Name=threadsPerCore,Value=1"
```
**Example DB 인스턴스 클래스에 유효한 프로세서 값 보기**
`describe-orderable-db-instance-options` 명령을 사용하여 기본 vCPU, 코어 및 코어당 스레드를 표시합니다. 예를 들어, 다음 명령의 출력은 db.r7i.2xlarge 인스턴스 클래스의 프로세서 옵션을 보여 줍니다.
```
aws rds describe-orderable-db-instance-options --engine sqlserver-ee \
--db-instance-class db.r7i.2xlarge
Sample output:
-------------------------------------------------------------
| DescribeOrderableDBInstanceOptions |
+-----------------------------------------------------------+
|| OrderableDBInstanceOptions ||
|+------------------------------------+--------------------+|
|| DBInstanceClass | db.r7i.2xlarge ||
|| Engine | sqlserver-ee ||
|| EngineVersion | 13.00.6300.2.v1 ||
|| LicenseModel | license-included ||
|| MaxIopsPerDbInstance | ||
|| MaxIopsPerGib | ||
|| MaxStorageSize | 64000 ||
|| MinIopsPerDbInstance | ||
|| MinIopsPerGib | ||
|| MinStorageSize | 20 ||
|| MultiAZCapable | True ||
|| OutpostCapable | False ||
|| ReadReplicaCapable | True ||
|| StorageType | gp2 ||
|| SupportsClusters | False ||
|| SupportsDedicatedLogVolume | False ||
|| SupportsEnhancedMonitoring | True ||
|| SupportsGlobalDatabases | False ||
|| SupportsIAMDatabaseAuthentication | False ||
|| SupportsIops | False ||
|| SupportsKerberosAuthentication | True ||
|| SupportsPerformanceInsights | True ||
|| SupportsStorageAutoscaling | True ||
|| SupportsStorageEncryption | True ||
|| SupportsStorageThroughput | False ||
|| Vpc | True ||
|+------------------------------------+--------------------+|
||| AvailabilityZones |||
||+-------------------------------------------------------+||
||| Name |||
||+-------------------------------------------------------+||
||| us-west-2a |||
||| us-west-2b |||
||| us-west-2c |||
||+-------------------------------------------------------+||
||| AvailableProcessorFeatures |||
||+-----------------+-----------------+-------------------+||
||| AllowedValues | DefaultValue | Name |||
||+-----------------+-----------------+-------------------+||
||| 1,2,3,4 | 4 | coreCount |||
||| 1 | 1 | threadsPerCore |||
||+-----------------+-----------------+-------------------+||
```
또한 DB 인스턴스 클래스 프로세서 정보에 대해 다음 명령을 실행할 수 있습니다.
+ `describe-db-instances` - 지정된 DB 인스턴스에 대한 프로세서 정보를 보여 줍니다.
+ `describe-db-snapshots` - 지정된 DB 스냅샷에 대한 프로세서 정보를 보여 줍니다.
+ `describe-valid-db-instance-modifications` – 지정된 DB 인스턴스에 유효한 프로세서 수정 사항을 보여 줍니다.
위 명령의 출력에서 프로세서 기능의 값은 CPU 최적화가 구성되지 않은 경우 `null`입니다.
**Example DB 인스턴스의 CPU 코어 수 설정**
다음 예제는 *mydbinstance*를 수정하여 CPU 코어 수를 4개로, threadsPerCore 값을 1로 설정합니다. `--apply-immediately`를 사용하여 변경 내용을 즉시 적용합니다. 다음 예약 유지 관리 기간 중에 변경 내용을 적용하려는 경우 `--apply-immediately option`을 생략합니다.
```
aws rds modify-db-instance \
--db-instance-identifier mydbinstance \
--db-instance-class db.r7i.8xlarge \
--processor-features "Name=coreCount,Value=4" "Name=threadsPerCore,Value=1" \
--apply-immediately
```
**Example DB 인스턴스의 기본 프로세서 설정으로 돌아가기**
다음 예제는 *mydbinstance*를 기본 프로세서 값으로 되돌려 수정합니다.
```
aws rds modify-db-instance \
--db-instance-identifier mydbinstance \
--db-instance-class db.r7i.8xlarge \
--use-default-processor-features \
--apply-immediately
```
# Microsoft SQL Server 보안
Microsoft SQL Server 데이터베이스 엔진은 역할 기반 보안을 사용합니다. DB 인스턴스를 생성할 때 지정하는 마스터 사용자 이름은 `processadmin`, `public` 및 `setupadmin` 고정 서버 역할의 구성원인 SQL Server 인증 로그인입니다.
데이터베이스를 만드는 사용자는 누구든 해당 데이터베이스에 대한 db\$1owner 역할에 할당되며, 백업에 사용되는 권한을 제외한 모든 데이터베이스 수준의 권한을 갖게 됩니다. Amazon RDS는 백업을 관리합니다.
Amazon RDS for SQL Server에서는 다음과 같은 서버 수준 역할을 사용할 수 없습니다.
+ bulkadmin
+ dbcreator
+ diskadmin
+ securityadmin
+ serveradmin
+ sysadmin
RDS for SQL Server DB 인스턴스에서는 다음 서버 수준 권한을 사용할 수 없습니다.
+ ALTER ANY DATABASE
+ ALTER ANY EVENT NOTIFICATION
+ ALTER RESOURCES
+ ALTER SETTINGS(DB 파라미터 그룹 API 작업을 사용하여 파라미터를 수정할 수 있습니다. 자세한 내용은 [Amazon RDS의 파라미터 그룹](USER_WorkingWithParamGroups.md) 단원을 참조하십시오.)
+ AUTHENTICATE SERVER
+ CONTROL\$1SERVER
+ CREATE DDL EVENT NOTIFICATION
+ CREATE ENDPOINT
+ CREATE SERVER ROLE
+ CREATE TRACE EVENT NOTIFICATION
+ DROP ANY DATABASE
+ EXTERNAL ACCESS ASSEMBLY
+ SHUTDOWN(RDS 재부팅 옵션을 대신 사용할 수 있음)
+ UNSAFE ASSEMBLY
+ 모든 가용성 그룹 변경
+ 가용성 그룹 생성
## Microsoft SQL Server 인스턴스를 위한 SSL 지원
SSL을 사용하여 애플리케이션과 Microsoft SQL Server를 실행하는 Amazon RDS DB 인스턴스 사이의 연결을 암호화할 수 있습니다. 또한 DB 인스턴스에 대한 모든 연결에서 SSL을 사용하도록 지정할 수도 있습니다. 연결이 SSL을 사용하도록 지정하면 클라이언트에 투명하게 발생하며, 클라이언트는 SSL 사용을 위해 작업을 수행할 필요가 없습니다.
SSL은 지원되는 모든 SQL Server 버전에 대해 모든 AWS 리전에서 사용할 수 있습니다. 자세한 내용은 [Microsoft SQL Server DB 인스턴스와 함께 SSL 사용](SQLServer.Concepts.General.SSL.Using.md) 단원을 참조하십시오.
# Microsoft SQL Server DB 인스턴스와 함께 SSL 사용
SSL(Secure Sockets Layer)을 사용하여 클라이언트 애플리케이션과 Microsoft SQL Server를 실행하는 Amazon RDS DB 인스턴스 사이의 연결을 암호화할 수 있습니다. 지원되는 모든 SQL Server 버전의 모든 AWS 리전에서 SSL 지원 기능을 사용할 수 있습니다.
SQL Server DB 인스턴스를 생성할 때 Amazon RDS는 인스턴스의 SSL 인증서를 만듭니다. SSL 인증서에는 스푸핑 공격으로부터 보호해주는 SSL 인증서를 위한 일반 이름(CN)으로 DB 인스턴스 엔드포인트가 포함되어 있습니다.
SSL을 사용하여 SQL Server DB 인스턴스에 연결하는 방법은 두 가지입니다.
+ 모든 연결에 대해 SSL 지정 – 이것은 클라이언트에 투명하게 발생하며, 클라이언트는 SSL 사용을 위해 작업을 수행할 필요가 없습니다.
**참고**
`rds.force_ssl`을 `1`로 설정하고 SSMS 버전 19.3, 20.0 및 20.2를 사용하는 경우 다음을 확인합니다.
SSMS에서 **신뢰 서버 인증서**를 활성화합니다.
사용 중인 시스템으로 인증서를 가져옵니다.
+ 특정 연결 암호화 – 이것은 특정 클라이언트 컴퓨터로부터 SSL 연결을 설정하며, 연결 암호화를 위해 클라이언트에서 작업을 수행해야 합니다.
SQL Server의 TLS(전송 계층 보안)에 대한 자세한 내용은 [Microsoft SQL Server에 대한 TLS 1.2 지원](https://support.microsoft.com/en-ca/help/3135244/tls-1-2-support-for-microsoft-sql-server)을 참조하십시오.
## DB 인스턴스 연결이 SSL을 사용하도록 지정
DB 인스턴스에 대한 모든 연결에서 SSL을 사용하도록 지정할 수 있습니다. 연결이 SSL을 사용하도록 지정하면 클라이언트에 투명하게 발생하며, 클라이언트는 SSL 사용을 위해 작업을 수행할 필요가 없습니다.
SSL을 지정하려면 `rds.force_ssl` 파라미터를 사용하십시오. 기본적으로 `rds.force_ssl` 파라미터는 `0 (off)`로 설정됩니다. 연결이 SSL을 사용하도록 지정하려면 `rds.force_ssl` 파라미터를 `1 (on)`로 설정하십시오. `rds.force_ssl` 파라미터는 정적이기 때문에 값을 변경하면 DB 인스턴스를 재부팅해야만 변경 사항이 적용됩니다.
**모든 DB 인스턴스 연결이 SSL을 사용하도록 지정**
1. DB 인스턴스에 첨부할 파라미터 그룹을 결정합니다.
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. Amazon RDS 콘솔의 오른쪽 상단에서 DB 인스턴스의 AWS 리전을 선택합니다.
1. 탐색 창에서 **데이터베이스**를 선택한 후, DB 인스턴스의 이름을 선택하여 세부 정보를 표시합니다.
1. **구성** 탭을 선택합니다. 섹션에서 [**파라미터 그룹(Parameter group)**]을 찾습니다.
1. 필요하다면 새 파라미터 그룹을 만듭니다. DB 인스턴스가 기본 파라미터 그룹을 사용한다면, 새 파라미터 그룹을 생성해야 합니다. DB 인스턴스가 기본이 아닌 파라미터 그룹을 사용한다면, 기존 파라미터 그룹을 편집하거나 새 파라미터 그룹을 생성할 수 있습니다. 기존 파라미터 그룹을 편집하면, 해당 파라미터 그룹을 사용하면 모든 DB 인스턴스가 영향받게 됩니다.
새 파라미터 그룹을 만들려면, [Amazon RDS에서 DB 파라미터 그룹 생성](USER_WorkingWithParamGroups.Creating.md)의 지침을 따르십시오.
1. 신규 또는 기존 파라미터 그룹을 편집해 `rds.force_ssl` 파라미터를 `true`로 설정하십시오. 파라미터 그룹을 편집하려면, [Amazon RDS에서 DB 파라미터 그룹의 파라미터 수정](USER_WorkingWithParamGroups.Modifying.md)의 지침을 따르십시오.
1. 새 파라미터 그룹을 생성했다면, DB 인스턴스를 수정해 새 파라미터 그룹을 첨부하십시오. DB 인스턴스의 **DB Parameter Group** 설정을 수정합니다. 자세한 내용은 [Amazon RDS DB 인스턴스 수정](Overview.DBInstance.Modifying.md) 섹션을 참조하세요.
1. DB 인스턴스를 재부팅합니다. 자세한 내용은 [ DB 인스턴스 재부팅](USER_RebootInstance.md) 섹션을 참조하세요.
## 특정 연결 암호화
모든 DB 인스턴스 연결이 SSL을 사용하도록 지정하거나, 특정 클라이언트 컴퓨터 연결만 암호화할 수 있습니다. 특정 클라이언트에서 SSL을 사용하려면, 클라이언트 컴퓨터의 인증서를 획득하고 클라이언트 컴퓨터에서 인증서를 가져온 다음 클라이언트 컴퓨터 연결을 암호화해야 합니다.
**참고**
2014년 8월 5일 이후에 만든 모든 SQL Server 인스턴스는 SSL 인증서의 일반 이름(CN) 필드에 DB 인스턴스 엔드포인트를 사용합니다. 2014년 8월 5일 이전에는 VPC 기반 SQL Server 인스턴스에 대해 SSL 인증서 확인 기능을 사용할 수 없었습니다. 2014년 8월 5일 이전에 생성된 VPC 기반 SQL Server DB 인스턴스가 있는 상태에서 SSL 인증서 확인을 사용하고 DB 인스턴스용 SSL 인증서에 대한 CN으로 인스턴스 엔드포인트를 반드시 포함시키려면, DB 인스턴스의 이름을 변경합니다. DB 인스턴스의 이름을 변경하면 새 인증서가 배포되고 인스턴스가 재부팅되어 새 인증서를 활성화합니다.
### 클라이언트 컴퓨터의 인증서 획득
클라이언트 컴퓨터와 Microsoft SQL Server를 실행하는 Amazon RDS DB 인스턴스 사이의 연결을 암호화하려면, 클라이언트 컴퓨터에 인증서가 있어야 합니다.
인증서를 얻으려면, 클라이언트 컴퓨터에 인증서를 다운로드하십시오. 모든 리전에 적용되는 루트 인증서를 다운로드할 수 있습니다. 이전 루트 인증서와 새 루트 인증서를 모두 포함하는 인증서 번들도 다운로드할 수 있습니다. 또한 리전별 중간 인증서를 다운로드할 수 있습니다. 인증서 다운로드에 대한 자세한 내용은 [SSL/TLS를 사용하여 DB 인스턴스 또는 클러스터 에 대한 연결 암호화](UsingWithRDS.SSL.md) 단원을 참조하십시오.
적절한 인증서를 다운로드했다면, 아래 항목에 있는 절차를 따라 Microsoft Windows 운영 체제로 인증서를 가져오십시오.
### 클라이언트 컴퓨터로 인증서 가져오기
다음 절차를 이용해 클라이언트 컴퓨터의 Microsoft Windows 운영 체제로 인증서를 가져올 수 있습니다.
**Windows 운영 체제로 인증서를 가져오는 방법:**
1. **시작** 메뉴에서 검색 상자에 **Run**을 입력하고 **Enter** 키를 누릅니다.
1. **열기** 상자에 **MMC**를 입력하고 **확인**을 선택합니다.
1. MMC 콘솔의 **파일** 메뉴에서 **스냅인 추가/제거**를 선택합니다.
1. **스냅인 추가/제거** 대화 상자의 **사용 가능한 스냅인**에서 **Certificates**를 선택하고 **추가**를 선택합니다.
1. **인증서 스냅인** 대화 상자에서 **컴퓨터 계정**을 선택한 후 **다음**을 선택합니다.
1. **컴퓨터 선택** 대화 상자에서 **마침**을 선택합니다.
1. **스냅인 추가/제거** 대화 상자에서 **확인**을 선택합니다.
1. MMC 콘솔에서 **인증서**를 확장하고, 문맥 메뉴(우클릭)를 열어 **신뢰할 수 있는 루트 인증 기관**을 선택하고, **모든 작업**을 선택한 후 **가져오기**를 선택합니다.
1. 인증서 가져오기 마법사의 첫 페이지에서 **다음**을 선택합니다.
1. 인증서 가져오기 마법사의 두 번째 페이지에서 **찾아보기**를 선택합니다. .pem은 표준 인증서 확장명이 아니기 때문에 브라우저 창에서 파일 유형을 **모든 파일(\$1.\$1)**로 변경합니다. 이전에 다운로드한 .pem 파일을 찾습니다.
**참고**
SQL Server Management Studio(SSMS)와 같은 Windows 클라이언트에서 연결할 때는 global-bundle.pem 파일 대신 PKCS\$17(.p7b) 인증서 형식을 사용하는 것이 좋습니다. .p7b 형식을 사용하면 루트 및 중간 인증 기관(CA)을 포함한 전체 인증서 체인을 Windows 인증서 스토어로 올바르게 가져올 수 있습니다. 이렇게 하면 .pem 가져오기가 전체 체인을 제대로 설치하지 못할 수 있으므로 필수 암호화가 활성화된 경우 발생할 수 있는 연결 실패를 방지할 수 있습니다.
1. **열기**를 선택해 인증서 파일을 선택하고 **다음**을 선택합니다.
1. 인증서 가져오기 마법사의 세 번째 페이지에서 **다음**을 선택합니다.
1. 인증서 가져오기 마법사의 네 번째 페이지에서 **종료**를 선택합니다. 가져오기에 성공했음을 표시하는 대화 상자가 나타날 것입니다.
1. MMC 콘솔에서 **인증서**와 **신뢰할 수 있는 루트 인증 기관**을 차례로 확장한 다음 **인증서**를 선택합니다. 다음과 같이 인증서를 찾아 인증서 존재를 확인하십시오.
![\[MMC 콘솔의 탐색 창에서 콘솔 루트, 인증서(로컬 컴퓨터) 및 신뢰할 수 있는 루트 인증 기관 중에서 검색하여 인증서 폴더를 선택합니다. 기본 페이지에서 필요한 CA 인증서를 선택합니다.\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/rds_sql_ssl_cert.png)
### Microsoft SQL Server 기반 Amazon RDS DB 인스턴스 연결 암호화
클라이언트 컴퓨터로 인증서를 가져오면, 클라이언트 컴퓨터와 Microsoft SQL Server를 실행하는 Amazon RDS DB 인스턴스 사이의 연결을 암호화할 수 있습니다.
SQL Server Management Studio의 경우, 다음 절차를 사용합니다. SQL Server Management Studio에 대한 자세한 내용은 [SQL Server Management Studio 사용](http://msdn.microsoft.com/en-us/library/ms174173.aspx)을 참조하십시오.
**SQL Server Management Studio 연결 암호화**
1. SQL Server Management Studio를 시작합니다.
1. [**서버에 연결(Connect to server)**]에 서버 정보, 로그인 사용자 이름 및 암호를 입력합니다.
1. **Options**를 선택합니다.
1. [**연결 암호화**]를 선택합니다.
1. [**Connect**]를 선택합니다.
1. 다음 쿼리를 실행하여 연결이 암호화되는지 확인합니다. 쿼리가 `true`에 대해 `encrypt_option`를 반환하는지 확인합니다.
```
select ENCRYPT_OPTION from SYS.DM_EXEC_CONNECTIONS where SESSION_ID = @@SPID
```
다른 SQL 클라이언트에는 다음 절차를 적용하십시오.
**다른 SQL 클라이언트 연결 암호화**
1. 연결 문자열에 `encrypt=true`를 추가합니다. 이 문자열은 GUI 도구의 연결 페이지에서 옵션 또는 속성으로 사용할 수 있습니다.
**참고**
JDBC를 사용하여 연결하는 클라이언트에 대해 SSL 암호화를 활성화하려면 Java CA 인증서(cacert) 저장소에 Amazon RDS SQL 인증서를 추가해야 할 수도 있습니다. [ keytool](http://docs.oracle.com/javase/7/docs/technotes/tools/solaris/keytool.html) 유틸리티를 사용하여 이 작업을 수행할 수 있습니다.
1. 다음 쿼리를 실행하여 연결이 암호화되는지 확인합니다. 쿼리가 `true`에 대해 `encrypt_option`를 반환하는지 확인합니다.
```
select ENCRYPT_OPTION from SYS.DM_EXEC_CONNECTIONS where SESSION_ID = @@SPID
```
# SQL Server 보안 프로토콜 및 암호 구성
DB 파라미터를 사용하여 특정 보안 프로토콜 및 암호를 설정하거나 해제할 수 있습니다. 구성할 수 있는 보안 파라미터(TLS 버전 1.2 제외) 는 다음 표에 나와 있습니다.
****
| DB 파라미터 | 허용된 값(기본값은 굵은 글꼴로 표시) | 설명 |
| --- | --- | --- |
| rds.tls10 | 기본값, 활성화, 비활성화 | TLS 1.0. |
| rds.tls11 | 기본값, 활성화, 비활성화 | TLS 1.1. |
| rds.tls12 | 기본값 | TLS 1.2 이 값은 수정할 수 없습니다. |
| rds.fips | 0, 1 | 이 파라미터를 1로 설정하면 RDS가 Federal Information Processing Standard(FIPS) 140-2 표준을 준수하는 모듈의 사용을 강제합니다. 자세한 내용은 Microsoft 설명서에서 [FIPS 140-2 호환 모드에서 SQL Server 2016 사용](https://docs.microsoft.com/en-us/troubleshoot/sql/security/sql-2016-fips-140-2-compliant-mode)을 참조하세요. |
| rds.rc4 | 기본값, 활성화, 비활성화 | RC4 스트림 암호. |
| rds.diffie-hellman | 기본값, 활성화, 비활성화 | Diffie-Hellman 키 교환 암호화. |
| rds.diffie-hellman-min-key-bit-length | 기본값, 1024, 2048, 3072, 4096 | Diffie-Hellman 키의 최소 비트 길이. |
| rds.curve25519 | 기본값, 활성화, 비활성화 | Curve25519 Elliptic-Curve 암호화 암호. 이 파라미터는 일부 엔진 버전에서 지원되지 않습니다. |
| rds.3des168 | 기본값, 활성화, 비활성화 | 168비트 키 길이의 Triple DES(Data Encryption Standard) 암호화 암호입니다. |
**참고**
16.00.4120.1, 15.00.4365.2, 14.00.3465.1, 13.00.6435.1 및 12.00.6449.1 후의 마이너 엔진 버전에서는 DB 파라미터 `rds.tls10`, `rds.tls11`, `rds.rc4`, `rds.curve25519`, `rds.3des168`에 대한 기본 설정이 **비활성화됨입니다. 그렇지 않으면 기본값은 **활성화됨입니다.
16.00.4120.1, 15.00.4365.2, 14.00.3465.1, 13.00.6435.1 및 12.00.6449.1 후의 마이너 엔진 버전에서는 `rds.diffie-hellman-min-key-bit-length`의 기본 설정이 3072입니다. 그렇지 않으면 기본값은 2048입니다.
다음 프로세스를 사용하여 보안 프로토콜 및 암호를 구성합니다.
1. 사용자 지정 DB 파라미터 그룹을 생성합니다.
1. 파라미터 그룹의 파라미터를 수정합니다.
1. DB 파라미터 그룹을 DB 인스턴스에 연결합니다.
DB 파라미터 그룹에 대한 자세한 내용은 [Amazon RDS의 파라미터 그룹](USER_WorkingWithParamGroups.md) 단원을 참조하십시오.
## 보안 관련 파라미터 그룹 생성
DB 인스턴스의 SQL Server 에디션 및 버전에 해당하는 보안 관련 파라미터에 대한 파라미터 그룹을 생성합니다.
### 콘솔
다음 절차에서는 SQL Server Standard Edition 2016에 대한 파라미터 그룹을 생성합니다.
**파라미터 그룹을 생성하려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **파라미터 그룹**을 선택합니다.
1. [**Create parameter group**]을 선택합니다.
1. **서브넷 그룹 생성** 창에서 다음을 수행합니다.
1. **파라미터 그룹 패밀리**에서 **sqlserver-se-13.0**을 선택합니다.
1. **그룹 이름**에 파라미터 그룹의 식별자(예: **sqlserver-ciphers-se-13**)를 입력합니다.
1. **설명**에 **Parameter group for security protocols and ciphers**를 입력합니다.
1. **생성(Create)**을 선택합니다.
### CLI
다음 절차에서는 SQL Server Standard Edition 2016에 대한 파라미터 그룹을 생성합니다.
**파라미터 그룹을 생성하려면**
+ 다음 명령 중 하나를 실행합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds create-db-parameter-group \
--db-parameter-group-name sqlserver-ciphers-se-13 \
--db-parameter-group-family "sqlserver-se-13.0" \
--description "Parameter group for security protocols and ciphers"
```
Windows의 경우:
```
aws rds create-db-parameter-group ^
--db-parameter-group-name sqlserver-ciphers-se-13 ^
--db-parameter-group-family "sqlserver-se-13.0" ^
--description "Parameter group for security protocols and ciphers"
```
## 보안 관련 파라미터 수정
DB 인스턴스의 SQL Server 에디션 및 버전에 해당하는 파라미터 그룹의 보안 관련 파라미터를 수정합니다.
### 콘솔
다음 절차에서는 SQL Server Standard Edition 2016에 대해 생성한 파라미터 그룹을 수정합니다. 이 예제에서는 TLS 버전 1.0을 해제합니다.
**파라미터 그룹을 수정하려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **파라미터 그룹**을 선택합니다.
1. 파라미터 그룹(예: **sqlserver-ciphers-se-13**)을 선택합니다.
1. **파라미터**에서 파라미터 목록을 **rds**로 필터링합니다.
1. **파라미터 편집**을 선택합니다.
1. **rds.tls10**을 선택합니다.
1. **값**에 대해 **비활성화**를 선택합니다.
1. **Save changes**(변경 사항 저장)를 선택합니다.
### CLI
다음 절차에서는 SQL Server Standard Edition 2016에 대해 생성한 파라미터 그룹을 수정합니다. 이 예제에서는 TLS 버전 1.0을 해제합니다.
**파라미터 그룹을 수정하려면**
+ 다음 명령 중 하나를 실행합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds modify-db-parameter-group \
--db-parameter-group-name sqlserver-ciphers-se-13 \
--parameters "ParameterName='rds.tls10',ParameterValue='disabled',ApplyMethod=pending-reboot"
```
Windows의 경우:
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name sqlserver-ciphers-se-13 ^
--parameters "ParameterName='rds.tls10',ParameterValue='disabled',ApplyMethod=pending-reboot"
```
## 보안 관련 파라미터 그룹을 DB 인스턴스와 연결
파라미터 그룹을 DB 인스턴스와 연결하려면 AWS Management Console 또는 AWS CLI를 사용합니다.
### 콘솔
파라미터 그룹을 새 DB 인스턴스 또는 기존 DB 인스턴스와 연결할 수 있습니다.
+ 새 DB 인스턴스의 경우 인스턴스를 시작할 때 연결합니다. 자세한 내용은 [Amazon RDS DB 인스턴스 생성](USER_CreateDBInstance.md) 섹션을 참조하세요.
+ 기존 DB 인스턴스의 경우 인스턴스를 수정하여 연결합니다. 자세한 내용은 [Amazon RDS DB 인스턴스 수정](Overview.DBInstance.Modifying.md) 단원을 참조하십시오.
### CLI
파라미터 그룹을 새 DB 인스턴스 또는 기존 DB 인스턴스와 연결할 수 있습니다.
**파라미터 그룹을 사용하여 DB 인스턴스를 생성하려면**
+ 파라미터 그룹을 생성할 때 사용한 것과 동일한 DB 엔진 유형과 메이저 버전을 지정합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds create-db-instance \
--db-instance-identifier mydbinstance \
--db-instance-class db.m5.2xlarge \
--engine sqlserver-se \
--engine-version 13.00.5426.0.v1 \
--allocated-storage 100 \
--master-user-password secret123 \
--master-username admin \
--storage-type gp2 \
--license-model li \
--db-parameter-group-name sqlserver-ciphers-se-13
```
Windows의 경우:
```
aws rds create-db-instance ^
--db-instance-identifier mydbinstance ^
--db-instance-class db.m5.2xlarge ^
--engine sqlserver-se ^
--engine-version 13.00.5426.0.v1 ^
--allocated-storage 100 ^
--master-user-password secret123 ^
--master-username admin ^
--storage-type gp2 ^
--license-model li ^
--db-parameter-group-name sqlserver-ciphers-se-13
```
**참고**
보안 모범 사례로 여기에 표시된 프롬프트 이외의 암호를 지정하는 것이 좋습니다.
**DB 인스턴스를 수정하고 파라미터 그룹을 연결하려면**
+ 다음 명령 중 하나를 실행합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds modify-db-instance \
--db-instance-identifier mydbinstance \
--db-parameter-group-name sqlserver-ciphers-se-13 \
--apply-immediately
```
Windows의 경우:
```
aws rds modify-db-instance ^
--db-instance-identifier mydbinstance ^
--db-parameter-group-name sqlserver-ciphers-se-13 ^
--apply-immediately
```
# 새 SSL/TLS 인증서를 사용해 Microsoft SQL Server DB 인스턴스에 연결할 애플리케이션을 업데이트
2023년 1월 13일부터 Amazon RDS는 보안 소켓 계층(SSL) 또는 전송 계층 보안(TLS)을 사용해 RDS DB 인스턴스에 연결하기 위한 용도의 새 인증 기관(CA) 인증서를 게시하였습니다. 아래에서 새 인증서를 사용하기 위해 애플리케이션을 업데이트하는 방법에 관한 정보를 찾으실 수 있습니다.
이 주제는 클라이언트 애플리케이션에서 SSL/TLS를 사용해 DB 인스턴스에 연결하는지 여부를 판단하는 데 도움이 됩니다. SSL/TLS를 사용해 연결한다면 이 애플리케이션에서 연결 시 인증서 확인이 필요한지 여부를 추가로 확인할 수 있습니다.
**참고**
어떤 애플리케이션은 서버에서 인증서를 성공적으로 확인할 수 있는 경우에만 SQL Server DB 인스턴스에 연결하도록 구성되어 있습니다.
이러한 애플리케이션의 경우 클라이언트 애플리케이션 트러스트 스토어를 업데이트하여 새 CA 인증서를 포함해야 합니다.
클라이언트 애플리케이션 트러스트 스토어에서 CA 인증서를 업데이트한 후에는 DB 인스턴스에서 인증서를 교환할 수 있습니다. 이 절차를 프로덕션 환경에서 구현하기 전에 개발 또는 스테이징 환경에서 테스트해볼 것을 적극 권장합니다.
인증서 교환에 대한 자세한 내용은 [SSL/TLS 인증서 교체](UsingWithRDS.SSL-certificate-rotation.md) 단원을 참조하십시오. 인증서 다운로드에 대한 자세한 내용은 [SSL/TLS를 사용하여 DB 인스턴스 또는 클러스터 에 대한 연결 암호화](UsingWithRDS.SSL.md) 단원을 참조하십시오. Microsoft SQL Server DB 인스턴스에서 SSL/TLS를 사용하는 방법에 관한 자세한 내용은 [Microsoft SQL Server DB 인스턴스와 함께 SSL 사용](SQLServer.Concepts.General.SSL.Using.md) 단원을 참조하십시오.
**Topics**
+ [애플리케이션에서 SSL을 사용해 Microsoft SQL Server DB 인스턴스에 연결하는지 여부 확인](#ssl-certificate-rotation-sqlserver.determining-server)
+ [클라이언트에서 연결을 위해 인증서 확인이 필요한지 여부 확인](#ssl-certificate-rotation-sqlserver.determining-client)
+ [애플리케이션 트러스트 스토어 업데이트](#ssl-certificate-rotation-sqlserver.updating-trust-store)
## 애플리케이션에서 SSL을 사용해 Microsoft SQL Server DB 인스턴스에 연결하는지 여부 확인
`rds.force_ssl` 파라미터의 값에 대한 DB 인스턴스 구성을 확인하십시오. 기본적으로 `rds.force_ssl` 파라미터는 0(해제)으로 설정됩니다. `rds.force_ssl` 파라미터가 1(켜짐)로 설정된 경우 클라이언트는 연결 시 SSL/TLS를 사용해야 합니다. 파라미터 그룹에 대한 자세한 내용은 [Amazon RDS의 파라미터 그룹](USER_WorkingWithParamGroups.md) 단원을 참조하세요.
다음 쿼리를 실행하여 DB 인스턴스에 대한 모든 열린 연결에 대한 현재 암호화 옵션을 가져옵니다. 연결이 암호화되면 `ENCRYPT_OPTION` 열이 `TRUE`를 반환합니다.
```
select SESSION_ID,
ENCRYPT_OPTION,
NET_TRANSPORT,
AUTH_SCHEME
from SYS.DM_EXEC_CONNECTIONS
```
이 쿼리는 현재 연결만 보여줍니다. 과거에 연결/연결 해제된 애플리케이션이 SSL을 사용했는지 여부는 표시되지 않습니다.
## 클라이언트에서 연결을 위해 인증서 확인이 필요한지 여부 확인
다양한 유형의 클라이언트에서 연결 시 인증서 확인이 필요한지 여부를 확인할 수 있습니다.
**참고**
나열된 것 이외의 커넥터를 사용하는 경우 암호화된 연결을 적용하는 방법에 대한 정보는 특정 커넥터 설명서를 참조하십시오. 자세한 정보는 Microsoft SQL Server 설명서의 [Microsoft SQL 데이터베이스용 연결 모듈](https://docs.microsoft.com/en-us/sql/connect/sql-connection-libraries?view=sql-server-ver15)을 참조하십시오.
### SQL Server Management Studio
SQL Server Management Studio 연결에 암호화가 적용되는지 확인하십시오.
1. SQL Server Management Studio를 시작합니다.
1. **서버에 연결**에 서버 정보, 로그인 사용자 이름 및 암호를 입력합니다.
1. **옵션(Options)**을 선택합니다.
1. 연결 페이지에서 **연결 암호화**가 선택되어 있는지 확인하십시오.
SQL Server Management Studio에 대한 자세한 내용은 [SQL Server Management Studio 사용](http://msdn.microsoft.com/en-us/library/ms174173.aspx)을 참조하십시오.
### sqlcmd
`sqlcmd` 클라이언트를 사용하는 다음 예제에서는 스크립트의 SQL Server 연결을 확인하여 성공적인 연결을 위해 유효한 인증서가 필요한지 여부를 판단하는 방법을 보여줍니다. 자세한 내용은 Microsoft SQL Server 설명서의 [sqlcmd로 연결](https://docs.microsoft.com/en-us/sql/connect/odbc/linux-mac/connecting-with-sqlcmd?view=sql-server-ver15)을 참조하십시오.
`sqlcmd`를 사용하는 경우 다음 예제와 같이 `-N` 명령 인수를 사용하여 연결을 암호화한다면 SSL 연결 시 서버 인증서에 대한 확인이 필요합니다.
```
$ sqlcmd -N -S dbinstance.rds.amazon.com -d ExampleDB
```
**참고**
`sqlcmd` 옵션을 사용하여 `-C`를 호출하면 클라이언트 측 트러스트 스토어와 일치하지 않더라도 서버 인증서를 신뢰합니다.
### ADO.NET
다음 예에서 애플리케이션은 SSL을 사용하여 연결하고, 서버 인증서를 확인해야 합니다.
```
using SQLC = Microsoft.Data.SqlClient;
...
static public void Main()
{
using (var connection = new SQLC.SqlConnection(
"Server=tcp:dbinstance.rds.amazon.com;" +
"Database=ExampleDB;User ID=LOGIN_NAME;" +
"Password=YOUR_PASSWORD;" +
"Encrypt=True;TrustServerCertificate=False;"
))
{
connection.Open();
...
}
```
### Java
다음 예에서 애플리케이션은 SSL을 사용하여 연결하고, 서버 인증서를 확인해야 합니다.
```
String connectionUrl =
"jdbc:sqlserver://dbinstance.rds.amazon.com;" +
"databaseName=ExampleDB;integratedSecurity=true;" +
"encrypt=true;trustServerCertificate=false";
```
JDBC를 사용하여 연결하는 클라이언트에 대해 SSL 암호화를 활성화하려면 Java CA 인증서 저장소에 Amazon RDS 인증서를 추가해야 할 수도 있습니다. 지침은 Microsoft SQL Server 설명서의 [암호화를 위한 클라이언트 구성](https://docs.microsoft.com/en-us/SQL/connect/jdbc/configuring-the-client-for-ssl-encryption?view=sql-server-2017)을 참조하십시오. 연결 문자열에 `trustStore=path-to-certificate-trust-store-file`을 추가하여 신뢰할 수 있는 CA 인증서 파일 이름을 직접 제공할 수도 있습니다.
**참고**
연결 문자열에 `TrustServerCertificate=true`(또는 이와 동등한)를 사용하면 연결 프로세스가 트러스트 체인 검증을 건너뜁니다. 이 경우 인증서를 검증할 수 없는 경우에도 애플리케이션이 연결됩니다. `TrustServerCertificate=false` 사용은 인증서 검증을 강제하며, 이것이 모범 사례입니다.
## 애플리케이션 트러스트 스토어 업데이트
Microsoft SQL Server를 사용하는 애플리케이션의 트러스트 스토어를 업데이트할 수 있습니다. 지침은 [특정 연결 암호화](SQLServer.Concepts.General.SSL.Using.md#SQLServer.Concepts.General.SSL.Client) 단원을 참조하십시오. 또한 Microsoft SQL Server 설명서의 [암호화를 위한 클라이언트 구성](https://docs.microsoft.com/en-us/SQL/connect/jdbc/configuring-the-client-for-ssl-encryption?view=sql-server-2017)을 참조하십시오.
Microsoft Windows 이외의 운영 체제를 사용하는 경우 새 루트 CA 인증서 추가에 대한 정보는 SSL/TLS 구현을 위한 소프트웨어 배포 설명서를 참조하십시오. 예를 들어 OpenSSL 및 GnuTLS가 널리 사용되는 옵션입니다. 이 구현 방법을 사용하여 RDS 루트 CA 인증서에 신뢰를 추가하십시오. Microsoft는 일부 시스템에 대한 인증서 구성 지침을 제공합니다.
루트 인증서 다운로드에 대한 자세한 내용은 [SSL/TLS를 사용하여 DB 인스턴스 또는 클러스터 에 대한 연결 암호화](UsingWithRDS.SSL.md) 단원을 참조하십시오.
인증서를 가져오는 샘플 스크립트는 [트러스트 스토어로 인증서를 가져오기 위한 샘플 스크립트](UsingWithRDS.SSL-certificate-rotation.md#UsingWithRDS.SSL-certificate-rotation-sample-script) 섹션을 참조하세요.
**참고**
트러스트 스토어를 업데이트할 때 새 인증서를 추가할 뿐 아니라 이전 인증서를 유지할 수도 있습니다.
## Microsoft SQL Server DB 인스턴스에 대한 규정 준수 프로그램 지원
AWS 범위 내 서비스는 외부 감사 기관의 철저한 평가를 거쳐 인증, 규정 준수 증명 또는 운영 권한(ATO)을 받았습니다. 자세한 내용은 [규정 준수 프로그램 제공 범위 내 AWS 서비스](https://aws.amazon.com/compliance/services-in-scope/)를 참조하세요.
### Microsoft SQL Server DB 인스턴스에 대한 HIPAA 지원
Amazon RDS for Microsoft SQL Server 데이터베이스를 사용하여 HIPAA 인증 애플리케이션을 개발할 수 있습니다. 예를 들어 AWS와 체결한 비즈니스 제휴 계약(BAA)에 따라 보호 대상 건강 정보(PHI)를 비롯한 의료 관련 정보를 저장할 수 있습니다. 자세한 내용은 [HIPAA 규정 준수](https://aws.amazon.com/compliance/hipaa-compliance/)를 참조하십시오.
Amazon RDS for SQL Server는 다음과 같은 버전 및 에디션에서 HIPAA를 지원합니다.
+ SQL Server 2022 Enterprise, Standard 및 Web Edition
+ SQL Server 2019 Enterprise, Standard 및 Web Edition
+ SQL Server 2017 Enterprise, Standard 및 Web Edition
+ SQL Server 2016 Enterprise, Standard 및 Web Edition
DB 인스턴스에서 HIPAA 지원을 활성화하려면 다음과 같이 세 가지 구성 요소를 설정해야 합니다.
****
| 구성 요소 | 세부 정보 |
| --- | --- |
| 감사 | 감사를 설정하려면 파라미터 `rds.sqlserver_audit`을 값 `fedramp_hipaa`로 설정합니다. DB 인스턴스가 아직 사용자 지정 DB 파라미터 그룹을 사용하지 않는 경우에는 `rds.sqlserver_audit` 파라미터를 수정하기 전에 먼저 사용자 그룹 파라미터를 생성한 후 DB 인스턴스에 연결해야 합니다. 자세한 내용은 [Amazon RDS의 파라미터 그룹](USER_WorkingWithParamGroups.md) 섹션을 참조하세요. |
| 전송 데이터 암호화 | 전송 데이터 암호화를 설정하려면 모든 DB 인스턴스 연결에 강제로 SSL(Secure Sockets Layer)을 사용해야 합니다. 자세한 내용은 [DB 인스턴스 연결이 SSL을 사용하도록 지정](SQLServer.Concepts.General.SSL.Using.md#SQLServer.Concepts.General.SSL.Forcing) 섹션을 참조하세요. |
| 유휴 시 암호화 | 저장 데이터 암호화의 설정은 다음과 같이 두 가지 옵션이 있습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html) |
# Amazon RDS의 Microsoft SQL Server 버전
새 DB 인스턴스를 생성할 때는 현재 지원되는 모든 Microsoft SQL Server 버전을 지정할 수 있습니다. Microsoft SQL Server 메이저 버전(예: Microsoft SQL Server 14.00) 및 지정된 메이저 버전에 대해 지원되는 모든 마이너 버전을 지정할 수 있습니다. 버전이 지정되지 않은 경우 Amazon RDS는 지원되는 버전(보통 최신 버전)을 기본값으로 설정합니다. 메이저 버전이 지정되었지만 마이너 버전이 지정되지 않은 경우, Amazon RDS는 고객이 지정한 메이저 버전의 최근 릴리스를 기본값으로 설정합니다.
다음 표에는 명시된 경우를 제외하고 모든 버전 및 모든 AWS 리전에서 지원되는 SQL Server 버전이 나와 있습니다.
**참고**
지원되는 버전 목록과 새로 만든 DB 인스턴스의 기본값을 보려면 [describe-db-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) AWS CLI 명령을 사용할 수도 있습니다. [describe-db-major-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-major-engine-versions.html) AWS CLI 명령을 실행하거나 [DescribeDBMajorEngineVersions](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBMajorEngineVersions.html) RDS API 작업을 사용하여 SQL Server 데이터베이스의 메이저 버전을 볼 수 있습니다.
| 메이저 버전 | 마이너 버전 | RDS API `EngineVersion` 및 CLI `engine-version` |
| --- | --- | --- |
| SQL Server 2022 | 16.00.4236.2(CU23) 16.00.4230.2(CU22 GDR) 16.00.4225.2(CU22) 16.00.4215.2(CU21) 16.00.4210.1(CU20 GDR) 16.00.4205.1(CU20) 16.00.4195.2(CU19) 16.00.4185.3(CU18) 16.00.4175.1(CU17) 16.00.4165.4(CU16) 16.00.4150.1(CU15) 16.00.4140.3(CU14 GDR) 16.00.4135.4(CU14) 16.00.4131.2(CU13) 16.00.4125.3(CU13) 16.00.4120.1(CU12 GDR) 16.00.4115.5(CU12) 16.00.4105.2(CU11) 16.00.4095.4(CU10) 16.00.4085.2(CU9) | `16.00.4236.2.v1` `16.00.4230.2.v1` `16.00.4225.2.v1` `16.00.4215.2.v1` `16.00.4210.1.v1` `16.00.4205.1.v1` `16.00.4195.2.v1` `16.00.4185.3.v1` `16.00.4175.1.v1` `16.00.4165.4.v1` `16.00.4150.1.v1` `16.00.4140.3.v1` `16.00.4135.4.v1` `16.00.4131.2.v1` `16.00.4125.3.v1` `16.00.4120.1.v1` `16.00.4115.5.v1` `16.00.4105.2.v1` `16.00.4095.4.v1` `16.00.4085.2.v1` |
| SQL Server 2019 | 15.00.4455.2(CU32 GDR) 15.00.4445.1(CU32 GDR) 15.00.4440.1(CU32 GDR) 15.00.4435.7(CU32) 15.00.4430.1(CU32) 15.00.4420.2(CU31) 15.00.4415.2(CU30) 15.00.4410.1(CU29 GDR) 15.00.4395.2(CU28) 15.00.4390.2(CU28) 15.00.4385.2(CU28) 15.00.4382.1(CU27) 15.00.4375.4(CU27) 15.00.4365.2(CU26) 15.00.4355.3(CU25) 15.00.4345.5(CU24) 15.00.4335.1(CU23) 15.00.4322.2(CU22) 15.00.4316.3(CU21) 15.00.4312.2(CU20) 15.00.4236.7(CU16) 15.00.4198.2(CU15) 15.00.4153.1(CU12) 15.00.4073.23(CU8) 15.00.4043.16(CU5) | `15.00.4455.2.v1` `15.00.4445.1.v1` `15.00.4440.1.v1` `15.00.4435.7.v1` `15.00.4430.1.v1` `15.00.4420.2.v1` `15.00.4415.2.v1` `15.00.4410.1.v1` `15.00.4395.2.v1` `15.00.4390.2.v1` `15.00.4385.2.v1` `15.00.4382.1.v1` `15.00.4375.4.v1` `15.00.4365.2.v1` `15.00.4355.3.v1` `15.00.4345.5.v1` `15.00.4335.1.v1` `15.00.4322.2.v1` `15.00.4316.3.v1` `15.00.4312.2.v1` `15.00.4236.7.v1` `15.00.4198.2.v1` `15.00.4153.1.v1` `15.00.4073.23.v1` `15.00.4043.16.v1` |
| SQL Server 2017 | 14.00.3515.1(CU31 GDR) 14.00.3505.1(CU31 GDR) 14.00.3500.1.(CU31 GDR) 14.00.3495.9(CU31 GDR) 14.00.3485.1(CU31 GDR) 14.00.3480.1(CU31) 14.00.3475.1(CU31) 14.00.3471.2(CU31) 14.00.3465.1(CU31) 14.00.3460.9(CU31) 14.00.3451.2(CU30) 14.00.3421.10(CU27) 14.00.3401.7(CU25) 14.00.3381.3(CU23) 14.00.3356.20(CU22) 14.00.3294.2(CU20) 14.00.3281.6(CU19) | `14.00.3515.1.v1` `14.00.3505.1.v1` `14.00.3500.1.v1` `14.00.3495.9.v1` `14.00.3485.1.v1` `14.00.3480.1.v1` `14.00.3475.1.v1` `14.00.3471.2.v1` `14.00.3465.1.v1` `14.00.3460.9.v1` `14.00.3451.2.v1` `14.00.3421.10.v1` `14.00.3401.7.v1` `14.00.3381.3.v1` `14.00.3356.20.v1` `14.00.3294.2.v1` `14.00.3281.6.v1` |
| SQL Server 2016 | 13.00.6475.1(GDR) 13.00.6470.1(GDR) 13.00.6465.1(GDR) 13.00.6460.7(GDR) 13.00.6455.2(GDR) 13.00.6450.1(GDR) 13.00.6445.1(GDR) 13.00.6441.1(GDR) 13.00.6435.1(GDR) 13.00.6430.49(GDR) 13.00.6419.1(SP3 \$1 Hotfix) 13.00.6300.2(SP3) | `14.00.6475.1.v1` `14.00.6470.1.v1` `13.00.6465.1.v1` `13.00.6460.7.v1` `13.00.6455.2.v1` `13.00.6450.1.v1` `13.00.6445.1.v1` `13.00.6441.1.v1` `13.00.6435.1.v1` `13.00.6430.49.v1` `13.00.6419.1.v1` `13.00.6300.2.v1` |
## Amazon RDS의 버전 관리
Amazon RDS에는 DB 인스턴스가 패치되거나 업그레이드되는 시기와 방법을 제어할 수 있는 유연한 버전 관리가 포함됩니다. 이렇게 하면 DB 엔진에 대해 다음을 수행할 수 있습니다.
+ 데이터베이스 엔진 패치 버전과의 호환성을 유지합니다.
+ 새로운 패치 버전을 테스트하여 프로덕션에 배포하기 전에 애플리케이션에서 잘 작동하는지 확인합니다.
+ 서비스 수준 계약 및 타이밍 요구 사항을 충족하도록 버전 업그레이드 계획 및 수행합니다.
### Amazon RDS의 Microsoft SQL Server 엔진 패치
Amazon RDS는 공식 Microsoft SQL Server 데이터베이스 패치를 정기적으로 Amazon RDS에 해당하는 DB 인스턴스 엔진 버전으로 집계합니다. 각 엔진 버전의 Microsoft SQL Server 패치에 대한 자세한 내용은 [Amazon RDS 기반 버전 및 기능 지원](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html#SQLServer.Concepts.General.FeatureSupport)을 참조하십시오.
현재 DB 인스턴스에서 모든 엔진 업그레이드를 수동으로 수행합니다. 자세한 내용은 [Microsoft SQL Server DB 엔진 업그레이드](USER_UpgradeDBInstance.SQLServer.md) 섹션을 참조하세요.
### Amazon RDS 기반 Microsoft SQL Server의 메이저 엔진 버전의 사용 중단 일정
다음 표에는 Microsoft SQL Server에 예정된 메이저 엔진 버전의 사용 중단 일정이 표시됩니다.
| 날짜 | 정보 |
| --- | --- |
| 2026년 7월 14일 | Microsoft는 SQL Server 2016에 대한 중요 패치 업데이트를 중단합니다. 자세한 내용은 Microsoft 설명서에서 [Microsoft SQL Server 2016](https://learn.microsoft.com/en-us/lifecycle/products/sql-server-2016)를 참조하세요. |
| 2026년 7월 14일 | Amazon RDS는 SQL Server에 대한 Microsoft SQL Server 2016 on RDS의 지원을 종료할 계획입니다. 지원 종료 시 나머지 인스턴스는 SQL Server 2017로 마이그레이션되도록 예약됩니다(최신 마이너 버전 사용 가능). 자세한 내용은 [공지 사항: Microsoft SQL Server 2016에 대한 Amazon RDS for SQL Server 지원 종료](https://repost.aws/articles/ARGkeWligDSU-MQgBwUQj0nA/announcement-amazon-rds-for-sql-server-ending-support-for-microsoft-sql-server-2016)를 참조하세요. Microsoft SQL Server 2016에서 자동으로 업그레이드하지 않으려면 편리하게 한 번에 업그레이드할 수 있습니다. 자세한 내용은 [DB 인스턴스 엔진 버전 업그레이드](USER_UpgradeDBInstance.Upgrading.md) 섹션을 참조하세요. |
| 2026년 1월 15일 | Amazon RDS는 Microsoft SQL Server 2016를 사용한 SQL Server DB 인스턴스용 신규 RDS 생성을 비활성화하기 시작합니다. 자세한 내용은 [공지 사항: Microsoft SQL Server 2016에 대한 Amazon RDS for SQL Server 지원 종료](https://repost.aws/articles/ARGkeWligDSU-MQgBwUQj0nA/announcement-amazon-rds-for-sql-server-ending-support-for-microsoft-sql-server-2016)를 참조하세요. |
| 2024년 7월 9일 | Microsoft는 SQL Server 2014에 대한 중요 패치 업데이트를 중단합니다. 자세한 내용은 Microsoft 설명서에서 [Microsoft SQL Server 2014](https://learn.microsoft.com/en-us/lifecycle/products/sql-server-2014)를 참조하세요. |
| 2024년 6월 1일 | Amazon RDS는 RDS for SQL Server에서 Microsoft SQL Server 2014의 지원을 종료할 계획입니다. 지원 종료 시 나머지 인스턴스는 SQL Server 2016으로 마이그레이션되도록 예약됩니다(최신 마이너 버전 사용 가능). 자세한 내용은 [공지 사항: SQL Server 2014 메이저 버전에 대한 Amazon RDS for SQL Server 지원 종료](https://repost.aws/articles/AR-eyAH1PSSuevuZRUE9FV3A)를 참조하세요. Microsoft SQL Server 2014에서 자동으로 업그레이드하지 않으려면 편리한 시간에 업그레이드할 수 있습니다. 자세한 내용은 [DB 인스턴스 엔진 버전 업그레이드](USER_UpgradeDBInstance.Upgrading.md) 섹션을 참조하세요. |
| 2022년 7월 12일 | Microsoft는 SQL Server 2012에 대한 중요 패치 업데이트를 중단합니다. 자세한 내용은 Microsoft 설명서에서 [Microsoft SQL Server 2012](https://docs.microsoft.com/en-us/lifecycle/products/microsoft-sql-server-2012)를 참조하세요. |
| 2022년 6월 1일 | Amazon RDS는 SQL Server에 대한 Microsoft SQL Server 2012 on RDS의 지원을 종료할 계획입니다. 지원 종료 시 나머지 인스턴스는 SQL Server 2014로 마이그레이션되도록 예약됩니다(최신 마이너 버전 사용 가능). 자세한 내용은 [공지 사항: SQL Server 2012 메이저 버전에 대한 Amazon RDS for SQL Server 지원 종료](https://repost.aws/questions/QUFNiETqrMQ_WT_AXSxOYNOA)를 참조하세요. Microsoft SQL Server 2012에서 자동으로 업그레이드하지 않으려면 편리하게 한 번에 업그레이드할 수 있습니다. 자세한 내용은 [DB 인스턴스 엔진 버전 업그레이드](USER_UpgradeDBInstance.Upgrading.md) 섹션을 참조하세요. |
| 2021년 9월 1일 | Amazon RDS는 Microsoft SQL Server 2012를 사용한 SQL Server DB 인스턴스용 신규 RDS 생성을 비활성화하기 시작합니다. 자세한 내용은 [공지 사항: SQL Server 2012 메이저 버전에 대한 Amazon RDS for SQL Server 지원 종료](https://repost.aws/questions/QUFNiETqrMQ_WT_AXSxOYNOA)를 참조하세요. |
| 2019년 7월 12일 | Amazon RDS 팀은 Microsoft SQL Server 2008 R2에 대한 지원을 2019년 6월부터 중단하였습니다. Microsoft SQL Server 2012 R2의 나머지 인스턴스는 SQL Server 2012로 마이그레이션되고 있습니다(최신 마이너 버전 사용 가능). Microsoft SQL Server 2008 R2에서 자동으로 업그레이드하지 않으려면 편리하게 한 번에 업그레이드할 수 있습니다. 자세한 내용은 [DB 인스턴스 엔진 버전 업그레이드](USER_UpgradeDBInstance.Upgrading.md) 섹션을 참조하세요. |
| 2019년 4월 25일 | 2019년 4월 말 이전에는 더 이상 Microsoft SQL Server 2008 R2를 사용하여 새로운 Amazon RDS for SQL Server 데이터베이스 인스턴스를 만들 수 없습니다. |
# Amazon RDS의 Microsoft SQL Server 기능
Amazon RDS에서 지원되는 SQL 서버 버전에는 다음과 같은 기능이 포함되어 있습니다. 일반적으로 Microsoft 설명서에 다른 언급이 없는 경우 각 버전에는 이전 버전의 기능도 포함됩니다.
**Topics**
+ [Microsoft SQL Server 2022 기능](#SQLServer.Concepts.General.FeatureSupport.2022)
+ [Microsoft SQL Server 2019 기능](#SQLServer.Concepts.General.FeatureSupport.2019)
+ [Microsoft SQL Server 2017 기능](#SQLServer.Concepts.General.FeatureSupport.2017)
+ [Microsoft SQL Server 2016 기능](#SQLServer.Concepts.General.FeatureSupport.2016)
+ [Amazon RDS에서 Microsoft SQL Server 2014 지원 종료](#SQLServer.Concepts.General.FeatureSupport.2014)
+ [Amazon RDS에서 Microsoft SQL Server 2012 지원 종료](#SQLServer.Concepts.General.FeatureSupport.2012)
+ [Amazon RDS에서 Microsoft SQL Server 2008 R2 지원 종료](#SQLServer.Concepts.General.FeatureSupport.2008)
+ [Microsoft SQL Server DB 인스턴스에 대한 변경 데이터 캡처 지원](SQLServer.Concepts.General.CDC.md)
+ [지원되지 않는 기능과 지원이 제한된 기능](SQLServer.Concepts.General.FeatureNonSupport.md)
## Microsoft SQL Server 2022 기능
SQL Server 2022는 다음과 같은 새 기능을 많이 제공합니다.
+ 파라미터를 중시하는 계획 최적화 - 파라미터화된 단일 문에 대해 여러 개의 캐시된 계획을 허용하여 파라미터 스니핑과 관련된 문제를 잠재적으로 줄일 수 있습니다.
+ SQL Server 원장 - 데이터가 승인 없이 변경되지 않았음을 암호로 증명할 수 있는 기능을 제공합니다.
+ 트랜잭션 로그 파일 증가 이벤트에 대한 즉각적인 파일 초기화 - TDE가 활성화된 데이터베이스를 포함하여 최대 64MB의 로그 증가 이벤트를 더 빠르게 실행할 수 있습니다.
+ 시스템 페이지 래치 동시성 향상 - 데이터 페이지 및 범위를 할당 및 할당 해제하는 동안 페이지 래치 경합을 줄여 과중한 `tempdb` 워크로드의 성능을 크게 향상시킵니다.
SQL Server 2022의 전체 기능 목록은 Microsoft 설명서의 [What's new in SQL Server 2022(16.x)](https://learn.microsoft.com/en-us/sql/sql-server/what-s-new-in-sql-server-2022?view=sql-server-ver16) 섹션을 참조하세요.
지원되지 않는 기능 목록은 [지원되지 않는 기능과 지원이 제한된 기능](SQLServer.Concepts.General.FeatureNonSupport.md) 섹션을 참조하세요.
## Microsoft SQL Server 2019 기능
SQL Server 2019는 다음과 같은 새 기능을 많이 제공합니다.
+ 가속 데이터베이스 복구(ADR) – 재시작 또는 장기 실행 트랜잭션 롤백 후 크래시 복구 시간을 줄입니다.
+ 지능형 쿼리 처리(IQP):
+ 행 모드 메모리 부여 피드백 – 과도한 부여를 자동으로 수정합니다. 그렇지 않으면 메모리가 낭비되고 동시성이 감소합니다.
+ Rowstore의 배치 모드 – Columnstore 인덱스를 요구하지 않고 분석 워크로드에 대해 배치 모드 실행을 활성화합니다.
+ 테이블 변수 지연 컴파일 – 테이블 변수를 참조하는 쿼리의 계획 품질 및 전반적인 성능을 개선합니다.
+ 지능적인 성능:
+ `OPTIMIZE_FOR_SEQUENTIAL_KEY` 인덱스 옵션 – 인덱스에 대한 동시성이 높은 삽입의 처리량을 개선합니다.
+ 향상된 간접 체크포인트 확장성 – DML 워크로드가 많은 데이터베이스를 지원합니다.
+ 동시 페이지 여유 공간(PFS) 업데이트 – 전용 래치가 아닌 공유 래치로 처리할 수 있습니다.
+ 모니터링 개선:
+ `WAIT_ON_SYNC_STATISTICS_REFRESH` 대기 유형 – 동기식 통계 새로 고침 작업에 소요된 누적된 인스턴스 수준 시간을 표시합니다.
+ 데이터베이스 범위 구성 –에는 `LIGHTWEIGHT_QUERY_PROFILING` 및 `LAST_QUERY_PLAN_STATS`가 포함됩니다.
+ 동적 관리 기능(DMF) –에는 `sys.dm_exec_query_plan_stats` 및 `sys.dm_db_page_info`가 포함합니다.
+ 상세 표시 잘림 경고 – 데이터 잘림 오류 메시지는 기본적으로 테이블 및 열 이름과 잘려진 값을 포함합니다.
+ 다시 시작 가능한 온라인 인덱스 생성 – SQL Server 2017에서는 다시 시작 가능한 온라인 인덱스 재구축만 지원됩니다.
SQL Server 2019의 전체 기능 목록은 Microsoft 설명서의 [What's new in SQL Server 2019(15.x)](https://docs.microsoft.com/en-us/sql/sql-server/what-s-new-in-sql-server-ver15) 섹션을 참조하세요.
지원되지 않는 기능 목록은 [지원되지 않는 기능과 지원이 제한된 기능](SQLServer.Concepts.General.FeatureNonSupport.md) 단원을 참조하십시오.
## Microsoft SQL Server 2017 기능
SQL Server 2017은 다음과 같은 새 기능을 많이 제공합니다.
+ 적응형 쿼리 처리
+ 자동 계획 수정(자동 튜닝 기능)
+ 그래프DB
+ 다시 시작 가능한 인덱스 재작성
SQL Server 2017의 전체 기능 목록은 Microsoft 설명서의 [What's new in SQL Server 2017](https://docs.microsoft.com/en-us/sql/sql-server/what-s-new-in-sql-server-2017) 단원을 참조하십시오.
지원되지 않는 기능 목록은 [지원되지 않는 기능과 지원이 제한된 기능](SQLServer.Concepts.General.FeatureNonSupport.md) 단원을 참조하십시오.
## Microsoft SQL Server 2016 기능
Amazon RDS는 다음과 같은 SQL Server 2016 기능을 지원합니다.
+ 항상 암호화
+ JSON 지원
+ 운영 분석
+ 쿼리 저장
+ 임시 테이블
SQL Server 2016의 전체 기능 목록은 Microsoft 설명서의 [What's new in SQL Server 2016](https://docs.microsoft.com/en-us/sql/sql-server/what-s-new-in-sql-server-2016) 단원을 참조하십시오.
## Amazon RDS에서 Microsoft SQL Server 2014 지원 종료
SQL Server 2014는 Amazon RDS에서 지원이 종료되었습니다.
RDS는 여전히 SQL Server 2014를 사용하는 모든 기존 DB 인스턴스를 SQL Server 2016의 최신 마이너 버전으로 업그레이드하고 있습니다. 자세한 내용은 [Amazon RDS의 버전 관리](SQLServer.Concepts.General.VersionSupport.md#SQLServer.Concepts.General.Version-Management) 섹션을 참조하세요.
## Amazon RDS에서 Microsoft SQL Server 2012 지원 종료
Amazon RDS에서 Microsoft SQL Server 2012 지원 종료
RDS는 여전히 SQL Server 2012를 사용하는 모든 기존 DB 인스턴스를 SQL Server 2016의 최신 마이너 버전으로 업그레이드하고 있습니다. 자세한 내용은 [Amazon RDS의 버전 관리](SQLServer.Concepts.General.VersionSupport.md#SQLServer.Concepts.General.Version-Management) 섹션을 참조하세요.
## Amazon RDS에서 Microsoft SQL Server 2008 R2 지원 종료
SQL Server 2008 R2는 Amazon RDS에서 지원이 종료되었습니다.
RDS는 여전히 SQL Server 2008 R2를 사용하는 모든 기존 DB 인스턴스를 SQL Server 2012의 최신 마이너 버전으로 업그레이드하고 있습니다. 자세한 내용은 [Amazon RDS의 버전 관리](SQLServer.Concepts.General.VersionSupport.md#SQLServer.Concepts.General.Version-Management) 섹션을 참조하세요.
# Microsoft SQL Server DB 인스턴스에 대한 변경 데이터 캡처 지원
Amazon RDS는 Microsoft SQL Server를 실행하는 DB 인스턴스에 대해 CDC(변경 데이터 캡처)를 지원합니다. CDC는 테이블의 데이터에 수행된 변경 사항을 캡처하고 각 변경 사항에 대해 나중에 액세스할 수 있는 메타데이터를 저장합니다. 자세한 내용은 Microsoft 설명서의 [변경 데이터 캡처](https://docs.microsoft.com/en-us/sql/relational-databases/track-changes/track-data-changes-sql-server#Capture)를 참조하십시오.
Amazon RDS는 다음 SQL Server 에디션과 버전에 대해 CDC를 지원합니다.
+ Microsoft SQL Server Enterprise Edition(모든 버전)
+ Microsoft SQL Server Standard Edition:
+ 2022
+ 2019
+ 2017
+ 2016 버전 13.00.4422.0 SP1 CU2 이상
Amazon RDS DB 인스턴스에 CDC를 사용하려면 먼저 RDS의 저장 프로시저를 사용하여 데이터베이스 수준에서 CDC를 활성화하거나 비활성화합니다. 그런 후에는 해당 데이터베이스에 대해 `db_owner` 역할이 있는 모든 사용자가 기본 Microsoft 저장 프로시저를 사용하여 해당 데이터베이스에서 CDC를 제어할 수 있습니다. 자세한 내용은 [Amazon RDS for SQL Server에 변경 데이터 캡처 사용](Appendix.SQLServer.CommonDBATasks.CDC.md) 단원을 참조하십시오.
CDC와 AWS Database Migration Service를 사용하여 SQL Server DB 인스턴스에서 지속적 복제를 활성화할 수 있습니다.
# 지원되지 않는 기능과 지원이 제한된 기능
다음 Microsoft SQL Server 기능은 Amazon RDS에서 지원되지 않습니다.
+ Microsoft Azure Blob Storage로 백업
+ 버퍼 풀 확장
+ 사용자 지정 암호 정책
+ 데이터 품질 서비스
+ 데이터베이스 로그 전달
+ 데이터베이스 스냅샷(Amazon RDS는 DB 인스턴스 스냅샷만 지원)
+ xp\$1cmdshell을 포함한 저장 프로시저 확장
+ FILESTREAM 지원
+ 파일 테이블
+ Machine Learning 및 R 서비스(설치를 위해 OS 액세스 필요)
+ 유지 관리 계획
+ 성능 데이터 수집기
+ 정책 기반 관리
+ PolyBase
+ 복제
+ 서버 수준 트리거
+ 서비스 브로커 엔드포인트
+ Stretch 데이터베이스
+ 신뢰할 수 있는 데이터베이스 속성(sysadmin 역할 필요)
+ T-SQL 엔드포인트(CREATE ENDPOINT를 사용하는 모든 작업을 사용할 수 없음)
+ WCF 데이터 서비스
다음 Microsoft SQL Server 기능은 Amazon RDS에서 지원이 제한적입니다.
+ 분산 쿼리/연결된 서버 자세한 내용은 [Implementing Linked Servers with Amazon RDS for Microsoft SQL Server](https://aws.amazon.com/blogs/database/implement-linked-servers-with-amazon-rds-for-microsoft-sql-server/)를 참조하세요.
+ CLR(공용 런타임 언어). RDS for SQL Server 2016 이하 버전에서 CLR은 `SAFE` 모드에서 지원되며 어셈블리 비트만 사용합니다. CLR은 RDS for SQL Server 2017 이상 버전에서 지원되지 않습니다. 자세한 내용은 Microsoft 설명서의 [공용 런타임 언어 통합](https://docs.microsoft.com/en-us/sql/relational-databases/clr-integration/common-language-runtime-integration-overview)을 참조하세요.
+ Amazon RDS for SQL Server에서 Oracle OLEDB와 서버를 연결합니다. 자세한 내용은 [Amazon RDS for SQL Server의 Oracle OLEDB 포함 연결된 서버 지원](Appendix.SQLServer.Options.LinkedServers_Oracle_OLEDB.md) 섹션을 참조하세요.
다음 기능은 SQL Server 2022가 설치된 Amazon RDS에서는 지원되지 않습니다.
+ 스냅샷을 위해 데이터베이스 일시 중지
+ 외부 데이터 소스
+ S3 호환 객체 스토리지로 백업 및 복원
+ 객체 스토어 통합
+ TLS 1.3 및 MS-TDS 8.0
+ QAT를 통한 백업 압축 오프로드
+ SSAS(SQL Server Analysis Services)
+ 다중 AZ 배포에서 데이터베이스 미러링. 다중 AZ 배포에서 지원되는 유일한 방법은 SQL Server Always On입니다.
## Microsoft SQL Server 데이터베이스 미러링 또는 상시 가동 가용성 그룹을 사용하여 다중 AZ 배포
Amazon RDS는 SQL Server 데이터베이스 미러링(DBM) 또는 상시 가동 가용성 그룹(AG)을 사용하여 Microsoft SQL Server 기반 DB 인스턴스의 다중 AZ 배포를 지원합니다. 다중 AZ 배포는 DB 인스턴스를 위해 향상된 가용성, 데이터 내구성 및 내결함성을 제공합니다. 계획된 데이터베이스 유지 관리 또는 예기치 않은 서비스 중단이 발생할 경우 Amazon RDS가 최신 보조 복제본으로 자동으로 장애 조치를 수행하므로 수동 개입 없이 데이터베이스 작업을 빠르게 재개할 수 있습니다. 기본 인스턴스 및 보조 인스턴스는 동일한 엔드포인트를 사용합니다. 이 엔드포인트의 물리적 네트워크 주소는 장애 조치 프로세스의 일환으로 수동 보조 복제본으로 전환됩니다. 장애 조치가 발생하는 경우 애플리케이션을 다시 구성할 필요가 없습니다.
Amazon RDS는 다중 AZ 배포를 능동적으로 모니터링하면서 기본 인스턴스에 문제가 발생할 때 장애 조치를 시작하여 장애 조치를 관리합니다. 대기 및 기본 인스턴스가 완벽히 동기화되어 있지 않는 한 장애 조치가 발생하지 않습니다. Amazon RDS는 비정상 DB 인스턴스를 자동으로 복구하고 동기식 복제를 다시 설정하여 다중 AZ 배포를 자동으로 유지합니다. 사용자가 따로 관리할 것이 없습니다. 따라서 Amazon RDS가 기본 인스턴스, 감시 인스턴스, 대기 인스턴스를 자동으로 처리합니다. SQL Server 다중 AZ를 설정하면 RDS가 인스턴스의 모든 데이터베이스에 대해 수동 보조 인스턴스를 구성합니다.
자세한 내용은 [Amazon RDS for Microsoft SQL Server의 다중 AZ 배포](USER_SQLServerMultiAZ.md) 섹션을 참조하세요.
## Transparent Data Encryption을 사용하여 유휴 데이터 암호화
Amazon RDS는 저장되어 있는 데이터를 자동으로 암호화할 수 있는 Microsoft SQL Server Transparent Data Encryption(TDE)을 지원합니다. Amazon RDS는 옵션 그룹을 사용하여 이러한 기능을 활성화하고 구성합니다. TDE 옵션에 대한 자세한 내용은 [SQL Server에서 TDE(투명한 데이터 암호화) 지원](Appendix.SQLServer.Options.TDE.md) 섹션을 참조하십시오.
# Amazon RDS for Microsoft SQL Server에 대한 함수 및 저장 프로시저
아래에서 SQL Server 태스크를 자동화하는 데 도움이 되는 Amazon RDS 함수 및 저장 프로시저 목록을 확인할 수 있습니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/SQLServer.Concepts.General.StoredProcedures.html)
# Microsoft SQL Server DB 인스턴스의 현지 시간대
Microsoft SQL Server를 실행 중인 Amazon RDS DB 인스턴스의 시간대가 기본적으로 설정되어 있습니다. 현재 기본값은 협정 세계시(UTC)입니다. DB 인스턴스의 시간대를 애플리케이션의 시간대와 일치하도록 현지 시간대로 설정할 수 있습니다.
DB 인스턴스를 처음 만들 때 시간대를 설정합니다. [AWS Management Console](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateDBInstance.html), Amazon RDS API [CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html.html) 작업 또는 AWS CLI [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) 명령을 사용하여 DB 인스턴스를 생성할 수 있습니다.
DB 인스턴스가 다중 AZ 배포의 일부인 경우(SQL Server DBM 또는 AG 사용) 장애 조치 중에 시간대가 설정된 현지 시간대로 유지됩니다. 자세한 내용은 [Microsoft SQL Server 데이터베이스 미러링 또는 상시 가동 가용성 그룹을 사용하여 다중 AZ 배포](CHAP_SQLServer.md#SQLServer.Concepts.General.Mirroring) 섹션을 참조하세요.
시점 복원을 요청할 경우 복원 시간을 지정합니다. 시간은 현지 시간대로 표시됩니다. 자세한 내용은 [Amazon RDS에서 DB 인스턴스를 지정된 시간으로 복원](USER_PIT.md) 섹션을 참조하세요.
다음은 DB 인스턴스에 대해 현지 시간대를 설정할 때 적용되는 제한 사항입니다.
+ 기존 SQL Server DB 인스턴스의 시간대를 수정할 수 없습니다.
+ DB 인스턴스의 스냅샷을 다른 시간대의 DB 인스턴스로 복원할 수 없습니다.
+ 한 표준 시간대의 백업 파일을 다른 표준 시간대로 복원하지 않는 것이 좋습니다. 한 표준 시간대의 백업 파일을 다른 표준 시간대로 복원하는 경우 쿼리와 애플리케이션을 감사하여 표준 시간대 변경의 영향을 확인해야 합니다. 자세한 내용은 [기본 백업 및 복원 기능을 사용하여 SQL Server 데이터베이스 가져오기 및 내보내기](SQLServer.Procedural.Importing.md) 섹션을 참조하세요.
## 지원되는 시간대
현지 시간대를 다음 표에 나열된 값 중 하나로 설정할 수 있습니다.
| 시간대 | 표준 시간 오프셋 | 설명 | 참고 |
| --- | --- | --- | --- |
| 아프가니스탄 표준시 | (UTC\$104:30) | 카불 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| 알래스카 표준시 | (UTC–09:00) | 알래스카 | |
| 알류샨 표준시 | (UTC–10:00) | 알류샨 열도 | |
| 알타이 표준시 | (UTC\$107:00) | 바르나울, 고르노알타이스크 | |
| 아랍 표준시 | (UTC\$103:00) | 쿠웨이트, 리야드 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| 아라비아 표준시 | (UTC\$104:00) | 아부다비, 무스카트 | |
| 아랍 표준시 | (UTC\$103:00) | 바그다드 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| 아르헨티나 표준시 | (UTC–03:00) | 부에노스아이레스 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| 아스트라한 표준시 | (UTC\$104:00) | 아스트라한, 울랴노브스크 | |
| 대서양 표준시 | (UTC–04:00) | 대서양 표준시(캐나다) | |
| AUS 중부 표준시 | (UTC\$109:30) | 다윈 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| 오스트레일리아 중부 표준시 | (UTC\$108:45) | 유클라 | |
| AUS 동부 표준시 | (UTC\$110:00) | 캔버라, 멜버른, 시드니 | |
| 아제르바이잔 표준시 | (UTC\$104:00) | 바쿠 | |
| 아조레스 표준시 | (UTC–01:00) | 아조레스 | |
| 바이아 표준시 | (UTC–03:00) | 살바도르 | |
| 방글라데시 표준시 | (UTC\$106:00) | 다카 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| 벨라루스 표준시 | (UTC\$103:00) | 민스크 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| 부건빌 표준시 | (UTC\$111:00) | 부겐빌 섬 | |
| 캐나다 중부 표준시 | (UTC–06:00) | 서스캐처원 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| 카포베르데 표준시 | (UTC–01:00) | 카포베르데 섬 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| 코카서스 표준시 | (UTC\$104:00) | 예레반 | |
| 중부 오스트레일리아 표준시 | (UTC\$109:30) | 애들레이드 | |
| 중앙 아메리카 표준시 | (UTC–06:00) | 중앙 아메리카 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| 중앙 아시아 표준시 | (UTC\$106:00) | 아스타나 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| 브라질 중부 표준시 | (UTC–04:00) | 쿠이아바 | |
| 중앙 유럽 표준시 | (UTC\$101:00) | 베오그라드, 브라티슬라바, 부다페스트, 류블랴나, 프라하 | |
| 중앙 유럽 표준시 | (UTC\$101:00) | 사라예보, 스코페, 바르샤바, 자그레브 | |
| 중앙 태평양 표준시 | (UTC\$111:00) | 솔로몬 제도, 뉴칼레도니아 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| 중부 표준시 | (UTC–06:00) | 중부 표준시(미국과 캐나다) | |
| 중부 표준시(멕시코) | (UTC–06:00) | 과달라하라, 멕시코 시티, 몬테레이 | |
| 채텀 섬 표준시 | (UTC\$112:45) | 채텀 섬 | |
| 중국 표준시 | (UTC\$108:00) | 베이징, 충칭, 홍콩 특별 행정구, 우루무치 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| 쿠바 표준시 | (UTC–05:00) | 하바나 | |
| 날짜 변경선 표준시 | (UTC–12:00) | 날짜 변경선 서쪽 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| E. 아프리카 표준시 | (UTC\$103:00) | 나이로비 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| E. 오스트레일리아 표준시 | (UTC\$110:00) | 브리즈번 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| E. 유럽 표준시 | (UTC\$102:00) | 키시나우 | |
| E. 남아메리카 표준시 | (UTC–03:00) | 브라질리아 | |
| 이스터 섬 표준시 | (UTC–06:00) | 이스터 섬 | |
| 동부 표준시 | (UTC–05:00) | 동부 표준시(미국과 캐나다) | |
| 동부 표준시(멕시코) | (UTC–05:00) | 체투말 | |
| 이집트 표준시 | (UTC\$102:00) | 카이로 | |
| 예카테린부르크 표준시 | (UTC\$105:00) | 예카테린부르크 | |
| 피지 표준시 | (UTC\$112:00) | 피지 | |
| FLE 표준시 | (UTC\$102:00) | 헬싱키, 키예프, 리가, 소피아, 탈린, 빌뉴스 | |
| 그루지야 표준시 | (UTC\$104:00) | 트빌리시 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| GMT 표준시 | (UTC) | 더블린, 에든버러, 리스본, 런던 | 이 시간대는 그리니치 표준시(GMT)와 다릅니다. 이 시간대는 일광 절약 시간을 준수합니다. |
| 그린란드 표준시 | (UTC–03:00) | 그린란드 | |
| 그리니치 표준시 | (UTC) | 몬로비아, 레이캬비크 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| GTB 표준시 | (UTC\$102:00) | 아테네, 부쿠레슈티 | |
| 아이티 표준시 | (UTC–05:00) | 아이티 | |
| 하와이 표준시 | (UTC–10:00) | 하와이 | |
| 인도 표준시 | (UTC\$105:30) | 첸나이, 콜카타, 뭄바이, 뉴델리 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| 이란 표준시 | (UTC\$103:30) | 테헤란 | |
| 이스라엘 표준시 | (UTC\$102:00) | 예루살렘 | |
| 요르단 표준시 | (UTC\$102:00) | 암만 | |
| 칼리닌그라드 표준시 | (UTC\$102:00) | 칼리닌그라드 | |
| 캄차카 표준시 | (UTC\$112:00) | 페트로파블로프스크-캄차스키 – 이전 | |
| 대한민국 표준시 | (UTC\$109:00) | 서울 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| 리비아 표준시 | (UTC\$102:00) | 트리폴리 | |
| 라인 제도 표준시 | (UTC\$114:00) | 키리티마티 섬 | |
| 로드하우 표준시 | (UTC\$110:30) | 로드하우 섬 | |
| 마가단 표준시 | (UTC\$111:00) | 마가단 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| 마가야네스 표준시 | (UTC–03:00) | 푼타 아레나스 | |
| 마키저스 표준시 | (UTC–09:30) | 마르케사스 제도 | |
| 모리셔스 표준시 | (UTC\$104:00) | 포트루이스 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| 중동 표준시 | (UTC\$102:00) | 베이루트 | |
| 몬테비데오 표준시 | (UTC–03:00) | 몬테비데오 | |
| 모로코 표준시 | (UTC\$101:00) | 카사블랑카 | |
| 산지 표준시 | (UTC–07:00) | 산지 표준시(미국과 캐나다) | |
| 산지 표준시(멕시코) | (UTC–07:00) | 치와와, 라파스, 마사틀란 | |
| 미얀마 표준시 | (UTC\$106:30) | 양곤(랑군) | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| N. 중앙 아시아 표준시 | (UTC\$107:00) | 노보시비르스크 | |
| 나미비아 표준시 | (UTC\$102:00) | 빈트후크 | |
| 네팔 표준시 | (UTC\$105:45) | 카트만두 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| 뉴질랜드 표준시 | (UTC\$112:00) | 오클랜드, 웰링턴 | |
| 뉴펀들랜드 표준시 | (UTC–03:30) | 뉴펀들랜드 | |
| 노퍽 표준시 | (UTC\$111:00) | 노퍽 섬 | |
| 북아시아 동부 표준시 | (UTC\$108:00) | 이르쿠츠크 | |
| 북아시아 표준시 | (UTC\$107:00) | 크라스노야르스크 | |
| 북한 표준시 | (UTC\$109:00) | 평양 | |
| 옴스크 표준시 | (UTC\$106:00) | 옴스크 | |
| 태평양 SA 표준시 | (UTC–03:00) | 산티아고 | |
| 태평양 표준시 | (UTC–08:00) | 태평양 표준시(미국과 캐나다) | |
| 태평양 표준시(멕시코) | (UTC–08:00) | 바하 캘리포니아 | |
| 파키스탄 표준시 | (UTC\$105:00) | 이슬라마바드, 카라치 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| 파라과이 표준시 | (UTC–04:00) | 아순시온 | |
| 로맨스 표준시 | (UTC\$101:00) | 브뤼셀, 코펜하겐, 마드리드, 파리 | |
| 러시아 표준 시간대 10 | (UTC\$111:00) | 초쿠르다흐 | |
| 러시아 표준 시간대 11 | (UTC\$112:00) | 아나디리, 페트로파블로프스크-캄차스키 | |
| 러시아 표준 시간대 3 | (UTC\$104:00) | 이젭스크, 사마라 | |
| 러시아 표준시 | (UTC\$103:00) | 모스크바, 상트페테르부르크, 볼고그라드 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| SA 동부 표준시 | (UTC–03:00) | 카옌, 포르탈레자 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| 태평양 SA 표준시 | (UTC–05:00) | 보고타, 리마, 키토, 리오 브랑코 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| SA 서부 표준시 | (UTC–04:00) | 조지타운, 라파스, 마노스, 산후안 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| 생피에르 표준시 | (UTC–03:00) | 세인트 피에르 미켈론 | |
| 사할린 표준시 | (UTC\$111:00) | 사할린 | |
| 사모아 표준시 | (UTC\$113:00) | 사모아 | |
| 상투메 표준시 | (UTC\$101:00) | 상투메 | |
| 사라토프 표준시 | (UTC\$104:00) | 사라토프 | |
| 동남아시아 표준시 | (UTC\$107:00) | 방콕, 하노이, 자카르타 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| 싱가포르 표준시 | (UTC\$108:00) | 쿠알라룸푸르, 싱가포르 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| 남아프리카 표준시 | (UTC\$102:00) | 하라레, 프리토리아 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| 스리랑카 표준시 | (UTC\$105:30) | 스리자야와르데네푸라 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| 수단 표준시 | (UTC\$102:00) | 하르툼 | |
| 시리아 표준시 | (UTC\$102:00) | 다마스쿠스 | |
| 타이베이 표준시 | (UTC\$108:00) | 타이베이 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| 태즈메이니아 표준시 | (UTC\$110:00) | 호바트 | |
| 토칸틴스 표준시 | (UTC–03:00) | 아라구아이나 | |
| 도쿄 표준시 | (UTC\$109:00) | 오사카, 삿포로, 도쿄 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| 톰스크 표준시 | (UTC\$107:00) | 톰스크 | |
| 통가 표준시 | (UTC\$113:00) | 누쿠알로파 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| 트란스바이칼 표준시 | (UTC\$109:00) | 치타 | |
| 터키 표준시 | (UTC\$103:00) | 이스탄불 | |
| 터크스 케이커스 표준시 | (UTC–05:00) | 터크스 케이커스 | |
| 울란바토르 표준시 | (UTC\$108:00) | 울란바토르 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| 미국 동부 표준시 | (UTC–05:00) | 인디애나(동부) | |
| 미국 산지 표준시 | (UTC–07:00) | 애리조나 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| UTC | UTC | 협정 세계시 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| UTC–02 | (UTC–02:00) | 협정 세계시–02 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| UTC–08 | (UTC–08:00) | 협정 세계시–08 | |
| UTC–09 | (UTC–09:00) | 협정 세계시–09 | |
| UTC–11 | (UTC–11:00) | 협정 세계시–11 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| UTC\$112 | (UTC\$112:00) | 협정 세계시\$112 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| UTC\$113 | (UTC\$113:00) | 협정 세계시\$113 | |
| 베네수엘라 표준시 | (UTC–04:00) | 카라카스 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| 블라디보스토크 표준시 | (UTC\$110:00) | 블라디보스토크 | |
| 볼고그라드 표준시 | (UTC\$104:00) | 볼고그라드 | |
| W. 오스트레일리아 표준시 | (UTC\$108:00) | 퍼스 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| W. 중앙 아프리카 표준시 | (UTC\$101:00) | 서중앙 아프리카 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| W. 유럽 표준시 | (UTC\$101:00) | 암스테르담, 베를린, 베른, 로마, 스톡홀름, 비엔나 | |
| W. 몽골 표준시 | (UTC\$107:00) | 호브드 | |
| 서아시아 표준시 | (UTC\$105:00) | 아슈하바트, 타슈켄트 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| 웨스트 뱅크 표준시 | (UTC\$102:00) | 가자, 헤브론 | |
| 서태평양 표준시 | (UTC\$110:00) | 괌, 포트모르즈비 | 이 시간대는 일광 절약 시간을 준수하지 않습니다. |
| 야쿠츠크 표준시 | (UTC\$109:00) | 야쿠츠크 | |
# Amazon RDS의 Microsoft SQL Server 라이선싱
Microsoft SQL Server용으로 Amazon RDS DB 인스턴스를 설정하는 경우 소프트웨어 라이선스가 포함됩니다.
따라서 SQL Server 라이선스를 별도로 구매할 필요가 없습니다. AWS는 SQL Server 데이터베이스 소프트웨어에 대한 라이선스를 보유합니다. Amazon RDS 요금에는 소프트웨어 라이선스, 기본 하드웨어 리소스 및 Amazon RDS 관리 기능이 포함됩니다.
Amazon RDS는 다음 Microsoft SQL Server 에디션을 지원합니다.
+ 엔터프라이즈
+ 표준
+ 웹
+ Express
**참고**
SQL Server Web Edition은 웹 호스트 및 웹 VAP 인터넷에 액세스할 수 있는 퍼블릭 웹 페이지, 웹 사이트, 웹 애플리케이션 및 웹 서비스를 호스팅하도록 설계되었습니다. 이 지원 수준은 Microsoft의 사용 권한을 준수하는 데 필요합니다. 자세한 내용은 [AWS 서비스 약관](https://aws.amazon.com/serviceterms)을 참조하세요.
Amazon RDS는 SQL Server 데이터베이스 미러링(DBM), 상시 가동 가용성 그룹(AG) 및 SQL Server Web Edition용 블록 수준 복제를 사용하여 Microsoft SQL Server를 실행하는 DB 인스턴스에 대한 다중 AZ 배포를 지원합니다. 다중 AZ 배포에 대한 추가 라이선스 요구 사항은 없습니다. 자세한 내용은 [Amazon RDS for Microsoft SQL Server의 다중 AZ 배포](USER_SQLServerMultiAZ.md) 섹션을 참조하세요.
## 라이선스가 종료된 DB 인스턴스 복원
Amazon RDS는 라이선스 종료된 DB 인스턴스의 스냅샷을 생성합니다. 라이선스 문제로 인스턴스가 종료되는 경우 스냅샷에서 새 DB 인스턴스로 복원할 수 있습니다. 새 DB 인스턴스에는 라이선스가 포함되어 있습니다.
자세한 내용은 [Amazon RDS for SQL Server에 대한 라이선스 종료 DB 인스턴스 복원](Appendix.SQLServer.CommonDBATasks.RestoreLTI.md) 섹션을 참조하세요.
## 개발 및 테스트
개발 및 테스트 시나리오에서는 Express Edition을 사용하여 다양한 개발, 테스트 및 기타 비프로덕션 환경 요구 사항을 충족할 수 있습니다. Developer Edition도 사용할 수 있습니다. 이 버전은 SQL Server Enterprise Edition의 모든 특성을 포함하지만, 비프로덕션 용도로만 라이선스가 부여됩니다. RDS for SQL Server에 SQL Server Developer Edition을 다운로드하여 설치할 수 있습니다. 자세한 내용은 BYOM(Bring Your Own Media)과 함께 사용자 지정 엔진 버전(CEV)을 사용하는 [RDS for SQL Server에서 SQL Server Developer Edition 작업](sqlserver-dev-edition.md) 섹션을 참조하세요.동일한 접근 방식을 사용하여 RDS Custom for SQL Server에 SQL Server Developer Edition을 다운로드하고 설치할 수도 있습니다. 자세한 내용은 [기존 보유 미디어를 사용(BYOM)하여 CEV 준비](custom-cev-sqlserver.preparing.md#custom-cev-sqlserver.preparing.byom) 섹션을 참조하세요. SQL Server 버전 간의 차이에 대한 자세한 정보는 Microsoft 설명서의 [SQL Server 2019의 버전과 지원하는 기능](https://learn.microsoft.com/en-us/sql/sql-server/editions-and-components-of-sql-server-2019?view=sql-server-ver15)을 참조하세요.
# Microsoft SQL Server DB 인스턴스에 연결
Amazon RDS가 DB 인스턴스를 프로비저닝한 후에는 표준 SQL 클라이언트 애플리케이션을 사용해 DB 인스턴스에 연결할 수 있습니다. 이 주제에서는 Microsoft SQL Server Management Studio(SSMS) 또는 SQL Workbench/J를 사용하여 DB 인스턴스에 연결합니다.
사용자가 샘플 DB 인스턴스를 만들어 연결하는 절차를 실습하는 예제는 [Microsoft SQL Server DB 인스턴스 생성 및 해당 인스턴스에 연결](CHAP_GettingStarted.CreatingConnecting.SQLServer.md) 단원을 참조하십시오.
## 연결하기 전에
DB 인스턴스에 연결하려면 먼저 인스턴스를 사용할 수 있고 액세스할 수 있어야 합니다.
1. 상태가 `available`인지 확인합니다. AWS Management Console의 인스턴스 세부 정보 페이지에서 확인하거나 [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) AWS CLI 명령을 사용하여 확인할 수 있습니다.
![\[DB 인스턴스를 사용할 수 있는지 확인\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/sqlserver-available.png)
1. 소스에서 액세스할 수 있는지 확인하세요. 시나리오에 따라 공개적으로 액세스할 필요가 없을 수도 있습니다. 자세한 내용은 [Amazon VPC 및 Amazon RDS](USER_VPC.md) 섹션을 참조하세요.
1. VPC 보안 그룹의 인바운드 규칙이 DB 인스턴스에 대한 액세스를 허용하는지 확인합니다. 자세한 내용은 [Amazon RDS DB 인스턴스에 연결할 수 없음](CHAP_Troubleshooting.md#CHAP_Troubleshooting.Connecting) 섹션을 참조하세요.
## DB 인스턴스 엔드포인트 및 포트 번호 찾기
DB 인스턴스에 연결하려면 엔드포인트와 포트 번호가 모두 필요합니다.
**엔드포인트 및 포트를 찾으려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. Amazon RDS 콘솔의 오른쪽 상단에서 DB 인스턴스의 AWS 리전을 선택합니다.
1. DB 인스턴스의 도메인 이름 시스템(DNS) 이름(엔드포인트) 및 포트 번호를 찾습니다.
1. RDS 콘솔을 연 다음 **데이터베이스**를 선택하여 DB 인스턴스의 목록을 표시합니다.
1. 세부 정보를 표시하고자 하는 SQL Server DB 인스턴스 이름을 선택합니다.
1. **Connectivity & security(연결 및 보안)** 탭에서 엔드포인트를 복사합니다.
![\[DB 인스턴스 엔드포인트 및 포트 찾기\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/SQL-Connect-Endpoint.png)
1. 포트 번호를 적어 둡니다.
# Microsoft SQL Server Management Studio로 DB 인스턴스에 연결
이 절차에서는 Microsoft SQL Server Management Studio(SSMS)를 사용하여 샘플 DB 인스턴스에 연결합니다. 이 유틸리티의 독립 실행형 버전을 다운로드하려면 Microsoft 설명서의 [SQL Server Management Studio(SSMS) 다운로드](https://docs.microsoft.com/en-us/sql/ssms/download-sql-server-management-studio-ssms)를 참조하십시오.
**SSMS를 사용하여 DB 인스턴스에 연결하려면**
1. SQL Server Management Studio를 시작합니다.
**Connect to Server** 대화 상자가 나타납니다.
![\[Connect to Server 대화 상자\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/RDSMSFTSQLConnect01.png)
1. DB 인스턴스에 대한 정보를 제공합니다.
1. [**Server type**]에서 [**Database Engine**]을 선택합니다.
1. [**서버 이름(Server name)**]에 DB 인스턴스의 DNS 이름(엔드포인트) 및 포트 번호를 쉼표로 구분하여 입력합니다.
**중요**
엔드포인트와 포트 번호 사이의 콜론을 쉼표로 바꿉니다.
서버 이름은 다음 예제와 같은 형식이어야 합니다.
```
database-2.cg034itsfake.us-east-1.rds.amazonaws.com,1433
```
1. [**Authentication**]의 경우 [**SQL Server Authentication**]을 선택합니다.
1. **로그인**에는 DB 인스턴스의 마스터 사용자 이름을 입력합니다.
1. **암호**에는 DB 인스턴스의 암호를 입력합니다.
1. [**Connect**]를 선택합니다.
몇 분 정도 지나면 SSMS가 DB 인스턴스에 연결됩니다.
DB 인스턴스에 연결할 수 없는 경우 [보안 그룹 고려 사항](USER_ConnectToMicrosoftSQLServerInstance.Security.md) 및 [SQL Server DB 인스턴스에 대한 연결 문제 해결](USER_ConnectToMicrosoftSQLServerInstance.Troubleshooting.md) 단원을 참조하십시오.
1. SQL Server DB 인스턴스는 SQL Server의 표준 기본 제공 시스템 데이터베이스(`master`, `model`, `msdb` 및 `tempdb`)와 함께 제공됩니다. 시스템 데이터베이스를 탐색하려면 다음을 수행하십시오.
1. SSMS의 [**View**] 메뉴에서 [**Object Explorer**]를 선택합니다.
1. DB 인스턴스와 **데이터베이스**를 확장하고 다음과 같이 **시스템 데이터베이스**를 확장합니다.
![\[시스템 데이터베이스를 표시하는 객체 탐색기\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/SQL-SSMS-SystemDBs.png)
1. SQL Server DB 인스턴스는 `rdsadmin`이라는 이름의 데이터베이스와 함께 제공됩니다. Amazon RDS는 이 데이터베이스를 사용하여 데이터베이스를 관리하는 데 사용하는 객체를 저장합니다. `rdsadmin` 데이터베이스에도 고급 작업 수행을 위해 실행할 수 있는 저장 절차가 포함됩니다. 자세한 내용은 [Amazon RDS for Microsoft SQL Server에 대한 일반 DBA 작업](Appendix.SQLServer.CommonDBATasks.md) 섹션을 참조하세요.
1. 이제 자체 데이터베이스 생성을 시작하고 평소대로 DB 인스턴스와 데이터베이스에 대한 쿼리 실행을 시작할 수 있습니다. DB 인스턴스에 대한 테스트 쿼리를 실행하려면 다음 중 하나를 수행합니다.
1. SSMS의 [**File**] 메뉴에서 [**New**]를 가리킨 후 [**Query with Current Connection**]을 선택합니다.
1. 다음 SQL 쿼리를 입력합니다.
```
select @@VERSION
```
1. 쿼리를 실행합니다. SSMS가 Amazon RDS DB 인스턴스의 SQL Server 버전을 반환합니다.
![\[SQL 쿼리 창\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/SQL-Connect-Query.png)
# SQL Workbench/J로 DB 인스턴스에 연결
이번 예에서는 SQL Workbench/J 데이터베이스 도구를 사용하여 Microsoft SQL Server 데이터베이스 엔진 기반 DB 인스턴스에 연결하는 방법을 나타냅니다. SQL Workbench/J를 다운로드하려면 [SQL Workbench/J](http://www.sql-workbench.net/)를 참조하십시오.
SQL Workbench/J가 JDBC를 이용해 DB 인스턴스에 연결합니다. 그 밖에 SQL Server용 JDBC 드라이버도 필요합니다. 이 드라이버를 다운로드하려면 [SQL Server용 Microsoft JDBC 드라이버 다운로드](https://learn.microsoft.com/en-us/sql/connect/jdbc/download-microsoft-jdbc-driver-for-sql-server?view=sql-server-ver16)를 참조하세요.
**SQL Workbench/J를 사용하여 DB 인스턴스에 연결하려면**
1. SQL Workbench/J를 엽니다. 아래와 같이 [**연결 프로파일 선택(Select Connection Profile)**] 대화 상자가 나타납니다.
![\[연결 프로파일 선택 대화 상자\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/workbench_profile.png)
1. 대화 상자 상단의 첫 번째 상자에 프로파일 이름을 입력합니다.
1. **드라이버**에서 **SQL JDBC 4.0**을 선택합니다.
1. **URL**에 **jdbc:sqlserver://**를 입력한 후, DB 인스턴스의 엔드포인트를 입력합니다. 예를 들면 URL 값은 다음과 같습니다.
```
jdbc:sqlserver://sqlsvr-pdz.abcd12340.us-west-2.rds.amazonaws.com:1433
```
1. **사용자 이름**에 DB 인스턴스의 마스터 사용자 이름을 입력하거나 붙여 넣습니다.
1. **암호**에 마스터 사용자 암호를 입력합니다.
1. 아래 그림과 같이 대화 상자 도구 모음에서 저장 아이콘을 선택합니다.
![\[프로파일 저장\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/save_example.png)
1. **확인**을 선택합니다. 몇 분 정도 지나면 SQL Workbench/J가 DB 인스턴스에 연결됩니다. DB 인스턴스에 연결할 수 없는 경우 [보안 그룹 고려 사항](USER_ConnectToMicrosoftSQLServerInstance.Security.md) 및 [SQL Server DB 인스턴스에 대한 연결 문제 해결](USER_ConnectToMicrosoftSQLServerInstance.Troubleshooting.md) 단원을 참조하십시오.
1. 쿼리 창에 다음과 같이 SQL 쿼리를 입력합니다.
```
select @@VERSION
```
1. 아래 그림과 같이 도구 모음에서 `Execute` 아이콘을 선택합니다.
![\[쿼리 실행\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/execute_example.png)
쿼리가 다음과 같이 DB 인스턴스의 버전 정보를 반환합니다.
```
Microsoft SQL Server 2017 (RTM-CU22) (KB4577467) - 14.0.3356.20 (X64)
```
# 보안 그룹 고려 사항
DB 인스턴스에 연결하려면 DB 인스턴스가 보안 그룹에 연결되어 있어야 합니다. 이 보안 그룹에는 DB 인스턴스에 액세스하는 데 사용하는 IP 주소와 네트워크 구성이 포함되어 있습니다. DB 인스턴스를 생성할 때 DB 인스턴스를 적합한 보안 그룹에 연결했을 수도 있습니다. DB 인스턴스를 생성할 때 따로 설정할 필요가 없는 기본 보안 그룹을 할당한 경우 DB 인스턴스 방화벽이 연결을 차단합니다.
경우에 따라 액세스를 활성화하기 위해 새 보안 그룹을 생성해야 할 수도 있습니다. 새 보안 그룹 생성에 대한 자세한 내용은 [보안 그룹을 통한 액세스 제어](Overview.RDSSecurityGroups.md) 단원을 참조하십시오. VPC 보안 그룹의 규칙 설정 절차를 안내하는 주제는 [자습서: DB 인스턴스에 사용할 Amazon VPC 생성(IPv4 전용)](CHAP_Tutorials.WebServerDB.CreateVPC.md) 단원을 참조하십시오.
새 보안 그룹을 생성하였으면 보안 그룹과 연결되도록 DB 인스턴스를 수정합니다. 자세한 내용은 [Amazon RDS DB 인스턴스 수정](Overview.DBInstance.Modifying.md) 섹션을 참조하세요.
SSL을 사용하여 DB 인스턴스 연결을 암호화함으로써 보안을 강화할 수 있습니다. 자세한 내용은 [Microsoft SQL Server DB 인스턴스와 함께 SSL 사용](SQLServer.Concepts.General.SSL.Using.md) 단원을 참조하십시오.
# SQL Server DB 인스턴스에 대한 연결 문제 해결
다음 표에는 SQL Server DB 인스턴스에 연결을 시도할 때 발생할 수 있는 오류 메시지가 나와 있습니다.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_ConnectToMicrosoftSQLServerInstance.Troubleshooting.html)
**참고**
연결 문제에 대한 자세한 내용은 [Amazon RDS DB 인스턴스에 연결할 수 없음](CHAP_Troubleshooting.md#CHAP_Troubleshooting.Connecting) 단원을 참조하십시오.
# RDS for SQL Server에서 SQL Server Developer Edition 작업
RDS for SQL Server가 SQL Server Developer Edition을 지원합니다. Developer Edition에는 모든 SQL Server Enterprise Edition 기능이 포함되어 있지만 비프로덕션 용도로만 라이선스가 부여됩니다. 사용자 지정 엔진 버전(CEV) 기능을 통해 자체 설치 미디어를 사용하여 RDS for SQL Server Developer Edition 인스턴스를 생성할 수 있습니다.
## 이점
RDS for SQL Server Developer Edition을 사용하여 다음을 수행할 수 있습니다.
+ 프로덕션 데이터베이스와의 기능 패리티를 유지하면서 개발 및 테스트 환경의 비용을 절감합니다.
+ Enterprise 라이선스 요금 없이 비프로덕션 환경에서 Enterprise Edition 기능에 액세스합니다.
+ 백업, 패치 적용 및 모니터링을 포함한 Amazon RDS 자동화 관리 기능을 사용합니다.
**참고**
SQL Server Developer Edition은 개발 및 테스트 목적으로만 라이선스가 부여되며 프로덕션 환경에서 사용할 수 없습니다.
## 리전 가용성
RDS for SQL Server Developer Edition은 다음 AWS 리전에서 사용할 수 있습니다.
+ 미국 동부(버지니아 북부)
+ 미국 동부(오하이오)
+ 미국 서부(오리건)
+ 미국 서부(캘리포니아 북부)
+ 아시아 태평양(뭄바이)
+ 아시아 태평양(서울)
+ 아시아 태평양(싱가포르)
+ 아시아 태평양(오사카)
+ 아시아 태평양(시드니)
+ 아시아 태평양(도쿄)
+ 유럽(아일랜드)
+ 유럽(프랑크푸르트)
+ 유럽(런던)
+ 유럽(스톡홀름)
+ 유럽(파리)
+ 캐나다(중부)
+ 남아메리카(상파울루)
+ 아프리카(케이프타운)
## 라이선스 및 사용
SQL Server Developer Edition은 Microsoft에서 개발 및 테스트 환경에 대해서만 라이선스를 부여합니다. Developer Edition을 프로덕션 서버로 사용할 수 없습니다. Amazon RDS에서 SQL Server Developer Edition을 사용하는 경우, Microsoft의 SQL Server Developer Edition 라이선스 약관을 준수할 책임은 사용자에게 있습니다. AWS 인프라 비용만 지불하면 되며, 추가 SQL Server 라이선스 요금은 없습니다. 요금 세부 정보는 [RDS for SQL Server 요금](https://aws.amazon.com/rds/sqlserver/pricing/)을 참조하세요.
## 사전 조건
RDS for SQL Server에서 SQL Server Developer Edition을 사용하기 전에 다음 요구 사항이 있는지 확인합니다.
+ Microsoft에서 직접 설치 바이너리를 가져와 Microsoft의 라이선스 약관을 준수하는지 확인해야 합니다.
+ Developer Edition DB 인스턴스를 생성하려면 다음 리소스를 사용할 수 있는 액세스 권한이 있어야 합니다.
+ `AmazonRDSFullAccess` 및 `s3:GetObject` 권한이 있는 AWS 계정입니다.
+ 설치 미디어를 저장하려면 Amazon S3 버킷이 필요합니다. CEV 생성의 일부로 Amazon S3 버킷에 업로드하려면 ISO 및 누적 업데이트 파일이 필요합니다. 자세한 내용은 [ Amazon S3 버킷에 설치 미디어 업로드](https://docs.aws.amazon.com/AmazonS3/latest/userguide/upload-objects.html)를 참조하세요.
+ 모든 설치 미디어 파일은 사용자 지정 엔진 버전이 생성된 곳과 동일한 리전의 동일한 Amazon S3 버킷과 해당 Amazon S3 버킷 내의 동일한 폴더 경로 내에 있어야 합니다.
### 지원되는 버전
RDS for SQL Server의 Developer Edition은 다음 버전을 지원합니다.
+ SQL Server 2022 CU 21(16.00.4215.2)
+ SQL Server 2019 CU 32 GDR(15.00.4455.2)
Developer Edition CEV 생성에 지원되는 모든 엔진 버전을 나열하려면 다음 AWS CLI 명령을 사용합니다.
```
aws rds describe-db-engine-versions --engine sqlserver-dev-ee --output json --query "{DBEngineVersions: DBEngineVersions[?Status=='requires-custom-engine-version'].{Engine: Engine, EngineVersion: EngineVersion, Status: Status, DBEngineVersionDescription: DBEngineVersionDescription}}"
```
이 명령은 다음 예제 출력과 유사한 출력을 반환합니다.
```
{
"DBEngineVersions": [
{
"Engine": "sqlserver-dev-ee",
"EngineVersion": "16.00.4215.2.v1",
"Status": "requires-custom-engine-version",
"DBEngineDescription": "Microsoft SQL Server Enterprise Developer Edition",
"DBEngineVersionDescription": "SQL Server 2022 16.00.4215.2.v1"
}
]
}
```
엔진 버전 상태로, `requires_custom_engine_version`이 식별한 지원되는 템플릿 엔진 버전입니다. 이러한 템플릿은 가져올 수 있는 SQL Server 버전을 보여 줍니다.
## 제한 사항
Amazon RDS의 SQL Server Developer Edition에는 다음과 같은 제한 사항이 적용됩니다.
+ 현재 M6i 및 R6i 인스턴스 클래스에서만 지원됩니다.
+ 다중 AZ 배포 및 읽기 전용 복제본은 지원되지 않습니다.
+ 자체 SQL Server 설치 미디어를 제공하고 관리해야 합니다.
+ SQL Server Developer Edition(sqlserver-dev-ee)의 사용자 지정 엔진 버전은 리전 간 또는 계정 간에 공유할 수 없습니다.
# RDS for SQL Server용 CEV 준비
## 사전 조건
사용자 지정 엔진 버전을 생성하기 전에 다음 사전 조건을 완료했는지 확인합니다.
### SQL Server Developer Edition 설치 미디어 준비
Microsoft에서 SQL Server Developer Edition 설치 미디어를 가져와 S3에 업로드할 준비를 해야 합니다.
**Microsoft에서 설치 미디어 다운로드**
1. **옵션 A:** [Visual Studio 구독](https://visualstudio.microsoft.com/subscriptions/)을 사용하여 Developer Edition ISO를 다운로드합니다. 영어 버전만 지원됩니다.
1. **옵션 B: SQL Server 설치 관리자 사용**
1. [SQL Server Developer Edition 설치 관리자](https://download.microsoft.com/download/c/c/9/cc9c6797-383c-4b24-8920-dc057c1de9d3/SQL2022-SSEI-Dev.exe)를 다운로드합니다.
1. 설치 관리자를 실행하고 **미디어 다운로드**를 선택하여 전체 ISO를 다운로드합니다.
1. **영어**를 기본 언어로 선택합니다.
1. 미디어 유형으로 **ISO**를 선택합니다.
1. **다운로드**를 선택합니다.
**누적 업데이트 다운로드**
1. [Microsoft 카탈로그 업데이트](https://www.catalog.update.microsoft.com/Home.aspx) 페이지를 방문하세요.
1. "SQL Server 2022 누적 업데이트"와 같이 RDS for SQL Server에서 지원되는 SQL Server Developer Edition을 찾습니다.
1. 지원되는 최신 CU 실행 파일을 다운로드하여 시스템에 저장합니다.
1. 예제 파일: `SQLServer2022-KB5065865-x64.exe`(SQL Server 2022용 CU21)
**중요**
RDS for SQL Server는 특정 누적 업데이트(CU) 버전만 지원합니다. 아래 표에 나열된 정확한 버전을 사용해야 합니다. 최신 CU 버전은 RDS와 호환되지 않을 수 있으므로 Microsoft에서 제공하더라도 사용하지 마세요.
또는 다음 위치에서 직접 필요한 누적 업데이트(CU) 파일을 다운로드할 수도 있습니다.
다음 표에는 지원되는 SQL Server Developer Edition 버전 및 RDS와 함께 사용할 수 있는 해당 누적 업데이트가 나열되어 있습니다.
| SQL Server 버전 | 지원되는 CU | KB 문서 | 다운로드 파일 이름 |
| --- | --- | --- | --- |
| SQL Server 2022 | `CU21` | [KB5065865](https://learn.microsoft.com/en-us/troubleshoot/sql/releases/sqlserver-2022/cumulativeupdate21) | `SQLServer2022-KB5065865-x64.exe` |
| SQL Server 2019 | `CU32 GDR` | [KB5068404](https://support.microsoft.com/en-us/topic/kb5068404-description-of-the-security-update-for-sql-server-2019-cu32-november-11-2025-c203bfbf-036e-46d2-bc10-6c01200dc48a) | `SQLServer2019-KB5068404-x64.exe` |
# RDS for SQL Server용 사용자 지정 엔진 버전 생성
RDS for SQL Server용 사용자 지정 엔진 버전(CEV)은 Amazon RDS로 가져온 SQL Server Developer Edition 설치 미디어로 구성됩니다. 기본 ISO 설치 관리자 및 누적 업데이트 파일(.exe)을 Amazon S3 버킷에 업로드해야 합니다. 업로드 후에는 RDS에서 CEV를 다운로드, 검증 및 생성할 수 있도록 Amazon S3 위치를 제공해야 합니다.
## 이름 지정 제한 사항
CEV를 생성할 때 특정 명명 규칙을 따라야 합니다.
+ CEV 이름은 `major-version.minor-version.customized-string` 패턴을 따라야 합니다.
+ `customized-string`에는 1\$150개의 영숫자, 밑줄, 대시 및 마침표를 포함할 수 있습니다. 예를 들어 SQL Server 2022의 경우 `16.00.4215.2.my-dev-cev`를 지정할 수 있습니다.
지원되는 모든 엔진 버전을 나열하려면 다음 명령을 사용합니다.
```
aws rds describe-db-engine-versions --engine sqlserver-dev-ee --output json --query "{DBEngineVersions: DBEngineVersions[?Status=='requires-custom-engine-version'].{Engine: Engine, EngineVersion: EngineVersion, Status: Status, DBEngineVersionDescription: DBEngineVersionDescription}}"
{
"DBEngineVersions": [
{
"Engine": "sqlserver-dev-ee",
"EngineVersion": "16.00.4215.2.v1",
"Status": "requires-custom-engine-version",
"DBEngineDescription": "Microsoft SQL Server Enterprise Developer Edition",
"DBEngineVersionDescription": "SQL Server 2022 16.00.4215.2.v1"
}
]
}
```
## AWS CLI
**사용자 지정 엔진 버전 생성**
+ [create-custom-db-engine-version](https://docs.aws.amazon.com/cli/latest/reference/rds/create-custom-db-engine-version.html) 명령을 사용합니다.
다음 옵션이 필요합니다.
+ `--engine`
+ `--engine-version`
+ `--database-installation-files-s3-bucket-name`
+ `--database-installation-files`
+ `--region`
다음 옵션도 지정할 수 있습니다.
+ `--database-installation-files-s3-prefix`
+ `--description`
+ `--tags`
```
aws rds create-custom-db-engine-version \
--engine sqlserver-dev-ee \
--engine-version 16.00.4215.2.cev-dev-ss2022-cu21 \
--region us-west-2 \
--database-installation-files-s3-bucket-name my-s3-installation-media-bucket \
--database-installation-files-s3-prefix sqlserver-dev-media \
--database-installation-files "SQLServer2022-x64-ENU-Dev.iso" "SQLServer2022-KB5065865-x64.exe"
```
CEV 생성에는 일반적으로 15\$130분이 소요됩니다. CEV 생성 진행 상황을 모니터링하려면 다음 명령을 사용합니다.
```
# Check CEV status
aws rds describe-db-engine-versions \
--engine sqlserver-dev-ee \
--engine-version 16.00.4215.2.my-dev-cev \
--region us-west-2
```
## RDS for SQL Server CEV의 수명 주기
RDS for SQL Server에서 SQL Server Developer Edition을 사용하는 경우 사용자 지정 엔진 버전은 다양한 수명 주기 상태로 전환됩니다.
| 수명 주기 상태 | 설명 | 발생하는 경우 | 사용 가능한 작업 |
| --- | --- | --- | --- |
| pending-validation | CEV 생성 시 초기 상태 | `create-custom-db-engine-version` 명령을 사용하여 생성한 후의 초기 상태입니다. | `describe-db-engine-version`을 통해 상태를 모니터링합니다. |
| 검증 | CEV 검증 상태 | Amazon RDS가 사용자 지정 엔진 버전(CEV)을 검증하고 있습니다. 이 비동기 프로세스를 완료하는 데 다소 시간이 걸릴 수 있습니다. | 검증이 완료될 때까지 상태를 모니터링합니다. |
| 사용 가능 | 사용자 지정 엔진 버전(CEV) 검증이 성공적으로 완료되었습니다. | 이제 사용자 지정 엔진 버전(CEV)을 사용할 수 있습니다. Amazon RDS가 SQL Server ISO 및 누적 업데이트 파일을 성공적으로 검증했습니다. 이제 이 CEV를 사용하여 DB 인스턴스를 생성할 수 있습니다. | 이 CEV를 사용하여 DB 인스턴스 생성 |
| 실패 | 검증 검사가 실패하여 RDS for SQL Server에서 사용자 지정 엔진 버전(CEV)을 생성할 수 없습니다. | ISO 및 누적 미디어 검증이 실패했습니다. | ISO 검증이 실패했습니다. `describe-db-engine-version`에서 실패 이유를 확인하고 해시 불일치 또는 손상된 콘텐츠와 같은 파일 문제를 해결한 다음 사용자 지정 엔진 버전(CEV)을 다시 생성합니다. |
| 삭제 중 | 사용자 지정 엔진 버전(CEV)이 삭제 중입니다. | 고객이 `delete-custom-db-engine-version`을 직접적으로 호출한 후 삭제 워크플로가 완료될 때까지. | `describe-db-engine-version`을 통해 상태를 모니터링합니다. |
| incompatible-installation-media | Amazon RDS가 사용자 지정 엔진 버전(CEV)에 제공된 설치 미디어를 검증할 수 없습니다. | 사용자 지정 엔진 버전(CEV) 검증이 실패했습니다. 이것은 종료 상태입니다. | `describe-db-engine-versions`를 통해 failureReason에서 검증이 실패한 이유에 대한 정보를 확인하고 CEV를 삭제합니다. |
### CEV 상태 설명
다음과 같이 AWS CLI를 사용하여 CEV 상태를 확인할 수 있습니다.
```
1. aws rds describe-db-engine-versions \
2. --engine sqlserver-dev-ee \
3. --engine-version 16.00.4215.2.my-dev-cev \
4. --region us-west-2 \
5. --query 'DBEngineVersions[0].{Version:EngineVersion,Status:Status}'
```
샘플 출력
```
| DescribeDBEngineVersions |
+------------+---------------------------------+
| Status | Version |
+------------+---------------------------------+
| available | 16.00.4215.2.cev-dev-ss2022-cu21 |
+------------+---------------------------------+
```
CEV에 `failed` 상태가 표시되면 다음 명령을 사용하여 이유를 확인할 수 있습니다.
```
1. aws rds describe-db-engine-versions \
2. --engine sqlserver-dev-ee \
3. --engine-version 16.00.4215.2.my-dev-cev \
4. --region us-west-2 \
5. --query 'DBEngineVersions[0].{Version:EngineVersion,Status:Status,FailureReason:FailureReason}'
```
# RDS for SQL Server Developer Edition DB 인스턴스 생성
RDS for SQL Server에서 Developer Edition 인스턴스를 시작하는 작업은 2단계 프로세스를 따릅니다. 먼저 `create-custom-db-engine-version`을 사용하여 CEV를 생성합니다. 사용자 지정 엔진 버전이 사용 가능한 상태가 되면 CEV를 사용하여 Amazon RDS 데이터베이스 인스턴스를 생성할 수 있습니다.
**Developer Edition 인스턴스 생성의 주요 차이점**
| 파라미터 | Developer Edition |
| --- | --- |
| `--engine` | sqlserver-dev-ee |
| `--engine-version` | 사용자 지정 엔진 버전(예: 16.00.4215.2.cev-dev-ss2022-cu21) |
| `--license-model` | BYOL(bring-your-own-license, 기존 보유 라이선스 사용) |
## AWS CLI
SQL Server Developer Edition DB 인스턴스를 생성하려면 다음 파라미터와 함께 [create-db-instance](https://docs.aws.amazon.com//cli/latest/reference/rds/create-db-instance.html) 명령을 사용합니다.
다음 옵션이 필요합니다.
+ `--db-instance-identifier`
+ `--db-instance-class`
+ `--engine` – `sqlserver-dev-ee`
+ `--region`
**예시:**
Linux, macOS, Unix의 경우:
```
aws rds create-db-instance \
--db-instance-identifier my-dev-sqlserver \
--db-instance-class db.m6i.xlarge \
--engine sqlserver-dev-ee \
--engine-version 16.00.4215.2.my-dev-cev \
--allocated-storage 200 \
--master-username admin \
--master-user-password changeThisPassword \
--license-model bring-your-own-license \
--no-multi-az \
--vpc-security-group-ids sg-xxxxxxxxx \
--db-subnet-group-name my-db-subnet-group \
--backup-retention-period 7 \
--region us-west-2
```
Windows의 경우:
```
aws rds create-db-instance ^
--db-instance-identifier my-dev-sqlserver ^
--db-instance-class db.m6i.xlarge ^
--engine sqlserver-dev-ee ^
--engine-version 16.00.4215.2.cev-dev-ss2022-cu21 ^
--allocated-storage 200 ^
--master-username admin ^
--master-user-password master_user_password ^
--license-model bring-your-own-license ^
--no-multi-az ^
--vpc-security-group-ids sg-xxxxxxxxx ^
--db-subnet-group-name my-db-subnet-group ^
--backup-retention-period 7 ^
--region us-west-2
```
AWS 콘솔을 사용하여 생성하려면 [DB 인스턴스 생성](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateDBInstance.html#USER_CreateDBInstance.Creating)을 참조하세요.
# 데이터베이스 마이너 버전 업그레이드 적용
RDS for SQL Server Developer Edition에서 데이터베이스 마이너 버전 업그레이드를 적용하려면 최신 누적 업데이트가 포함된 새 사용자 지정 엔진 버전(CEV)을 생성해야 합니다. SQL Server Developer Edition의 데이터베이스 마이너 버전 업그레이드에는 다음 단계가 포함됩니다.
1. 업그레이드하기 전에 인스턴스의 현재 엔진 버전을 확인하고 Amazon RDS 지원 버전에서 대상 데이터베이스 엔진 버전을 식별합니다. Amazon RDS에서 사용할 수 있는 SQL Server 버전에 대한 자세한 내용은 [RDS for SQL Server에서 SQL Server Developer Edition 작업](sqlserver-dev-edition.md) 섹션을 참조하세요.
1. 설치 미디어(ISO 및 CU)를 가져와 업로드한 다음 [새 사용자 지정 엔진 버전을 생성](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/sqlserver-dev-edition.creating-cev.html)합니다.
1. 새 CEV와 함께 Amazon RDS [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)를 사용하여 데이터베이스 마이너 버전 업그레이드를 적용합니다.
```
aws rds modify-db-instance \
--db-instance-identifier \
--engine-version \
--no-apply-immediately ## use --apply-immediately for immediate update
```
**참고**
다음 유지 관리 기간에 변경 사항을 적용하려면 `--no-apply-immediately`(기본값)를 사용합니다.
# 사용자 지정 엔진 버전 보기 및 관리
모든 RDS for SQL Server Developer Edition CEV를 보려면 `--engine` 입력을 `sqlserver-dev-ee`로 `describe-db-engine-versions` 명령을 사용합니다.
```
aws rds describe-db-engine-versions \
--engine sqlserver-dev-ee \
--include-all \
--region us-west-2
```
특정 CEV의 세부 정보를 보려면 다음 명령을 사용합니다.
```
aws rds describe-db-engine-versions \
--engine sqlserver-dev-ee \
--engine-version 16.00.4215.2.cev-dev-ss2022-cu21 \
--region us-west-2
```
**참고**
이 명령은 `available` 상태의 CEV만 반환합니다. 검증 중 또는 기타 상태의 CEV를 보려면 `--include-all` 플래그를 포함합니다.
## 사용자 지정 엔진 버전 삭제
CEV를 삭제하기 전에 CEV가 다음 중 하나에 속하지 않는지 확인하세요.
+ Amazon RDS DB 인스턴스
+ Amazon RDS DB 인스턴스의 스냅샷
+ Amazon RDS DB 인스턴스의 자동 백업
**참고**
연결된 리소스가 있는 경우 CEV를 삭제할 수 없습니다.
사용자 지정 엔진 버전을 삭제하려면 [delete-custom-db-engine-version](https://docs.aws.amazon.com//cli/latest/reference/rds/delete-custom-db-engine-version.html) 명령을 사용합니다.
+ `--engine`: Developer Edition에 대해 `sqlserver-dev-ee` 지정
+ `--engine-version`: 삭제할 정확한 CEV 버전 식별자
+ `--region`: CEV가 있는 AWS 리전
```
aws rds delete-custom-db-engine-version \
--engine sqlserver-dev-ee \
--engine-version 16.00.4215.2.my-dev-cev \
--region us-west-2
```
CEV 삭제 프로세스를 모니터링하려면 `describe-db-engine-versions` 명령을 사용하고 RDS for SQL Server CEV 엔진 버전을 지정합니다.
```
aws rds describe-db-engine-versions \
--engine sqlserver-dev-ee \
--engine-version 16.00.4215.2.my-dev-cev \
--region us-west-2
```
상태 값:
+ `deleting`: CEV 삭제 진행 중
+ 반환된 결과 없음: CEV가 성공적으로 삭제됨
# RDS for SQL Server용 SQL Server 개발자 버전 문제 해결
다음 표에는 SQL Server Developer Edition for RDS for SQL Server 작업 시 발생하는 몇 가지 일반적인 오류와 해당 해결 방법이 나와 있습니다.
**일반적인 오류 및 해결 방법**
| 오류 코드 | 설명 | Solution |
| --- | --- | --- |
| InvalidParameterValue | 잘못된 CEV 파라미터 또는 파일 참조 | 파일 이름, 경로 및 파라미터 구문 확인 |
| DBSubnetGroupNotFound | 서브넷 그룹이 존재하지 않음 | 서브넷 그룹 생성 또는 이름 확인 |
| InvalidVPCNetworkState | VPC 구성 문제 | VPC, 서브넷 및 라우팅 테이블 확인 |
| InvalidEngineVersion | CEV를 사용할 수 없거나 유효하지 않음 | CEV 상태 및 이름 확인 |
| InvalidDBInstanceClass | 인스턴스 클래스가 지원되지 않음 | 지원되는 인스턴스 클래스 선택 |
| CustomDBEngineVersionQuotaExceededFault | 최대 사용자 지정 엔진 버전 수에 도달했습니다. | 필요한 경우 서비스 할당량을 늘리거나, 사용하지 않는 CEV를 삭제합니다. |
| CreateCustomDBEngineVersionFault | Amazon RDS가 Amazon S3 버킷의 지정된 설치 관리자 파일에 액세스할 수 없습니다. | Amazon RDS는 지정된 Amazon S3 위치의 SQL Server 설치 파일에 액세스할 수 없습니다. Amazon S3 버킷 정책에서 Amazon RDS 서비스 위탁자(rds.amazonaws.com) s3:GetObject 권한을 부여합니다. Amazon S3 버킷 리전이 CEV를 생성하는 리전과 동일한지 확인합니다. |
# RDS for SQL Server를 사용하여 Active Directory 작업
RDS for SQL Server DB 인스턴스를 Microsoft Active Directory(AD) 도메인에 가입시킬 수 있습니다. AD 도메인은 AWS 내의 AWS 관리형 AD, 선택한 위치의 자체 관리형 AD(기업 데이터 센터 포함) 또는 AWS EC2에서 호스팅하거나 다른 클라우드 공급자를 통해 호스팅할 수 있습니다.
자체 관리형 Active Directory 및 AWS Managed Microsoft AD를 통해 NTLM 인증과 Kerberos 인증을 사용하여 도메인 사용자를 인증할 수 있습니다.
다음 섹션에서는 Amazon RDS에서 Microsoft SQL Server용 자체 관리형 Active Directory 및 AWS 관리형 Active Directory를 사용하여 작업하는 정보를 찾을 수 있습니다.
**Topics**
+ [Amazon RDS for SQL Server DB 인스턴스를 사용하여 자체 관리형 Active Directory 작업](USER_SQLServer_SelfManagedActiveDirectory.md)
+ [RDS for SQL Server를 사용하여 AWS 관리형 Active Directory 작업](USER_SQLServerWinAuth.md)
# Amazon RDS for SQL Server DB 인스턴스를 사용하여 자체 관리형 Active Directory 작업
Amazon RDS for SQL Server는 데이터 센터, Amazon EC2 또는 다른 클라우드 공급자 등 AD가 호스팅되는 위치에 관계없이 자체 관리형 Active Directory(AD) 도메인과 원활하게 통합됩니다. 이 통합을 통해 NTLM 또는 Kerberos 프로토콜을 통해 직접 사용자 인증을 사용할 수 있으므로 복잡한 중간 도메인 또는 포리스트 신뢰가 필요하지 않습니다. RDS SQL Server DB 인스턴스에 연결하면 인증 요청이 지정된 AD 도메인으로 안전하게 전달되어, Amazon RDS의 관리형 데이터베이스 기능을 활용하면서 기존 ID 관리 구조를 유지합니다.
**Topics**
+ [리전 및 버전 사용 가능 여부](#USER_SQLServer_SelfManagedActiveDirectory.RegionVersionAvailability)
+ [요구 사항](USER_SQLServer_SelfManagedActiveDirectory.Requirements.md)
+ [고려 사항](#USER_SQLServer_SelfManagedActiveDirectory.Limitations)
+ [자체 관리형 Active Directory 설정](USER_SQLServer_SelfManagedActiveDirectory.SettingUp.md)
+ [DB 인스턴스를 자체 관리형 Active Directory에 조인](USER_SQLServer_SelfManagedActiveDirectory.Joining.md)
+ [자체 관리형 Active Directory 도메인에서 DB 인스턴스 관리](USER_SQLServer_SelfManagedActiveDirectory.Managing.md)
+ [자체 관리형 Active Directory 도메인 멤버십에 대한 이해](#USER_SQLServer_SelfManagedActiveDirectory.Understanding)
+ [자체 관리형 Active Directory 문제 해결](USER_SQLServer_SelfManagedActiveDirectory.TroubleshootingSelfManagedActiveDirectory.md)
+ [SQL Server DB 인스턴스를 복원한 후 자체 관리형 Active Directory 도메인에 추가](#USER_SQLServer_SelfManagedActiveDirectory.Restore)
## 리전 및 버전 사용 가능 여부
Amazon RDS는 모든 상용 AWS 리전 및 AWS GovCloud (US) Regions에서 NTLM 및 Kerberos를 사용하는 자체 관리형 AD for SQL Server를 지원합니다.
# 요구 사항
RDS for SQL Server DB 인스턴스를 자체 관리형 AD 도메인에 가입시키기 전에 다음 요구 사항을 충족해야 합니다.
**Topics**
+ [온프레미스 AD 구성](#USER_SQLServer_SelfManagedActiveDirectory.Requirements.OnPremConfig)
+ [네트워크 연결 구성](#USER_SQLServer_SelfManagedActiveDirectory.Requirements.NetworkConfig)
+ [AD 도메인 서비스 계정 구성](#USER_SQLServer_SelfManagedActiveDirectory.Requirements.DomainAccountConfig)
+ [LDAPS를 통한 보안 통신 구성](#USER_SQLServer_SelfManagedActiveDirectory.Requirements.LDAPS)
## 온프레미스 AD 구성
Amazon RDS for SQL Server 인스턴스에 가입시킬 수 있는 온프레미스 또는 기타 자체 관리형 Microsoft AD가 있어야 합니다. 온프레미스 AD는 다음과 같은 구성을 가져야 합니다.
+ AD 사이트가 정의되어 있는 경우 RDS for SQL Server DB 인스턴스와 연결된 VPC의 서브넷이 AD 사이트에 정의되어 있는지 확인합니다. VPC의 서브넷과 다른 AD 사이트의 서브넷 간에 충돌이 없는지 확인합니다.
+ AD 도메인 컨트롤러의 도메인 기능 수준은 Windows Server 2008 R2 이상입니다.
+ AD 도메인 이름은 단일 레이블 도메인(SLD) 형식일 수 없습니다. RDS for SQL Server는 SLD 도메인을 지원하지 않습니다.
+ AD의 정규화된 도메인 이름(FQDN)이 47자를 초과하면 안 됩니다.
## 네트워크 연결 구성
다음 네트워크 구성을 충족하는지 확인합니다.
+ RDS for SQL Server DB 인스턴스를 생성하려는 Amazon VPC와 자체 관리형 Active Directory 간에 연결을 구성합니다. AWS Direct Connect, AWS VPN, VPC 피어링 또는 AWS 전송 게이트웨이를 사용하여 연결을 설정할 수 있습니다.
+ VPC 보안 그룹의 경우 기본 Amazon VPC의 기본 보안 그룹이 콘솔의 RDS for SQL Server DB 인스턴스에 이미 추가되었습니다. RDS for SQL Server DB 인스턴스를 만드는 서브넷의 보안 그룹과 VPC 네트워크 ACL이 다음 다이어그램에 표시된 방향으로 포트를 통한 트래픽을 허용하는지 확인합니다.
![\[자체 관리형 AD 네트워크 구성 포트 규칙입니다.\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/SQLServer_SelfManagedActiveDirectory_Requirements_NetworkConfig.png)
다음 테이블에는 각 포트의 역할이 나와 있습니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_SQLServer_SelfManagedActiveDirectory.Requirements.html)
+ 일반적으로 도메인 DNS 서버는 AD 도메인 컨트롤러에 있습니다. 이 기능을 사용하기 위해 VPC DHCP 옵션 세트를 구성할 필요는 없습니다. 자세한 정보는 *Amazon VPC 사용 설명서*의 [DHCP 옵션 세트](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html)를 참조하세요.
**중요**
VPC 네트워크 ACL을 사용하는 경우 RDS for SQL Server DB 인스턴스의 동적 포트(49152-65535)를 통한 아웃바운드 트래픽도 허용해야 합니다. 이러한 트래픽 규칙이 각 AD 도메인 컨트롤러, DNS 서버 및 RDS for SQL Server DB 인스턴스에 적용되는 방화벽에도 반영되는지 확인하세요.
VPC 보안 그룹에서는 네트워크 트래픽이 시작되는 방향으로만 포트를 열어야 하지만, 대부분의 Windows 방화벽과 VPC 네트워크 ACL에서는 포트가 양방향으로 열려 있어야 합니다.
## AD 도메인 서비스 계정 구성
AD 도메인 서비스 계정에 대한 다음 요구 사항을 충족했는지 확인합니다.
+ 자체 관리형 AD 도메인에는 컴퓨터를 도메인에 연결할 수 있는 권한이 위임된 도메인 서비스 계정이 있어야 합니다. 도메인 서비스 계정은 특정 작업을 수행할 권한이 위임된 자체 관리형 AD의 사용자 계정입니다.
+ 도메인 서비스 계정은 RDS for SQL Server DB 인스턴스에 가입시키려는 조직 단위(OU)에서 다음 권한을 위임받아야 합니다.
+ DNS 호스트 이름에 쓸 수 있는 검증된 기능
+ 서비스 보안 주체 이름에 쓸 수 있는 검증된 기능
+ 컴퓨터 객체 생성 및 삭제
이러한 권한은 컴퓨터 객체를 자체 관리형 AD에 조인하는 데 필요한 최소 권한 집합을 나타냅니다. 자세한 내용은 Microsoft Windows Server 설명서에서 [컴퓨터를 도메인에 연결하려고 할 때 발생하는 오류](https://learn.microsoft.com/en-US/troubleshoot/windows-server/identity/access-denied-when-joining-computers)를 참조하세요.
+ Kerberos 인증을 사용하려면 AD 도메인 서비스 계정에 서비스 위탁자 이름(SPN) 및 DNS 권한을 제공해야 합니다.
+ **SPN 쓰기**: RDS for SQL Server DB 인스턴스에 조인해야 하는 OU의 AD 도메인 서비스 계정에 **SPN 쓰기** 권한을 위임합니다. 이 권한은 검증된 쓰기 SPN과 다릅니다.
+ **DNS 권한**: 도메인 컨트롤러의 서버 수준에서 DNS 관리자의 AD 도메인 서비스 계정에 다음 권한을 제공합니다.
+ 콘텐츠 나열
+ 모든 속성 읽기
+ 권한 읽기
**중요**
DB 인스턴스를 만든 후에는 RDS for SQL Server가 조직 단위에서 생성한 컴퓨터 객체를 옮기지 마세요. 연결된 객체를 이동하면 RDS for SQL Server DB 인스턴스가 잘못 구성될 수 있습니다. Amazon RDS에서 생성한 컴퓨터 객체를 이동해야 하는 경우 [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) RDS API 작업을 사용하여 컴퓨터 객체의 원하는 위치로 도메인 파라미터를 수정하세요.
## LDAPS를 통한 보안 통신 구성
RDS가 도메인 컨트롤러의 SPNs뿐만 아니라 컴퓨터 객체를 쿼리하고 액세스하는 데 LDAPS를 통한 통신이 권장됩니다. 보안 LDAP를 사용하려면 보안 LDAPS 요구 사항을 충족하는 도메인 컨트롤러에서 유효한 SSL 인증서를 사용합니다. 도메인 컨트롤러에 유효한 SSL 인증서가 없는 경우 RDS for SQL Server DB 인스턴스는 기본적으로 LDAP를 사용합니다. 인증서 유효성에 대한 자세한 내용은 [LDAPS 인증서 요구 사항](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/enable-ldap-over-ssl-3rd-certification-authority#requirements-for-an-ldaps-certificate)을 참조하세요.
## 고려 사항
자체 관리형 AD에 RDS for SQL Server DB 인스턴스를 추가할 때는 다음 사항을 고려하세요.
+ DB 인스턴스는 AD 도메인의 시간 서버가 아닌 AWS의 NTP 서비스와 동기화됩니다. AD 도메인 내에서 연결된 SQL Server 인스턴스 간의 데이터베이스 연결의 경우, SQL 인증만 가능하며 Windows 인증은 사용할 수 없습니다.
+ 자체 관리형 AD 도메인의 Group Policy Object 설정은 RDS for SQL Server 인스턴스에 전파되지 않습니다.
# 자체 관리형 Active Directory 설정
자체 관리형 AD를 설정하려면 다음 단계를 따르세요.
**Topics**
+ [1단계: AD에서 조직 단위 생성](#USER_SQLServer_SelfManagedActiveDirectory.SettingUp.CreateOU)
+ [2단계: AD에서 AD 도메인 서비스 계정 생성](#USER_SQLServer_SelfManagedActiveDirectory.SettingUp.CreateADuser)
+ [3단계: AD 도메인 서비스 계정에 제어 위임](#USER_SQLServer_SelfManagedActiveDirectory.SettingUp.DelegateControl)
+ [4단계: AWS KMS 키 생성](#USER_SQLServer_SelfManagedActiveDirectory.SettingUp.CreateKMSkey)
+ [5단계: AWS 보안 암호 생성](#USER_SQLServer_SelfManagedActiveDirectory.SettingUp.CreateSecret)
## 1단계: AD에서 조직 단위 생성
**중요**
자체 관리형 AD 도메인에 가입된 RDS for SQL Server DB 인스턴스를 소유한 AWS 계정에 대해 전용 OU 및 해당 OU 범위의 서비스 보안 인증을 만드는 것이 좋습니다. 전용 OU 및 서비스 보안 인증을 지정하면 권한 충돌을 피하고 최소 권한 원칙을 따를 수 있습니다.
**AD에서 OU를 생성하려면**
1. 도메인 관리자로 AD 도메인에 연결합니다.
1. **Active Directory 사용자 및 컴퓨터**를 열고 OU를 생성할 도메인을 선택합니다.
1. 도메인을 마우스 오른쪽 버튼으로 클릭하고 **새로 만들기**를 선택한 다음 **조직 단위**를 선택합니다.
1. OU 이름을 입력합니다.
1. **컨테이너가 실수로 삭제되지 않도록 보호** 확인란을 선택한 상태로 유지합니다.
1. **확인**을 클릭합니다. 새 OU는 도메인 아래에 표시됩니다.
## 2단계: AD에서 AD 도메인 서비스 계정 생성
도메인 자격 증명은 AWS Secrets Manager에서 보안 암호로 사용됩니다.
**AD에서 AD 도메인 서비스 계정 생성**
1. **Active Directory 사용자 및 컴퓨터**를 열고 사용자를 생성할 도메인과 OU를 선택합니다.
1. **사용자** 객체를 마우스 오른쪽 버튼으로 클릭하고 **새로 만들기**, **사용자** 순으로 선택합니다.
1. 사용자의 이름, 성 및 로그온 이름을 입력합니다. **다음**을 클릭합니다.
1. 사용자의 암호를 입력합니다. **“다음 로그인 시 사용자가 암호를 변경해야 함”**을 선택하지 마세요. **“계정이 비활성화됨”**을 선택하지 마세요. **다음**을 클릭합니다.
1. **확인**을 클릭합니다. 새 사용자는 도메인 아래에 표시됩니다.
## 3단계: AD 도메인 서비스 계정에 제어 위임
**도메인의 AD 도메인 서비스 계정에 제어 권한 위임**
1. **Active Directory 사용자 및 컴퓨터** MMC 스냅인을 열고 사용자를 생성할 도메인을 선택합니다.
1. 이전에 만든 OU를 마우스 오른쪽 버튼으로 클릭하고 **제어 위임**을 선택합니다.
1. **제어 위임 마법사**에서 **다음**을 클릭합니다.
1. **사용자 또는 그룹** 섹션에서 **추가**를 클릭합니다.
1. **사용자, 컴퓨터 또는 그룹 선택** 섹션에서 생성한 AD 도메인 서비스 계정을 입력하고 **이름 확인**을 클릭합니다. AD 도메인 서비스 계정 확인에 성공하면 **확인**을 클릭합니다.
1. **사용자 또는 그룹** 섹션에서 AD 도메인 서비슥 ㅖ정이 추가되었는지 확인하고 **다음**을 클릭합니다.
1. **위임할 작업** 섹션에서 **위임할 사용자 지정 작업 생성**을 선택하고 **다음**을 클릭합니다.
1. **Active Directory 객체 유형** 섹션에서:
1. **폴더의 다음 객체만**을 선택합니다.
1. **컴퓨터 객체**를 선택합니다.
1. **이 폴더에서 선택한 객체 생성**을 선택합니다.
1. **이 폴더에서 선택한 객체 삭제**를 선택하고 **다음**을 클릭합니다.
1. **권한** 섹션에서:
1. **일반**을 선택한 상태로 유지합니다.
1. **DNS 호스트 이름에 대한 검증된 쓰기**를 선택합니다.
1. **서비스 보안 주체 이름에 대한 검증된 쓰기**를 선택하고 **다음**을 클릭합니다.
1. Kerberos 인증을 활성화하려면 **속성별**을 선택한 상태로 유지하고 목록에서 **servicePrincipalName 쓰기**를 선택합니다.
1. **제어 위임 마법사를 완료하려면** 설정을 검토 및 확인한 다음 **마침**을 클릭합니다.
1. Kerberos 인증의 경우 DNS 관리자를 열고 **서버** 속성을 엽니다.
1. Windows 대화 상자에 `dnsmgmt.msc`를 입력합니다.
1. **보안** 탭 아래에 AD 도메인 서비스 계정을 추가합니다.
1. **읽기** 권한을 선택하고 변경 사항을 적용합니다.
## 4단계: AWS KMS 키 생성
KMS 키는 AWS 보안 암호를 암호화하는 데 사용됩니다.
**AWS KMS 키를 생성하려면**
**참고**
**암호화 키**의 경우 AWS 기본 KMS 키를 사용하지 마세요. 자체 관리형 AD에 가입시키려는 RDS for SQL Server DB 인스턴스가 포함된 동일한 AWS 계정에 AWS KMS 키를 만들어야 합니다.
1. AWS KMS 콘솔에서 **키 생성**을 선택합니다.
1. **키 유형**에 대해 **대칭**을 선택합니다.
1. **키 사용**에서 **암호화 및 암호 해독**을 선택합니다.
1. **고급 옵션**에서 다음을 수행합니다.
1. **키 구성 요소 오리진**에서 **KMS**를 선택합니다.
1. **리전 구분**에서 **단일 리전 키**를 선택하고 **다음**을 클릭합니다.
1. **별칭**의 경우 KMS 키의 이름을 입력합니다.
1. (선택 사항) **설명**에 KMS 키에 대한 설명을 입력합니다.
1. (선택 사항) **태그**의 경우 KMS 키에 태그를 지정하고 **다음**을 클릭합니다.
1. **키 관리자**의 경우 IAM 사용자의 이름을 입력하고 선택합니다.
1. **키 삭제**의 경우 **키 관리자가 이 키를 삭제하도록 허용** 확인란을 선택한 상태로 유지하고 **다음**을 클릭합니다.
1. **키 사용자**의 경우 이전 단계와 동일한 IAM 사용자를 입력하고 해당 사용자를 선택합니다. **다음**을 클릭합니다.
1. 구성을 검토합니다.
1. **주요 정책**의 경우 정책 **문**에 다음을 포함하세요.
```
{
"Sid": "Allow use of the KMS key on behalf of RDS",
"Effect": "Allow",
"Principal": {
"Service": [
"rds.amazonaws.com"
]
},
"Action": "kms:Decrypt",
"Resource": "*"
}
```
1. **완료**를 클릭합니다.
## 5단계: AWS 보안 암호 생성
**보안 암호 생성**
**참고**
자체 관리형 AD에 가입시키려는 RDS for SQL Server DB 인스턴스가 포함된 동일한 AWS 계정에 보안 암호를 만들어야 합니다.
1. AWS Secrets Manager에서 **새 보안 암호 저장**을 선택합니다.
1. **보안 암호 유형**에서 **다른 유형의 보안 암호**를 선택합니다.
1. **키/값 쌍**의 경우 2개의 키를 추가합니다.
1. 첫 번째 키에는 `SELF_MANAGED_ACTIVE_DIRECTORY_USERNAME`를 입력합니다.
1. 첫 번째 키 값에는 AD 사용자의 사용자 이름(도메인 접두사 제외)만 입력합니다. 도메인 이름을 포함하면 인스턴스 생성이 실패하므로 포함하지 마세요.
1. 두 번째 키에는 `SELF_MANAGED_ACTIVE_DIRECTORY_PASSWORD`를 입력합니다.
1. 두 번째 키의 값으로 도메인의 AD 사용자에 대해 생성한 암호를 입력합니다.
1. **암호화 키**에는 이전 단계에서 생성한 KMS 키를 입력하고 **다음**을 클릭합니다.
1. **보안 암호 이름**에는 나중에 암호를 찾는 데 도움이 되는 설명이 포함된 이름을 입력합니다.
1. (선택 사항) **설명**에 보안 암호 이름에 대한 설명을 입력합니다.
1. **리소스 권한**의 경우 **편집**을 클릭합니다.
1. 권한 정책에 다음 정책을 추가합니다.
**참고**
*혼란스러운 대리인* 문제를 피하기 위해 정책의 `aws:sourceAccount` 및 `aws:sourceArn` 조건을 사용하는 것이 좋습니다. `aws:sourceAccount`에는 AWS 계정를 사용하고 `aws:sourceArn`에는 RDS for SQL Server DB 인스턴스를 사용합니다. 자세한 내용은 [교차 서비스 혼동된 대리자 문제 방지](cross-service-confused-deputy-prevention.md) 섹션을 참조하세요.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":
[
{
"Effect": "Allow",
"Principal":
{
"Service": "rds.amazonaws.com"
},
"Action": "secretsmanager:GetSecretValue",
"Resource": "*",
"Condition":
{
"StringEquals":
{
"aws:sourceAccount": "123456789012"
},
"ArnLike":
{
"aws:sourceArn": "arn:aws:rds:us-west-2:123456789012:db:*"
}
}
}
]
}
```
------
1. **저장**을 클릭한 후 **다음**을 클릭합니다.
1. **교체 설정 구성**에서 기본값을 유지하고 **다음**을 선택합니다.
1. 보안 암호 설정을 검토하고 **저장**을 클릭합니다.
1. 생성한 보안 암호를 선택하고 **보안 암호 ARN**의 값을 복사합니다. 이는 다음 단계에서 자체 관리형 Active Directory를 설정하는 데 사용됩니다.
# DB 인스턴스를 자체 관리형 Active Directory에 조인
RDS for SQL Server DB 인스턴스를 자체 관리형 AD에 조인하려면 다음 단계를 따르세요.
## 1단계: SQL Server DB 인스턴스 생성 또는 수정
콘솔, CLI 또는 RDS API를 사용하여 RDS for SQL Server DB 인스턴스를 자체 관리형 AD 도메인에 연결할 수 있습니다. 이 작업을 다음 중 한 가지 방법으로 수행할 수 있습니다.
+ 콘솔, [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) CLI 명령 또는 [CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) RDS API 작업을 사용하여 새 SQL Server DB 인스턴스를 생성합니다.
지침은 [Amazon RDS DB 인스턴스 생성](USER_CreateDBInstance.md) 섹션을 참조하세요.
+ 콘솔, [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) CLI 명령 또는 [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) RDS API 작업을 사용하여 기존 SQL Server DB 인스턴스를 수정합니다.
지침은 [Amazon RDS DB 인스턴스 수정](Overview.DBInstance.Modifying.md) 섹션을 참조하세요.
+ 콘솔, [restore-db-instance-from-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html) CLI 명령 또는 [RestoreDBInstanceFromDBSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html) RDS API 작업을 사용하여 DB 스냅샷에서 SQL Server DB 인스턴스를 복원합니다.
지침은 [DB 인스턴스 복원](USER_RestoreFromSnapshot.md) 섹션을 참조하세요.
+ 콘솔, [restore-db-instance-to-point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html) CLI 명령 또는 [RestoreDBInstanceToPointInTime](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html) RDS API 작업을 사용하여 SQL Server DB 인스턴스를 특정 시점으로 복구합니다.
지침은 [Amazon RDS에서 DB 인스턴스를 지정된 시간으로 복원](USER_PIT.md) 섹션을 참조하세요.
AWS CLI를 사용하는 경우 DB 인스턴스가 생성한 자체 관리형 AD 도메인을 사용하려면 다음과 같은 파라미터가 필요합니다.
+ `--domain-fqdn` 파라미터에는 자체 관리형 AD의 정규화된 도메인 이름(FQDN)을 사용합니다.
+ `--domain-ou` 파라미터에는 자체 관리형 AD에서 만든 OU를 사용합니다.
+ `--domain-auth-secret-arn` 파라미터에는 이전 단계에서 생성한 **보안 암호 ARN**의 값을 사용합니다.
+ `--domain-dns-ips` 파라미터에는 자체 관리형 AD용 DNS 서버의 프라이머리 및 보조 IPv4 주소를 사용합니다. 보조 DNS 서버 IP 주소가 없는 경우 프라이머리 IP 주소를 2번 입력합니다.
다음 예제 CLI 명령은 자체 관리형 AD 도메인이 있는 RDS for SQL Server DB 인스턴스를 생성, 수정 및 제거하는 방법을 보여줍니다.
**중요**
자체 관리형 AD 도메인에 가입하거나 자체 관리형 AD 도메인에서 제거하도록 DB 인스턴스를 수정한 경우 변경 사항이 적용되려면 DB 인스턴스를 재부팅해야 합니다. 변경 사항을 즉시 적용하거나 다음 유지 관리 기간까지 기다릴 수 있습니다. **즉시 적용** 옵션을 선택하면 단일 AZ DB 인스턴스에 가동 중단이 발생합니다. 다중 AZ DB 인스턴스는 재부팅을 완료하기 전에 장애 조치를 수행합니다. 자세한 내용은 [수정 예약 설정 사용](USER_ModifyInstance.ApplyImmediately.md) 섹션을 참조하세요.
다음 CLI 명령은 새 RDS for SQL Server DB 인스턴스를 만들어 자체 관리형 AD 도메인에 가입시킵니다.
대상 LinuxmacOS, 또는Unix:
```
aws rds create-db-instance \
--db-instance-identifier my-DB-instance \
--db-instance-class db.m5.xlarge \
--allocated-storage 50 \
--engine sqlserver-se \
--engine-version 15.00.4043.16.v1 \
--license-model license-included \
--master-username my-master-username \
--master-user-password my-master-password \
--domain-fqdn my_AD_domain.my_AD.my_domain \
--domain-ou OU=my-AD-test-OU,DC=my-AD-test,DC=my-AD,DC=my-domain \
--domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:my-AD-test-secret-123456" \
--domain-dns-ips "10.11.12.13" "10.11.12.14"
```
Windows의 경우:
```
aws rds create-db-instance ^
--db-instance-identifier my-DB-instance ^
--db-instance-class db.m5.xlarge ^
--allocated-storage 50 ^
--engine sqlserver-se ^
--engine-version 15.00.4043.16.v1 ^
--license-model license-included ^
--master-username my-master-username ^
--master-user-password my-master-password ^
--domain-fqdn my-AD-test.my-AD.mydomain ^
--domain-ou OU=my-AD-test-OU,DC=my-AD-test,DC=my-AD,DC=my-domain ^
--domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:my-AD-test-secret-123456" \ ^
--domain-dns-ips "10.11.12.13" "10.11.12.14"
```
다음 CLI 명령은 자체 관리형 AD 도메인을 사용하도록 기존 RDS for SQL Server DB 인스턴스를 수정합니다.
대상 LinuxmacOS, 또는Unix:
```
aws rds modify-db-instance \
--db-instance-identifier my-DB-instance \
--domain-fqdn my_AD_domain.my_AD.my_domain \
--domain-ou OU=my-AD-test-OU,DC=my-AD-test,DC=my-AD,DC=my-domain \
--domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:my-AD-test-secret-123456" \
--domain-dns-ips "10.11.12.13" "10.11.12.14"
```
Windows의 경우:
```
aws rds modify-db-instance ^
--db-instance-identifier my-DBinstance ^
--domain-fqdn my_AD_domain.my_AD.my_domain ^
--domain-ou OU=my-AD-test-OU,DC=my-AD-test,DC=my-AD,DC=my-domain ^
--domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:my-AD-test-secret-123456" ^
--domain-dns-ips "10.11.12.13" "10.11.12.14"
```
다음 CLI 명령은 자체 관리형 AD 도메인에서 RDS for SQL Server DB 인스턴스를 제거합니다.
대상 LinuxmacOS, 또는Unix:
```
aws rds modify-db-instance \
--db-instance-identifier my-DB-instance \
--disable-domain
```
Windows의 경우:
```
aws rds modify-db-instance ^
--db-instance-identifier my-DB-instance ^
--disable-domain
```
## 2단계: Kerberos 또는 NTLM 인증 사용
### NTLM 인증
각 Amazon RDS DB 인스턴스에는 엔드포인트가 있으며, 각 엔드포인트에는 DB 인스턴스의 DNS 이름과 포트 번호가 있습니다. SQL 클라이언트 애플리케이션을 사용해 DB 인스턴스에 연결하려면 DB 인스턴스에 연결할 수 있는 DNS 이름과 포트 번호가 필요합니다. NTLM 인증을 사용하여 인증하려면 다중 AZ 배포를 사용하는 경우 RDS 엔드포인트 또는 리스너 엔드포인트에 연결해야 합니다.
계획된 데이터베이스 유지 관리 또는 예기치 않은 서비스 중단이 발생할 경우 Amazon RDS가 최신 보조 데이터베이스로 자동으로 장애 조치를 수행하므로 수동 개입 없이 작업을 빠르게 재개할 수 있습니다. 기본 인스턴스 및 보조 인스턴스는 동일한 엔드포인트를 사용합니다. 이 엔드포인트의 물리적 네트워크 주소는 장애 조치 프로세스의 일환으로 보조로 전환됩니다. 장애 조치가 발생하는 경우 애플리케이션을 다시 구성할 필요가 없습니다.
### Kerberos 인증
RDS for SQL Server에 대한 Kerberos 기반 인증을 수행하려면 특정 서비스 위탁자 이름(SPN)에 연결해야 합니다. 그러나 장애 조치 이벤트 후 애플리케이션이 새 SPN을 인식하지 못할 수 있습니다. 이를 해결하기 위해 RDS for SQL Server는 Kerberos 기반 엔드포인트를 제공합니다.
Kerberos 기반 엔드포인트는 특정 형식을 따릅니다. RDS 엔드포인트가 `rds-instance-name.account-region-hash.aws-region.rds.amazonaws.com`인 경우 해당 Kerberos 기반 엔드포인트는 `rds-instance-name.account-region-hash.aws-region.awsrds.fully qualified domain name (FQDN)`입니다.
예를 들어 RDS 엔드포인트가 `ad-test.cocv6zwtircu.us-east-1.rds.amazonaws.com`이고 도메인 이름이 `corp-ad.company.com`인 경우 Kerberos 기반 엔드포인트는 `ad-test.cocv6zwtircu.us-east-1.awsrds.corp-ad.company.com`입니다.
이 Kerberos 기반 엔드포인트는 기본 SQL Server 인스턴스의 새 SPN을 가리키도록 엔드포인트가 자동으로 업데이트되므로 장애 조치 이벤트 후에도 Kerberos를 사용하여 SQL Server 인스턴스로 인증하는 데 사용할 수 있습니다.
### CNAME 찾기
CNAME를 찾으려면 도메인 컨트롤러에 연결하고 **DNS Manager**를 엽니다. **정방향 조회 영역** 및 FQDN으로 이동합니다.
**awsrds**, **aws-region**, **계정 및 리전별 해시**를 탐색합니다.
![\[DB 인스턴스의 스토리지 크기 수정\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/kerb-endpoint-selfManagedAD-RDSMS.png)
원격 클라이언트에서 CNAME를 연결한 후 NTLM 연결이 반환되면 필요한 포트가 허용 목록에 있는지 확인합니다.
연결에서 Kerberos를 사용 중인지 확인하려면 다음 쿼리를 실행합니다.
```
SELECT net_transport, auth_scheme
FROM sys.dm_exec_connections
WHERE session_id = @@SSPID;
```
Kerberos 엔드포인트에 연결할 때 인스턴스가 NTLM 연결을 반환하는 경우 네트워크 구성 및 사용자 구성을 확인합니다. [네트워크 연결 구성](USER_SQLServer_SelfManagedActiveDirectory.Requirements.md#USER_SQLServer_SelfManagedActiveDirectory.Requirements.NetworkConfig)을(를) 참조하세요.
## 3단계: Windows 인증 SQL Server 로그인 생성
다른 DB 인스턴스의 경우와 같은 방법으로 Amazon RDS 마스터 사용자 보안 인증 정보를 사용하여 SQL Server DB 인스턴스에 연결합니다. DB 인스턴스는 자체 관리형 AD 도메인에 가입되므로 SQL Server 로그인 및 사용자를 프로비저닝할 수 있습니다. 이 작업은 자체 관리형 AD 도메인의 AD 사용자 및 그룹 유틸리티에서 수행합니다. 데이터베이스 권한은 이러한 Windows 로그인에 부여되거나 취소되는 표준 SQL Server 권한을 통해 관리됩니다.
자체 관리형 AD 도메인 서비스 계정이 SQL 서버를 사용하여 인증하려면 자체 관리형 AD 도메인 서비스 계정 또는 사용자가 구성원인 자체 관리형 AD 그룹에 대한 SQL Server Windows 로그인이 있어야 합니다. 세분화된 액세스 제어는 이러한 SQL Server 로그인에 대한 권한을 부여하거나 취소하여 처리합니다. SQL Server 로그인이 없거나 이러한 로그인이 있는 자체 관리형 AD 그룹에 속하지 않은 자체 관리형 AD 도메인 서비스 계정은 SQL Server DB 인스턴스에 액세스할 수 없습니다.
자체 관리형 AD SQL Server 로그인을 생성하려면 ALTER ANY LOGIN 권한이 필요합니다. 이 권한으로 로그인을 생성하지 않은 경우 SQL Server 인증을 사용하여 DB 인스턴스의 마스터 사용자로 연결하고 마스터 사용자의 맥락에서 자체 관리형 AD SQL Server 로그인을 생성합니다.
다음과 같은 데이터 정의 언어(DDL) 명령을 실행하여 자체 관리형 AD 도메인 서비스 계정 또는 그룹에 대한 SQL Server 로그인을 생성할 수 있습니다.
**참고**
Windows 2000 이전 로그인 이름을 사용하여 사용자 및 그룹을 `my_AD_domain\my_AD_domain_user` 형식으로 지정합니다. UPN(User Principle Name)을 *`my_AD_domain_user`*`@`*`my_AD_domain`* 형식으로 사용할 수 없습니다.
```
USE [master]
GO
CREATE LOGIN [my_AD_domain\my_AD_domain_user] FROM WINDOWS WITH DEFAULT_DATABASE = [master], DEFAULT_LANGUAGE = [us_english];
GO
```
자세한 내용은 Microsoft Developer Network 설명서에서 [CREATE LOGIN(Transact-SQL)](https://msdn.microsoft.com/en-us/library/ms189751.aspx)을 참조하세요.
도메인의 사용자(사람 및 애플리케이션)는 이제 Windows 인증을 사용하여 자체 관리형 AD 도메인이 연결된 클라이언트 컴퓨터의 RDS for SQL Server 인스턴스에 연결할 수 있습니다.
# 자체 관리형 Active Directory 도메인에서 DB 인스턴스 관리
콘솔, AWS CLI 또는 Amazon RDS API를 사용하여 DB 인스턴스 및 DB 인스턴스와 자체 관리형 AD 도메인과의 관계를 관리할 수 있습니다. 예를 들어, DB 인스턴스를 도메인 내로, 도메인 외부로 또는 도메인 간에 이동할 수 있습니다.
예를 들어 Amazon RDS API를 사용하여 다음을 수행할 수 있습니다.
+ 실패한 멤버십에 대해 자체 관리형 도메인 가입을 다시 시도하려면 [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) API 작업을 사용하고 동일한 파라미터 세트를 지정하세요.
+ `--domain-fqdn`
+ `--domain-dns-ips`
+ `--domain-ou`
+ `--domain-auth-secret-arn`
+ 자체 관리형 도메인에서 DB 인스턴스를 제거하려면 `ModifyDBInstance` API 작업을 사용하고 `--disable-domain`을 도메인 파라미터로 지정합니다.
+ DB 인스턴스를 한 자체 관리형 도메인에서 다른 도메인으로 이동하려면 `ModifyDBInstance` API 작업을 사용하고 새 도메인에 대한 도메인 파라미터를 지정합니다.
+ `--domain-fqdn`
+ `--domain-dns-ips`
+ `--domain-ou`
+ `--domain-auth-secret-arn`
+ 각 DB 인스턴스에 대한 자체 관리형 AD 도메인 멤버십을 나열하려면 [DescribeDBInstances](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/DescribeDBInstances.html) API 작업을 사용합니다.
## 자체 관리형 Active Directory 도메인 멤버십에 대한 이해
AD 세부 정보를 지정하여 DB 인스턴스를 생성하거나 수정한 경우 해당 인스턴스는 자체 관리형 AD 도메인의 구성원이 됩니다. AWS 콘솔은 DB 인스턴스에 대한 자체 관리형 Active Directory 도메인 멤버십의 상태를 나타냅니다. DB 인스턴스의 상태는 다음 중 한 가지가 될 수 있습니다.
+ **joined** – 인스턴스가 AD 도메인의 구성원입니다.
+ **joining** – 인스턴스가 AD 도메인 구성원이 되기 위한 과정을 진행하고 있습니다.
+ **pending-join** – 인스턴스 멤버십이 보류 중입니다.
+ **pending-maintenance-join** - AWS에서 다음 예약된 유지 관리 기간 동안 인스턴스를 AD 도메인의 구성원으로 만들려고 시도합니다.
+ **pending-removal** – AD 도메인에서 인스턴스 제거 작업이 보류 중입니다.
+ **pending-maintenance-removal** - AWS에서 다음 예약된 유지 관리 기간 동안 AD 도메인에서 인스턴스를 제거하려고 시도합니다.
+ **failed** – 구성 문제가 발생하여 인스턴스가 AD 도메인에 가입되지 않았습니다. 인스턴스 수정 명령을 다시 실행하기 전에 구성을 확인하고 수정합니다.
+ **removing** – 인스턴스를 자체 관리형 AD 도메인에서 제거하고 있습니다.
**중요**
네트워크 연결 문제로 인해 자체 관리형 AD 도메인 구성원 되기 요청이 실패할 수 있습니다. 예를 들어 DB 인스턴스를 생성하거나 기존 인스턴스를 수정하여 DB 인스턴스가 자체 관리형 AD 도메인의 구성원이 되려는 시도를 못하게 할 수 있습니다. 이 경우 명령을 다시 실행하여 DB 인스턴스를 생성 또는 수정하거나 새로 생성된 인스턴스를 수정하여 자체 관리형 AD 도메인에 가입할 수 있습니다.
# 자체 관리형 Active Directory 문제 해결
다음은 자체 관리형 AD를 설정하거나 수정할 때 발생할 수 있는 문제입니다.
****
| 오류 코드 | 설명 | 일반적인 원인 | 문제 해결 제안 |
| --- | --- | --- | --- |
| 오류 2/0x2 | 시스템이 지정된 파일을 찾을 수 없습니다. | `—domain-ou` 파라미터로 지정된 조직 단위(OU)의 형식 또는 위치가 잘못되었습니다. AWS Secrets Manager를 통해 지정된 도메인 서비스 계정에는 OU에 가입하는 데 필요한 권한이 없습니다. | `—domain-ou` 파라미터를 검토합니다. 도메인 서비스 계정에 OU에 대한 올바른 권한이 있는지 확인합니다. 자세한 내용은 [AD 도메인 서비스 계정 구성](USER_SQLServer_SelfManagedActiveDirectory.Requirements.md#USER_SQLServer_SelfManagedActiveDirectory.Requirements.DomainAccountConfig) 섹션을 참조하세요. |
| 오류 5/0x5 | 액세스가 거부되었습니다. | 도메인 서비스 계정에 대한 권한이 잘못 구성되었거나 컴퓨터 계정이 이미 도메인에 있습니다. | 도메인의 도메인 서비스 계정 권한을 검토하고 RDS 컴퓨터 계정이 도메인에 중복되지 않았는지 확인합니다. RDS for SQL Server DB 인스턴스에서 `SELECT @@SERVERNAME`을 실행하여 RDS 컴퓨터 계정의 이름을 확인할 수 있습니다. 다중 AZ를 사용하는 경우 장애 조치를 사용하여 재부팅한 다음 RDS 컴퓨터 계정을 다시 확인합니다. 자세한 내용은 [ DB 인스턴스 재부팅](USER_RebootInstance.md) 섹션을 참조하세요. |
| 오류 87/0x57 | 파라미터가 올바르지 않습니다. | AWS Secrets Manager를 통해 지정된 도메인 서비스 계정에 올바른 권한이 없습니다. 사용자 프로필도 손상되었을 수 있습니다. | 도메인 서비스 계정의 요구 사항을 검토합니다. 자세한 내용은 [AD 도메인 서비스 계정 구성](USER_SQLServer_SelfManagedActiveDirectory.Requirements.md#USER_SQLServer_SelfManagedActiveDirectory.Requirements.DomainAccountConfig) 섹션을 참조하세요. |
| 오류 234/0xEA | 지정된 조직 단위(OU)가 없습니다. | `—domain-ou` 파라미터로 지정된 OU가 자체 관리형 AD에 존재하지 않습니다. | `—domain-ou` 파라미터를 검토하고 지정된 OU가 자체 관리형 AD에 있는지 확인합니다. |
| 오류 1326/0x52E | 사용자 이름 또는 암호가 잘못되었습니다. | AWS Secrets Manager에 제공된 도메인 서비스 계정 보안 인증 정보에 알 수 없는 사용자 이름이나 잘못된 암호가 있습니다. 자체 관리형 AD에서 도메인 계정을 사용하지 않도록 설정할 수도 있습니다. | AWS Secrets Manager에 제공된 자격 증명이 올바르고 자체 관리형 AD에서 도메인 계정이 활성화되어 있는지 확인합니다. |
| 오류 1355/0x54B | 지정된 도메인이 존재하지 않거나 해당 주소를 찾을 수 없습니다. | 도메인이 중지되었거나, 지정된 DNS IP 집합에 연결할 수 없거나, 지정된 FQDN에 연결할 수 없습니다. | `—domain-dns-ips` 및 `—domain-fqdn` 파라미터를 검토하여 올바른지 확인합니다. RDS for SQL Server DB 인스턴스의 네트워킹 구성을 검토하고 자체 관리형 AD에 연결할 수 있는지 확인합니다. 자세한 내용은 [네트워크 연결 구성](USER_SQLServer_SelfManagedActiveDirectory.Requirements.md#USER_SQLServer_SelfManagedActiveDirectory.Requirements.NetworkConfig) 섹션을 참조하세요. |
| 오류 1722/0x6BA | RPC 서버를 사용할 수 없습니다. | AD 도메인의 RPC 서비스에 연결하는 중 문제가 발생했습니다. 서비스 또는 네트워크 문제일 수 있습니다. | RPC 서비스가 도메인 컨트롤러에서 실행되고 있고 TCP 포트 `135` 및 `49152-65535`에서 RDS for SQL Server DB 인스턴스의 도메인에 연결할 수 있는지 확인합니다. |
| 오류 1727/0x6BF | 원격 프로시저 직접 호출이 실패했으며 실행되지 않았습니다. | 도메인 컨트롤러와의 RPC 통신을 차단하는 네트워크 연결 문제 또는 방화벽 제한. | 교차 VPC 도메인 조인을 사용하는 경우 VPC 피어링 또는 전송 게이트웨이를 사용하여 교차 VPC 통신이 올바르게 설정되었는지 확인합니다. 가능한 방화벽 제한을 포함하여 RDS for SQL Server DB 인스턴스에서 도메인의 TCP 하이 포트 `49152-65535`에 연결할 수 있는지 확인합니다. |
| 오류 2224/0x8B0 | 계정이 이미 있습니다. | 자체 관리형 AD에 추가하려는 컴퓨터 계정이 이미 있습니다. | RDS for SQL Server DB 인스턴스에서 `SELECT @@SERVERNAME`을 실행하여 컴퓨터 계정을 식별한 다음 자체 관리형 AD에서 해당 계정을 신중히 제거합니다. |
| 오류 2242/0x8c2 | 이 사용자의 암호가 만료되었습니다. | AWS Secrets Manager를 통해 지정한 도메인 서비스 계정의 암호가 만료되었습니다. | RDS for SQL Server DB 인스턴스를 자체 관리형 AD에 가입시키는 데 사용되는 도메인 서비스 계정의 암호를 업데이트합니다. |
DB 인스턴스를 자체 관리형 Active Directory 도메인에 조인한 후 도메인 상태와 관련된 RDS 이벤트를 수신할 수 있습니다.
```
Unhealthy domain state detected while attempt to verify or
configure your Kerberos endpoint in your domain on
node node_n. message
```
다중 AZ 인스턴스의 경우 node1과 node2 모두에 대한 오류 보고가 표시될 수 있습니다. 이는 인스턴스의 Kerberos 구성이 장애 조치를 받을 준비가 되지 않았음을 나타냅니다. 장애 조치 시 Kerberos를 사용하는 데 인증 문제가 발생할 수 있습니다. 구성 문제를 해결하여 Kerberos 설정이 유효하고 최신 상태인지 확인합니다. 다중 AZ 인스턴스의 경우 모든 네트워크 및 권한 구성이 마련되어 있으므로 새 기본 호스트에서 Kerberos 인증을 사용하는 데 필요한 작업이 없습니다.
단일 AZ 인스턴스의 경우 node1이 프라이머리 노드입니다. Kerberos 인증이 예상대로 작동하지 않는 경우 인스턴스 이벤트를 확인하고 구성 문제를 해결하여 Kerberos 설정이 유효하고 최신 상태인지 확인합니다.
## SQL Server DB 인스턴스를 복원한 후 자체 관리형 Active Directory 도메인에 추가
DB 스냅샷을 복원하거나 SQL Server DB 인스턴스에 대한 특정 시점 복구(PITR)를 수행한 후 자체 관리형 Active Directory 도메인에 추가할 수 있습니다. DB 인스턴스가 복원된 후 [1단계: SQL Server DB 인스턴스 생성 또는 수정](USER_SQLServer_SelfManagedActiveDirectory.Joining.md#USER_SQLServer_SelfManagedActiveDirectory.SettingUp.CreateModify)에 설명된 프로세스를 사용하여 DB 인스턴스를 자체 관리형 AD 도메인에 추가하도록 인스턴스를 수정합니다.
# RDS for SQL Server를 사용하여 AWS 관리형 Active Directory 작업
사용자가 RDS for SQL Server DB 인스턴스에 연결할 때 AWS Managed Microsoft AD를 통해 Windows 인증으로 사용자를 인증할 수 있습니다. DB 인스턴스는 AWS Directory Service for Microsoft Active Directory라고도 하는 AWS Managed Microsoft AD과 함께 작동하여 Windows 인증을 활성화합니다. 사용자가 신뢰할 수 있는 도메인에 가입된 SQL Server DB 인스턴스를 사용하여 인증할 경우 Directory Service를 사용하여 만든 도메인 디렉터리에 인증 요청이 전달됩니다.
## 리전 및 버전 사용 가능 여부
Amazon RDS는 AWS Managed Microsoft AD를 Windows 인증에만 사용할 수 있도록 지원합니다. RDS는 AD Connector 사용을 지원하지 않습니다. 자세한 내용은 다음 자료를 참조하세요.
+ [의 애플리케이션 호환성 정책AWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_app_compatibility.html)
+ [AD Connector의 애플리케이션 호환성 정책](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ad_connector_app_compatibility.html)
버전 및 리전 가용성에 관한 자세한 내용은 [Kerberos 인증을 사용하는 RDS for SQL Server](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.RDS_Fea_Regions_DB-eng.Feature.KerberosAuthentication.html#Concepts.RDS_Fea_Regions_DB-eng.Feature.KerberosAuthentication.sq)를 참조하세요.
## Windows 인증 설정 개요
Amazon RDS는 Windows 인증에 혼합 모드를 사용합니다. 이 접근 방식에서 *마스터 사용자*(SQL Server DB 인터페이스를 생성하는 데 사용된 이름과 암호)는 SQL 인증을 사용합니다. 마스터 사용자 계정은 권한 있는 자격 증명이므로 이 계정에 대한 액세스를 제한해야 합니다.
온프레미스 또는 자체 호스팅된 Microsoft Active Directory를 사용하여 Windows 인증을 얻으려면 포리스트 신뢰를 생성합니다. 단방향 또는 양방향 트러스트가 가능합니다. Directory Service를 사용하여 포리스트 신뢰를 설정하는 방법에 대한 자세한 내용은 *AWS Directory Service 관리 안내서*의 [신뢰 관계를 생성해야 하는 경우](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_setup_trust.html)를 참조하십시오.
SQL Server DB 인스턴스에 대한 Windows 인증을 설정하려면 [SQL Server DB 인스턴스에 대한 Windows 인증 설정](USER_SQLServerWinAuth.SettingUp.md)에 자세히 설명된 다음 단계를 수행합니다.
1. AWS Managed Microsoft AD 또는 AWS Management Console API에서 Directory Service를 사용하여 AWS Managed Microsoft AD 디렉터리를 생성합니다.
1. AWS CLI 또는 Amazon RDS API를 사용하여 SQL Server DB 인스턴스를 생성하는 경우 AWS Identity and Access Management(IAM) 역할을 생성합니다. 이 역할은 관리형 IAM 정책 `AmazonRDSDirectoryServiceAccess`를 사용하며 이 역할을 통해 Amazon RDS에서 디렉터리를 호출할 수 있습니다. 콘솔을 사용하여 SQL Server DB 인스턴스를 생성하는 경우 AWS에서 IAM 역할을 자동으로 생성합니다.
역할이 액세스를 허용하려면 AWS Security Token Service 리전에서 AWS STS 계정의 AWS(AWS) 엔드포인트를 활성화해야 합니다. AWS STS 엔드포인트는 기본적으로 모든 AWS 리전에서 활성화되어 있으므로 더 이상의 조치 없이 사용할 수 있습니다. 자세한 내용은 *IAM 사용 설명서*의 [AWS 리전에서 AWS STS 관리](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html)를 참조하세요.
1. Microsoft Active Directory 도구를 사용하여 AWS Managed Microsoft AD 디렉터리에서 사용자 및 그룹을 만들고 구성합니다. Active Directory에서 사용자 및 그룹을 생성하는 방법에 대한 자세한 내용은 *AWS Directory Service 관리 안내서*의 에서 [AWS Managed Microsoft AD에서 사용자 및 그룹 관리](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_manage_users_groups.html)를 참조하세요.
1. 디렉터리와 DB 인스턴스를 다른 VPC에 배치하려면 VPC 간 트래픽을 활성화하십시오.
1. Amazon RDS를 사용하여 콘솔, AWS CLI 또는 Amazon RDS API에서 새 SQL Server DB 인스턴스를 생성합니다. 생성 요청에서 디렉터리를 만들 때 생성된 도메인 식별자("`d-*`" 식별자)와 생성된 역할의 이름을 제공합니다. DB 인스턴스에 대한 도메인 및 IAM 역할 파라미터를 설정하여 Windows 인증을 사용하도록 기존 SQL Server DB 인스턴스를 수정할 수도 있습니다.
1. 다른 DB 인스턴스의 경우와 같은 방법으로 Amazon RDS 마스터 사용자 자격 증명을 사용하여 SQL Server DB 인스턴스에 연결합니다. DB 인스턴스는 AWS Managed Microsoft AD 도메인에 조인되므로 도메인에 있는 Active Directory 사용자 및 그룹의 SQL Server 로그인과 사용자를 프로비저닝할 수 있습니다. (이를 SQL Server "Windows" 로그인이라고 합니다.) 데이터베이스 권한은 이러한 Windows 로그인에 부여되거나 취소되는 표준 SQL Server 권한을 통해 관리됩니다.
Amazon RDS 콘솔을 사용하여 도메인 연결 RDS for SQL Server DB 인스턴스를 생성하면 AWS가 `rds-directoryservice-access-role` IAM 역할을 자동으로 생성합니다. 이 역할은 도메인 연결 인스턴스를 관리하는 데 필수적이며 다음 작업에 필요합니다.
+ 도메인 연결 SQL Server 인스턴스에 대한 구성 변경
+ Active Directory 통합 설정 관리
+ 도메인 조인 인스턴스에 대한 유지 관리 작업 수행
**중요**
`rds-directoryservice-access-role` IAM 역할을 삭제하면 Amazon RDS 콘솔 또는 API를 통해 도메인 연결 SQL Server 인스턴스를 변경할 수 없습니다. 이 인스턴스를 수정하려고 하면 iam:CreateRole에 대한 권한이 없다는 오류 메시지가 표시됩니다. 액세스를 요청하려면 다음 텍스트를 복사하여 AWS 관리자에게 전송합니다.
이 오류는 Amazon RDS가 도메인 연결을 관리하기 위해 역할을 다시 생성해야 하지만 필요한 권한이 없기 때문에 발생합니다. 또한 이 오류는 CloudTrail에 로깅되지 않으므로 문제 해결이 더 어려울 수 있습니다.
실수로 `rds-directoryservice-access-role`을 삭제한 경우 다시 생성할 수 있는 `iam:CreateRole` 권한이 있어야 도메인 연결 SQL Server 인스턴스를 변경할 수 있습니다. 역할을 수동으로 다시 생성하려면 `AmazonRDSDirectoryServiceAccess` 관리형 정책이 연결되어 있고 RDS 서비스가 해당 역할을 수임하도록 허용하는 적절한 신뢰 관계가 있는지 확인합니다.
# Kerberos 인증에 대한 엔드포인트 만들기
Kerberos 기반 인증을 사용하려면 엔드포인트가 고객이 지정한 호스트 이름과 마침표(.) 및 정규화된 도메인 이름(FQDN) 순으로 구성되어야 합니다. 예를 들어, 다음은 Kerberos 기반 인증과 함께 사용할 수 있는 엔드포인트의 예입니다. 이 예에서 SQL Server DB 인스턴스 호스트 이름은 `ad-test`이고 도메인 이름은 `corp-ad.company.com`입니다.
```
ad-test.corp-ad.company.com
```
현재 연결에서 Kerberos를 사용 중인지 확인하려면 다음 쿼리를 실행합니다.
```
1. SELECT net_transport, auth_scheme
2. FROM sys.dm_exec_connections
3. WHERE session_id = @@SPID;
```
# SQL Server DB 인스턴스에 대한 Windows 인증 설정
AWS Directory Service for Microsoft Active Directory라고도 하는 AWS Managed Microsoft AD를 사용하여 SQL Server DB 인스턴스의 Windows 인증을 설정합니다. Windows 인증을 설정하려면 다음 단계를 수행합니다.
## 1단계: AWS Directory Service for Microsoft Active Directory를 사용하여 디렉터리 만들기
Directory Service는 AWS 클라우드에 완전관리형 Microsoft Active Directory를 만듭니다. AWS Managed Microsoft AD 디렉터리를 생성할 때 Directory Service에서 두 개의 도메인 컨트롤러 및 Domain Name System(DNS) 서버가 자동으로 생성됩니다. 디렉터리 서버는 VPC 내 가용 영역 두 곳에 있는 두 개의 서브넷에서 생성됩니다. 이러한 중복은 장애가 발생해도 디렉터리에 액세스할 수 있도록 보장하는 데 도움이 됩니다.
AWS Managed Microsoft AD 디렉터리를 생성하는 경우 Directory Service에서 다음 작업이 자동으로 수행됩니다.
+ VPC 내에서 Microsoft Active Directory를 설정합니다.
+ 사용자 이름 Admin과 지정된 암호를 사용하여 디렉터리 관리자 계정을 생성합니다. 이 계정을 사용하여 디렉터리를 관리할 수 있습니다.
+ 디렉터리 컨트롤러에 대한 보안 그룹을 만듭니다.
AWS Directory Service for Microsoft Active Directory를 시작하면 AWS에서 모든 디렉터리의 객체를 포함하는 OU(조직 단위)를 생성합니다. 디렉터리를 만들 때 입력한 NetBIOS 이름을 가진 이 OU는 도메인 루트에 있습니다. 도메인 루트는 AWS에서 소유하고 관리합니다.
AWS Managed Microsoft AD 디렉터리를 사용하여 만든 *admin* 계정은 OU의 가장 일반적인 관리 활동에 대한 권한을 갖습니다.
+ 사용자, 그룹 및 컴퓨터를 생성, 업데이트 또는 삭제합니다.
+ 도메인(예: 파일 또는 인쇄 서버)에 리소스를 추가한 다음 OU 내의 사용자 및 그룹에 해당 리소스에 대한 권한 할당.
+ 추가 OU 및 컨테이너 생성.
+ 권한 위임.
+ 그룹 정책 생성 및 연결.
+ Active Directory 휴지통에서 삭제된 객체 복원.
+ Active Directory 웹 서비스에서 AD 및 DNS Windows PowerShell 모듈 실행.
또한 admin 계정은 다음 도메인 차원 활동을 수행할 권한이 있습니다.
+ DNS 구성 관리(레코드, 영역 및 전달자 추가, 제거 또는 업데이트)
+ DNS 이벤트 로그 보기
+ 보안 이벤트 로그 보기
**AWS Managed Microsoft AD으로 디렉터리를 생성하려면**
1. [Directory Service 콘솔](https://console.aws.amazon.com/directoryservicev2/) 탐색 창에서 **디렉터리**를 선택한 후 **디렉터리 설정**을 선택합니다.
1. 를 선택합니다.**AWS Managed Microsoft AD**. 이것은 현재 Amazon RDS에서 사용하도록 지원되는 유일한 옵션입니다.
1. **다음**을 선택합니다.
1. **디렉터리 정보 입력** 페이지에서 다음 정보를 제공합니다.
**Edition**
요구 사항에 맞는 에디션을 선택합니다.
**디렉터리 DNS 이름**
디렉터리를 위한 정규화된 이름(예: `corp.example.com`)입니다. 47자를 초과하는 이름은 SQL Server에서 지원되지 않습니다.
**디렉터리 NetBIOS 이름**
디렉터리의 선택적 짧은 이름(예: `CORP`)입니다.
**디렉터리 설명**
디렉터리에 대한 선택적 설명을 입력합니다.
**관리자 암호**
디렉터리 관리자의 암호입니다. 디렉터리 생성 프로세스에서는 사용자 이름 Admin과 이 암호를 사용하여 관리자 계정을 생성합니다.
디렉터리 관리자 암호는 `admin`이라는 단어를 포함할 수 없습니다. 암호는 대소문자를 구분하며 길이가 8\$164자 사이여야 합니다. 또한 다음 네 범주 중 세 개에 해당하는 문자를 1자 이상 포함해야 합니다.
+ 소문자(a-z)
+ 대문자(A-Z)
+ 숫자(0-9)
+ 영숫자 외의 특수 문자(\$1\$1@\$1\$1%^&\$1\$1-\$1=`\$1\$1()\$1\$1[]:;"'<>,.?/)
**[Confirm Password]**
관리자 암호를 다시 입력합니다.
1. [**Next**]를 선택합니다.
1. **Choose VPC and subnets(VPC 및 서브넷 선택)** 페이지에 다음 정보를 입력합니다.
**VPC**
디렉터리에 대한 VPC를 선택합니다.
디렉터리와 DB 인스턴스를 서로 다른 VPC에서 찾을 수 있지만, 그렇게 할 경우 교차 VPC 트래픽을 활성화해야 합니다. 자세한 내용은 [4단계: 디렉터리와 DB 인스턴스 사이에 VPC 간 트래픽 활성화](#USER_SQLServerWinAuth.SettingUp.VPC-Peering) 섹션을 참조하세요.
**서브넷**
디렉터리 서버에 대한 서브넷을 선택합니다. 두 서브넷이 서로 다른 가용 영역에 있어야 합니다.
1. **Next**(다음)를 선택합니다.
1. 디렉터리 정보를 검토합니다. 변경이 필요하면 **이전**을 선택합니다. 정보가 올바르면 **Create directory(디렉터리 생성)**을 선택합니다.
![\[페이지 검토 및 생성\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/WinAuth2.png)
디렉터리를 생성하는 데 몇 분 정도 걸립니다. 디렉터리가 성공적으로 생성되면 **상태** 값이 **활성**으로 변경됩니다.
디렉터리에 대한 정보를 보려면 디렉터리 목록에서 해당 디렉터리 ID를 선택합니다. **디렉터리 ID**를 적어 두십시오. SQL Server DB 인스턴스를 생성하거나 수정할 때 이 값이 필요합니다.
![\[디렉터리 세부 정보 페이지\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/WinAuth3.png)
## 2단계: Amazon RDS에 사용할 IAM 역할 생성
콘솔을 사용하여 SQL Server DB 인스턴스를 생성하는 경우 이 단계를 건너뛸 수 있습니다. CLI 또는 RDS API를 사용하여 SQL Server DB 인스턴스를 생성하는 경우 `AmazonRDSDirectoryServiceAccess` 관리형 IAM 정책을 사용하는 IAM 역할을 생성해야 합니다. 이 역할을 사용하여 Amazon RDS에서 Directory Service를 자동으로 호출할 수 있습니다.
AWS 관리형 `AmazonRDSDirectoryServiceAccess` 정책을 사용하는 대신 도메인 가입에 사용자 지정 정책을 사용하는 경우 `ds:GetAuthorizedApplicationDetails` 작업을 허용해야 합니다. 이 요구 사항은 Directory Service API 변경으로 인해 2019년 7월부터 유효합니다.
다음 IAM 정책 `AmazonRDSDirectoryServiceAccess`는 Directory Service에 대한 액세스를 제공합니다.
**Example Directory Service에 대한 액세스 제공을 위한 IAM 정책**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ds:DescribeDirectories",
"ds:AuthorizeApplication",
"ds:UnauthorizeApplication",
"ds:GetAuthorizedApplicationDetails"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
서비스 권한을 특정 리소스로 제한하는 리소스 기반 신뢰 관계의 [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) 및 [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) 전역 조건 컨텍스트 키를 사용하는 것이 좋습니다. 이는 [혼동된 대리자 문제](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)를 방지하는 가장 효과적인 방법입니다.
전역 조건 컨텍스트 키를 모두 사용하고 `aws:SourceArn` 값에 계정 ID가 포함되도록 할 수 있습니다. 이 경우 `aws:SourceAccount` 값과 `aws:SourceArn` 값의 계정이 동일한 문에서 사용될 때 동일한 계정 ID를 사용해야 합니다.
+ 단일 리소스에 대한 교차 서비스 액세스를 원하는 경우 `aws:SourceArn`을 사용하세요.
+ 해당 계정의 모든 리소스가 교차 서비스 사용과 연결되도록 허용하려는 경우 `aws:SourceAccount`를 사용하세요.
신뢰 정책에서는 역할에 액세스하는 리소스의 전체 Amazon 리소스 이름(ARN)이 포함된 `aws:SourceArn` 전역 조건 컨텍스트 키를 사용해야 합니다. Windows 인증의 경우 다음 예와 같이 DB 인스턴스를 포함해야 합니다.
**Example Windows 인증을 위한 전역 조건 컨텍스트 키와의 신뢰 관계**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceArn": [
"arn:aws:rds:Region:my_account_ID:db:db_instance_identifier"
]
}
}
}
]
}
```
이 IAM 정책 및 신뢰 관계를 사용하여 IAM 역할을 생성합니다. IAM 역할 생성에 대한 자세한 내용은 *IAM 사용 설명서*의 [고객 관리형 정책 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-using.html#create-managed-policy-console)을 참조하세요.
## 3단계: 사용자 및 그룹 생성 및 구성
Active Directory 사용자 및 컴퓨터 도구를 사용하여 사용자 및 그룹을 생성할 수 있습니다. 이 도구는 Active Directory 도메인 서비스 및 Active Directory Lightweight Directory Services 도구 중 하나입니다. 사용자는 디렉터리에 액세스할 수 있는 개별 사용자 또는 개체를 나타냅니다. 그룹은 개별 사용자에게 권한을 적용할 필요 없이 사용자 그룹에 권한을 부여하거나 거부하는 데 매우 유용합니다.
Directory Service 디렉터리에 사용자 및 그룹을 생성하려면 Directory Service 디렉터리의 멤버인 Windows EC2 인스턴스에 연결해야 합니다. 또한 사용자 및 그룹을 생성할 수 있는 권한을 가진 사용자로 로그인해야 합니다. 자세한 내용은 *AWS Directory Service관리 안내서*에서 [사용자 및 그룹 추가(Simple AD 및 AWS Managed Microsoft AD)](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/creating_ad_users_and_groups.html)를 참조하세요.
## 4단계: 디렉터리와 DB 인스턴스 사이에 VPC 간 트래픽 활성화
디렉터리와 DB 인스턴스를 동일한 VPC에 배치하려면 이 단계를 건너뛰고 [5단계: SQL Server DB 인스턴스 생성 또는 수정](#USER_SQLServerWinAuth.SettingUp.CreateModify) 섹션으로 이동하세요.
디렉터리와 DB 인스턴스를 서로 다른 VPC에 배치하려면 VPC 피어링 또는 [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)를 사용하여 VPC 간 트래픽을 구성하세요.
다음 절차는 VPC 피어링을 사용하여 VPC 간 트래픽을 활성화합니다. *Amazon Virtual Private Cloud 피어링 안내서*의 [VPC 피어링이란?](https://docs.aws.amazon.com/vpc/latest/peering/Welcome.html) 지침을 따르십시오.
**VPC 피어링을 사용하여 VPC 간 트래픽을 활성화하려면**
1. 네트워크 트래픽이 양방향으로 흐를 수 있도록 적절한 VPC 라우팅 규칙을 설정합니다.
1. DB 인스턴스의 보안 그룹이 디렉터리의 보안 그룹에서 인바운드 트래픽을 수신할 수 있는지 확인합니다.
1. 트래픽을 차단하는 네트워크 ACL(액세스 제어 목록) 규칙이 없어야 합니다.
다른 AWS 계정이 디렉터리를 소유하는 경우 디렉터리를 공유해야 합니다.
**AWS 계정 간에 디렉터리를 공유하려면**
1. *AWS 관리 안내서*의 [자습서: 원활한 EC2 도메인 조인을 위해 AWS Managed Microsoft AD 디렉터리 공유](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_directory_sharing.html)에 있는 지침에 따라 DB 인스턴스가 생성될 Directory Service 계정과 디렉터리를 공유하는 작업을 시작합니다.
1. DB 인스턴스용 계정을 사용하여 Directory Service 콘솔에 로그인하고 계속하기 전에 도메인이 `SHARED` 상태가 되었는지 확인합니다.
1. DB 인스턴스용 계정을 사용하여 Directory Service 콘솔에 로그인하는 동안 **디렉터리 ID** 값을 기록해 둡니다. 이 디렉터리 ID를 사용하여 DB 인스턴스를 도메인에 조인합니다.
## 5단계: SQL Server DB 인스턴스 생성 또는 수정
디렉터리에서 사용할 SQL Server DB 인스턴스를 생성하거나 수정합니다. 콘솔, CLI 또는 RDS API를 사용하여 DB 인스턴스를 디렉터리에 연결할 수 있습니다. 이 작업을 다음 중 한 가지 방법으로 수행할 수 있습니다.
+ 콘솔, [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) CLI 명령 또는 [CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) RDS API 작업을 사용하여 새 SQL Server DB 인스턴스를 생성합니다.
지침은 [Amazon RDS DB 인스턴스 생성](USER_CreateDBInstance.md) 섹션을 참조하세요.
+ 콘솔, [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) CLI 명령 또는 [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) RDS API 작업을 사용하여 기존 SQL Server DB 인스턴스를 수정합니다.
지침은 [Amazon RDS DB 인스턴스 수정](Overview.DBInstance.Modifying.md) 섹션을 참조하세요.
+ 콘솔, [restore-db-instance-from-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html) CLI 명령 또는 [RestoreDBInstanceFromDBSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html) RDS API 작업을 사용하여 DB 스냅샷에서 SQL Server DB 인스턴스를 복원합니다.
지침은 [DB 인스턴스 복원](USER_RestoreFromSnapshot.md) 섹션을 참조하세요.
+ 콘솔, [restore-db-instance-to-point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html) CLI 명령 또는 [RestoreDBInstanceToPointInTime](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html) RDS API 작업을 사용하여 SQL Server DB 인스턴스를 특정 시점으로 복구합니다.
지침은 [Amazon RDS에서 DB 인스턴스를 지정된 시간으로 복원](USER_PIT.md) 섹션을 참조하세요.
Windows 인증은 VPC의 SQL Server DB 인스턴스에 대해서만 지원됩니다.
DB 인스턴스에서 생성한 도메인 디렉터리를 사용할 수 있으려면 다음이 필요합니다.
+ **디렉터리**의 경우 디렉터리를 만들 때 생성된 도메인 식별자(`d-ID`)를 선택해야 합니다.
+ VPC 보안 그룹에 DB 인스턴스가 디렉터리와 통신할 수 있도록 하는 아웃바운드 규칙이 있는지 확인합니다.
![\[Microsoft SQL Server Windows 인증 디렉터리\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/WinAuth1.png)
AWS CLI를 사용하는 경우 생성한 도메인 디렉터리를 DB 인스턴스에서 사용하려면 다음과 같은 파라미터가 필요합니다.
+ `--domain` 파라미터의 경우 디렉터리를 만들 때 생성된 도메인 식별자(`d-ID`)를 사용합니다.
+ `--domain-iam-role-name` 파라미터의 경우 관리형 IAM 정책 `AmazonRDSDirectoryServiceAccess`를 사용하여 생성한 역할을 사용합니다.
예를 들어 다음 CLI 명령에서는 디렉터리를 사용하도록 DB 인스턴스를 수정합니다.
대상 LinuxmacOS, 또는Unix:
```
aws rds modify-db-instance \
--db-instance-identifier mydbinstance \
--domain d-ID \
--domain-iam-role-name role-name
```
Windows의 경우:
```
aws rds modify-db-instance ^
--db-instance-identifier mydbinstance ^
--domain d-ID ^
--domain-iam-role-name role-name
```
**중요**
DB 인스턴스를 수정하여 Kerberos 인증을 활성화하는 경우에는 변경 후 DB 인스턴스를 재부팅하세요.
## 6단계: Windows 인증 SQL Server 로그인 생성
다른 DB 인스턴스의 경우와 같은 방법으로 Amazon RDS 마스터 사용자 자격 증명을 사용하여 SQL Server DB 인스턴스에 연결합니다. DB 인스턴스는 AWS Managed Microsoft AD 도메인에 조인되므로 SQL Server 로그인 및 사용자를 프로비저닝할 수 있습니다. 도메인의 Active Directory 사용자 및 그룹에서 이 작업을 수행합니다. 데이터베이스 권한은 이러한 Windows 로그인에 부여되거나 취소되는 표준 SQL Server 권한을 통해 관리됩니다.
Active Directory 사용자가 SQL Server로 인증하려면 사용자 또는 사용자가 속한 그룹에 대한 SQL Server Windows 로그인이 있어야 합니다. 세분화된 액세스 제어는 이러한 SQL Server 로그인에 대한 권한을 부여하거나 취소하여 처리합니다. SQL Server 로그인이 없거나 이러한 로그인이 있는 그룹에 속하지 않은 사용자는 SQL Server DB 인스턴스에 액세스할 수 없습니다.
Active Directory SQL Server 로그인을 생성하려면 ALTER ANY LOGIN 권한이 필요합니다. 이 권한을 가진 로그인을 아직 생성하지 않은 경우 SQL Server 인증을 사용하여 DB 인스턴스의 마스터 사용자로 연결합니다.
다음 예와 같은 DDL(데이터 정의 언어) 명령을 실행하여 Active Directory 사용자 또는 그룹에 대한 SQL Server 로그인을 생성합니다.
**참고**
Windows 2000 이전 로그인 이름을 사용하여 사용자 및 그룹을 `domainName\login_name` 형식으로 지정합니다. UPN(User Principle Name)을 *`login_name`*`@`*`DomainName`* 형식으로 사용할 수 없습니다.
T-SQL 문을 사용해야만 RDS for SQL Server 인스턴스에서 Windows 인증 로그인을 만들 수 있습니다. SQL Server 관리 스튜디오를 사용하여 Windows 인증 로그인을 만들 수 없습니다.
```
USE [master]
GO
CREATE LOGIN [mydomain\myuser] FROM WINDOWS WITH DEFAULT_DATABASE = [master], DEFAULT_LANGUAGE = [us_english];
GO
```
자세한 내용은 Microsoft Developer Network 설명서에서 [CREATE LOGIN(Transact-SQL)](https://msdn.microsoft.com/en-us/library/ms189751.aspx)을 참조하세요.
도메인의 사용자(사람 및 애플리케이션)는 이제 Windows 인증을 사용하여 도메인이 조인된 클라이언트 컴퓨터의 RDS for SQL Server 인스턴스에 연결할 수 있습니다.
# 도메인에서 DB 인스턴스 관리
콘솔, AWS CLI 또는 Amazon RDS API를 사용하여 DB 인스턴스 및 DB 인스턴스와 도메인과의 관계를 관리할 수 있습니다. 예를 들어, DB 인스턴스를 도메인 내로, 도메인 외부로 또는 도메인 간에 이동할 수 있습니다.
예를 들어 Amazon RDS API를 사용하여 다음을 수행할 수 있습니다.
+ 실패한 멤버십에 대한 도메인 조인을 다시 시도하려면 [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) API 작업을 사용하고 현재 멤버십의 디렉터리 ID를 지정합니다.
+ 멤버십에 대한 IAM 역할 이름을 업데이트하려면 `ModifyDBInstance` API 작업을 사용하고 현재 멤버십의 디렉터리 ID 및 새 IAM 역할을 지정합니다.
+ 도메인에서 DB 인스턴스를 제거하려면 `ModifyDBInstance` API 작업을 사용하고 `none`을 도메인 파라미터로 지정합니다.
+ 한 도메인에서 다른 도메인으로 DB 인스턴스를 이동하려면 `ModifyDBInstance` API 작업을 사용하여 새 도메인의 도메인 식별자를 도메인 파라미터로 지정합니다.
+ 각 DB 인스턴스에 대한 멤버십을 나열하려면 [DescribeDBInstances](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/DescribeDBInstances.html) API 작업을 사용합니다.
## 도메인 멤버십 이해
DB 인스턴스를 생성하거나 수정한 경우 해당 인스턴스는 도메인의 구성원이 됩니다. AWS 콘솔은 DB 인스턴스에 대한 도메인 멤버십의 상태를 나타냅니다. DB 인스턴스의 상태는 다음 중 한 가지가 될 수 있습니다.
+ **joined** – 인스턴스가 도메인의 구성원입니다.
+ **joining** – 인스턴스가 도메인 구성원이 되기 위한 과정을 진행하고 있습니다.
+ **pending-join** – 인스턴스 멤버십이 보류 중입니다.
+ **pending-maintenance-join** - AWS에서 다음 예약된 유지 관리 기간 동안 인스턴스를 도메인의 멤버로 만들려고 시도합니다.
+ **pending-removal** – 도메인에서 인스턴스 제거 작업이 보류 중입니다.
+ **pending-maintenance-removal** - AWS에서 다음 예약된 유지 관리 기간 동안 도메인에서 인스턴스를 제거하려고 시도합니다.
+ **failed** – 구성 문제가 발생하여 인스턴스가 도메인에 조인되지 않았습니다. 인스턴스 수정 명령을 다시 실행하기 전에 구성을 확인하고 수정합니다.
+ **removing** – 인스턴스를 도메인에서 제거하고 있습니다.
네트워크 연결 문제 또는 잘못된 IAM 역할로 인해 도메인 구성원 되기 요청이 실패할 수 있습니다. 예를 들어, DB 인스턴스를 생성하거나 기존 인스턴스를 수정하여 DB 인스턴스가 도메인의 멤버가 되려는 시도를 못하게 할 수 있습니다. 이 경우 명령을 다시 실행하여 DB 인스턴스를 생성 또는 수정하거나 새로 생성된 인스턴스를 수정하여 도메인에 조인할 수 있습니다.
# Windows 인증을 사용하여 SQL Server에 연결
Windows 인증을 사용하여 SQL Server에 연결하려면 도메인에 조인된 컴퓨터에 도메인 사용자로 로그인해야 합니다. 다음과 같이 SQL Server Management Studio를 시작한 후 **Windows 인증**을 인증 유형으로 선택합니다.
![\[Windows 인증을 사용하여 SQL Server에 연결\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/WinAuth4.png)
## SQL Server DB 인스턴스를 복원한 후 도메인에 추가
DB 스냅샷을 복원하거나 SQL Server DB 인스턴스에 대한 특정 시점 복구(PITR)를 수행한 후 도메인에 추가할 수 있습니다. DB 인스턴스가 복원된 후 [5단계: SQL Server DB 인스턴스 생성 또는 수정](USER_SQLServerWinAuth.SettingUp.md#USER_SQLServerWinAuth.SettingUp.CreateModify)에 설명된 프로세스를 사용하여 DB 인스턴스를 도메인에 추가하도록 인스턴스를 수정합니다.
# Microsoft SQL Server DB 엔진 업그레이드
Amazon RDS에서 새 데이터베이스 엔진 버전을 지원하는 경우, DB 인스턴스를 새 버전으로 업그레이드할 수 있습니다. SQL Server DB 인스턴스의 업그레이드에는 메이저 버전 업그레이드와 마이너 버전 업그레이드라는 두 가지 업그레이드가 있습니다.
*메이저 버전 업그레이드*에는 기존 애플리케이션과 호환되지 않는 데이터베이스 변경 사항이 포함될 수 있습니다. 따라서 DB 인스턴스의 메이저 버전 업그레이드를 *수동으로* 수행해야 합니다. DB 인스턴스를 수정하여 메이저 버전 업그레이드를 시작할 수 있습니다. 그러나 메이저 버전 업그레이드를 수행하기 전에 [RDS for SQL Server 업그레이드 테스트](USER_UpgradeDBInstance.SQLServer.UpgradeTesting.md)에 설명된 단계에 따라 업그레이드를 테스트하는 것이 좋습니다.
*마이너 버전 업그레이드*에는 기존 애플리케이션과 호환되는 변경 사항만 포함됩니다. 다음 두 가지 방법으로 DB 인스턴스의 마이너 버전을 업그레이드할 수 있습니다.
+ *수동* - 업그레이드를 시작하도록 DB 인스턴스 수정
+ *자동* - DB 인스턴스에 대해 자동 마이너 버전 업그레이드 활성화
자동 마이너 버전 업그레이드를 활성화하면 RDS for SQL Server는 새로운 마이너 버전에서 중요한 보안 업데이트를 사용할 수 있을 때 예약된 유지 관리 기간 동안 데이터베이스 인스턴스를 자동으로 업그레이드합니다.
`16.00.4120.1`, `15.00.4365.2`, `14.00.3465.1`, `13.00.6435.1` 이후 마이너 엔진 버전의 경우 다음 보안 프로토콜이 기본적으로 비활성화됩니다.
+ `rds.tls10`(TLS 1.0 프로토콜)
+ `rds.tls11`(TLS 1.1 프로토콜)
+ `rds.rc4`(RC4 암호)
+ `rds.curve25519`(Curve25519 암호화)
+ `rds.3des168`(트리플 DES 암호화)
이전 엔진 버전의 경우 Amazon RDS는 기본적으로 이러한 보안 프로토콜을 활성화합니다.
```
...
"ValidUpgradeTarget": [
{
"Engine": "sqlserver-se",
"EngineVersion": "14.00.3281.6.v1",
"Description": "SQL Server 2017 14.00.3281.6.v1",
"AutoUpgrade": false,
"IsMajorVersionUpgrade": false
}
...
```
업그레이드 수행에 대한 자세한 내용은 [SQL Server DB 인스턴스 업그레이드](#USER_UpgradeDBInstance.SQLServer.Upgrading) 섹션을 참조하세요. Amazon RDS에서 사용할 수 있는 SQL Server 버전에 대한 자세한 내용은 [Amazon RDS for Microsoft SQL Server](CHAP_SQLServer.md) 섹션을 참조하세요.
또한 Amazon RDS는 업그레이드 롤아웃 정책을 지원하여 여러 데이터베이스 리소스 및 AWS 계정에서 자동 마이너 버전 업그레이드를 관리합니다. 자세한 내용은 [자동 마이너 버전 AWS Organizations 업그레이드에 업그레이드 롤아웃 정책 사용](RDS.Maintenance.AMVU.UpgradeRollout.md) 섹션을 참조하세요.
**Topics**
+ [RDS for SQL Server의 메이저 버전 업그레이드](USER_UpgradeDBInstance.SQLServer.Major.md)
+ [SQL Server 업그레이드 고려 사항](USER_UpgradeDBInstance.SQLServer.Considerations.md)
+ [RDS for SQL Server 업그레이드 테스트](USER_UpgradeDBInstance.SQLServer.UpgradeTesting.md)
+ [SQL Server DB 인스턴스 업그레이드](#USER_UpgradeDBInstance.SQLServer.Upgrading)
+ [지원 종료 전에 사용되지 않는 DB 인스턴스 업그레이드](#USER_UpgradeDBInstance.SQLServer.DeprecatedVersions)
# RDS for SQL Server의 메이저 버전 업그레이드
Amazon RDS는 현재 Microsoft SQL Server DB 인스턴스에 대해 다음 메이저 버전의 업그레이드를 지원합니다.
SQL Server 2008을 제외한 어떤 버전에서든 SQL Server 2017 또는 2019로 기존 DB 인스턴스를 업그레이드할 수 있습니다. SQL Server 2008에서 업그레이드하려면 다음 버전 중 하나로 업그레이드하십시오.
****
| 현재 버전 | 지원하는 업그레이드 버전 |
| --- | --- |
| SQL Server 2019 | SQL Server 2022 |
| SQL Server 2017 | SQL Server 2022 SQL Server 2019 |
| SQL Server 2016 | SQL Server 2022 SQL Server 2019 SQL Server 2017 |
다음 예와 같은 AWS CLI 쿼리를 사용하여 특정 데이터베이스 엔진 버전에 사용 가능한 업그레이드를 찾을 수 있습니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds describe-db-engine-versions \
--engine sqlserver-se \
--engine-version 14.00.3281.6.v1 \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" \
--output table
```
Windows의 경우:
```
aws rds describe-db-engine-versions ^
--engine sqlserver-se ^
--engine-version 14.00.3281.6.v1 ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" ^
--output table
```
출력은 버전 14.00.3281.6을 사용 가능한 최신 SQL Server 2017 또는 2019 버전으로 업그레이드할 수 있음을 보여줍니다.
```
--------------------------
|DescribeDBEngineVersions|
+------------------------+
| EngineVersion |
+------------------------+
| 14.00.3294.2.v1 |
| 14.00.3356.20.v1 |
| 14.00.3381.3.v1 |
| 14.00.3401.7.v1 |
| 14.00.3421.10.v1 |
| 14.00.3451.2.v1 |
| 15.00.4043.16.v1 |
| 15.00.4073.23.v1 |
| 15.00.4153.1.v1 |
| 15.00.4198.2.v1 |
| 15.00.4236.7.v1 |
+------------------------+
```
## 데이터베이스 호환성 수준
Microsoft SQL Server 데이터베이스 호환성 수준을 이용해 일부 데이터베이스 동작이 이전 버전의 SQL Server를 모방하도록 조정할 수 있습니다. 자세한 내용은 Microsoft 설명서의 [호환성 수준](https://msdn.microsoft.com/en-us/library/bb510680.aspx)을 참조하십시오. DB 인스턴스를 업그레이드할 때 기존의 모든 데이터베이스는 원래 호환성 수준으로 유지됩니다.
ALTER DATABASE 명령을 사용하여 데이터베이스의 호환성 수준을 변경할 수 있습니다. 예를 들어, `customeracct`라는 이름의 데이터베이스를 SQL Server 2016과 호환되도록 변경하려면 다음 명령을 실행합니다.
```
1. ALTER DATABASE customeracct SET COMPATIBILITY_LEVEL = 130
```
# SQL Server 업그레이드 고려 사항
Amazon RDS는 업그레이드 프로세스 중에 DB 스냅샷을 2개 캡처합니다. 첫 번째 DB 스냅샷은 업그레이드 변경 이전 DB 인스턴스의 스냅샷입니다. 두 번째 DB 스냅샷은 업그레이드 완료 이후에 캡처됩니다.
**참고**
DB 인스턴스에 대한 백업 보존 기간을 0보다 큰 수로 설정하면 Amazon RDS는 DB 스냅샷만 캡처합니다. 백업 보존 기간을 변경하려면 [Amazon RDS DB 인스턴스 수정](Overview.DBInstance.Modifying.md) 섹션을 참조하세요.
업그레이드가 완료되고 나면 이전 버전의 데이터베이스 엔진으로 되돌릴 수 없습니다. 이때 이전 버전으로 되돌리려면 업그레이드 전에 캡처한 DB 스냅샷으로 복구하여 새로운 DB 인스턴스를 생성해야 합니다.
SQL Server의 마이너 버전 또는 메이저 버전 업그레이드 중에는 **여유 스토리지 공간** 및 **디스크 대기열 깊이** 측정치가 `-1`로 표시됩니다. 이후 업그레이드가 완료되면 두 측정치 모두 정상적으로 돌아옵니다.
SQL Server 인스턴스를 업그레이드하기 전에 다음 정보를 검토합니다.
**Topics**
+ [업그레이드를 시작하기 전 모범 사례](#USER_UpgradeDBInstance.SQLServer.BestPractices)
+ [다중 AZ 고려 사항](#USER_UpgradeDBInstance.SQLServer.MAZ)
+ [읽기 전용 복제본 고려 사항](#USER_UpgradeDBInstance.SQLServer.readreplica)
+ [옵션 그룹 고려 사항](#USER_UpgradeDBInstance.SQLServer.OGPG.OG)
+ [파라미터 그룹 고려 사항](#USER_UpgradeDBInstance.SQLServer.OGPG.PG)
## 업그레이드를 시작하기 전 모범 사례
업그레이드 프로세스를 시작하기 전에 다음과 같은 준비 단계를 구현하여 최적의 업그레이드 성능을 허용하고 잠재적 문제를 최소화합니다.
타이밍 및 워크로드 관리
+ 트랜잭션 볼륨이 적은 기간 동안 업그레이드를 예약합니다.
+ 업그레이드 기간 동안 쓰기 작업을 최소화합니다.
이렇게 하면 Amazon RDS가 보조-기본 페어링 중에 RDS가 복원해야 하는 트랜잭션 로그 백업 파일의 수를 줄임으로써 업그레이드를 더 빠르게 완료할 수 있습니다.
트랜잭션 관리
+ 장기 실행 트랜잭션 식별 및 모니터링
+ 업그레이드를 시작하기 전에 모든 중요한 트랜잭션이 커밋되었는지 확인합니다.
+ 업그레이드 기간 동안 장기 실행 트랜잭션을 방지합니다.
로그 파일 최적화
다음과 같이 트랜잭션 로그 파일을 검토하고 최적화합니다.
+ 과대 로그 파일을 줄입니다.
+ 높은 로그 소비 패턴을 줄입니다.
+ 가상 로그 파일(VLF)을 관리합니다.
+ 정상적인 작업을 위해 충분한 여유 공간을 유지합니다.
## 다중 AZ 고려 사항
Amazon RDS는 SQL Server 데이터베이스 미러링(DBM) 또는 상시 가동 가용성 그룹(AG)을 사용하여 Microsoft SQL Server 기반 DB 인스턴스의 다중 AZ 배포를 지원합니다. 자세한 내용은 [Amazon RDS for Microsoft SQL Server의 다중 AZ 배포](USER_SQLServerMultiAZ.md) 섹션을 참조하세요.
다중 AZ 배포(미러링/AlwaysOn)에서 업그레이드가 요청되면 RDS는 기본 및 보조 인스턴스에 대한 롤링 업그레이드 전략을 따릅니다. 롤링 업그레이드를 사용하면 보조 인스턴스가 업그레이드되는 동안 트랜잭션에 최소 하나의 인스턴스를 사용할 수 있습니다. 중단은 장애 조치 기간 동안만 지속될 것으로 예상됩니다.
업그레이드 중에 RDS는 다중 AZ 구성에서 보조 인스턴스를 제거하고, 보조 인스턴스의 업그레이드를 수행하고, 연결이 해제된 시간 동안 가져온 기본 인스턴스에서 트랜잭션 로그 백업을 복원합니다. 모든 로그 백업이 복원되면 RDS는 업그레이드된 보조 인스턴스를 기본 인스턴스에 조인합니다. 모든 데이터베이스가 동기화된 상태이면 RDS는 업그레이드된 보조 인스턴스로의 장애 조치를 수행합니다. 장애 조치가 완료되면 RDS는 이전 기본 인스턴스 업그레이드를 진행하고 트랜잭션 로그 백업을 복원한 다음, 새 기본 인스턴스와 페어링합니다.
이 장애 조치 기간을 최소화하려면 연결 문자열에서 `MultiSubnetFailover` 연결 옵션을 지원하는 클라이언트 라이브러리를 사용할 때 AlwaysOn AGs 가용성 그룹 리스너 엔드포인트를 사용하는 것이 좋습니다. 가용성 그룹 리스너 엔드포인트를 사용할 때 장애 조치 시간은 일반적으로 10초 미만이지만, 이 기간에는 추가 충돌 복구 시간이 포함되지 않습니다.
## 읽기 전용 복제본 고려 사항
데이터베이스 버전 업그레이드 중에 Amazon RDS는 기본 DB 인스턴스와 함께 읽기 전용 복제본도 모두 업그레이드합니다. Amazon RDS는 읽기 전용 복제본에 대한 데이터베이스 버전 업그레이드를 별도로 지원하지 않습니다. 읽기 전용 복제본에 대한 자세한 내용은 [Amazon RDS에서 Microsoft SQL Server용 읽기 전용 복제본 작업](SQLServer.ReadReplicas.md) 섹션을 참조하세요.
기본 DB 인스턴스의 데이터베이스 버전 업그레이드를 수행하면 읽기 전용 복제본도 모두 자동으로 업그레이드됩니다. Amazon RDS는 기본 DB 인스턴스를 업그레이드하기 전에 읽기 전용 복제본을 모두 동시에 업그레이드합니다. 기본 DB 인스턴스의 데이터베이스 버전 업그레이드가 완료되기 전까지는 읽기 전용 복제본을 사용하지 못할 수 있습니다.
## 옵션 그룹 고려 사항
DB 인스턴스에서 사용자 지정 DB 옵션 그룹을 사용할 경우 Amazon RDS에서 DB 인스턴스에 새 옵션 그룹을 할당할 수 없는 경우도 있습니다. 예를 들어 새로운 메이저 버전으로 업그레이드할 경우 새로운 옵션 그룹을 지정해야 합니다. 새 옵션 그룹을 생성하고 동일한 옵션을 기존 사용자 지정 옵션 그룹에 추가하는 것이 좋습니다.
자세한 내용은 [옵션 그룹 생성](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Create) 또는 [옵션 그룹 생성](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Copy) 섹션을 참조하세요.
## 파라미터 그룹 고려 사항
DB 인스턴스에서 사용자 지정 DB 파라미터 그룹을 사용하는 경우:
+ 업그레이드 후 Amazon RDS가 DB 인스턴스를 자동으로 재부팅합니다.
+ 경우에 따라 RDS가 DB 인스턴스에 새 파라미터 그룹을 자동으로 할당하지 못할 수 있습니다.
예를 들어 새로운 메이저 버전으로 업그레이드할 경우 새로운 파라미터 그룹을 지정해야 합니다. 새 파라미터 그룹을 생성하고 기존 사용자 지정 파라미터 그룹에서와 같은 방법으로 파라미터를 구성하는 것이 좋습니다.
자세한 내용은 [Amazon RDS에서 DB 파라미터 그룹 생성](USER_WorkingWithParamGroups.Creating.md) 또는 [Amazon RDS에서 DB 파라미터 그룹 복사](USER_WorkingWithParamGroups.Copying.md) 섹션을 참조하세요.
# RDS for SQL Server 업그레이드 테스트
DB 인스턴스에 대한 메이저 버전 업그레이드를 수행하기 전에 데이터베이스 및 해당 데이터베이스에 액세스하는 모든 애플리케이션이 새 버전과 호환되는지 여부를 철저하게 테스트해야 합니다. 다음 절차를 참조하는 것이 좋습니다.
**메이저 버전 업그레이드를 테스트하려면**
1. 새 버전의 데이터베이스 엔진에 대한 Microsoft 설명서에서 [SQL Server 업그레이드](https://docs.microsoft.com/en-us/sql/database-engine/install-windows/upgrade-sql-server)를 검토하여 데이터베이스나 애플리케이션에 영향을 끼칠 수도 있는 호환성 문제가 있는지 살펴봅니다.
1. DB 인스턴스에서 사용자 지정 옵션 그룹을 사용할 경우 업그레이드하려는 새 버전과 호환되는 새 옵션 그룹을 생성합니다. 자세한 내용은 [옵션 그룹 고려 사항](USER_UpgradeDBInstance.SQLServer.Considerations.md#USER_UpgradeDBInstance.SQLServer.OGPG.OG) 섹션을 참조하세요.
1. DB 인스턴스에서 사용자 지정 파라미터 그룹을 사용할 경우 업그레이드하려는 새 버전과 호환되는 새 파라미터 그룹을 생성합니다. 자세한 내용은 [파라미터 그룹 고려 사항](USER_UpgradeDBInstance.SQLServer.Considerations.md#USER_UpgradeDBInstance.SQLServer.OGPG.PG) 섹션을 참조하세요.
1. 업그레이드할 DB 인스턴스의 DB 스냅샷을 생성합니다. 자세한 내용은 [Amazon RDS의 단일 AZ DB 인스턴스에 대한 DB 스냅샷 생성](USER_CreateSnapshot.md) 섹션을 참조하세요.
1. DB 스냅샷을 복구하여 새로운 테스트 DB 인스턴스를 생성합니다. 자세한 내용은 [DB 인스턴스 복원](USER_RestoreFromSnapshot.md) 섹션을 참조하세요.
1. 다음 방법 중 한 가지를 사용하여 이 새로운 테스트 DB 인스턴스를 변경하고 새로운 버전으로 업그레이드합니다.
+ [콘솔](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.Manual.Console)
+ [AWS CLI](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.Manual.CLI)
+ [RDS API](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.Manual.API)
1. 업그레이드한 인스턴스에서 사용할 스토리지를 평가하여 업그레이드 시 추가 스토리지의 필요 여부를 결정합니다.
1. 업그레이드한 DB 인스턴스와 관련하여 데이터베이스 및 애플리케이션과 새로운 버전의 호환성을 보장하는 데 필요하다면 최대한 많은 수의 품질 보증 테스트를 실행합니다. 또한 1단계에서 발견된 호환성 문제의 영향을 평가하는 데 필요한 새로운 테스트도 모두 실행합니다. 저장된 프로시저와 함수를 모두 테스트합니다. 업그레이드한 DB 인스턴스에 대해 애플리케이션의 테스트 버전을 실행합니다.
1. 모든 테스트가 통과되면 프로덕션 환경의 DB 인스턴스에도 업그레이드를 실행합니다. 단, 모든 기능이 정상 작동하는 것을 확인할 때까지 쓰기 연산은 DB 인스턴스에 실행하지 않는 것이 좋습니다.
## SQL Server DB 인스턴스 업그레이드
SQL Server DB 인스턴스의 수동 또는 자동 업그레이드에 대한 자세한 내용은 다음을 참조하십시오.
+ [DB 인스턴스 엔진 버전 업그레이드](USER_UpgradeDBInstance.Upgrading.md)
+ [Amazon RDS for SQL Server의 SQL Server 2008 R2를 SQL Server 2016으로 업그레이드하는 모범 사례](https://aws.amazon.com/blogs/database/best-practices-for-upgrading-sql-server-2008-r2-to-sql-server-2016-on-amazon-rds-for-sql-server/)
**중요**
AWS KMS를 사용하여 암호화한 스냅샷이 있는 경우, 지원이 끝나기 전에 업그레이드를 시작하는 것이 좋습니다.
## 지원 종료 전에 사용되지 않는 DB 인스턴스 업그레이드
메이저 버전이 사용되지 않으면 새 DB 인스턴스에 설치할 수 없습니다. RDS는 기존의 모든 DB 인스턴스를 자동으로 업그레이드하려고 시도합니다.
사용되지 않는 DB 인스턴스를 복원해야 하는 경우 특정 시점으로 복구(PITR)하거나 스냅샷을 복원할 수 있습니다. 이렇게 하면 사용되지 않는 버전을 사용하는 DB 인스턴스에 임시 액세스할 수 있습니다. 그러나 메이저 버전이 완전히 사용되지 않게 되면 이 DB 인스턴스도 지원되는 버전으로 자동 업그레이드됩니다.
# RDS for SQL Server에서 스토리지 작업
RDS for SQL Server를 사용하면 RDS for SQL Server 인스턴스에 최대 3개의 추가 볼륨을 연결할 수 있으며, 각 볼륨은 고유한 Windows 드라이브 문자에 매핑됩니다. 이렇게 하면 기본 `D:` 드라이브를 넘어 여러 볼륨에 데이터베이스 파일을 배포할 수 있습니다. 스토리지 볼륨을 추가하면 데이터베이스 파일 관리 및 스토리지 최적화를 위한 유연성이 향상됩니다.
이점은 다음과 같습니다.
+ **유연한 파일 배포** - 데이터베이스 데이터 파일과 로그 파일을 여러 볼륨에 분산하여 I/O 성능을 개선합니다.
+ **스토리지 최적화** - 워크로드 요구 사항에 따라 다양한 스토리지 유형 및 구성을 사용합니다.
+ **확장성** - 기존 볼륨을 수정하지 않고 스토리지 용량을 추가합니다.
**Topics**
+ [RDS for SQL Server에서 추가 스토리지 볼륨을 사용하기 위한 고려 사항](#SQLServer.ASV.Considerations)
+ [RDS for SQL Server를 사용하여 스토리지 볼륨 추가, 제거 또는 수정](#SQLServer.ASV.Management)
+ [RDS for SQL Server를 사용하여 추가 스토리지 볼륨에 대한 복원 작업](#SQLServer.ASV.Restore)
+ [RDS for SQL Server를 사용한 추가 스토리지 볼륨 사용 사례](#SQLServer.ASV.UseCases)
## RDS for SQL Server에서 추가 스토리지 볼륨을 사용하기 위한 고려 사항
RDS for SQL Server에서 추가 스토리지 볼륨을 사용할 때는 다음 기능과 제한 사항에 유의하세요.
+ SQL Server Standard Edition(SE), Enterprise Edition(EE) 및 Developer Edition(DEV-EE)에서만 스토리지 볼륨을 추가할 수 있습니다.
+ 인스턴스당 최대 3개의 스토리지 볼륨을 추가할 수 있습니다.
+ 볼륨 이름은 다음과 같이 Windows 드라이브 문자에 자동으로 매핑됩니다.
+ `rdsdbdata2` – `H:` 드라이브
+ `rdsdbdata3` – `I:` 드라이브
+ `rdsdbdata4` – `J:` 드라이브
+ TempDB 파일은 NVMe 인스턴스 스토리지를 사용할 때 `T:` 드라이브를 계속 사용합니다. SQL Server Audit 파일과 Microsoft Business Intelligence(MSBI) 파일은 `D:` 드라이브에 남아 있습니다.
+ 범용 SSD(gp3)와 프로비저닝된 IOPS SSD(io2) 스토리지 유형만 추가할 수 있습니다.
+ 추가 스토리지 볼륨의 최소 스토리지 크기는 기본 `D:` 드라이브에 설정된 제한과 동일합니다. DB 인스턴스의 최대 스토리지 크기는 모든 볼륨에서 총 256TiB입니다.
+ 읽기 전용 복제본이 있는 인스턴스 또는 읽기 전용 복제본 인스턴스에 스토리지 볼륨을 추가하는 것은 지원되지 않습니다.
+ 교차 리전 자동 백업이 활성화된 인스턴스에 스토리지 볼륨을 추가하는 것은 지원되지 않습니다.
+ 스토리지 자동 규모 조정을 위한 추가 스토리지 볼륨 구성은 지원되지 않습니다.
+ 생성 후 볼륨 간 파일 이동은 지원되지 않습니다.
+ `D:` 볼륨은 삭제할 수 없지만 비어 있는 다른 스토리지 볼륨은 삭제할 수 있습니다.
+ 스냅샷 복원 또는 특정 시점 복구(PITR) 중에 기존 볼륨의 크기를 수정하는 것은 지원되지 않습니다. 그러나 복원 작업 중에 새 스토리지 볼륨을 추가할 수 있습니다.
## RDS for SQL Server를 사용하여 스토리지 볼륨 추가, 제거 또는 수정
AWS CLI 또는 AWS Management Console을 사용하여 추가 스토리지 볼륨을 추가, 수정 및 제거할 수 있습니다. 모든 작업은 `additional-storage-volumes` 파라미터와 함께 `modify-db-instance` API 작업을 사용합니다.
**중요**
스토리지 볼륨을 추가하거나 제거하면 백업 보류 중 작업과 특정 시점 복원 블랙아웃 창이 생성됩니다. 백업 워크플로가 완료되면 이 창이 닫힙니다.
**Topics**
+ [스토리지 볼륨 추가](#SQLServer.ASV.Adding)
+ [추가 스토리지 볼륨 확장](#SQLServer.ASV.Scaling)
+ [추가 스토리지 볼륨 제거](#SQLServer.ASV.Removing)
### 스토리지 볼륨 추가
기본 `D:` 드라이브 외에 최대 3개의 스토리지 볼륨을 추가할 수 있습니다. RDS for SQL Server 인스턴스에 새 스토리지 볼륨을 추가하려면 `additional-storage-volumes` 파라미터와 함께 `modify-db-instance` 명령을 사용합니다.
다음 예제에서는 `rdsdbdata4`라는 새로운 4,000GiB 범용 SSD(gp3) 볼륨을 추가합니다.
```
aws rds modify-db-instance \
--db-instance-identifier my-sql-server-instance \
--region us-east-1 \
--additional-storage-volumes '[{"VolumeName":"rdsdbdata4","StorageType":"gp3","AllocatedStorage":4000}]' \
--apply-immediately
```
### 추가 스토리지 볼륨 확장
스토리지 크기를 제외한 추가 볼륨의 모든 스토리지 설정을 수정할 수 있습니다. 다음 예시에서는 `rdsdbdata2` 볼륨에 대한 IOPS 설정을 수정합니다.
```
aws rds modify-db-instance \
--db-instance-identifier my-sql-server-instance \
--region us-east-1 \
--additional-storage-volumes '[{"VolumeName":"rdsdbdata2","IOPS":4000}]' \
--apply-immediately
```
### 추가 스토리지 볼륨 제거
`D:` 볼륨은 삭제할 수 없지만 다른 스토리지 볼륨이 비어 있을 때는 삭제할 수 있습니다.
**주의**
추가 스토리지 볼륨을 제거하기 전에 볼륨에 저장된 데이터베이스 파일이 없는지 확인합니다.
다음 예제에서는 `rdsdbdata4` 볼륨을 제거합니다.
```
aws rds modify-db-instance \
--db-instance-identifier my-sql-server-instance \
--region us-east-1 \
--additional-storage-volumes '[{"VolumeName":"rdsdbdata4","SetForDelete":true}]' \
--apply-immediately
```
## RDS for SQL Server를 사용하여 추가 스토리지 볼륨에 대한 복원 작업
데이터베이스를 복원할 때 스토리지 볼륨을 추가할 수 있습니다. 기존 볼륨의 스토리지 설정을 수정할 수도 있습니다.
**Topics**
+ [스냅샷 복원](#SQLServer.ASV.SnapshotRestore)
+ [시점 복구](#SQLServer.ASV.PITR)
+ [기본 데이터베이스 복원](#SQLServer.ASV.NativeRestore)
### 스냅샷 복원
스냅샷에서 복원할 때 새 스토리지 볼륨을 추가하거나 기존 볼륨의 IOPS, 처리량 및 스토리지 유형 설정을 수정할 수 있습니다.
다음 예시에서는 스냅샷에서 DB 인스턴스를 복원하고 `rdsdbdata2` 볼륨에 대한 IOPS 설정을 수정합니다.
```
aws rds restore-db-instance-from-db-snapshot \
--db-instance-identifier my-restored-instance \
--db-snapshot-identifier my-snapshot \
--region us-east-1 \
--additional-storage-volumes '[{"VolumeName":"rdsdbdata2","IOPS":5000}]'
```
### 시점 복구
특정 시점 복구(PITR) 중에 사용자 지정 구성을 사용하여 새 스토리지 볼륨을 추가할 수 있습니다.
다음 예제에서는 PITR을 수행하고 새로운 5,000GiB 범용 SSD(gp3) 볼륨을 추가합니다.
```
aws rds restore-db-instance-to-point-in-time \
--source-db-instance-identifier my-source-instance \
--target-db-instance my-pitr-instance \
--use-latest-restorable-time \
--region us-east-1 \
--additional-storage-volumes '[{"VolumeName":"rdsdbdata4","StorageType":"gp3","AllocatedStorage":5000,"IOPS":5000,"StorageThroughput":200}]'
```
### 기본 데이터베이스 복원
`rds_restore_database` 저장 프로시저를 사용하여 데이터베이스를 특정 추가 스토리지 볼륨으로 복원할 수 있습니다. 두 가지 새로운 파라미터가 볼륨 선택을 지원합니다.
**`data_file_volume`**
데이터베이스 데이터 파일의 드라이브 문자를 지정합니다.
**`log_file_volume`**
데이터베이스 로그 파일의 드라이브 문자를 지정합니다.
다음 예시에서는 `H:` 드라이브의 데이터 파일과 `I:` 드라이브의 로그 파일을 사용하여 데이터베이스를 복원합니다.
```
EXEC msdb.dbo.rds_restore_database
@restore_db_name='my_database',
@s3_arn_to_restore_from='arn:aws:s3:::my-bucket/backup-file.bak',
@data_file_volume='H:',
@log_file_volume='I:';
```
볼륨 파라미터를 지정하지 않거나 두 파라미터 모두에 `D:` 드라이브를 지정하면 데이터베이스 파일이 기본 `D:` 드라이브로 복원됩니다.
```
EXEC msdb.dbo.rds_restore_database
@restore_db_name='my_database',
@s3_arn_to_restore_from='arn:aws:s3:::my-bucket/backup-file.bak';
```
## RDS for SQL Server를 사용한 추가 스토리지 볼륨 사용 사례
추가 스토리지 볼륨은 다양한 데이터베이스 관리 시나리오를 지원합니다. 다음 섹션에서는 일반적인 사용 사례 및 구현 접근 방식을 설명합니다.
**Topics**
+ [추가 스토리지 볼륨에 데이터베이스 생성](#SQLServer.ASV.NewDatabase)
+ [스토리지 용량 확장](#SQLServer.ASV.ExtendStorage)
+ [볼륨 간 데이터베이스 이동](#SQLServer.ASV.MoveDatabase)
+ [비용 효과적인 스토리지에 데이터 보관](#SQLServer.ASV.ArchiveData)
### 추가 스토리지 볼륨에 데이터베이스 생성
표준 SQL Server `CREATE DATABASE` 문을 사용하여 추가 스토리지 볼륨에 직접 새 데이터베이스를 생성할 수 있습니다.
다음 예시에서는 `H:` 드라이브의 데이터 파일과 `I:` 드라이브의 로그 파일을 사용하여 데이터베이스를 생성합니다.
```
CREATE DATABASE MyDatabase
ON (
NAME = 'MyDatabase_Data',
FILENAME = 'H:\rdsdbdata\data\MyDatabase_Data.mdf',
SIZE = 100MB,
FILEGROWTH = 10MB
)
LOG ON (
NAME = 'MyDatabase_Log',
FILENAME = 'I:\rdsdbdata\data\MyDatabase_Log.ldf',
SIZE = 10MB,
FILEGROWTH = 10%
);
```
### 스토리지 용량 확장
기본 `D:` 드라이브가 최대 용량에 도달하면 스토리지 볼륨을 추가하고, 기존 볼륨을 확장하고, 새 볼륨에 새 데이터 파일 또는 로그 파일을 생성할 수 있습니다.
**스토리지 용량 확장**
1. `modify-db-instance` 명령을 사용하여 인스턴스에 스토리지 볼륨을 추가합니다.
1. 추가 스토리지 볼륨에 새 데이터 파일을 추가합니다.
```
ALTER DATABASE MyDatabase
ADD FILE (
NAME = 'MyDatabase_Data2',
FILENAME = 'H:\rdsdbdata\data\MyDatabase_Data2.ndf',
SIZE = 500MB,
FILEGROWTH = 50MB
);
```
### 볼륨 간 데이터베이스 이동
데이터베이스를 다른 볼륨으로 이동하려면 `rds_backup_database` 및 `rds_restore_database` 저장 프로시저와 함께 백업 및 복원 접근 방식을 사용합니다. 자세한 내용은 [기본 백업 및 복원 사용](SQLServer.Procedural.Importing.Native.Using.md) 섹션을 참조하세요.
**데이터베이스를 다른 볼륨으로 이동**
1. `rds_backup_database`를 사용하여 데이터베이스를 백업합니다.
```
EXEC msdb.dbo.rds_backup_database
@source_db_name='MyDatabase',
@s3_arn_to_backup_to='arn:aws:s3:::my-bucket/database-backup.bak';
```
1. 데이터베이스를 대상 볼륨으로 복원합니다.
```
EXEC msdb.dbo.rds_restore_database
@restore_db_name='MyDatabase_New',
@s3_arn_to_restore_from='arn:aws:s3:::my-bucket/database-backup.bak',
@data_file_volume='H:',
@log_file_volume='I:';
```
1. 이전 드라이브에서 데이터베이스를 삭제하여 공간을 해제합니다. 자세한 내용은 [Amazon RDS for Microsoft SQL Server DB 인스턴스 데이터베이스 삭제](Appendix.SQLServer.CommonDBATasks.DropMirrorDB.md) 섹션을 참조하세요.
### 비용 효과적인 스토리지에 데이터 보관
분할된 테이블의 경우 이전 데이터를 성능 특성이 다른 추가 스토리지 볼륨에 보관할 수 있습니다.
**분할된 데이터 아카이브**
1. 적절한 스토리지 유형 및 용량을 가진 스토리지 볼륨을 추가합니다.
1. 추가 스토리지 볼륨에 새 파일 그룹을 생성합니다.
```
ALTER DATABASE MyDatabase
ADD FILEGROUP ArchiveFileGroup;
ALTER DATABASE MyDatabase
ADD FILE (
NAME = 'Archive_Data',
FILENAME = 'H:\rdsdbdata\data\Archive_Data.ndf',
SIZE = 1GB,
FILEGROWTH = 100MB
) TO FILEGROUP ArchiveFileGroup;
```
1. SQL Server 파티션 관리 명령을 사용하여 파티션을 새 파일 그룹으로 이동합니다.
# 기본 백업 및 복원 기능을 사용하여 SQL Server 데이터베이스 가져오기 및 내보내기
Amazon RDS는 전체 백업 파일(.bak 파일)을 사용하여 Microsoft SQL Server 데이터베이스에 기본 백업 및 복원을 할 수 있도록 지원합니다. RDS를 사용할 때 데이터베이스 서버의 로컬 파일 시스템을 사용하는 대신 Amazon S3에 저장된 파일에 액세스합니다.
예를 들어 로컬 서버에서 전체 백업을 생성하고, 이를 S3에 저장한 후, 기존 Amazon RDS DB 인스턴스에서 복원할 수 있습니다. 또한 RDS에서 백업을 만들고, 이를 S3에 저장한 후, 어디든 원하는 곳에서 복원할 수 있습니다.
읽기 전용 복제본이 있는 다중 AZ DB 인스턴스를 포함하여 모든 AWS 리전에서 단일 AZ 및 다중 AZ DB 인스턴스에 대해 기본 백업 및 복원을 사용할 수 있습니다. Amazon RDS에서 지원되는 Microsoft SQL Server의 모든 버전에 기본 백업 및 복원이 제공됩니다.
다음 다이어그램은 지원되는 시나리오를 보여 줍니다.
![\[기본 백업 및 복원 아키텍처\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/SQL-bak-file.png)
기본 .bak 파일을 사용하여 데이터베이스를 백업 및 복원하는 과정은 대개의 경우 데이터베이스를 가장 빨리 백업하고 복원할 수 있는 방법입니다. 또한 기본 백업 및 복원을 이용하는 것보다 장점이 더 많습니다. 예를 들면,
+ Amazon RDS로/에서 데이터베이스 마이그레이션
+ RDS for SQL Server DB 인스턴스 간에 데이터베이스를 이동합니다.
+ .bak 파일 내부의 데이터, 스키마, 저장 프로시저, 트리거 및 기타 데이터베이스 코드를 마이그레이션합니다.
+ DB 인스턴스 전체가 아닌 데이터베이스 하나를 백업 및 복원합니다.
+ 개발, 테스트, 교육, 데모를 위해 데이터베이스 사본을 만듭니다.
+ 재해 복구를 위한 추가 보호 계층을 위해 Amazon S3를 통해 백업 파일을 저장 및 전송합니다.
+ 투명한 데이터 암호화(TDE)가 설정된 데이터베이스의 기본 백업을 생성하고, 이러한 백업을 온프레미스 데이터베이스에 복원합니다. 자세한 내용은 [SQL Server에서 TDE(투명한 데이터 암호화) 지원](Appendix.SQLServer.Options.TDE.md) 섹션을 참조하세요.
+ TDE가 설정된 온프레미스 데이터베이스의 기본 백업을 RDS for SQL Server DB 인스턴스로 복원합니다. 자세한 내용은 [SQL Server에서 TDE(투명한 데이터 암호화) 지원](Appendix.SQLServer.Options.TDE.md) 섹션을 참조하세요.
**Contents**
+ [제한 및 권장 사항](#SQLServer.Procedural.Importing.Native.Limitations)
+ [기본 백업 및 복원 설정](SQLServer.Procedural.Importing.Native.Enabling.md)
+ [기본 백업 및 복원을 위한 IAM 역할 수동으로 만들기](SQLServer.Procedural.Importing.Native.Enabling.md#SQLServer.Procedural.Importing.Native.Enabling.IAM)
+ [기본 백업 및 복원 사용](SQLServer.Procedural.Importing.Native.Using.md)
+ [데이터베이스 백업](SQLServer.Procedural.Importing.Native.Using.md#SQLServer.Procedural.Importing.Native.Using.Backup)
+ [사용법](SQLServer.Procedural.Importing.Native.Using.md#SQLServer.Procedural.Importing.Native.Backup.Syntax)
+ [예제](SQLServer.Procedural.Importing.Native.Using.md#SQLServer.Procedural.Importing.Native.Backup.Examples)
+ [데이터베이스 복원](SQLServer.Procedural.Importing.Native.Using.md#SQLServer.Procedural.Importing.Native.Using.Restore)
+ [사용법](SQLServer.Procedural.Importing.Native.Using.md#SQLServer.Procedural.Importing.Native.Restore.Syntax)
+ [예제](SQLServer.Procedural.Importing.Native.Using.md#SQLServer.Procedural.Importing.Native.Restore.Examples)
+ [로그 복원](SQLServer.Procedural.Importing.Native.Using.md#SQLServer.Procedural.Importing.Native.Restore.Log)
+ [사용법](SQLServer.Procedural.Importing.Native.Using.md#SQLServer.Procedural.Importing.Native.Restore.Log.Syntax)
+ [예제](SQLServer.Procedural.Importing.Native.Using.md#SQLServer.Procedural.Importing.Native.Restore.Log.Examples)
+ [데이터베이스 복원 마무리](SQLServer.Procedural.Importing.Native.Using.md#SQLServer.Procedural.Importing.Native.Finish.Restore)
+ [사용법](SQLServer.Procedural.Importing.Native.Using.md#SQLServer.Procedural.Importing.Native.Finish.Restore.Syntax)
+ [부분적으로 복원된 데이터베이스 작업](SQLServer.Procedural.Importing.Native.Using.md#SQLServer.Procedural.Importing.Native.Partially.Restored)
+ [부분적으로 복원된 데이터베이스 삭제](SQLServer.Procedural.Importing.Native.Using.md#SQLServer.Procedural.Importing.Native.Drop.Partially.Restored)
+ [부분적으로 복원된 데이터베이스에 대한 스냅샷 복원 및 특정 시점으로 복구 동작](SQLServer.Procedural.Importing.Native.Using.md#SQLServer.Procedural.Importing.Native.Snapshot.Restore)
+ [작업 취소](SQLServer.Procedural.Importing.Native.Using.md#SQLServer.Procedural.Importing.Native.Using.Cancel)
+ [사용법](SQLServer.Procedural.Importing.Native.Using.md#SQLServer.Procedural.Importing.Native.Cancel.Syntax)
+ [작업 상태 추적](SQLServer.Procedural.Importing.Native.Using.md#SQLServer.Procedural.Importing.Native.Tracking)
+ [사용법](SQLServer.Procedural.Importing.Native.Using.md#SQLServer.Procedural.Importing.Native.Tracking.Syntax)
+ [예제](SQLServer.Procedural.Importing.Native.Using.md#SQLServer.Procedural.Importing.Native.Tracking.Examples)
+ [응답](SQLServer.Procedural.Importing.Native.Using.md#SQLServer.Procedural.Importing.Native.Tracking.Response)
+ [백업 파일 압축](SQLServer.Procedural.Importing.Native.Compression.md)
+ [문제 해결](SQLServer.Procedural.Importing.Native.Troubleshooting.md)
+ [다른 방법으로 SQL Server 데이터 가져오기 및 내보내기](SQLServer.Procedural.Importing.Snapshots.md)
+ [스냅샷을 사용하여 RDS for SQL Server로 데이터 가져오기](SQLServer.Procedural.Importing.Snapshots.md#SQLServer.Procedural.Importing.Procedure)
+ [데이터 가져오기](SQLServer.Procedural.Importing.Snapshots.md#ImportData.SQLServer.Import)
+ [스크립트 생성 및 게시 마법사](SQLServer.Procedural.Importing.Snapshots.md#ImportData.SQLServer.MgmtStudio.ScriptWizard)
+ [가져오기 및 내보내기 마법사](SQLServer.Procedural.Importing.Snapshots.md#ImportData.SQLServer.MgmtStudio.ImportExportWizard)
+ [대량 복사](SQLServer.Procedural.Importing.Snapshots.md#ImportData.SQLServer.MgmtStudio.BulkCopy)
+ [RDS for SQL Server에서 데이터 내보내기](SQLServer.Procedural.Importing.Snapshots.md#SQLServer.Procedural.Exporting)
+ [SQL Server 가져오기 및 내보내기 마법사](SQLServer.Procedural.Importing.Snapshots.md#SQLServer.Procedural.Exporting.SSIEW)
+ [SQL Server 스크립트 생성 및 게시 마법사와 bcp 유틸리티](SQLServer.Procedural.Importing.Snapshots.md#SQLServer.Procedural.Exporting.SSGPSW)
+ [Linux의 BCP 유틸리티를 사용하여 데이터 가져오기 및 내보내기](SQLServer.Procedural.Importing.BCP.Linux.md)
+ [사전 조건](SQLServer.Procedural.Importing.BCP.Linux.md#SQLServer.Procedural.Importing.BCP.Linux.Prerequisites)
+ [Linux에 SQL Server 명령줄 도구 설치](SQLServer.Procedural.Importing.BCP.Linux.md#SQLServer.Procedural.Importing.BCP.Linux.Installing)
+ [RDS for SQL Server에서 데이터 내보내기](SQLServer.Procedural.Importing.BCP.Linux.md#SQLServer.Procedural.Importing.BCP.Linux.Exporting)
+ [기본 내보내기 구문](SQLServer.Procedural.Importing.BCP.Linux.md#SQLServer.Procedural.Importing.BCP.Linux.Exporting.Basic)
+ [내보내기 예시](SQLServer.Procedural.Importing.BCP.Linux.md#SQLServer.Procedural.Importing.BCP.Linux.Exporting.Example)
+ [RDS for SQL Server로 데이터 가져오기](SQLServer.Procedural.Importing.BCP.Linux.md#SQLServer.Procedural.Importing.BCP.Linux.Importing)
+ [기본 가져오기 구문](SQLServer.Procedural.Importing.BCP.Linux.md#SQLServer.Procedural.Importing.BCP.Linux.Importing.Basic)
+ [가져오기 예시](SQLServer.Procedural.Importing.BCP.Linux.md#SQLServer.Procedural.Importing.BCP.Linux.Importing.Example)
+ [일반적인 BCP 옵션](SQLServer.Procedural.Importing.BCP.Linux.md#SQLServer.Procedural.Importing.BCP.Linux.Options)
+ [모범 사례 및 고려 사항](SQLServer.Procedural.Importing.BCP.Linux.md#SQLServer.Procedural.Importing.BCP.Linux.BestPractices)
+ [일반적인 문제 해결](SQLServer.Procedural.Importing.BCP.Linux.md#SQLServer.Procedural.Importing.BCP.Linux.Troubleshooting)
## 제한 및 권장 사항
다음은 기본 백업 및 복원을 사용할 때 적용되는 몇 가지 제한 사항입니다.
+ Amazon RDS DB 인스턴스와 다른 AWS 리전에서는 Amazon S3 버킷으로 백업하거나 복원할 수 없습니다.
+ 기존 데이터베이스와 이름이 같은 데이터베이스는 복원할 수 없습니다. 데이터베이스 이름은 고유합니다.
+ 한 표준 시간대의 백업 파일을 다른 표준 시간대로 복원하지 않는 것이 좋습니다. 한 표준 시간대의 백업 파일을 다른 표준 시간대로 복원하는 경우 쿼리와 애플리케이션을 감사하여 표준 시간대 변경의 영향을 확인해야 합니다.
+ RDS for Microsoft SQL Server의 파일당 크기 제한은 5TB입니다. 큰 데이터베이스의 기본 백업의 경우 다중 파일 백업을 사용할 수 있습니다.
+ S3에 백업할 수 있는 최대 데이터베이스 크기는 DB 인스턴스에서 사용 가능한 메모리, CPU, I/O 및 네트워크 리소스에 따라 다릅니다. 데이터베이스가 클수록 백업 에이전트에서 더 많은 메모리를 사용합니다.
+ 10개 이상의 백업 파일에서 동시에 백업 또는 복원할 수 없습니다.
+ 차등 백업은 마지막 전체 백업을 기반을 합니다. 차등 백업이 작동할 수 있도록 마지막 전체 백업과 차등 백업 간에는 스냅샷을 만들 수 없습니다. 차등 백업을 만들려고 하는데 수동 또는 자동 스냅샷이 이미 있으면 차등 백업을 진행하기 전에 다른 전체 백업을 만드십시오.
+ file\$1guid(고유 식별자)가 `NULL`로 설정된 파일이 있는 데이터베이스에서는 차등 복원 및 로그 복원이 지원되지 않습니다.
+ 백업 또는 복원 작업은 최대 2개까지 동시에 실행할 수 있습니다.
+ Amazon RDS의 SQL Server에서 기본 로그 백업을 수행할 수 없습니다.
+ RDS는 데이터베이스의 기본 복원을 최대 64TiB까지 지원합니다. SQL Server Express Edition의 데이터베이스 기본 복원은 10GB로 제한됩니다.
+ 유지 관리 기간 또는 Amazon RDS에서 데이터베이스 스냅샷을 만드는 동안에는 기본 백업을 수행할 수 없습니다. 기본 백업 작업이 RDS 일일 백업 기간과 겹치는 경우 기본 백업 작업이 취소됩니다.
+ 다중 AZ DB 인스턴스에서는 전체 복구 모델로 백업된 데이터베이스만 기본적으로 복원할 수 있습니다.
+ 트랜잭션 내에서 기본 백업 및 복원을 위한 RDS 프로시저 호출은 지원되지 않습니다.
+ 대칭 암호화 AWS KMS key을(를) 사용하여 백업을 암호화합니다. Amazon RDS에서는 비대칭 KMS 키가 지원되지 않습니다. 자세한 내용은 *AWS Key Management Service 개발자 안내서*의 [대칭 암호화 KMS 키 생성](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-symmetric-cmk)을 참조하세요.
+ 기본 백업 파일은 "암호화 전용" 암호 모드를 사용하여 지정된 KMS 키로 암호화됩니다. 암호화된 백업 파일을 복원할 때 파일이 "암호화 전용" 암호 모드로 암호화되었음을 알고 있어야 합니다.
+ FILESTREAM 파일 그룹이 포함된 데이터베이스는 복원할 수 없습니다.
+ AWS KMS(SSE-KMS)를 사용한 Amazon S3 서버 측 암호화는 백업 저장 프로시저로 `@enable_bucket_default_encryption=1`을 전달할 때 S3 버킷의 기본 암호화 구성을 통해 지원됩니다. 기본적으로 복원은 S3 객체의 서버 측 암호화를 지원합니다.
저장 프로시저에 KMS 키를 제공하면 모든 기본 백업 및 복원은 KMS 키를 사용하여 클라이언트 측에서 암호화 및 암호 해독됩니다. AWS는 `@enable_bucket_default_encryption=0`인 경우 SSE-S3를 사용하여 S3 버킷에 백업을 저장하거나 `@enable_bucket_default_encryption=1`인 경우 S3 버킷의 구성된 기본 암호화 키를 사용하여 백업을 저장합니다.
+ S3 액세스 포인트를 사용하는 경우 RDS 내부 VPC를 사용하도록 액세스 포인트를 구성할 수 없습니다.
+ 최상의 성능을 위해 디렉터리 버킷 또는 디렉터리 버킷에 대한 액세스 포인트를 해당 리전에서 사용할 수 있는 경우 사용하는 것이 좋습니다.
백업 파일을 만들고, 복사하고, 복원하는 동안 데이터베이스를 오프라인 상태로 둘 수 있다면 RDS로 마이그레이션할 때 기본 백업 및 복원을 사용하는 것이 좋습니다. 온프레미스 데이터베이스를 오프라인으로 전환할 수 없다면 AWS Database Migration Service를 사용하여 데이터베이스를 Amazon RDS로 마이그레이션하는 것이 좋습니다. 자세한 내용은 [AWS Database Migration Service란 무엇입니까?](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html)를 참조하십시오.
기본 백업 및 복원은 리전 간 스냅샷 복사 기능의 데이터 복구 대신 사용하기 위한 기능이 아닙니다. Amazon RDS에서 교차 리전 재해 복구를 위해 데이터베이스 스냅샷을 다른 AWS 리전으로 복사할 때는 스냅샷 복사를 이용하는 것이 좋습니다. 자세한 내용은 [Amazon RDS용 DB 스냅샷 복사](USER_CopySnapshot.md) 섹션을 참조하세요.
# 기본 백업 및 복원 설정
기본 백업 및 복원을 설정하려면 다음 세 가지 구성 요소가 필요합니다.
1. 백업 파일을 저장할 Amazon S3 버킷.
백업 파일에 사용한 후 RDS로 마이그레이션하려는 백업을 업로드할 S3 버킷이 있어야 합니다. 이미 Amazon S3 버킷이 있으면 그 버킷을 사용하면 됩니다. 없는 경우 [버킷을 생성](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingaBucket.html)할 수 있습니다. 또는 `SQLSERVER_BACKUP_RESTORE`을 사용하여 AWS Management Console 옵션을 추가할 때 새 버킷이 생성되도록 선택할 수도 있습니다.
S3 사용에 대한 자세한 내용은 [Amazon Simple Storage Service 사용 설명서](https://docs.aws.amazon.com/AmazonS3/latest/userguide/)를 참조하세요.
1. 버킷에 액세스하기 위한 AWS Identity and Access Management(IAM) 역할.
이미 IAM 역할이 있으면 그 역할을 사용하면 됩니다. AWS Management Console을 사용하여 `SQLSERVER_BACKUP_RESTORE` 옵션을 추가할 때 새 IAM 역할이 생성되도록 선택할 수도 있습니다. 또는 수동으로 역할을 새로 만들 수 있습니다.
수동으로 새 IAM 역할을 만들려면 다음 단원에서 설명하는 방법을 사용하십시오. 기존 IAM 역할에 신뢰 관계와 권한 정책을 연결하려는 경우에도 동일한 작업을 수행합니다.
1. DB 인스턴스의 옵션 그룹에 `SQLSERVER_BACKUP_RESTORE` 옵션 추가.
DB 인스턴스에서 기본 백업 및 복원을 활성화하려면 DB 인스턴스의 옵션 그룹에 `SQLSERVER_BACKUP_RESTORE` 옵션을 추가합니다. 자세한 정보와 지침은 [SQL Server에서 기본 백업 및 복원 지원](Appendix.SQLServer.Options.BackupRestore.md) 섹션을 참조하십시오.
## 기본 백업 및 복원을 위한 IAM 역할 수동으로 만들기
기본 백업 및 복원에 사용할 새 IAM 역할을 수동으로 생성할 수 있습니다. 이 경우 Amazon RDS 서비스에서 Amazon S3 버킷으로 권한을 위임하는 역할을 생성합니다. IAM 역할을 만들 때 신뢰 관계와 권한 정책을 연결합니다. 신뢰 관계를 통해 RDS가 이 역할을 맡도록 허용합니다. 권한 정책은 이 역할이 수행할 수 있는 작업을 정의합니다. 역할을 만드는 방법에 대한 자세한 내용은 [AWS 서비스에 대한 권한을 위임할 역할 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)을 참조하세요.
기본 백업 및 복원 기능의 경우, 이 단원의 예제와 비슷한 신뢰 관계 및 권한 정책을 사용합니다. 다음 예제에서는 서비스 보안 주체 이름 `rds.amazonaws.com`을 모든 서비스 계정의 별칭으로 사용합니다. 다른 예에서는 신뢰 정책에서 액세스 권한을 부여할 다른 계정, 사용자, 역할을 식별하기 위해 Amazon 리소스 이름(ARN)을 지정합니다.
서비스 권한을 특정 리소스로 제한하는 리소스 기반 신뢰 관계의 [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) 및 [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) 전역 조건 컨텍스트 키를 사용하는 것이 좋습니다. 이는 [혼동된 대리자 문제](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)를 방지하는 가장 효과적인 방법입니다.
전역 조건 컨텍스트 키를 모두 사용하고 `aws:SourceArn` 값에 계정 ID가 포함되도록 할 수 있습니다. 이 경우 `aws:SourceAccount` 값과 `aws:SourceArn` 값의 계정이 동일한 문에서 사용될 때 동일한 계정 ID를 사용해야 합니다.
+ 단일 리소스에 대한 교차 서비스 액세스를 원하는 경우 `aws:SourceArn`을 사용하세요.
+ 해당 계정의 모든 리소스가 교차 서비스 사용과 연결되도록 허용하려는 경우 `aws:SourceAccount`를 사용하세요.
신뢰 관계에서는 역할에 액세스하는 리소스의 전체 ARN이 포함된 `aws:SourceArn` 전역 조건 컨텍스트 키를 사용해야 합니다. 기본 백업 및 복원의 경우 다음 예와 같이 DB 옵션 그룹과 DB 인스턴스를 모두 포함해야 합니다.
**Example 기본 백업 및 복원을 위한 전역 조건 컨텍스트 키와의 신뢰 관계**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceArn": [
"arn:aws:rds:Region:0123456789:db:db_instance_identifier",
"arn:aws:rds:Region:0123456789:og:option_group_name"
],
"aws:SourceAccount": "0123456789"
}
}
}
]
}
```
다음 예에서는 ARN을 사용하여 리소스를 지정합니다. ARN 사용에 대한 자세한 내용은 [Amazon 리소스 이름(ARN)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html)을 참조하십시오.
**Example 암호화 지원 없는 기본 백업 및 복원을 위한 권한 정책**
****
```
{
"Version":"2012-10-17",
"Statement":
[
{
"Effect": "Allow",
"Action":
[
"s3:ListBucket",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket"
},
{
"Effect": "Allow",
"Action":
[
"s3:GetObjectAttributes",
"s3:GetObject",
"s3:PutObject",
"s3:ListMultipartUploadParts",
"s3:AbortMultipartUpload"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*"
}
]
}
```
**Example 암호화 지원 있는 기본 백업 및 복원을 위한 권한 정책**
백업 파일을 암호화하려면 권한 정책에 암호화 키를 포함시켜야 합니다. 암호화 키에 대한 자세한 내용은 *AWS Key Management Service 개발자 안내서*에서 [시작하기](https://docs.aws.amazon.com/kms/latest/developerguide/getting-started.html)를 참조하세요.
대칭 암호화 KMS 키를 사용하여 백업을 암호화해야 합니다. Amazon RDS에서는 비대칭 KMS 키가 지원되지 않습니다. 자세한 내용은 *AWS Key Management Service 개발자 안내서*의 [대칭 암호화 KMS 키 생성](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-symmetric-cmk)을 참조하세요.
IAM 역할은 KMS 키의 키 사용자 및 키 관리자여야 합니다. 즉, 키 정책에서 지정해야 합니다. 자세한 내용은 *AWS Key Management Service 개발자 안내서*의 [대칭 암호화 KMS 키 생성](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-symmetric-cmk)을 참조하세요.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowAccessToKey",
"Effect": "Allow",
"Action": [
"kms:DescribeKey",
"kms:GenerateDataKey",
"kms:Encrypt",
"kms:Decrypt"
],
"Resource": "arn:aws:kms:us-east-1:123456789012:key/key-id"
},
{
"Sid": "AllowAccessToS3",
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket"
},
{
"Sid": "GetS3Info",
"Effect": "Allow",
"Action": [
"s3:GetObjectAttributes",
"s3:GetObject",
"s3:PutObject",
"s3:ListMultipartUploadParts",
"s3:AbortMultipartUpload"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*"
}
]
}
```
**Example 액세스 포인트를 사용하며 암호화 지원 없는 기본 백업 및 복원을 위한 권한 정책**
S3 액세스 포인트를 사용하는 데 필요한 작업은 S3 버킷과 동일합니다. 리소스 경로가 S3 액세스 포인트 ARN 패턴과 일치하도록 업데이트됩니다.
RDS는 프라이빗 VPC를 게시하지 않으므로 **네트워크 오리진: 인터넷**을 사용하도록 액세스 포인트를 구성해야 합니다. RDS 인스턴스의 S3 트래픽은 프라이빗 VPC를 통과하므로 퍼블릭 인터넷을 통과하지 않습니다.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetBucketLocation"
],
"Resource": [
"arn:aws:s3:us-east-1:111122223333:accesspoint/amzn-s3-demo-ap",
"arn:aws:s3:::underlying-bucket"
]
},
{
"Effect": "Allow",
"Action": [
"s3:GetObjectAttributes",
"s3:GetObject",
"s3:PutObject",
"s3:ListMultipartUploadParts",
"s3:AbortMultipartUpload"
],
"Resource": [
"arn:aws:s3:us-east-1:111122223333:accesspoint/amzn-s3-demo-ap/*",
"arn:aws:s3:::underlying-bucket/*"
]
}
]
}
```
**Example 암호화 지원이 없는 디렉터리 버킷에 대한 액세스 포인트를 사용한 네이티브 백업 및 복원을 위한 권한 정책**
디렉터리 버킷은 범용 버킷과 다른 [세션 기반 권한 부여 메커니즘](https://docs.aws.amazon.com//AmazonS3/latest/userguide/s3-express-authenticating-authorizing.html)을 사용하므로 기본 백업 복원에 필요한 유일한 권한은 버킷 수준 “s3express:CreateSession” 권한입니다. 객체 수준 액세스를 구성하려면 [디렉터리 버킷에 액세스 포인트](https://docs.aws.amazon.com//AmazonS3/latest/userguide/access-points-directory-buckets-policies.html)를 사용해야 합니다.
RDS는 프라이빗 VPC를 게시하지 않으므로 **네트워크 오리진: 인터넷**을 사용하도록 액세스 포인트를 구성해야 합니다. RDS 인스턴스의 S3 트래픽은 프라이빗 VPC를 통과하므로 퍼블릭 인터넷을 통과하지 않습니다.
****
```
{
"Version":"2012-10-17",
"Statement":
[
{
"Effect": "Allow",
"Action": "s3express:CreateSession",
"Resource":
[
"arn:aws:s3express:us-east-1:111122223333:accesspoint/amzn-s3-demo-accesspoint--use1-az6--xa-s3",
"arn:aws:s3express:us-east-1:111122223333:bucket/amzn-s3-demo-bucket--use1-az6--x-s3"
]
}
]
}
```
# 기본 백업 및 복원 사용
기본 백업 및 복원을 활성화하고 구성한 다음에는 사용하기 시작할 수 있습니다. 먼저 Microsoft SQL Server 데이터베이스에 연결한 다음 해당 작업을 위한 Amazon RDS 저장 프로시저를 호출합니다. 데이터베이스 연결 방법에 대한 자세한 내용은 [Microsoft SQL Server DB 인스턴스에 연결](USER_ConnectToMicrosoftSQLServerInstance.md) 섹션을 참조하십시오.
저장 프로시저 중에는 Amazon S3 버킷과 파일에 ARN(Amazon 리소스 이름)을 제공해야 하는 것도 있습니다. ARN의 형식은 `arn:aws:s3:::bucket_name/file_name.extension`입니다. Amazon S3에서는 ARN에 계정 번호나 AWS 리전을 요구하지 않습니다.
KMS 키(선택 사항)도 제공하는 경우 키의 ARN 형식은 `arn:aws:kms:region:account-id:key/key-id`입니다. 자세한 내용은 [Amazon 리소스 이름(ARN) 및 AWS 서비스 네임스페이스](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html)를 참조하세요. 대칭 암호화 KMS 키를 사용하여 백업을 암호화해야 합니다. Amazon RDS에서는 비대칭 KMS 키가 지원되지 않습니다. 자세한 내용은 *AWS Key Management Service 개발자 안내서*의 [대칭 암호화 KMS 키 생성](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-symmetric-cmk)을 참조하세요.
**참고**
KMS 키를 사용하는지 여부에 관계없이 기본 백업 및 복원 작업을 통해 S3에 업로드된 파일에 대해 기본값으로 SSE-S3를 통한 서버 측 고급 암호화 표준(AES) 256비트 암호화를 사용할 수 있습니다. `@enable_bucket_default_encryption=1`을 백업 저장 프로시저로 전달하면 S3 버킷의 구성된 기본 암호화 키가 사용됩니다.
각각의 저장 프로시저를 호출하는 방법에 대한 지침은 다음 주제를 참조하십시오.
+ [데이터베이스 백업](#SQLServer.Procedural.Importing.Native.Using.Backup)
+ [데이터베이스 복원](#SQLServer.Procedural.Importing.Native.Using.Restore)
+ [로그 복원](#SQLServer.Procedural.Importing.Native.Restore.Log)
+ [데이터베이스 복원 마무리](#SQLServer.Procedural.Importing.Native.Finish.Restore)
+ [부분적으로 복원된 데이터베이스 작업](#SQLServer.Procedural.Importing.Native.Partially.Restored)
+ [작업 취소](#SQLServer.Procedural.Importing.Native.Using.Cancel)
+ [작업 상태 추적](#SQLServer.Procedural.Importing.Native.Tracking)
## 데이터베이스 백업
데이터베이스를 백업하려면 `rds_backup_database` 저장 프로시저를 사용하십시오.
**참고**
유지 관리 기간 중 또는 Amazon RDS에서 스냅샷을 만드는 동안에는 데이터베이스를 백업할 수 없습니다.
### 사용법
```
exec msdb.dbo.rds_backup_database
@source_db_name='database_name',
@s3_arn_to_backup_to='arn:aws:s3:::bucket_name/file_name.extension',
[@kms_master_key_arn='arn:aws:kms:region:account-id:key/key-id'],
[@overwrite_s3_backup_file=0|1],
[@block_size=512|1024|2048|4096|8192|16384|32768|65536],
[@max_transfer_size=n],
[@buffer_count=n],
[@type='DIFFERENTIAL|FULL'],
[@number_of_files=n],
[@enable_bucket_default_encryption=0|1];
```
다음 파라미터는 필수 파라미터입니다.
+ `@source_db_name` – 백업할 데이터베이스의 이름입니다.
+ `@s3_arn_to_backup_to` – 백업에 사용할 Amazon S3 버킷, 액세스 포인트, 디렉터리 버킷 또는 디렉터리 버킷의 액세스 포인트와 백업 파일의 이름을 나타내는 ARN입니다.
파일에는 어떤 확장명이든 있을 수 있지만 `.bak`이 주로 사용됩니다. 액세스 포인트 ARN은 `arn:aws:s3:us-east-1:111122223333:access-point-name/object/key` 형식이어야 합니다.
다음 파라미터는 선택적입니다.
+ `@kms_master_key_arn` – 항목을 암호화하는 데 사용할 대칭 암호화 KMS 키의 ARN입니다.
+ 기본 암호화 키는 사용할 수 없습니다. 기본 키를 사용하면 데이터베이스가 백업되지 않습니다.
+ KMS 키 식별자를 지정하지 않으면 백업 파일이 암호화되지 않습니다. 자세한 내용은 [Amazon RDS 리소스 암호화](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html) 섹션을 참조하십시오.
+ KMS 키를 지정하면 클라이언트 측 암호화가 사용됩니다.
+ Amazon RDS에서는 비대칭 KMS 키가 지원되지 않습니다. 자세한 내용은 *AWS Key Management Service 개발자 안내서*의 [대칭 암호화 KMS 키 생성](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-symmetric-cmk)을 참조하세요.
+ `@overwrite_s3_backup_file` – 기존 백업 파일을 덮어쓸지 여부를 나타내는 값입니다.
+ `0` – 기존 파일을 덮어쓰지 않습니다. 이 값이 기본값입니다.
`@overwrite_s3_backup_file`을 0으로 설정하면 파일이 이미 존재할 경우 오류를 반환합니다.
+ `1` – 백업 파일이 아니더라도 지정된 이름이 있는 기존 파일을 덮어씁니다.
+ `@type` – 백업 유형입니다.
+ `DIFFERENTIAL` – 차등 백업을 수행합니다.
+ `FULL` – 전체 백업을 수행합니다. 이 값이 기본값입니다.
차등 백업은 마지막 전체 백업을 기반을 합니다. 차등 백업이 작동할 수 있도록 마지막 전체 백업과 차등 백업 간에는 스냅샷을 만들 수 없습니다. 차등 백업을 만들려고 하는데 스냅샷이 이미 있으면 차등 백업을 진행하기 전에 다른 전체 백업을 만드십시오.
다음 예제 SQL 쿼리를 사용하여 마지막 전체 백업 또는 스냅샷을 찾을 수 있습니다.
```
select top 1
database_name
, backup_start_date
, backup_finish_date
from msdb.dbo.backupset
where database_name='mydatabase'
and type = 'D'
order by backup_start_date desc;
```
+ `@number_of_files` – 백업을 분할(청크)할 파일 수입니다. 최대 개수는 10입니다.
+ 다중 파일 백업은 전체 백업과 차등 백업에 모두 지원됩니다.
+ 값 1을 입력하거나 파라미터를 생략하면 단일 백업 파일이 생성됩니다.
파일에 공통으로 사용되는 접두사를 입력한 다음 접미사로 별표(`*`)를 붙입니다. 별표는 S3 ARN의 *file\$1name* 부분 아무 곳이나 지정할 수 있습니다. 별표는 생성된 파일에서 일련의 영숫자 문자열로 대체되며 `1-of-number_of_files`부터 시작합니다.
예를 들어, S3 ARN의 파일 이름이 `backup*.bak`이고 `@number_of_files=4`를 설정한 경우 생성되는 백업 파일은 `backup1-of-4.bak`, `backup2-of-4.bak`, `backup3-of-4.bak` 및 `backup4-of-4.bak`입니다.
+ 파일 이름이 이미 존재하고 `@overwrite_s3_backup_file`이 0이면 오류가 반환됩니다.
+ 다중 파일 백업에는 S3 ARN의 *file\$1name* 부분에 별표를 하나만 지정할 수 있습니다.
+ 단일 파일 백업에는 S3 ARN의 *file\$1name* 부분에 별표를 여러 개 지정할 수 있습니다. 별표는 생성된 파일 이름에서 제거되지 않습니다.
+ `@block_size` - 백업 작업의 물리적 블록 크기를 지정하는 블록 크기(바이트)입니다. 유효한 값은 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536입니다.
+ `@max_transfer_size` – 최대 전송 크기는 백업 프로세스 중에 I/O 작업당 전송되는 데이터 볼륨의 상한(바이트)을 나타냅니다. 유효한 값은 65,536바이트(64KB)의 배수로, 최대 4,194,304바이트(4MB)입니다.
+ `@buffer_count` - 백업 프로세스에 사용할 I/O 버퍼의 총 수입니다.
+ `@enable_bucket_default_encryption` - S3에서 서버 측 암호화에 S3 버킷 기본 암호화 구성을 사용할지 여부를 나타내는 값입니다. 디렉터리 버킷은이 설정에 관계없이 항상 버킷의 기본 암호화 구성을 사용합니다.
+ `0` - 서버 측 암호화는 SSE-S3를 통한 고급 암호화 표준(AES) 256비트 암호화를 사용합니다.
+ `1` - 서버 측 암호화는 S3 버킷의 구성된 [기본 암호화](https://docs.aws.amazon.com//AmazonS3/latest/userguide/bucket-encryption.html)를 사용합니다.
### 예제
**Example 차등 백업**
```
exec msdb.dbo.rds_backup_database
@source_db_name='mydatabase',
@s3_arn_to_backup_to='arn:aws:s3:::mybucket/backup1.bak',
@overwrite_s3_backup_file=1,
@type='DIFFERENTIAL';
```
**Example 클라이언트 측 암호화를 사용하는 전체 백업**
```
exec msdb.dbo.rds_backup_database
@source_db_name='mydatabase',
@s3_arn_to_backup_to='arn:aws:s3:::mybucket/backup1.bak',
@kms_master_key_arn='arn:aws:kms:us-east-1:123456789012:key/AKIAIOSFODNN7EXAMPLE',
@overwrite_s3_backup_file=1,
@type='FULL';
```
**Example 다중 파일 백업**
```
exec msdb.dbo.rds_backup_database
@source_db_name='mydatabase',
@s3_arn_to_backup_to='arn:aws:s3:::mybucket/backup*.bak',
@number_of_files=4;
```
**Example 다중 파일 차등 백업**
```
exec msdb.dbo.rds_backup_database
@source_db_name='mydatabase',
@s3_arn_to_backup_to='arn:aws:s3:::mybucket/backup*.bak',
@type='DIFFERENTIAL',
@number_of_files=4;
```
**Example 암호화를 사용한 다중 파일 백업**
```
exec msdb.dbo.rds_backup_database
@source_db_name='mydatabase',
@s3_arn_to_backup_to='arn:aws:s3:::mybucket/backup*.bak',
@kms_master_key_arn='arn:aws:kms:us-east-1:123456789012:key/AKIAIOSFODNN7EXAMPLE',
@number_of_files=4;
```
**Example S3 덮어쓰기를 사용한 다중 파일 백업**
```
exec msdb.dbo.rds_backup_database
@source_db_name='mydatabase',
@s3_arn_to_backup_to='arn:aws:s3:::mybucket/backup*.bak',
@overwrite_s3_backup_file=1,
@number_of_files=4;
```
**Example 블록 크기를 사용한 백업**
```
exec msdb.dbo.rds_backup_database
@source_db_name='mydatabase',
@s3_arn_to_backup_to='arn:aws:s3:::mybucket/backup*.bak',
@block_size=512;
```
**Example `@max_transfer_size` 및 `@buffer_count`를 사용한 멀티파일 백업**
```
exec msdb.dbo.rds_backup_database
@source_db_name='mydatabase',
@s3_arn_to_backup_to='arn:aws:s3:::mybucket/backup*.bak',
@number_of_files=4,
@max_transfer_size=4194304,
@buffer_count=10;
```
**Example @number\$1of\$1files 파라미터를 사용하는 단일 파일 백업**
이 예제에서는 `backup*.bak` 백업 파일을 생성합니다.
```
exec msdb.dbo.rds_backup_database
@source_db_name='mydatabase',
@s3_arn_to_backup_to='arn:aws:s3:::mybucket/backup*.bak',
@number_of_files=1;
```
**Example 서버 측 암호화를 사용하는 전체 백업**
```
exec msdb.dbo.rds_backup_database
@source_db_name='mydatabase',
@s3_arn_to_backup_to='arn:aws:s3:::mybucket/backup*.bak',
@overwrite_s3_backup_file=1,
@type='FULL',
@enable_bucket_default_encryption=1;
```
**Example 액세스 포인트를 사용한 전체 백업**
```
exec msdb.dbo.rds_backup_database
@source_db_name='mydatabase',
@s3_arn_to_backup_to='arn:aws:s3:us-east-1:111122223333:accesspoint/my-access-point/object/backup1.bak',
@overwrite_s3_backup_file=1,
@type='FULL';
```
**Example 디렉터리 버킷의 액세스 포인트를 사용한 전체 백업**
```
exec msdb.dbo.rds_backup_database
@source_db_name='mydatabase',
@s3_arn_to_backup_to='arn:aws:s3express:us-east-1:123456789012:accesspoint/my-access-point--use1-az6--xa-s3/object/backup1.bak',
@overwrite_s3_backup_file=1,
@type='FULL';
```
## 데이터베이스 복원
데이터베이스를 복원하려면 `rds_restore_database` 저장 프로시저를 호출합니다. 복원 태스크가 완료되고 데이터베이스가 열린 후 Amazon RDS가 데이터베이스의 초기 스냅샷을 생성합니다.
### 사용법
```
exec msdb.dbo.rds_restore_database
@restore_db_name='database_name',
@s3_arn_to_restore_from='arn:aws:s3:::bucket_name/file_name.extension',
@with_norecovery=0|1,
[@keep_cdc=0|1],
[@data_file_volume='D:|H:|I:|J:'],
[@log_file_volume='D:|H:|I:|J:'],
[@kms_master_key_arn='arn:aws:kms:region:account-id:key/key-id'],
[@block_size=512|1024|2048|4096|8192|16384|32768|65536],
[@max_transfer_size=n],
[@buffer_count=n],
[@type='DIFFERENTIAL|FULL'];
```
다음 파라미터는 필수 파라미터입니다.
+ `@restore_db_name` – 복원할 데이터베이스의 이름입니다. 데이터베이스 이름은 고유합니다. 기존 데이터베이스와 이름이 같은 데이터베이스는 복원할 수 없습니다.
+ `@s3_arn_to_restore_from` – 데이터베이스를 복원하는 데 사용되는 백업 파일의 Amazon S3 접두사 및 이름을 나타내는 ARN입니다.
+ 단일 파일 백업의 경우 전체 파일 이름을 입력하십시오.
+ 다중 파일 백업의 경우 파일에 공통으로 사용되는 접두사를 제공한 다음 접미사로 별표(`*`)를 붙입니다.
+ 디렉터리 버킷을 사용하는 경우 [디렉터리 버킷의 차이](https://docs.aws.amazon.com//AmazonS3/latest/userguide/s3-express-differences.html)로 인해 ARN이 `/*`로 끝나야 합니다.
+ `@s3_arn_to_restore_from`이 비어 있으면 다음 오류가 반환됩니다. S3 ARN prefix cannot be empty(S3 ARN 접두사는 비워 둘 수 없습니다).
차등 복원에는 다음 파라미터가 필수적이지만 전체 복원에는 선택적입니다.
+ `@with_norecovery` – 복원 작업에 사용할 복구 절입니다.
+ RECOVERY로 복원하려면 `0`으로 설정합니다. 이 경우 데이터베이스는 복원 후 온라인 상태입니다.
+ NORECOVERY로 복원하려면 `1`로 설정합니다. 이 경우 데이터베이스는 복원 작업 완료 후 RESTORING 상태로 유지됩니다. 이 방법을 사용하면 나중에 차등 복원을 수행할 수 있습니다.
+ DIFFERENTIAL 복원의 경우 `0` 또는 `1`을 지정하십시오.
+ `FULL` 복원의 경우, 이 값은 기본적으로 `0`로 설정됩니다.
다음 파라미터는 선택적입니다.
+ `@keep_cdc` - 복원된 데이터베이스에서 변경 데이터 캡처(CDC) 구성을 유지할지 여부를 나타냅니다. KEEP\$1CDC를 활성화하려면 `1`로 설정하고 비활성화하려면 `0`으로 설정합니다. 기본값은 `0`입니다.
+ `@data_file_volume` - 데이터베이스 데이터 파일의 드라이브 문자를 지정합니다. 기본값은 `D:`입니다.
+ `@log_file_volume` - 데이터베이스 로그 파일의 드라이브 문자를 지정합니다. 기본값은 `D:`입니다.
+ `@kms_master_key_arn` – 백업 파일을 암호화한 경우 파일 복호화에 사용할 KMS 키입니다.
KMS 키를 지정하면 클라이언트 측 암호화가 사용됩니다.
+ `@type` – 복원의 유형입니다. 유효한 형식은 `DIFFERENTIAL` 및 `FULL`입니다. 기본 값은 `FULL`입니다.
+ `@block_size` - 백업 작업의 물리적 블록 크기를 지정하는 블록 크기(바이트)입니다. 유효한 값은 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536입니다.
+ `@max_transfer_size` – 최대 전송 크기는 백업 프로세스 중에 I/O 작업당 전송되는 데이터 볼륨의 상한(바이트)을 나타냅니다. 유효한 값은 65,536바이트(64KB)의 배수로, 최대 4,194,304바이트(4MB)입니다.
+ `@buffer_count` - 백업 프로세스에 사용할 I/O 버퍼의 총 수입니다.
**참고**
차등 복원의 경우 데이터베이스가 RESTORING 상태이거나 NORECOVERY로 복원하는 작업이 이미 존재해야 합니다.
데이터베이스가 온라인 상태인 동안 나중에 차등 백업을 복원할 수 없습니다.
이미 RECOVERY로 복원 작업을 보류 중인 데이터베이스에 대해서는 복원 작업을 제출할 수 없습니다.
NORECOVERY와 KEEP\$1CDC가 모두 포함된 전체 복원은 지원되지 않습니다.
리전 간 읽기 전용 복제본이 있는 인스턴스에서는 모든 기본 복원이 지원되지 않습니다.
지원되는 구성의 경우, 읽기 전용 복제본을 사용하여 다중 AZ 인스턴스에서 데이터베이스를 복원하는 것은 다중 AZ 인스턴스에서 데이터베이스를 복원하는 것과 유사합니다. 복제본에서 데이터베이스를 복원하기 위해 추가 작업을 수행할 필요가 없습니다.
### 예제
**Example 단일 파일 복원**
```
exec msdb.dbo.rds_restore_database
@restore_db_name='mydatabase',
@s3_arn_to_restore_from='arn:aws:s3:::mybucket/backup1.bak';
```
**Example 다중 파일 복원**
여러 파일을 복원하는 동안 오류를 방지하려면 모든 백업 파일의 접두사가 같고 다른 파일은 이 접두사를 사용하지 않아야 합니다.
```
exec msdb.dbo.rds_restore_database
@restore_db_name='mydatabase',
@s3_arn_to_restore_from='arn:aws:s3:::mybucket/backup*';
```
**Example RECOVERY로 전체 데이터베이스 복원**
다음 세 가지 예는 동일한 작업, RECOVERY를 사용한 전체 복원을 수행합니다.
```
exec msdb.dbo.rds_restore_database
@restore_db_name='mydatabase',
@s3_arn_to_restore_from='arn:aws:s3:::mybucket/backup1.bak';
```
```
exec msdb.dbo.rds_restore_database
@restore_db_name='mydatabase',
@s3_arn_to_restore_from='arn:aws:s3:::mybucket/backup1.bak',
[@type='DIFFERENTIAL|FULL'];
```
```
exec msdb.dbo.rds_restore_database
@restore_db_name='mydatabase',
@s3_arn_to_restore_from='arn:aws:s3:::mybucket/backup1.bak',
@type='FULL',
@with_norecovery=0;
```
**Example 암호화로 전체 데이터베이스 복원**
```
exec msdb.dbo.rds_restore_database
@restore_db_name='mydatabase',
@s3_arn_to_restore_from='arn:aws:s3:::mybucket/backup1.bak',
@kms_master_key_arn='arn:aws:kms:us-east-1:123456789012:key/AKIAIOSFODNN7EXAMPLE';
```
**Example 블록 크기를 사용한 복원**
```
exec msdb.dbo.rds_restore_database
@restore_db_name='mydatabase',
@s3_arn_to_restore_from='arn:aws:s3:::mybucket/backup1.bak',
@block_size=512;
```
**Example @max\$1transfer\$1size 및 @buffer\$1count를 사용한 멀티파일 복원**
```
exec msdb.dbo.rds_restore_database
@restore_db_name='mydatabase',
@s3_arn_to_restore_from='arn:aws:s3:::mybucket/backup*',
@max_transfer_size=4194304,
@buffer_count=10;
```
**Example NORECOVERY로 전체 데이터베이스 복원**
```
exec msdb.dbo.rds_restore_database
@restore_db_name='mydatabase',
@s3_arn_to_restore_from='arn:aws:s3:::mybucket/backup1.bak',
@type='FULL',
@with_norecovery=1;
```
**Example NORECOVERY로 차등 복원**
```
exec msdb.dbo.rds_restore_database
@restore_db_name='mydatabase',
@s3_arn_to_restore_from='arn:aws:s3:::mybucket/backup1.bak',
@type='DIFFERENTIAL',
@with_norecovery=1;
```
**Example RECOVERY로 차등 복원**
```
exec msdb.dbo.rds_restore_database
@restore_db_name='mydatabase',
@s3_arn_to_restore_from='arn:aws:s3:::mybucket/backup1.bak',
@type='DIFFERENTIAL',
@with_norecovery=0;
```
**Example 액세스 포인트를 사용하여 RECOVERY를 사용한 전체 데이터베이스 복원**
```
exec msdb.dbo.rds_restore_database
@restore_db_name='mydatabase',
@s3_arn_to_backup_to='arn:aws:s3:us-east-1:111122223333:accesspoint/my-access-point/object/backup1.bak',
@with_norecovery=0;
```
**Example KEEP\$1CDC으로 전체 데이터베이스 복원**
```
exec msdb.dbo.rds_restore_database
@restore_db_name='mydatabase',
@s3_arn_to_restore_from='arn:aws:s3:::mybucket/backup1.bak',
@keep_cdc=1;
```
## 로그 복원
로그를 복원하려면 `rds_restore_log` 저장 프로시저를 호출합니다.
### 사용법
```
exec msdb.dbo.rds_restore_log
@restore_db_name='database_name',
@s3_arn_to_restore_from='arn:aws:s3:::bucket_name/log_file_name.extension',
[@kms_master_key_arn='arn:aws:kms:region:account-id:key/key-id'],
[@with_norecovery=0|1],
[@keep_cdc=0|1],
[@stopat='datetime'],
[@block_size=512|1024|2048|4096|8192|16384|32768|65536],
[@max_transfer_size=n],
[@buffer_count=n];
```
다음 파라미터는 필수 파라미터입니다.
+ `@restore_db_name` – 로그를 복원할 데이터베이스의 이름입니다.
+ `@s3_arn_to_restore_from` – 로그를 복원하는 데 사용되는 로그 파일의 Amazon S3 접두사 및 이름을 나타내는 ARN입니다. 파일에는 어떤 확장명이든 있을 수 있지만 `.trn`이 주로 사용됩니다.
`@s3_arn_to_restore_from`이 비어 있으면 다음 오류가 반환됩니다. S3 ARN prefix cannot be empty(S3 ARN 접두사는 비워 둘 수 없습니다).
다음 파라미터는 선택적입니다.
+ `@keep_cdc` - 복원된 데이터베이스에서 변경 데이터 캡처(CDC) 구성을 유지할지 여부를 나타냅니다. KEEP\$1CDC를 활성화하려면 1로 설정하고 비활성화하려면 0으로 설정합니다. 기본값은 0입니다.
+ `@kms_master_key_arn` – 로그를 암호화한 경우, 로그 복호화에 사용할 KMS 키입니다.
+ `@with_norecovery` – 복원 작업에 사용할 복구 절입니다. 기본값은 `1`입니다.
+ RECOVERY로 복원하려면 `0`으로 설정합니다. 이 경우 데이터베이스는 복원 후 온라인 상태입니다. 데이터베이스가 온라인 상태인 동안 더 이상 로그 백업을 복원할 수 없습니다.
+ NORECOVERY로 복원하려면 `1`로 설정합니다. 이 경우 데이터베이스는 복원 작업 완료 후 RESTORING 상태로 유지됩니다. 이 방법을 사용하면 나중에 로그 복원을 수행할 수 있습니다.
+ `@stopat` – 데이터베이스가 지정된 날짜 및 시간(날짜 시간 형식)에서 해당 상태로 복원되도록 지정하는 값입니다. 지정된 날짜 및 시간 이전에 작성된 트랜잭션 로그 레코드만 데이터베이스에 적용됩니다.
이 파라미터를 지정하지 않으면(NULL 인 경우) 전체 로그가 복원됩니다.
+ `@block_size` - 백업 작업의 물리적 블록 크기를 지정하는 블록 크기(바이트)입니다. 유효한 값은 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536입니다.
+ `@max_transfer_size` – 최대 전송 크기는 백업 프로세스 중에 I/O 작업당 전송되는 데이터 볼륨의 상한(바이트)을 나타냅니다. 유효한 값은 65,536바이트(64KB)의 배수로, 최대 4,194,304바이트(4MB)입니다.
+ `@buffer_count` - 백업 프로세스에 사용할 I/O 버퍼의 총 수입니다.
**참고**
로그 복원의 경우 데이터베이스가 복원 상태이거나 NORECOVERY로 복원하는 작업이 이미 존재해야 합니다.
데이터베이스가 온라인 상태인 동안 로그 백업을 복원할 수 없습니다.
이미 RECOVERY로 복원 작업을 보류 중인 데이터베이스에서는 로그 복원 작업을 제출할 수 없습니다.
### 예제
**Example 로그 복원**
```
exec msdb.dbo.rds_restore_log
@restore_db_name='mydatabase',
@s3_arn_to_restore_from='arn:aws:s3:::mybucket/mylog.trn';
```
**Example 암호화로 로그 복원**
```
exec msdb.dbo.rds_restore_log
@restore_db_name='mydatabase',
@s3_arn_to_restore_from='arn:aws:s3:::mybucket/mylog.trn',
@kms_master_key_arn='arn:aws:kms:us-east-1:123456789012:key/AKIAIOSFODNN7EXAMPLE';
```
**Example NORECOVERY로 로그 복원**
다음 두 가지 예는 동일한 작업, NORECOVERY를 사용한 로그 복원을 수행합니다.
```
exec msdb.dbo.rds_restore_log
@restore_db_name='mydatabase',
@s3_arn_to_restore_from='arn:aws:s3:::mybucket/mylog.trn',
@with_norecovery=1;
```
```
exec msdb.dbo.rds_restore_log
@restore_db_name='mydatabase',
@s3_arn_to_restore_from='arn:aws:s3:::mybucket/mylog.trn';
```
**Example 블록 크기를 사용한 복원**
```
exec msdb.dbo.rds_restore_log
@restore_db_name='mydatabase',
@s3_arn_to_restore_from='arn:aws:s3:::mybucket/mylog.trn',
@block_size=512;
```
**Example RECOVERY로 로그 복원**
```
exec msdb.dbo.rds_restore_log
@restore_db_name='mydatabase',
@s3_arn_to_restore_from='arn:aws:s3:::mybucket/mylog.trn',
@with_norecovery=0;
```
**Example STOPAT 절로 로그 복원**
```
exec msdb.dbo.rds_restore_log
@restore_db_name='mydatabase',
@s3_arn_to_restore_from='arn:aws:s3:::mybucket/mylog.trn',
@with_norecovery=0,
@stopat='2019-12-01 03:57:09';
```
**Example KEEP\$1CDC를 사용한 로그 복원**
```
exec msdb.dbo.rds_restore_database
@restore_db_name='mydatabase',
@s3_arn_to_restore_from='arn:aws:s3:::mybucket/backup1.bak',
@keep_cdc=1;
```
## 데이터베이스 복원 마무리
`@with_norecovery=1`을 사용하여 데이터베이스에서 마지막 복원 작업을 수행한 경우, 데이터베이스는 이제 RESTORING 상태입니다. `rds_finish_restore` 저장 프로시저를 사용하여 정상적으로 작동할 이 데이터베이스를 엽니다.
### 사용법
```
exec msdb.dbo.rds_finish_restore @db_name='database_name';
```
**참고**
이 방법을 사용하려면 데이터베이스가 보류 중인 복원 작업 없이 RESTORING 상태여야 합니다.
데이터베이스 복원을 마치려면 마스터 로그인을 사용하십시오. 또는 가장 최근에 NORECOVERY로 데이터베이스나 로그를 복원한 사용자 로그인 정보를 사용하십시오.
## 부분적으로 복원된 데이터베이스 작업
### 부분적으로 복원된 데이터베이스 삭제
부분적으로 복원된 데이터베이스를 삭제하려면(RESTORING 상태로 남음), `rds_drop_database` 저장 프로시저를 사용하십시오.
```
exec msdb.dbo.rds_drop_database @db_name='database_name';
```
**참고**
이미 보류 중인 복원 작업이 있거나 복원 작업을 마친 데이터베이스에 대해서는 DROP 데이터베이스 요청을 제출할 수 없습니다.
데이터베이스를 삭제하려면 마스터 로그인을 사용합니다. 또는 가장 최근에 NORECOVERY로 데이터베이스나 로그를 복원한 사용자 로그인 정보를 사용하십시오.
### 부분적으로 복원된 데이터베이스에 대한 스냅샷 복원 및 특정 시점으로 복구 동작
원본 인스턴스에서 부분적으로 복원된 데이터베이스(RESTORING 상태로 남음)는 스냅샷 복원 및 특정 시점으로 복구 도중에 대상 인스턴스에서 삭제됩니다.
## 작업 취소
백업 또는 복원 작업을 취소하려면 `rds_cancel_task` 저장 프로시저를 호출합니다.
**참고**
FINISH\$1RESTORE 작업을 취소할 수 없습니다.
### 사용법
```
exec msdb.dbo.rds_cancel_task @task_id=ID_number;
```
다음 파라미터는 필수입니다.
+ `@task_id` – 취소할 작업의 ID입니다. 작업 ID는 `rds_task_status`를 호출하여 확인할 수 있습니다.
## 작업 상태 추적
백업 및 복원 작업의 상태를 추적하려면 `rds_task_status` 저장 프로시저를 호출합니다. 파라미터를 제공하지 않으면 이 저장 프로시저는 모든 작업의 상태를 반환합니다. 작업 상태는 약 2분마다 업데이트됩니다. 작업 기록은 36일 동안 보존됩니다.
### 사용법
```
exec msdb.dbo.rds_task_status
[@db_name='database_name'],
[@task_id=ID_number];
```
다음 파라미터는 선택적입니다.
+ `@db_name` – 작업 상태를 표시할 데이터베이스의 이름입니다.
+ `@task_id` – 작업 상태를 표시할 작업의 ID입니다.
### 예제
**Example 특정 작업의 상태 나열**
```
exec msdb.dbo.rds_task_status @task_id=5;
```
**Example 특정 데이터베이스 및 작업의 상태 나열**
```
exec msdb.dbo.rds_task_status
@db_name='my_database',
@task_id=5;
```
**Example 특정 데이터베이스의 모든 작업 및 상태 나열**
```
exec msdb.dbo.rds_task_status @db_name='my_database';
```
**Example 현재 인스턴스의 모든 작업 및 상태 나열**
```
exec msdb.dbo.rds_task_status;
```
### 응답
`rds_task_status` 저장 프로시저는 다음과 같은 열을 반환합니다.
****
| 열 | 설명 |
| --- | --- |
| `task_id` | 작업의 ID입니다. |
| `task_type` | 입력 파라미터에 따라 다음과 같은 작업 유형: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/SQLServer.Procedural.Importing.Native.Using.html) 다음 복원 작업이 완료되고 데이터베이스가 열린 후 Amazon RDS가 데이터베이스의 최초 스냅샷을 만듭니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/SQLServer.Procedural.Importing.Native.Using.html) |
| `database_name` | 작업이 연결되어 있는 데이터베이스의 이름입니다. |
| `% complete` | 백분율로 나타낸 작업의 진행률입니다. |
| `duration (mins)` | 작업에 소요된 시간입니다(분). |
| `lifecycle` | 작업의 상태입니다. 가능한 상태는 다음과 같습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/SQLServer.Procedural.Importing.Native.Using.html) |
| `task_info` | 작업에 대한 추가 정보입니다. 데이터베이스를 백업하거나 복원하는 동안 오류가 발생하면 이 열에 오류에 대한 정보가 포함됩니다. 가능한 오류 목록 및 완화 전략은 [문제 해결](SQLServer.Procedural.Importing.Native.Troubleshooting.md) 섹션을 참조하십시오. |
| `last_updated` | 작업 상태를 마지막으로 업데이트한 날짜와 시간입니다. 상태는 5% 진행 후마다 업데이트됩니다. |
| `created_at` | 작업을 생성한 날짜와 시간입니다. |
| S3\$1object\$1arn | 백업 또는 복원 중인 파일의 Amazon S3 접두사 및 이름을 나타내는 ARN입니다. |
| `overwrite_s3_backup_file` | 백업 작업을 호출할 때 지정된 `@overwrite_s3_backup_file` 파라미터의 값입니다. 자세한 내용은 [데이터베이스 백업](#SQLServer.Procedural.Importing.Native.Using.Backup) 섹션을 참조하세요. |
| KMS\$1master\$1key\$1arn | 암호화(백업용) 및 복호화(복원용)에 사용되는 KMS 키의 ARN입니다. |
| filepath | 기본 백업 및 복원 작업에는 해당되지 않음 |
| overwrite\$1file | 기본 백업 및 복원 작업에는 해당되지 않음 |
# 백업 파일 압축
Amazon S3 버킷 용량 절약을 위해 백업 파일을 압축할 수 있습니다. 백업 파일 압축에 대한 자세한 내용은 Microsoft 설명서의 [Backup Compression](https://msdn.microsoft.com/en-us/library/bb964719.aspx)을 참조하십시오.
백업 파일 압축은 다음 데이터베이스 에디션에 지원됩니다.
+ Microsoft SQL Server Enterprise Edition
+ Microsoft SQL Server Standard Edition
백업 파일에 대한 압축 옵션을 확인하려면 다음 코드를 실행합니다.
```
1. exec rdsadmin.dbo.rds_show_configuration 'S3 backup compression';
```
백업 파일 압축을 설정하려면 다음 코드를 실행하십시오.
```
1. exec rdsadmin.dbo.rds_set_configuration 'S3 backup compression', 'true';
```
백업 파일 압축을 해제하려면 다음 코드를 실행하십시오.
```
1. exec rdsadmin.dbo.rds_set_configuration 'S3 backup compression', 'false';
```
# 문제 해결
다음은 기본 백업 및 복원을 사용할 때 생길 수 있는 문제들입니다.
****
| 문제 | 문제 해결 제안 |
| --- | --- |
| 데이터베이스 백업/복원 옵션이 아직 활성화되지 않았거나 활성화되는 중입니다. 나중에 다시 시도하세요. | `SQLSERVER_BACKUP_RESTORE` 옵션을 DB 인스턴스와 연결된 DB 옵션 그룹에 추가해야 합니다. 자세한 내용은 [기본 백업 및 복원 옵션 추가](Appendix.SQLServer.Options.BackupRestore.md#Appendix.SQLServer.Options.BackupRestore.Add) 섹션을 참조하세요. |
| 객체 '*rds\$1backup\$1database*', 데이터베이스 'msdb', 스키마 'dbo'에서 EXECUTE 권한이 거부되었습니다. | 저장 프로시저를 실행할 때 마스터 사용자를 사용하고 있는지 확인합니다. 마스터 사용자로 로그인한 후에도 이 오류가 발생하면 관리 사용자 권한이 잘못 정렬되었기 때문일 수 있습니다. 마스터 사용자를 재설정하려면 AWS Management Console을 사용합니다. [Amazon RDS for SQL Server 마스터 사용자의 db\$1owner 역할 멤버십 재설정](Appendix.SQLServer.CommonDBATasks.ResetPassword.md)을(를) 참조하세요. |
| 객체 '*rds\$1restore\$1database*', 데이터베이스 'msdb', 스키마 'dbo'에서 EXECUTE 권한이 거부되었습니다. | 저장 프로시저를 실행할 때 마스터 사용자를 사용하고 있는지 확인합니다. 마스터 사용자로 로그인한 후에도 이 오류가 발생하면 관리 사용자 권한이 잘못 정렬되었기 때문일 수 있습니다. 마스터 사용자를 재설정하려면 AWS Management Console을 사용합니다. [Amazon RDS for SQL Server 마스터 사용자의 db\$1owner 역할 멤버십 재설정](Appendix.SQLServer.CommonDBATasks.ResetPassword.md)을(를) 참조하세요. |
| 액세스 거부됨 | 백업 또는 복원 프로세스는 백업 파일에 액세스할 수 없습니다. 이것의 원인이 되는 문제는 일반적으로 다음과 같습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/SQLServer.Procedural.Importing.Native.Troubleshooting.html) |
| 압축 기능이 있는 백업 데이터베이스는 Edition에서 지원되지 않습니다. | 백업 파일 압축은 Microsoft SQL Server Enterprise Edition 및 Standard Edition에서만 지원됩니다. 자세한 내용은 [백업 파일 압축](SQLServer.Procedural.Importing.Native.Compression.md) 섹션을 참조하세요. |
| 키 이 존재하지 않습니다. | 암호화된 백업을 복원하려고 시도했으나 유효한 암호화 키를 제공하지 않았습니다. 암호화 키를 확인한 후 다시 시도하십시오.자세한 내용은 [데이터베이스 복원](SQLServer.Procedural.Importing.Native.Using.md#SQLServer.Procedural.Importing.Native.Using.Restore) 섹션을 참조하세요. |
| 올바른 유형 및 덮어쓰기 속성을 사용하여 작업을 다시 실행하세요(Please reissue task with correct type and overwrite property) | 데이터베이스 백업을 시도할 때 이미 존재하는 파일 이름을 입력하고 덮어쓰기 속성을 false로 설정하면 저장 작업이 실패합니다. 이 오류를 해결하려면 존재하지 않는 파일 이름을 입력하거나 덮어쓰기 속성을 true로 설정하십시오. 자세한 내용은 [데이터베이스 백업](SQLServer.Procedural.Importing.Native.Using.md#SQLServer.Procedural.Importing.Native.Using.Backup) 섹션을 참조하세요. 데이터베이스를 복원할 때 잘못하여 `rds_backup_database` 저장 프로시저를 호출했을 수도 있습니다. 이 경우 대신 `rds_restore_database` 저장 프로시저를 호출하십시오. 자세한 내용은 [데이터베이스 복원](SQLServer.Procedural.Importing.Native.Using.md#SQLServer.Procedural.Importing.Native.Using.Restore) 섹션을 참조하세요. 데이터베이스를 복원할 때 `rds_restore_database` 저장 프로시저를 호출한 경우, 유효한 백업 파일 이름을 입력했는지 확인하십시오. 자세한 내용은 [기본 백업 및 복원 사용](SQLServer.Procedural.Importing.Native.Using.md) 섹션을 참조하세요. |
| RDS 인스턴스와 동일한 리전에 있는 버킷을 지정하세요. | Amazon RDS DB 인스턴스와 다른 AWS 리전에서는 Amazon S3 버킷으로 백업하거나 복원할 수 없습니다. Amazon S3 복제를 사용하여 백업 파일을 올바른 AWS 리전에 복사할 수 있습니다. 자세한 내용은 Amazon S3 설명서의 [리전 간 복제](https://docs.aws.amazon.com/AmazonS3/latest/userguide/crr.html) 단원을 참조하십시오. |
| 지정된 버킷이 존재하지 않습니다 | 버킷 및 파일에 대해 올바른 ARN을 올바른 형식으로 입력했는지 확인하십시오. 자세한 내용은 [기본 백업 및 복원 사용](SQLServer.Procedural.Importing.Native.Using.md) 섹션을 참조하세요. |
| 사용자 이 리소스 에 대해 수행할 권한이 없습니다 | 암호화된 작업을 요청했으나 올바른 AWS KMS 권한을 제공하지 않았습니다. 올바른 권한이 있는지 확인하거나 올바른 권한을 추가하십시오. 자세한 내용은 [기본 백업 및 복원 설정](SQLServer.Procedural.Importing.Native.Enabling.md) 섹션을 참조하세요. |
| 복원 작업은 10개 이상의 백업 파일에서 복원할 수 없습니다. 일치하는 파일 수를 줄이고 다시 시도하세요 | 복원하려는 파일 수를 줄입니다. 필요한 경우 개별 파일을 더 크게 만들 수 있습니다. |
| 데이터베이스의 '*database\$1name*’이 이미 있습니다. 대/소문자 또는 액센트만 다른 두 데이터베이스는 허용되지 않습니다. 다른 데이터베이스 이름을 선택합니다. | 기존 데이터베이스와 이름이 같은 데이터베이스는 복원할 수 없습니다. 데이터베이스 이름은 고유합니다. |
# 다른 방법으로 SQL Server 데이터 가져오기 및 내보내기
다음으로, 스냅샷을 사용하여 Microsoft SQL Server 데이터를 Amazon RDS로 가져오는 방법에 대한 정보를 찾을 수 있습니다. 스냅샷을 사용하여 SQL Server를 실행 중인 RDS DB 인스턴스에서 데이터를 내보내는 방법에 대한 정보도 찾을 수 있습니다.
이 방법이 가능한 시나리오라면 기본 백업 및 복원 기능을 사용하여 Amazon RDS 안팎으로 데이터를 옮기는 것이 더 쉽습니다. 자세한 내용은 [기본 백업 및 복원 기능을 사용하여 SQL Server 데이터베이스 가져오기 및 내보내기](SQLServer.Procedural.Importing.md) 섹션을 참조하세요.
**참고**
Amazon RDS for Microsoft SQL Server는 `msdb` 데이터베이스로 데이터 가져오기를 지원하지 않습니다.
## 스냅샷을 사용하여 RDS for SQL Server로 데이터 가져오기
**스냅샷을 사용하여 SQL Server DB 인스턴스로 데이터를 가져오려면**
1. DB 인스턴스를 만듭니다. 자세한 내용은 [Amazon RDS DB 인스턴스 생성](USER_CreateDBInstance.md) 섹션을 참조하세요.
1. 애플리케이션이 대상 DB 인스턴스에 액세스하지 못하게 차단합니다.
데이터를 가져오는 동안 DB 인스턴스에 대한 액세스를 금지하면 데이터 전송이 더 빨라집니다. 또한, 다른 애플리케이션이 DB 인스턴스에 동시에 쓸 수 없는 경우 데이터가 로드되는 동안 충돌에 대해 걱정할 필요가 없습니다. 뭔가 잘못되어 이전의 데이터베이스 스냅샷으로 롤백해야 할 때 잃게 되는 유일한 변경 내용은 가져온 데이터입니다. 문제를 해결한 후 이 데이터를 다시 가져올 수 있습니다.
DB 인스턴스 액세스 제어에 대한 자세한 정보는 [보안 그룹을 통한 액세스 제어](Overview.RDSSecurityGroups.md)을(를) 참조하십시오.
1. 대상 데이터베이스의 스냅샷을 만듭니다.
대상 데이터베이스가 이미 데이터로 채워져 있으면 데이터베이스의 스냅샷을 만든 후에 데이터를 가져오는 것이 좋습니다. 데이터 가져오기에 문제가 있거나 변경 내용을 취소하려는 경우 스냅샷을 사용하여 데이터베이스를 이전 상태로 복원할 수 있습니다. 데이터베이스 스냅샷에 대한 자세한 정보는 [Amazon RDS의 단일 AZ DB 인스턴스에 대한 DB 스냅샷 생성](USER_CreateSnapshot.md)을(를) 참조하십시오.
**참고**
데이터베이스 스냅샷을 만들 때, 백업이 진행되는 동안 데이터베이스에 대한 I/O 작업이 잠시(밀리초) 중단됩니다.
1. 대상 데이터베이스에서 자동 백업을 비활성화합니다.
자동 백업이 비활성화되어 있을 때는 Amazon RDS가 트랜잭션을 로그에 기록하지 않기 때문에 대상 DB 인스턴스에서 자동 백업을 비활성화하면 데이터를 가져오는 동안 성능이 향상됩니다. 하지만 몇 가지 고려해야 할 사항이 있습니다. 특정 시점으로 복구를 수행하려면 자동 백업이 필요합니다. 따라서 데이터를 가져오는 동안 데이터베이스를 특정 시점으로 복원할 수 없습니다. 또한 보관을 선택하지 않을 경우 DB 인스턴스에서 생성된 자동 백업 데이터가 지워집니다.
자동 백업을 유지하도록 선택하면 실수로 데이터가 삭제되는 것을 방지할 수 있습니다. 또한 Amazon RDS는 데이터베이스 인스턴스 속성을 각 자동 백업과 함께 저장하여 쉽게 복구할 수 있도록 지원합니다. 이 옵션을 사용하면 데이터베이스 인스턴스가 삭제된 이후에도 백업 보존 기간 중 특정 시점으로 데이터베이스 인스턴스를 복원할 수 있습니다. 자동 백업은 활성 데이터베이스 인스턴스에서와 마찬가지로 지정된 백업 기간이 종료되면 자동으로 삭제됩니다.
또한 이전 스냅샷을 사용하여 데이터베이스를 복구할 수 있고, 지금까지 만든 스냅샷은 전부 그대로 사용할 수 있습니다. 자동 백업에 대한 자세한 내용은 [백업 소개](USER_WorkingWithAutomatedBackups.md) 단원을 참조하십시오.
1. 해당될 경우 외래 키 제약 조건을 비활성화합니다.
외래 키 제약 조건을 비활성화할 필요가 있는 경우 다음 스크립트로 비활성화할 수 있습니다.
```
--Disable foreign keys on all tables
DECLARE @table_name SYSNAME;
DECLARE @cmd NVARCHAR(MAX);
DECLARE table_cursor CURSOR FOR SELECT name FROM sys.tables;
OPEN table_cursor;
FETCH NEXT FROM table_cursor INTO @table_name;
WHILE @@FETCH_STATUS = 0 BEGIN
SELECT @cmd = 'ALTER TABLE '+QUOTENAME(@table_name)+' NOCHECK CONSTRAINT ALL';
EXEC (@cmd);
FETCH NEXT FROM table_cursor INTO @table_name;
END
CLOSE table_cursor;
DEALLOCATE table_cursor;
GO
```
1. 해당될 경우 인덱스를 삭제합니다.
1. 트리거가 있는 경우 비활성화합니다.
트리거를 비활성화해야 하는 경우 다음 스크립트로 비활성화할 수 있습니다.
```
--Disable triggers on all tables
DECLARE @enable BIT = 0;
DECLARE @trigger SYSNAME;
DECLARE @table SYSNAME;
DECLARE @cmd NVARCHAR(MAX);
DECLARE trigger_cursor CURSOR FOR SELECT trigger_object.name trigger_name,
table_object.name table_name
FROM sysobjects trigger_object
JOIN sysobjects table_object ON trigger_object.parent_obj = table_object.id
WHERE trigger_object.type = 'TR';
OPEN trigger_cursor;
FETCH NEXT FROM trigger_cursor INTO @trigger, @table;
WHILE @@FETCH_STATUS = 0 BEGIN
IF @enable = 1
SET @cmd = 'ENABLE ';
ELSE
SET @cmd = 'DISABLE ';
SET @cmd = @cmd + ' TRIGGER dbo.'+QUOTENAME(@trigger)+' ON dbo.'+QUOTENAME(@table)+' ';
EXEC (@cmd);
FETCH NEXT FROM trigger_cursor INTO @trigger, @table;
END
CLOSE trigger_cursor;
DEALLOCATE trigger_cursor;
GO
```
1. 원본 SQL Server 인스턴스에서 대상 DB 인스턴스로 가져오려는 로그인을 쿼리합니다.
SQL Server는 `master` 데이터베이스에 로그인과 암호를 저장합니다. Amazon RDS는 `master` 데이터베이스에 액세스 권한을 부여하지 않기 때문에, 로그인 정보와 암호를 대상 DB 인스턴스로 직접 가져올 수는 없습니다. 대신, 원본 SQL Server 인스턴스에서 `master` 데이터베이스를 쿼리하여 DDL(데이터 정의 언어) 파일을 생성해야 합니다. 이 파일에는 대상 DB 인스턴스에 추가하려는 모든 로그인 정보와 암호가 포함되어야 합니다. 이 파일에는 전송하려는 역할 멤버십 및 권한도 포함되어야 합니다.
`master` 데이터베이스 쿼리에 대한 자세한 정보는 Microsoft 기술 자료의 [SQL Server 인스턴스 간에 로그인 및 암호 전송](https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/security/transfer-logins-passwords-between-instances)을 참조하세요.
스크립트의 출력은 대상 DB 인스턴스에서 실행할 수 있는 또 다른 스크립트입니다. 기술 자료 문서에 있는 스크립트에 다음 코드가 있을 경우
```
p.type IN
```
`p.type`이 나타나는 곳에서는 모두 다음 코드를 대신 사용합니다.
```
p.type = 'S'
```
1. [데이터 가져오기](#ImportData.SQLServer.Import)의 방법을 사용하여 데이터를 가져옵니다.
1. 애플리케이션에 대상 DB 인스턴스에 대한 액세스 권한을 부여합니다.
데이터 가져오기가 완료되면 가져오기 중에 차단한 애플리케이션에 DB 인스턴스 액세스 권한을 부여할 수 있습니다. DB 인스턴스 액세스 제어에 대한 자세한 정보는 [보안 그룹을 통한 액세스 제어](Overview.RDSSecurityGroups.md)을(를) 참조하십시오.
1. 대상 DB 인스턴스에서 자동 백업을 활성화합니다.
자동 백업에 대한 자세한 내용은 [백업 소개](USER_WorkingWithAutomatedBackups.md) 단원을 참조하십시오.
1. 외래 키 제약 조건을 활성화합니다.
앞서 외래 키 제약 조건을 비활성화한 경우 다음 스크립트로 활성화할 수 있습니다.
```
--Enable foreign keys on all tables
DECLARE @table_name SYSNAME;
DECLARE @cmd NVARCHAR(MAX);
DECLARE table_cursor CURSOR FOR SELECT name FROM sys.tables;
OPEN table_cursor;
FETCH NEXT FROM table_cursor INTO @table_name;
WHILE @@FETCH_STATUS = 0 BEGIN
SELECT @cmd = 'ALTER TABLE '+QUOTENAME(@table_name)+' CHECK CONSTRAINT ALL';
EXEC (@cmd);
FETCH NEXT FROM table_cursor INTO @table_name;
END
CLOSE table_cursor;
DEALLOCATE table_cursor;
```
1. 인덱스가 있는 경우 인덱스를 활성화합니다.
1. 트리거가 있는 경우 트리거를 활성화합니다.
앞서 트리거를 비활성화했다면 다음 스크립트로 활성화할 수 있습니다.
```
--Enable triggers on all tables
DECLARE @enable BIT = 1;
DECLARE @trigger SYSNAME;
DECLARE @table SYSNAME;
DECLARE @cmd NVARCHAR(MAX);
DECLARE trigger_cursor CURSOR FOR SELECT trigger_object.name trigger_name,
table_object.name table_name
FROM sysobjects trigger_object
JOIN sysobjects table_object ON trigger_object.parent_obj = table_object.id
WHERE trigger_object.type = 'TR';
OPEN trigger_cursor;
FETCH NEXT FROM trigger_cursor INTO @trigger, @table;
WHILE @@FETCH_STATUS = 0 BEGIN
IF @enable = 1
SET @cmd = 'ENABLE ';
ELSE
SET @cmd = 'DISABLE ';
SET @cmd = @cmd + ' TRIGGER dbo.'+QUOTENAME(@trigger)+' ON dbo.'+QUOTENAME(@table)+' ';
EXEC (@cmd);
FETCH NEXT FROM trigger_cursor INTO @trigger, @table;
END
CLOSE trigger_cursor;
DEALLOCATE trigger_cursor;
```
### 데이터 가져오기
Microsoft SQL Server Management Studio는 Express Edition을 제외한 모든 Microsoft SQL Server 버전에 포함되는 그래픽 SQL Server 클라이언트입니다. SQL Server Management Studio Express는 Microsoft에서 무료 다운로드로 사용할 수 있습니다. 다운로드에 관해서는 [Microsoft 웹 사이트](https://www.microsoft.com/en-us/download)을(를) 참조하십시오.
**참고**
SQL Server Management Studio는 Windows 기반 애플리케이션으로만 사용할 수 있습니다.
SQL Server Management Studio에는 SQL Server DB 인스턴스로 데이터를 가져오는 데 유용한 다음 도구가 포함됩니다.
+ 스크립트 생성 및 게시 마법사
+ 가져오기 및 내보내기 마법사
+ 대량 복사
#### 스크립트 생성 및 게시 마법사
스크립트 생성 및 게시 마법사는 데이터베이스의 스키마, 데이터 자체 또는 두 가지를 모두 포함한 스크립트를 만듭니다. 로컬 SQL Server 배포에서 데이터베이스에 대한 스크립트를 생성할 수 있습니다. 그런 다음, 포함된 정보를 Amazon RDS DB 인스턴스로 전송하는 스크립트를 실행할 수 있습니다.
**참고**
1GiB 이상의 데이터베이스인 경우, 데이터베이스 스키마만 스크립팅하는 것이 더 효율적입니다. 그런 다음 가져오기 및 내보내기 마법사 또는 SQL Server의 대량 복사 기능을 사용하여 데이터를 전송합니다.
스크립트 생성 및 게시 마법사에 대한 자세한 정보는 [Microsoft SQL Server 문서](http://msdn.microsoft.com/en-us/library/ms178078%28v=sql.105%29.aspx)을(를) 참조하십시오.
마법사에서는 특히 [**스크립팅 옵션 설정**] 페이지의 고급 옵션에 주의하여 스크립트에 포함하려는 모든 것이 선택되어 있는지 확인하십시오. 예를 들어 데이터베이스 트리거는 기본적으로 스크립트에 포함되지 않습니다.
스크립트가 생성되고 저장되면 SQL Server Management Studio를 사용하여 DB 인스턴스에 연결한 후 스크립트를 실행할 수 있습니다.
#### 가져오기 및 내보내기 마법사
가져오기 및 내보내기 마법사는 특별한 통합 서비스 패키지를 만드는데, 이 패키지를 사용하여 로컬 SQL Server 데이터베이스에서 대상 DB 인스턴스로 데이터를 복사할 수 있습니다. 이 마법사에서는 대상 DB 인스턴스로 어떤 테이블, 심지어 테이블 내에 있는 어떤 튜플을 복사할지 필터링할 수 있습니다.
**참고**
가져오기 및 내보내기 마법사는 큰 데이터 집합에 매우 효과적이지만, 로컬 배포 위치에서 원격으로 데이터를 내보내는 가장 빠른 방법은 아닐 수도 있습니다. 훨씬 더 빠른 방법을 원한다면, SQL Server 대량 복사 기능을 고려하십시오.
가져오기 및 내보내기 마법사에 대한 자세한 내용은 [Microsoft SQL Server 문서](http://msdn.microsoft.com/en-us/library/ms140052%28v=sql.105%29.aspx)를 참조하십시오.
이 마법사의 [**대상 선택**] 페이지에서 다음을 수행합니다.
+ [**서버 이름**]에 DB 인스턴스의 엔드포인트 이름을 입력합니다.
+ 서버 인증 모드를 위해 [**SQL Server 인증 사용**]을 선택합니다.
+ [**사용자 이름**] 및 [**암호**]에 DB 인스턴스용으로 만든 마스터 사용자의 자격 증명을 입력합니다.
#### 대량 복사
SQL Server 대량 복사 기능은 원본 데이터베이스에서 DB 인스턴스로 데이터를 복사하는 효율적인 수단입니다. 대량 복사는 ASCII 파일과 같은 데이터 파일에 사용자가 지정하는 데이터를 쓰는 기능입니다. 대량 복사를 다시 실행하여 파일의 내용을 대상 DB 인스턴스에 쓸 수 있습니다.
이 섹션에서는 모든 SQL Server 버전에 포함되어 있는 **bcp** 유틸리티를 사용합니다. 대량 가져오기 및 내보내기 작업에 대한 자세한 정보는 [Microsoft SQL Server 문서](http://msdn.microsoft.com/en-us/library/ms187042%28v=sql.105%29.aspx)를 참조하십시오.
**참고**
대량 복사 기능을 사용하기 전에, 우선 데이터베이스 스키마를 대상 DB 인스턴스로 가져와야 합니다. 이 주제의 앞 부분에서 설명한 스크립트 생성 및 게시 마법사는 이 목적으로 사용하기에 훌륭한 도구입니다.
다음 명령은 로컬 SQL Server 인스턴스에 연결합니다. 그러면 기존 SQL Server 배포의 C:\$1 루트 디렉터리에 지정된 테이블의 탭으로 구분된 파일이 생성됩니다. 테이블은 정규화된 이름으로 지정되고, 텍스트 파일은 복사되는 테이블과 이름이 같습니다.
```
bcp dbname.schema_name.table_name out C:\table_name.txt -n -S localhost -U username -P password -b 10000
```
앞에 나온 코드에는 다음 옵션이 포함됩니다.
+ `-n`은 대량 복사에서 복사되는 데이터의 기본 데이터 형식을 사용할 것임을 지정합니다.
+ `-S`는 *bcp* 유틸리티가 연결할 SQL Server 인스턴스를 지정합니다.
+ `-U`는 SQL Server 인스턴스에 로그인할 계정의 사용자 이름을 지정합니다.
+ `-P`는 로 지정된 사용자의 암호를 지정합니다.`-U`
+ `-b`는 가져온 데이터의 배치당 행 수를 지정합니다.
**참고**
가져오기 작업에 중요한 다른 파라미터가 있을 수 있습니다. 예를 들어, 자격 증명 값에 속한 `-E` 파라미터가 필요할 수 있습니다. 자세한 내용은 [Microsoft SQL Server 문서](http://msdn.microsoft.com/en-us/library/ms162802%28v=sql.105%29.aspx)에서 **bcp** 유틸리티 관련 명령줄 구문에 대한 상세 설명을 참조하십시오.
예를 들어 기본 스키마 `store`를 사용하는 `dbo`라는 이름의 데이터베이스에 `customers`라는 이름의 테이블이 있다고 가정합시다. 암호가 `admin`인 사용자 계정 `insecure`이 `customers` 테이블에서 10,000개의 행을 `customers.txt`라는 파일로 복사합니다.
```
bcp store.dbo.customers out C:\customers.txt -n -S localhost -U admin -P insecure -b 10000
```
데이터 파일을 생성한 후 비슷한 명령을 사용하여 DB 인스턴스에 데이터를 업로드할 수 있습니다. 사전에 대상 DB 인스턴스에서 데이터베이스 및 스키마를 생성하십시오. 출력 파일을 지정하는 `in` 대신 입력 파일을 지정하는 `out` 인수를 사용합니다. 로컬 SQL Server 인스턴스를 지정하기 위해 localhost를 사용하는 대신, DB 인스턴스의 엔드포인트를 지정합니다. 1433 이외의 포트를 사용하는 경우 그 포트도 지정합니다. 사용자 이름과 암호는 DB 인스턴스에 대한 마스터 사용자와 암호가 됩니다. 구문은 다음과 같습니다.
```
bcp dbname.schema_name.table_name
in C:\table_name.txt -n -S endpoint,port -U master_user_name -P master_user_password -b 10000
```
이전 예제를 진행하기 위해, 마스터 사용자 이름이 `admin`이고 암호가 `insecure`라고 가정합니다. DB 인스턴스의 엔드포인트는 `rds.ckz2kqd4qsn1.us-east-1.rds.amazonaws.com`이고, 포트 4080을 사용합니다. 명령은 다음과 같습니다.
```
bcp store.dbo.customers in C:\customers.txt -n -S rds.ckz2kqd4qsn1.us-east-1.rds.amazonaws.com,4080 -U admin -P insecure -b 10000
```
**참고**
보안 모범 사례로 여기에 표시된 프롬프트 이외의 암호를 지정하는 것이 좋습니다.
## RDS for SQL Server에서 데이터 내보내기
다음 옵션 중 하나를 선택하여 RDS for SQL Server DB 인스턴스에서 데이터를 내보낼 수 있습니다.
+ **전체 백업 파일(.bak)을 사용한 기본 데이터베이스 백업** – .bak 파일을 사용하여 데이터베이스를 백업하는 과정은 철저히 최적화되어 있으며, 대개의 경우 데이터를 가장 빨리 내보내는 방법입니다. 자세한 내용은 [기본 백업 및 복원 기능을 사용하여 SQL Server 데이터베이스 가져오기 및 내보내기](SQLServer.Procedural.Importing.md) 섹션을 참조하세요.
+ **SQL Server 가져오기 및 내보내기 마법사** – 자세한 내용은 [SQL Server 가져오기 및 내보내기 마법사](#SQLServer.Procedural.Exporting.SSIEW) 섹션을 참조하세요.
+ **SQL Server 스크립트 생성 및 게시 마법사와 bcp 유틸리티** – 자세한 내용은 [SQL Server 스크립트 생성 및 게시 마법사와 bcp 유틸리티](#SQLServer.Procedural.Exporting.SSGPSW) 섹션을 참조하세요.
### SQL Server 가져오기 및 내보내기 마법사
SQL Server 가져오기 및 내보내기 마법사를 사용하여 RDS for SQL Server DB 인스턴스에서 다른 데이터 스토어로 하나 이상의 테이블, 보기 또는 쿼리를 복사할 수 있습니다. 대상 데이터 스토어가 SQL Server가 아닌 경우 이 방법이 가장 좋습니다. 자세한 내용은 SQL Server 문서의 [SQL Server 가져오기 및 내보내기 마법사](http://msdn.microsoft.com/en-us/library/ms141209%28v=sql.110%29.aspx)를 참조하십시오.
SQL Server 가져오기 및 내보내기 마법사는 Microsoft SQL Server Management Studio의 일부로 제공됩니다. 이 그래픽 SQL Server 클라이언트는 Express Edition을 제외한 모든 Microsoft SQL Server 버전에 포함됩니다. SQL Server Management Studio는 Windows 기반 애플리케이션으로만 사용할 수 있습니다. SQL Server Management Studio Express는 Microsoft에서 무료 다운로드로 사용할 수 있습니다. 다운로드에 관해서는 [Microsoft 웹 사이트](http://www.microsoft.com/en-us/search/Results.aspx?q=sql%20server%20management%20studio)을(를) 참조하십시오.
**SQL Server 가져오기 및 내보내기 마법사를 사용하여 데이터를 내보내려면**
1. SQL Server Management Studio에서 RDS for SQL Server DB 인스턴스에 연결합니다. 이 작업을 수행하는 자세한 방법은 [Microsoft SQL Server DB 인스턴스에 연결](USER_ConnectToMicrosoftSQLServerInstance.md) 단원을 참조하십시오.
1. [**개체 탐색기**]에서 [**데이터베이스**]를 확장하고, 원본 데이터베이스에 대한 컨텍스트 메뉴를 마우스 오른쪽 버튼을 클릭하여 열고, [**작업**]을 선택한 다음, [**데이터 내보내기**]를 선택합니다. 그러면 마법사가 표시됩니다.
1. [**데이터 소스 선택**] 페이지에서 다음을 수행합니다.
1. **Data source(데이터 원본)**에 **SQL Server Native Client 11.0**을 선택합니다.
1. [**서버 이름(Server name)**] 상자에 RDS for SQL Server DB 인스턴스의 엔드포인트가 표시되는지 확인합니다.
1. [**SQL 서버 인증 사용**]을 선택합니다. [**사용자 이름(User name)**] 및 [**암호(Password)**]에서 DB 인스턴스의 마스터 사용자 이름과 암호를 입력합니다.
1. [**데이터베이스**] 상자에 데이터를 내보내려는 원본 데이터베이스가 표시되는지 확인합니다.
1. **다음**을 선택합니다.
1. [**대상 선택**] 페이지에서 다음을 수행합니다.
1. **Destination(대상)**에 **SQL Server Native Client 11.0**을 선택합니다.
**참고**
다른 대상 데이터 원본을 사용할 수 있습니다. 여기에는 .NET Framework 데이터 공급자, OLE DB 공급자, SQL Server Native Client 공급자, ADO.NET 공급자, Microsoft Office Excel, Microsoft Office Access 및 Flat File 소스 등이 포함됩니다. 이러한 데이터 원본 중 하나를 대상으로 선택한 경우 나머지 4단계를 건너뛰십시오. 다음에 제공할 연결 정보에 대한 자세한 내용은 SQL Server 문서의 [대상 선택](http://msdn.microsoft.com/en-us/library/ms178430%28v=sql.110%29.aspx)을 참조하십시오.
1. [**서버 이름**]에 대상 SQL Server DB 인스턴스의 서버 이름을 입력합니다.
1. 알맞은 인증 유형을 선택합니다. 필요한 경우 사용자 이름과 암호를 입력합니다.
1. [**데이터베이스**]에서 대상 데이터베이스의 이름을 선택하거나, [**새로 만들기**]를 선택하여 내보낸 데이터를 포함하는 새 데이터베이스를 만듭니다.
**새로 만들기**를 선택하는 경우, 제공할 데이터베이스 정보에 대한 자세한 내용은 SQL Server 문서의 [데이터베이스 생성](http://msdn.microsoft.com/en-us/library/ms183323%28v=sql.110%29.aspx)을 참조하십시오.
1. **다음**을 선택합니다.
1. [**테이블 복사 또는 쿼리**] 페이지에서 [**하나 이상의 테이블 또는 뷰에서 데이터 복사**] 또는 [**전송 데이터를 지정할 쿼리 작성**]을 선택합니다. **다음**을 선택합니다.
1. [**전송 데이터를 지정할 쿼리 작성**]을 선택한 경우 [**원본 쿼리 지정**] 페이지가 표시됩니다. SQL 쿼리를 입력하거나 붙여 넣은 다음, [**구문 분석**]을 선택하여 확인합니다. 쿼리 유효성 검사가 끝나면 [**다음**]을 선택합니다.
1. [**원본 테이블 및 뷰 선택**] 페이지에서 다음을 수행합니다.
1. 내보내려는 테이블과 뷰를 선택하거나 사용자가 입력한 쿼리가 선택되어 있는지 확인합니다.
1. [**매핑 편집**]을 선택하고 데이터베이스 및 열 매핑 정보를 지정합니다. 자세한 내용은 SQL Server 문서의 [열 매핑](http://msdn.microsoft.com/en-us/library/ms189660%28v=sql.110%29.aspx)을 참조하십시오.
1. (선택 사항) 내보낼 데이터의 미리 보기를 확인하려면 테이블, 뷰 또는 쿼리를 선택한 후 [**미리 보기**]를 선택합니다.
1. **다음**을 선택합니다.
1. [**패키지 실행**] 페이지에서 [**즉시 실행**]이 선택되어 있는지 확인합니다. **다음**을 선택합니다.
1. [**마법사 완료**] 페이지에서 데이터 내보내기 세부 정보가 예상한 대로인지 확인합니다. [**마침**]을 클릭합니다.
1. [**실행이 성공했습니다.**] 페이지에서 [**닫기**]를 선택합니다.
### SQL Server 스크립트 생성 및 게시 마법사와 bcp 유틸리티
SQL Server 스크립트 생성 및 게시 마법사를 사용하여 데이터베이스 전체 또는 선택한 개체만을 위한 스크립트를 작성할 수 있습니다. 대상 SQL Server DB 인스턴스에서 이런 스크립트를 실행하여 스크립팅된 객체를 다시 만들 수 있습니다. 그런 다음, bcp 유틸리티를 사용하여 선택한 객체에 대한 데이터를 대상 DB 인스턴스로 대량으로 내보낼 수 있습니다. (테이블 이외의 객체를 포함한) 전체 데이터베이스를 이동하거나 두 SQL Server DB 인스턴스 사이에서 대량의 데이터를 이동하려는 경우에 이 마법사를 선택하는 것이 최선입니다. bcp 명령줄 구문에 대한 전체 설명은 Microsoft SQL Server 문서의 [bcp 유틸리티](http://msdn.microsoft.com/en-us/library/ms162802%28v=sql.110%29.aspx)를 참조하십시오.
SQL Server 스크립트 생성 및 게시 마법사는 Microsoft SQL Server Management Studio의 일부로 제공됩니다. 이 그래픽 SQL Server 클라이언트는 Express Edition을 제외한 모든 Microsoft SQL Server 버전에 포함됩니다. SQL Server Management Studio는 Windows 기반 애플리케이션으로만 사용할 수 있습니다. SQL Server Management Studio Express는 Microsoft에서 [무료 다운로드](http://www.microsoft.com/en-us/search/Results.aspx?q=sql%20server%20management%20studio)로 사용할 수 있습니다.
**SQL Server 스크립트 생성 및 게시 마법사와 bcp 유틸리티를 사용하여 데이터를 내보내려면**
1. SQL Server Management Studio에서 RDS for SQL Server DB 인스턴스에 연결합니다. 이 작업을 수행하는 자세한 방법은 [Microsoft SQL Server DB 인스턴스에 연결](USER_ConnectToMicrosoftSQLServerInstance.md) 단원을 참조하십시오.
1. [**개체 탐색기**]에서 [**데이터베이스**] 노드를 확장하고 스크립팅하려는 데이터베이스를 선택합니다.
1. 스크립트 파일을 만들려면 SQL Server 문서의 [스크립트 생성 및 게시 마법사](http://msdn.microsoft.com/en-us/library/bb895179%28v=sql.110%29.aspx)에 설명되어 있는 지침을 따르십시오.
1. SQL Server Management Studio에서 대상 SQL Server DB 인스턴스에 연결합니다.
1. **객체 탐색기(Object Explorer)**에서 대상 SQL Server DB 인스턴스를 선택한 상태에서 **파일(File)** 메뉴에서 **열기(Open)**를 선택하고, **파일(File)**을 선택한 후 스크립트 파일을 엽니다.
1. 전체 데이터베이스를 스크립팅한 경우 스크립트에서 CREATE DATABASE 문을 검토하십시오. 데이터베이스가 원하는 위치 및 파라미터로 작성되고 있는지 확인하십시오. 자세한 정보는 SQL Server 문서의 [CREATE DATABASE](http://msdn.microsoft.com/en-us/library/ms176061%28v=sql.110%29.aspx)를 참조하십시오.
1. 스크립트에서 데이터베이스 사용자를 만들 경우 대상 DB 인스턴스에 해당 사용자에 대한 서버 로그인이 존재하는지 확인합니다. 존재하지 않을 경우 해당 사용자에 대한 로그인을 만듭니다. 그렇지 않으면, 데이터베이스 사용자를 만들기 위해 스크립팅된 명령이 실패합니다. 자세한 정보는 SQL Server 문서의 [로그인 생성](http://msdn.microsoft.com/en-us/library/aa337562%28v=sql.110%29.aspx)을 참조하십시오.
1. SQL 편집기 메뉴에서 **\$1Execute**를 선택하여 스크립트 파일을 실행하고 데이터베이스 개체를 생성합니다. 스크립트가 완료되면 모든 데이터베이스 개체가 예상한 대로 존재하는지 확인합니다.
1. bcp 유틸리티를 사용하여 RDS for SQL Server DB 인스턴스에서 파일로 데이터를 내보냅니다. 명령 프롬프트를 열고 다음 명령을 입력합니다.
```
bcp database_name.schema_name.table_name out data_file -n -S aws_rds_sql_endpoint -U username -P password
```
앞에 나온 코드에는 다음 옵션이 포함됩니다.
+ *table\$1name*은 대상 데이터베이스에서 다시 만들어 이제 데이터를 채우려는 테이블 중 하나의 이름입니다.
+ *data\$1file*은 만들 데이터 파일의 전체 경로와 이름입니다.
+ `-n`은 대량 복사에서 복사되는 데이터의 기본 데이터 형식을 사용할 것임을 지정합니다.
+ `-S`는 데이터를 내보낼 원본 SQL Server DB 인스턴스를 지정합니다.
+ `-U`는 SQL Server DB 인스턴스에 연결할 때 사용할 사용자 이름을 지정합니다.
+ `-P`는 로 지정된 사용자의 암호를 지정합니다.`-U`
다음은 명령의 예시입니다.
```
bcp world.dbo.city out C:\Users\JohnDoe\city.dat -n -S sql-jdoe.1234abcd.us-west-2.rds.amazonaws.com,1433 -U JohnDoe -P ClearTextPassword
```
내보낼 모든 테이블에 대한 데이터 파일을 확보할 때까지 이 단계를 반복하십시오.
1. SQL Server 문서의 [대량 데이터 가져오기 준비](http://msdn.microsoft.com/en-us/library/ms189989%28v=sql.110%29.aspx)에 설명되어 있는 지침에 따라 대량 데이터 가져오기를 위해 대상 DB 인스턴스를 준비하십시오.
1. SQL Server 문서의 [대량 가져오기 및 내보내기 작업 정보](http://msdn.microsoft.com/en-us/library/ms187042%28v=sql.105%29.aspx)에 설명되어 있는 성능 및 기타 문제를 고려한 후 사용할 대량 가져오기 방법을 결정하십시오.
1. bcp 유틸리티를 사용하여 생성한 데이터 파일에서 데이터를 대량으로 가져옵니다. 그러려면 11단계에서 결정한 바에 따라, SQL Server 문서의 [bcp 유틸리티를 사용하여 대량 데이터 가져오기 및 내보내기](http://msdn.microsoft.com/en-us/library/aa337544%28v=sql.110%29.aspx) 또는 [BULK INSERT 또는 OPENROWSET(BULK...)를 사용하여 대량 데이터 가져오기](http://msdn.microsoft.com/en-us/library/ms175915%28v=sql.110%29.aspx)에 설명되어 있는 지침에 따르십시오.
# Linux의 BCP 유틸리티를 사용하여 데이터 가져오기 및 내보내기
Bulk Copy Program(BCP) 유틸리티는 RDS for SQL Server DB 인스턴스와 데이터 파일 간에 대량의 데이터를 전송하는 효율적인 방법을 제공합니다. Linux 환경의 BCP를 사용하여 일괄 데이터 작업을 수행할 수 있으므로 데이터 마이그레이션, ETL 프로세스 및 정기적인 데이터 전송에 유용합니다.
BCP는 파일에서 SQL Server 테이블로 데이터를 가져오고 SQL Server 테이블에서 파일로 데이터를 내보내는 것을 모두 지원합니다. 이는 구분된 텍스트 파일을 포함한 다양한 형식의 정형 데이터를 전송하는 데 특히 효과적입니다.
## 사전 조건
Linux에서 RDS for SQL Server DB 인스턴스와 함께 BCP를 사용하기 전에 다음 사항이 있는지 확인합니다.
+ RDS for SQL Server DB 인스턴스에 네트워크로 연결된 Linux 환경
+ 다음을 포함하여 Linux 시스템에 설치된 Microsoft SQL Server 명령줄 도구:
+ sqlcmd - SQL Server 명령줄 쿼리 도구
+ bcp - Bulk Copy Program 유틸리티
+ RDS for SQL Server DB 인스턴스에 유효한 자격 증명
+ SQL Server 포트(일반적으로 1433)에서 연결을 허용하도록 보안 그룹을 통해 구성된 네트워크 액세스
+ 수행하려는 작업에 대한 적절한 데이터베이스 권한
## Linux에 SQL Server 명령줄 도구 설치
Linux의 BCP를 사용하려면 Microsoft SQL Server 명령줄 도구를 설치해야 합니다. 특정 Linux 배포에 대한 자세한 설치 지침은 다음 Microsoft 설명서를 참조하세요.
+ [Install sqlcmd and bcp the SQL Server command-line tools on Linux](https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-setup-tools)
+ [bcp utility](https://docs.microsoft.com/en-us/sql/tools/bcp-utility) - BCP 유틸리티에 대한 전체 참조 문서
설치 후 다음을 실행하여 PATH에서 도구를 사용할 수 있는지 확인합니다.
```
bcp -v
sqlcmd -?
```
## RDS for SQL Server에서 데이터 내보내기
BCP를 사용하여 RDS for SQL Server DB 인스턴스의 데이터를 Linux 시스템의 파일로 내보낼 수 있습니다. 이는 백업 생성, 데이터 분석 또는 마이그레이션을 위한 데이터 준비에 유용합니다.
### 기본 내보내기 구문
BCP를 사용하여 데이터를 내보내는 기본 구문은 다음과 같습니다.
```
bcp database.schema.table out output_file -S server_name -U username -P password [options]
```
위치:
+ `database.schema.table` - 정규화된 테이블 이름
+ `output_file` - 출력 파일의 경로 및 이름
+ `server_name` - RDS for SQL Server 엔드포인트
+ `username` - 데이터베이스 사용자 이름
+ `password` - 데이터베이스 암호
### 내보내기 예시
다음 예시에서는 `sales` 데이터베이스의 `customers` 테이블에서 데이터를 내보냅니다.
```
bcp sales.dbo.customers out /home/user/customers.txt \
-S mydb.cluster-abc123.us-east-1.rds.amazonaws.com \
-U admin \
-P mypassword \
-c \
-t "|" \
-r "\n"
```
이 명령은 다음을 수행합니다.
+ `customers` 테이블에서 데이터 내보내기
+ 출력을 `/home/user/customers.txt`에 저장
+ 문자 형식(`-c`) 사용
+ 파이프(\$1)를 필드 구분 기호(`-t "|"`)로 사용
+ 줄 바꿈을 행 구분 기호(`-r "\n"`)로 사용
## RDS for SQL Server로 데이터 가져오기
BCP를 사용하여 Linux 시스템의 파일에서 RDS for SQL Server DB 인스턴스로 데이터를 가져올 수 있습니다. 이는 데이터 마이그레이션, 테스트 데이터 로드 또는 정기적인 데이터 업데이트에 유용합니다.
### 기본 가져오기 구문
BCP를 사용하여 데이터를 가져오는 기본 구문은 다음과 같습니다.
```
bcp database.schema.table in input_file -S server_name -U username -P password [options]
```
위치:
+ `database.schema.table` - 정규화된 대상 테이블 이름
+ `input_file` - 입력 파일의 경로 및 이름
+ `server_name` - RDS for SQL Server 엔드포인트
+ `username` - 데이터베이스 사용자 이름
+ `password` - 데이터베이스 암호
### 가져오기 예시
다음 예시에서는 파일에서 `customers` 테이블로 데이터를 가져옵니다.
```
bcp sales.dbo.customers in /home/user/customers.txt \
-S mydb.cluster-abc123.us-east-1.rds.amazonaws.com \
-U admin \
-P mypassword \
-c \
-t "|" \
-r "\n" \
-b 1000
```
이 명령은 다음을 수행합니다.
+ 데이터를 `customers` 테이블로 가져오기
+ `/home/user/customers.txt`에서 데이터를 읽습니다.
+ 문자 형식(`-c`) 사용
+ 파이프(\$1)를 필드 구분 기호(`-t "|"`)로 사용
+ 줄 바꿈을 행 구분 기호(`-r "\n"`)로 사용
+ 1,000개 행의 배치로 데이터 처리(`-b 1000`)
## 일반적인 BCP 옵션
BCP는 데이터 형식 지정 및 전송 동작을 제어하는 다양한 옵션을 제공합니다. 다음 표에 일반적으로 사용되는 옵션이 설명되어 있습니다.
| 옵션 | 설명 |
| --- | --- |
| -c | 모든 열에 문자 데이터 유형 사용 |
| -n | 기본 데이터베이스 데이터 유형 사용 |
| -t | 필드 구분 기호 지정(기본값은 탭) |
| -r | 행 구분 기호 지정(기본값은 줄 바꿈) |
| -b | 일괄 작업의 배치 크기 지정 |
| -F | 내보내거나 가져올 첫 번째 행 지정 |
| -L | 내보내거나 가져올 마지막 행 지정 |
| -e | 거부된 행을 캡처할 오류 파일 지정 |
| -f | 데이터 형식 지정을 위한 형식 파일 지정 |
| -q | 객체 이름에 따옴표로 묶인 식별자 사용 |
## 모범 사례 및 고려 사항
Linux에서 RDS for SQL Server와 함께 BCP를 사용하는 경우 다음 모범 사례를 고려하세요.
+ **배치 처리 사용** - 대규모 데이터세트의 경우 `-b` 옵션을 사용하여 데이터를 배치로 처리합니다. 이렇게 하면 성능이 개선되고 오류 복구가 개선됩니다.
+ **적절한 오류 처리** - `-e` 옵션을 사용하여 분석을 위해 오류 정보와 거부된 행을 별도의 파일로 캡처합니다.
+ **적절한 데이터 형식 선택** - 교차 플랫폼 호환성을 위해 문자 형식(`-c`)을 사용하거나 소스와 대상이 모두 SQL Server인 경우 더 나은 성능을 위해 기본 형식(`-n`)을 사용합니다.
+ **자격 증명 보호** - 암호를 명령줄에 직접 입력하지 마세요. 적절한 권한이 있는 환경 변수 또는 구성 파일을 사용하는 것이 좋습니다.
+ **작은 데이터세트로 테스트** - 대량의 데이터를 처리하기 전에 작은 데이터세트로 BCP 명령을 테스트하여 형식 지정 및 연결을 확인합니다.
+ **네트워크 연결 모니터링** - 특히 대규모 데이터 전송의 경우 안정적인 네트워크 연결을 보장합니다. 장기 실행 작업에는 `screen` 또는 `tmux`와 같은 도구를 사용하는 것이 좋습니다.
+ **데이터 무결성 검증** - 데이터 전송 후 행 수와 샘플 데이터를 확인하여 작업이 성공적으로 완료되었는지 확인합니다.
## 일반적인 문제 해결
다음 표에는 Linux의 BCP 및 해당 솔루션을 사용할 때 발생할 수 있는 일반적인 문제가 설명되어 있습니다.
| 문제 | Solution |
| --- | --- |
| 연결 제한 시간 초과 또는 네트워크 오류 | Amazon RDS 엔드포인트, 보안 그룹 설정 및 네트워크 연결을 확인합니다. Linux 시스템에서 SQL Server 포트(일반적으로 1433)에 액세스할 수 있는지 확인합니다. |
| 인증 실패 횟수 | 사용자 이름과 암호를 확인합니다. 데이터베이스 사용자에게 수행 중인 작업에 대한 적절한 권한이 있는지 확인합니다. |
| 데이터 형식 오류 | 필드와 행 구분 기호를 확인합니다. 데이터 형식이 BCP에서 요구하는 것과 일치하는지 확인합니다. 복잡한 데이터 구조에 형식 파일을 사용합니다. |
| 권한 거부 오류 | 데이터베이스 사용자에게 대상 테이블에 대한 가져오기의 경우 INSERT 권한, 내보내기의 경우 SELECT 권한이 있는지 확인합니다. |
| 대용량 파일 처리 문제 | -b 옵션과 함께 배치 처리를 사용합니다. 성능 향상 및 오류 복구를 위해 대용량 파일을 더 작은 묶음으로 분할하는 것이 좋습니다. |
| 문자 인코딩 문제 | 데이터 파일이 호환되는 문자 인코딩을 사용하는지 확인합니다. 문자 형식에 -c 옵션을 사용하거나 적절한 코드 페이지를 지정합니다. |
# Amazon RDS에서 Microsoft SQL Server용 읽기 전용 복제본 작업
일반적으로 읽기 전용 복제본을 사용하여 Amazon RDS DB 인스턴스 간 복제를 구성합니다. 읽기 전용 복제본에 대한 일반적인 정보는 [DB 인스턴스 읽기 전용 복제본 작업](USER_ReadRepl.md) 단원을 참조하십시오.
이 단원에서는 Amazon RDS for SQL Server의 읽기 전용 복제본 작업에 대한 특정 정보를 찾을 수 있습니다.
+ [데이터베이스 사용자 및 객체를 SQL Server 읽기 전용 복제본과 동기화](SQLServer.ReadReplicas.ObjectSynchronization.md)
+ [SQL Server 읽기 전용 복제본 문제 해결](SQLServer.ReadReplicas.Troubleshooting.md)
## SQL Server용 읽기 전용 복제본 구성
DB 인스턴스를 복제용 원본 인스턴스로 사용하려면 원본 DB 인스턴스의 자동 백업을 활성화해야 합니다. 이렇게 하려면 백업 보존 기간을 0 이외의 값으로 설정합니다. 이 유형의 배포를 설정하면 자동 백업도 강제로 활성화됩니다.
SQL Server 읽기 복제본을 만들 때 기본 DB 인스턴스의 운영 중단이 필요하지 않습니다. Amazon RDS는 서비스 중단 없이 소스 DB 및 읽기 전용 복제본에 필요한 파라미터와 권한을 설정합니다. 원본 DB 인스턴스를 캡처한 스냅샷이 읽기 전용 복제본이 됩니다. 읽기 전용 복제본을 삭제하더라도 중단은 발생하지 않습니다.
원본 DB 인스턴스 하나에서 최대 15개까지 읽기 전용 복제본을 생성할 수 있습니다. 효과적인 복제를 위해서는 읽기 전용 복제본도 각각 소스 DB 인스턴스와 동일한 양의 컴퓨팅 및 스토리지 리소스를 갖도록 구성해야 합니다. 원본 DB 인스턴스를 확장하는 경우 읽기 전용 복제본도 확장합니다.
소스 DB 인스턴스의 SQL Server DB 엔진 버전과 모든 읽기 전용 복제본은 동일해야 합니다. Amazon RDS는 유지 관리 기간과 상관없이 읽기 전용 복제본을 업그레이드한 후 즉시 기본 인스턴스를 업그레이드합니다. DB 엔진 버전 업그레이드에 대한 자세한 내용은 [Microsoft SQL Server DB 엔진 업그레이드](USER_UpgradeDBInstance.SQLServer.md) 단원을 참조하세요.
읽기 전용 복제본이 원본에서 변경 사항을 받아 적용하려면 충분한 컴퓨팅 및 스토리지 리소스가 있어야 합니다. 읽기 전용 복제본이 컴퓨팅, 네트워크 또는 스토리지 리소스 용량에 도달하면 읽기 전용 복제본은 해당 원본에서 변경 사항을 수신하거나 적용하는 것을 중지합니다. 읽기 전용 복제본의 스토리지 및 CPU 리소스를 해당 원본 및 다른 읽기 전용 복제본과 별도로 수정할 수 있습니다.
읽기 전용 복제본 생성 방법에 대한 자세한 내용은 [읽기 전용 복제본 생성](USER_ReadRepl.Create.md) 섹션을 참조하세요.
## SQL Server의 읽기 전용 복제본 제한 사항
Amazon RDS의 SQL Server 읽기 전용 복제본에는 다음 제한 사항이 적용됩니다.
+ 읽기 전용 복제본은 SQL Server Enterprise Edition(EE) 엔진에서만 사용할 수 있습니다.
+ 읽기 복제본은 SQL Server 버전 2016\$12022에서 사용할 수 있습니다.
+ 원본 DB 인스턴스 하나에서 최대 15개까지 읽기 전용 복제본을 생성할 수 있습니다. 소스 DB 인스턴스에 읽기 전용 복제본이 5개 이상인 경우 복제가 지연될 수 있습니다.
+ 읽기 전용 복제본은 4개 이상의 vCPU가 있는 DB 인스턴스 클래스에서 실행되는 DB 인스턴스에만 사용할 수 있습니다.
+ 읽기 전용 복제본은 인스턴스 클래스 유형 및 가용성 모드에 따라 최대 100개의 데이터베이스를 지원합니다. 읽기 전용 복제본으로 자동 복제하려면 소스 DB 인스턴스에 데이터베이스를 생성해야 합니다. 복제할 데이터베이스를 하나씩 선택할 수는 없습니다. 자세한 내용은 [Microsoft SQL Server DB 인스턴스의 한도](CHAP_SQLServer.md#SQLServer.Concepts.General.FeatureSupport.Limits) 섹션을 참조하세요.
+ 읽기 전용 복제본에서 데이터베이스를 삭제할 수 없습니다. 데이터베이스를 삭제하려면 `rds_drop_database` 저장 프로시저를 통해 소스 DB 인스턴스에서 삭제합니다. 자세한 내용은 [Amazon RDS for Microsoft SQL Server DB 인스턴스 데이터베이스 삭제](Appendix.SQLServer.CommonDBATasks.DropMirrorDB.md) 섹션을 참조하세요.
+ 소스 DB 인스턴스가 Transparent Data Encryption(TDE)을 사용하는 경우 읽기 전용 복제본 역시 TDE를 자동으로 구성합니다.
소스 DB 인스턴스가 KMS 키를 사용하여 데이터를 암호화할 경우 동일한 리전의 읽기 전용 복제본은 동일한 KMS 키를 사용합니다. 크로스 리전 읽기 전용 복제본의 경우 읽기 전용 복제본을 생성할 때 읽기 전용 복제본의 리전에서 KMS 키를 지정해야 합니다. 읽기 전용 복제본의 KMS는 변경할 수 없습니다.
+ 읽기 전용 복제본은 생성된 가용 영역에 상관없이 소스 DB 인스턴스와 동일한 시간대 및 데이터 정렬 기준을 갖습니다.
+ 다음은 Amazon RDS for SQL Server에서 지원되지 않습니다.
+ 읽기 전용 복제본의 백업 보존
+ 읽기 전용 복제본의 특정 시점으로 복구
+ 읽기 전용 복제본의 수동 스냅샷
+ 다중 AZ 읽기 전용 복제본
+ 읽기 전용 복제본의 읽기 전용 복제본 생성
+ 읽기 전용 복제본에 대한 사용자 로그인 동기화
+ Amazon RDS for SQL Server는 개입을 통해 원본 DB 인스턴스와 해당 읽기 전용 복제본 간의 긴 복제본 지연 시간을 완화하지 않습니다. 원본 DB 인스턴스와 해당 읽기 전용 복제본이 운영 로드에 맞게 컴퓨팅 파워 및 스토리지 면에서 제대로 크기가 조정되었는지 확인합니다.
+ AWS GovCloud(미국 동부) 리전과 AWS GovCloud(미국-서부) 리전 간에 복제할 수 있지만 AWS GovCloud (US) Regions 내부 또는 외부로 복제할 수는 없습니다.
## RDS for SQL Server 복제본에 대한 옵션 고려 사항
RDS for SQL Server 복제본을 생성하기 전에 다음 요구 사항, 제한 사항 및 권장 사항을 확인하세요.
+ SQL Server 복제본이 소스 DB 인스턴스와 동일한 리전에 있는 경우 해당 복제본이 원본 DB 인스턴스와 동일한 옵션 그룹에 속해 있는지 확인하세요. 원본 옵션 그룹 또는 원본 옵션 그룹 멤버십에 대한 수정 사항은 복제본으로 전파됩니다. 이러한 변경 사항은 복제본의 유지 관리 기간과 상관없이 원본 DB 인스턴스에 적용된 직후 복제본에 적용됩니다.
옵션 그룹에 대한 자세한 내용은 [옵션 그룹 작업](USER_WorkingWithOptionGroups.md) 단원을 참조하십시오.
+ SQL Server 리전 간 복제본을 생성하면 Amazon RDS가 전용 옵션 그룹을 생성합니다.
전용 옵션 그룹에서 SQL Server 리전 간 복제본을 제거할 수 없습니다. 다른 DB 인스턴스는 SQL Server 리전 간 복제본에 전용 옵션 그룹을 사용할 수 없습니다.
다음 옵션은 복제된 옵션입니다. SQL Server 리전 간 읽기 전용 복제본에 복제된 옵션을 추가하려면 원본 DB 인스턴스의 옵션 그룹에 추가하세요. 이 옵션은 모든 원본 DB 인스턴스의 복제본에도 설치됩니다.
+ `TDE`
다음 옵션은 복제되지 않은 옵션입니다. 전용 옵션 그룹에 복제되지 않은 옵션을 추가하거나 제거할 수 있습니다.
+ `MSDTC`
+ `SQLSERVER_AUDIT`
+ 리전 간 읽기 전용 복제본에서 `SQLSERVER_AUDIT` 옵션을 활성화하려면 리전 간 읽기 전용 복제본의 전용 옵션 그룹과 원본 인스턴스의 옵션 그룹에 `SQLSERVER_AUDIT` 옵션을 추가하세요. SQL Server 리전 간 읽기 전용 복제본의 원본 인스턴스에 `SQLSERVER_AUDIT` 옵션을 추가하면 원본 인스턴스의 각 리전 간 읽기 전용 복제본에 서버 수준 감사 객체 및 서버 수준 감사 사양을 생성할 수 있습니다. 리전 간 읽기 전용 복제본에 액세스하여 완성된 감사 로그를 Amazon S3 버킷에 업로드할 수 있도록 하려면 전용 옵션 그룹에 `SQLSERVER_AUDIT` 옵션을 추가하고 옵션 설정을 구성하세요. 감사 파일의 대상으로 사용하는 Amazon S3 버킷은 리전 간 읽기 전용 복제본과 같은 리전에 있어야 합니다. 각 리전 간 읽기 전용 복제본에 대한 `SQLSERVER_AUDIT` 옵션의 옵션 설정을 개별적으로 수정하여 각 읽기 전용 복제본이 해당 리전의 Amazon S3 버킷에 액세스하도록 할 수 있습니다.
다음 옵션은 읽기 전용 복제본에서 지원되지 않습니다.
+ `SSRS`
+ `SSAS`
+ `SSIS`
다음 옵션은 리전 간 읽기 전용 복제본에서 부분적으로 지원됩니다.
+ `SQLSERVER_BACKUP_RESTORE`
+ SQL Server 리전 간 복제본의 원본 DB 인스턴스에는 `SQLSERVER_BACKUP_RESTORE` 옵션이 있을 수 있지만 원본 DB 인스턴스의 모든 리전 간 복제본을 삭제하기 전에는 원본 DB 인스턴스에서 기본 복원을 수행할 수 없습니다. 리전 간 복제본을 생성하는 동안 기존의 모든 기본 복원 작업이 취소됩니다. 전용 옵션 그룹에는 `SQLSERVER_BACKUP_RESTORE` 옵션을 추가할 수 없습니다.
기본 백업 및 복원에 대한 자세한 내용은 [기본 백업 및 복원 기능을 사용하여 SQL Server 데이터베이스 가져오기 및 내보내기](SQLServer.Procedural.Importing.md) 섹션을 참조하세요.
SQL Server 리전 간 읽기 전용 복제본을 승격하면 승격된 복제본은 옵션 관리를 포함해 다른 SQL Server DB 인스턴스와 동일하게 작동합니다. 옵션 그룹에 대한 자세한 내용은 [옵션 그룹 작업](USER_WorkingWithOptionGroups.md) 단원을 참조하세요.
# 데이터베이스 사용자 및 객체를 SQL Server 읽기 전용 복제본과 동기화
읽기 전용 복제본을 생성할 때 프라이머리 DB 인스턴스에 있는 모든 로그인, 사용자 지정 서버 역할, SQL 에이전트 작업 또는 기타 서버 수준 객체가 새로 생성된 읽기 전용 복제본에 있어야 합니다. 하지만 읽기 전용 복제본을 생성한 후에 프라이머리 DB 인스턴스에 생성된 서버 수준 객체는 자동으로 복제되지 않으므로 읽기 전용 복제본에서 수동으로 생성해야 합니다.
데이터베이스 사용자는 프라이머리 DB 인스턴스에서 읽기 전용 복제본으로 자동 복제됩니다. 읽기 전용 복제본 데이터베이스는 읽기 전용 모드이므로 데이터베이스 사용자의 보안 식별자(SID)를 데이터베이스에서 업데이트할 수 없습니다. 따라서 읽기 전용 복제본에서 SQL 로그인을 생성할 때는 해당 로그인의 SID가 프라이머리 DB 인스턴스의 해당 SQL 로그인 SID와 일치하는지 확인해야 합니다. SQL 로그인의 SID를 동기화하지 않으면 읽기 전용 복제본의 데이터베이스에 액세스할 수 없습니다. Windows Active Directory(AD) 인증 로그인은 SQL Server가 Active Directory에서 SID를 가져오기 때문에 이 문제가 발생하지 않습니다.
**프라이머리 DB 인스턴스에서 읽기 전용 복제본으로 SQL 로그인 동기화**
1. 프라이머리 DB 인스턴스에 연결합니다.
1. 프라이머리 DB 인스턴스에 새 SQL 로그인을 생성합니다.
```
USE [master]
GO
CREATE LOGIN TestLogin1
WITH PASSWORD = 'REPLACE WITH PASSWORD';
```
**참고**
보안 모범 사례로 여기에 표시된 프롬프트 이외의 암호를 지정하는 것이 좋습니다.
1. 데이터베이스에 SQL 로그인을 위한 새 데이터베이스 사용자를 생성합니다.
```
USE [REPLACE WITH YOUR DB NAME]
GO
CREATE USER TestLogin1 FOR LOGIN TestLogin1;
GO
```
1. 프라이머리 DB 인스턴스에서 새로 생성한 SQL 로그인의 SID를 확인합니다.
```
SELECT name, sid FROM sys.server_principals WHERE name = 'TestLogin1';
```
1. 읽기 전용 복제본에 연결합니다. 새 SQL 로그인을 생성합니다.
```
CREATE LOGIN TestLogin1 WITH PASSWORD = 'REPLACE WITH PASSWORD', SID=REPLACE WITH sid FROM STEP #4;
```
**또는 읽기 전용 복제본 데이터베이스에 액세스할 수 있는 경우 다음과 같이 분리된 사용자를 수정할 수 있습니다.**
1. 읽기 전용 복제본에 연결합니다.
1. 데이터베이스에서 분리된 사용자를 식별합니다.
```
USE [REPLACE WITH YOUR DB NAME]
GO
EXEC sp_change_users_login 'Report';
GO
```
1. 분리된 데이터베이스 사용자를 위한 새 SQL 로그인을 생성합니다.
```
CREATE LOGIN TestLogin1 WITH PASSWORD = 'REPLACE WITH PASSWORD', SID=REPLACE WITH sid FROM STEP #2;
```
예제:
```
CREATE LOGIN TestLogin1 WITH PASSWORD = 'TestPa$$word#1', SID=0x1A2B3C4D5E6F7G8H9I0J1K2L3M4N5O6P;
```
**참고**
보안 모범 사례로 여기에 표시된 프롬프트 이외의 암호를 지정하는 것이 좋습니다.
# SQL Server 읽기 전용 복제본 문제 해결
Amazon CloudWatch에서 Amazon RDS `ReplicaLag` 지표를 보고 복제 지연을 모니터링할 수 있습니다. 복제 지연 시간에 대한 자세한 내용은 [읽기 전용 복제본 모니터링](USER_ReadRepl.Monitoring.md) 단원을 참조하십시오.
복제 지연 시간이 너무 긴 경우 다음 쿼리를 사용하여 지연 시간에 대한 정보를 얻을 수 있습니다.
```
SELECT AR.replica_server_name
, DB_NAME (ARS.database_id) 'database_name'
, AR.availability_mode_desc
, ARS.synchronization_health_desc
, ARS.last_hardened_lsn
, ARS.last_redone_lsn
, ARS.secondary_lag_seconds
FROM sys.dm_hadr_database_replica_states ARS
INNER JOIN sys.availability_replicas AR ON ARS.replica_id = AR.replica_id
--WHERE DB_NAME(ARS.database_id) = 'database_name'
ORDER BY AR.replica_server_name;
```
# Amazon RDS for Microsoft SQL Server의 다중 AZ 배포
다중 AZ 배포는 DB 인스턴스를 위해 향상된 가용성, 데이터 내구성 및 내결함성을 제공합니다. 계획된 데이터베이스 유지 관리 또는 예기치 않은 서비스 중단이 발생할 경우, Amazon RDS가 최신 보조 DB 인스턴스로 자동으로 장애 조치를 수행합니다. 이 기능을 통해 수동 개입 없이 데이터베이스 작업을 빠르게 재개할 수 있습니다. 기본 인스턴스 및 예비 인스턴스는 동일한 엔드포인트를 사용합니다. 이 엔드포인트의 물리적 네트워크 주소는 장애 조치 프로세스의 일환으로 보조 복제본으로 전환됩니다. 장애 조치가 발생하는 경우 애플리케이션을 다시 구성할 필요가 없습니다.
Amazon RDS는 SQL Server 데이터베이스 미러링(DBM), 상시 가동 가용성 그룹(AG) 또는 블록 수준 복제를 사용하여 Microsoft SQL Server에 대한 다중 AZ 배포를 지원합니다. Amazon RDS는 다중 AZ 배포의 상태를 모니터링하고 유지합니다. 문제가 발생하면 RDS는 이상 있는 DB 인스턴스를 복구하고, 동기화를 재설정하며, 장애 조치를 시작합니다. 대기 및 기본 인스턴스가 완벽히 동기화되어 있는 경우에만 장애 조치가 이루어집니다. 사용자가 따로 관리할 것이 없습니다.
SQL Server 다중 AZ를 설정하면 RDS는 인스턴스의 모든 데이터베이스를 DBM, AG 또는 블록 수준 복제를 사용하도록 자동으로 구성합니다. Amazon RDS는 DBM 또는 AG를 구성할 때 프라이머리, 감시 및 세컨더리 DB 인스턴스를 자동으로 처리합니다. 블록 수준 복제의 경우 RDS는 기본 및 보조 DB 인스턴스를 처리합니다. 구성이 자동으로 이루어지므로 RDS는 배포하는 SQL Server 버전에 따라 DBM, 상시 가동 AG 또는 블록 수준 복제를 선택합니다.
Amazon RDS는 다음 SQL Server 버전에 상시 가동 AG를 통한 다중 AZ를 지원합니다.
+ SQL Server 2022:
+ Standard Edition
+ Enterprise Edition
+ SQL Server 2019:
+ Standard Edition 15.00.4073.23 이상
+ Enterprise Edition
+ SQL Server 2017:
+ Standard Edition 14.00.3401.7 이상
+ Enterprise Edition 14.00.3049.1 이상
+ SQL Server 2016: Enterprise Edition 13.00.5216.0 이상
Amazon RDS는 앞서 언급한 버전을 제외한 다음 SQL Server 버전에 대해 DBM를 통한 다중 AZ를 지원합니다.
+ SQL Server 2019: Standard Edition 15.00.4043.16
+ SQL Server 2017: Standard 및 Enterprise Edition
+ SQL Server 2016: Standard 및 Enterprise Edition
Amazon RDS는 SQL Server 2022 Web Edition 16.00.4215.2 이상에 대한 블록 수준 복제를 통해 다중 AZ를 지원합니다.
**참고**
16.00.4215.2 이상으로 생성된 새 DB 인스턴스만 블록 수준 복제를 통한 다중 AZ 배포를 지원합니다. 기존 SQL Server 2022 Web Edition 인스턴스에는 다음 제한이 적용됩니다.
버전 16.00.4215.2의 기존 인스턴스의 경우 블록 수준 복제를 활성화하려면 마이너 버전이 동일하거나 더 높은 새 인스턴스로 스냅샷을 복원해야 합니다.
이전 마이너 버전의 SQL Server 2022 웹 인스턴스를 마이너 버전 16.00.4215.2 이상으로 업그레이드하여 블록 수준 복제를 활성화할 수 있습니다.
다음 SQL 쿼리를 사용하여 SQL Server DB 인스턴스가 단일 AZ, DBM 기능이 있는 다중 AZ 또는 상시 가동 AG 기능이 있는 다중 AZ인지 확인할 수 있습니다. 이 쿼리는 SQL Server Web Edition의 다중 AZ 배포에는 적용되지 않습니다.
```
SELECT CASE WHEN dm.mirroring_state_desc IS NOT NULL THEN 'Multi-AZ (Mirroring)'
WHEN dhdrs.group_database_id IS NOT NULL THEN 'Multi-AZ (AlwaysOn)'
ELSE 'Single-AZ'
END 'high_availability'
FROM sys.databases sd
LEFT JOIN sys.database_mirroring dm ON sd.database_id = dm.database_id
LEFT JOIN sys.dm_hadr_database_replica_states dhdrs ON sd.database_id = dhdrs.database_id AND dhdrs.is_local = 1
WHERE DB_NAME(sd.database_id) = 'rdsadmin';
```
출력은 다음과 유사합니다.
```
high_availability
Multi-AZ (AlwaysOn)
```
## 다중 AZ를 Microsoft SQL Server DB 인스턴스에 추가
AWS Management Console을 사용하여 SQL Server DB 인스턴스를 새로 생성할 때 데이터베이스 미러링(DBM), 상시 가동 AG 또는 블록 수준 복제를 사용하는 다중 AZ를 추가할 수 있습니다. **다중 AZ 배포**에서 **예(미러링/상시 가동/블록 수준 복제)**를 선택하면 됩니다. 자세한 내용은 [Amazon RDS DB 인스턴스 생성](USER_CreateDBInstance.md) 섹션을 참조하세요.
콘솔을 사용하여 기존 SQL Server DB 인스턴스를 수정할 때, **DB 인스턴스 수정** 페이지의 **다중 AZ 배포**에서 **예(미러링/상시 가동/블록 수준 복제)**를 선택하여 DBM, AG 또는 블록 수준 복제를 사용하는 다중 AZ를 추가할 수 있습니다. 자세한 내용은 [Amazon RDS DB 인스턴스 수정](Overview.DBInstance.Modifying.md) 섹션을 참조하세요.
**참고**
DB 인스턴스가 상시 작동 가용성 그룹(AG)이 아닌 데이터베이스 미러링(DBM)을 실행 중인 경우 다중 AZ를 추가하기 전에 인 메모리 최적화를 비활성화해야 할 수도 있습니다. DB 인스턴스에서 SQL Server 2016 또는 2017 Enterprise Edition을 실행하고 있으며 인 메모리 최적화가 활성화된 경우 다중 AZ를 추가하기 전에 DBM으로 인 메모리 최적화를 비활성화합니다.
DB 인스턴스가 SQL Server Web Edition에 대한 AG 또는 블록 수준 복제를 실행하는 경우 이 단계가 필요하지 않습니다.
## Microsoft SQL Server DB 인스턴스에서 다중 AZ 제거
AWS Management Console을 사용하여 기존 SQL Server DB 인스턴스를 수정할 때 DBM, AG 또는 블록 수준 복제를 사용한 다중 AZ를 제거할 수 있습니다. **DB 인스턴스 수정** 페이지의 **다중 AZ 배포**에서 **아니요(미러링/상시 가동/블록 수준 복제)**를 선택하면 됩니다. 자세한 내용은 [Amazon RDS DB 인스턴스 수정](Overview.DBInstance.Modifying.md) 섹션을 참조하세요.
# Microsoft SQL Server 다중 AZ 배포의 제한, 참고 및 권장 사항
다음은 RDS for SQL Server DB 인스턴스에서 다중 AZ 배포 작업 시 알아두어야 할 몇 가지 제한 사항입니다.
+ 교차 리전 다중 AZ는 지원되지 않습니다.
+ 다중 AZ 배포에서는 RDS for SQL Server DB 인스턴스를 중지할 수 없습니다.
+ 보조 DB 인스턴스가 데이터베이스 읽기 작업을 허용하도록 구성할 수 없습니다.
+ 상시 작동 가용성 그룹(AG)을 사용하는 다중 AZ는 인 메모리 최적화를 지원합니다.
+ 상시 작동 가용성 그룹(AG)이 있는 다중 AZ는 가용성 그룹 리스너에 대한 Kerberos 인증을 지원하지 않습니다. 이는 리스너에 SPN(서비스 보안 주체 이름)이 없기 때문입니다.
+ 블록 수준 복제가 포함된 다중 AZ는 현재 SQL Server Web Edition 인스턴스에서만 지원됩니다.
+ SQL Server 다중 AZ 배포에 있는 SQL Server DB 인스턴스의 데이터베이스는 이름을 변경할 수 없습니다. 그러한 인스턴스의 데이터베이스 이름을 바꿔야 하는 경우, 먼저 DB 인스턴스의 다중 AZ를 끈 후 데이터베이스 이름을 바꿉니다. 마지막으로 DB 인스턴스의 다중 AZ를 다시 켭니다.
+ 전체 복구 모델을 사용하여 백업한 다중 AZ DB 인스턴스만 복원할 수 있습니다.
+ 다중 AZ 배포에서는 SQL Server 에이전트 작업이 10,000개로 제한됩니다.
한도를 늘려야 할 경우 지원에 문의하여 할당량 증대를 요청하세요. [[지원 센터(AWS Support Center)](https://console.aws.amazon.com/support/home#/)] 페이지를 열고 필요한 경우, 로그인한 다음 [**사례 생성(Create Case)**]을 선택합니다. **Service Limit increase(서비스 한도 증가)**를 선택합니다. 양식을 작성하고 제출합니다.
+ SQL Server 다중 AZ 배포에 있는 SQL Server DB 인스턴스에 오프라인 데이터베이스를 가질 수 없습니다.
+ RDS for SQL Server는 보조 인스턴스에 MSDB 데이터베이스 권한을 복제하지 않습니다. 보조 인스턴스에서 이러한 권한이 필요한 경우 수동으로 다시 생성해야 합니다.
+ 블록 수준 복제를 사용하는 인스턴스의 보조 호스트에는 볼륨 지표를 사용할 수 없습니다.
다음은 RDS for SQL Server DB 인스턴스에서 다중 AZ 배포 작업 시 알아두어야 할 몇 가지 참고 사항입니다.
+ Amazon RDS는 상시 가동 AG [가용성 그룹 리스너 엔드포인트](https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/listeners-client-connectivity-application-failover)를 표시합니다. 이 엔드포인트는 콘솔에 표시되며, `DescribeDBInstances` API 작업에 의해 엔드포인트 필드의 항목으로 반환됩니다.
+ Amazon RDS는 [가용성 그룹 다중 서브넷 장애 조치](https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/listeners-client-connectivity-application-failover)를 지원합니다.
+ Virtual Private Cloud(VPC)에서 SQL Server DB 인스턴스와 함께 SQL Server 다중 AZ를 사용하려면 먼저 별개의 가용 영역 2개 이상에 서브넷이 있는 DB 서브넷 그룹을 만들어야 합니다. 그런 다음 SQL Server DB 인스턴스의 기본 복제본에 DB 서브넷 그룹을 할당합니다.
+ DB 인스턴스를 다중 AZ 배포로 수정할 때 수정하는 동안 인스턴스의 상태는 [**수정 중(modifying)**]입니다. Amazon RDS는 대기 인스턴스를 생성하고 프라이머리 DB 인스턴스를 백업합니다. 프로세스가 완료되면 기본 DB 인스턴스의 상태가 **사용 가능**이 됩니다.
+ 다중 AZ 배포가 같은 노드 상의 모든 데이터베이스를 유지 관리합니다. 기본 호스트의 데이터베이스가 장애 조치하는 경우, 모든 SQL Server 데이터베이스가 하나의 원자 단위로 대기 호스트로 장애 조치합니다. Amazon RDS는 새로운 정상 호스트를 프로비저닝하고 비정상 호스트를 대체합니다.
+ DBM, AG 또는 블록 수준 복제를 사용하는 다중 AZ는 단일 대기 복제본을 지원합니다.
+ 사용자, 로그인 및 권한은 보조에 자동으로 복제됩니다. 이를 다시 생성할 필요가 없습니다. 사용자 정의 서버 역할은 상시 가동 AG를 사용하는 DB 인스턴스 또는 다중 AZ 배포를 위한 블록 수준 복제에 복제됩니다.
+ 다중 AZ 배포에서 RDS for SQL Server는 SQL Server 로그인을 생성하여 상시 작동 AG 또는 데이터베이스 미러링을 허용합니다. RDS는 `db__node1_login`, `db__node2_login`, `db__witness_login` 패턴으로 로그인을 생성합니다.
+ RDS for SQL Server는 읽기 전용 복제본에 대한 액세스를 허용하기 위해 SQL Server 로그인을 생성합니다. RDS는 `db__node_login` 패턴으로 로그인을 생성합니다.
+ 다중 AZ 배포에서 SQL Server 에이전트 작업은 작업 복제 기능이 켜져 있을 때 기본 호스트에서 보조 호스트로 복제됩니다. 자세한 내용은 [SQL Server 에이전트 작업 복제 켜기](Appendix.SQLServer.CommonDBATasks.Agent.md#SQLServerAgent.Replicate)을 참조하세요.
+ 동기식 데이터 복제로 인해 단일 가용 영역에서 표준 DB 인스턴스 배포와 비교했을 때 지연 시간이 증가할 수 있습니다.
+ 장애 조치 시간은 복구 프로세스 완료에 걸리는 시간의 영향을 받습니다. 트랜잭션이 크면 장애 조치 시간이 늘어납니다.
+ SQL Server 다중 AZ 배포에서 장애 조치를 사용하여 재부팅하면 기본 DB 인스턴스만 재부팅됩니다. 장애 조치 후에는 기본 DB 인스턴스가 새 보조 DB 인스턴스가 됩니다. 다중 AZ 인스턴스의 경우 파라미터가 업데이트되지 않을 수 있습니다. 장애 조치 없이 재부팅하는 경우 기본 DB 인스턴스와 보조 DB 인스턴스가 모두 재부팅되고 재부팅된 후 파라미터가 업데이트됩니다. DB 인스턴스가 응답하지 않는 경우 장애 조치 없이 재부팅하는 것이 좋습니다.
다음은 RDS for Microsoft SQL Server DB 인스턴스에서 다중 AZ 배포 작업 시 알아두어야 할 몇 가지 권장 사항입니다.
+ 프로덕션 또는 프로덕션 이전 환경에서 사용되는 데이터베이스의 경우 다음 옵션을 권장합니다.
+ 고가용성을 위한 다중 AZ 배포
+ 빠르고 일관적인 성능을 위한 “프로비저닝된 IOPS”
+ “범용”이 아닌 “메모리 최적화”
+ 보조 인스턴스에 대해 가용 영역(AZ)을 선택할 수 없으므로 애플리케이션 호스트를 배포할 경우 이 점을 고려하십시오. 데이터베이스를 다른 AZ로 장애 조치할 수 있으며, 애플리케이션 호스트가 데이터베이스와 다른 AZ에 있을 수도 있습니다. 이러한 이유로 지정된 AWS 리전의 모든 AZ에서 애플리케이션 호스트의 균형을 조정하는 것이 좋습니다.
+ 최적의 성능을 위해서는 대규모 데이터 로드 작업 중에 데이터베이스 미러링, 상시 가동 AG 또는 블록 수준 복제를 활성화하지 않습니다. 데이터 로드를 최대한 빠르게 수행하려면 데이터 로드를 완료한 후에 DB 인스턴스를 다중 AZ 배포로 변환합니다.
+ SQL Server 데이터베이스에 액세스하는 애플리케이션에 연결 오류를 포착하는 예외 처리 기능이 있어야 합니다. 다음 코드 샘플에 통신 오류를 포착하는 try/catch 블록이 표시되어 있습니다. 이 예제에서 `break` 문은 연결에 성공하면 `while` 루프를 종료하지만 예외가 발생하면 10회까지 다시 시도합니다.
```
int RetryMaxAttempts = 10;
int RetryIntervalPeriodInSeconds = 1;
int iRetryCount = 0;
while (iRetryCount < RetryMaxAttempts)
{
using (SqlConnection connection = new SqlConnection(DatabaseConnString))
{
using (SqlCommand command = connection.CreateCommand())
{
command.CommandText = "INSERT INTO SOME_TABLE VALUES ('SomeValue');";
try
{
connection.Open();
command.ExecuteNonQuery();
break;
}
catch (Exception ex)
{
Logger(ex.Message);
iRetryCount++;
}
finally {
connection.Close();
}
}
}
Thread.Sleep(RetryIntervalPeriodInSeconds * 1000);
}
```
+ DBM 또는 AG를 사용하여 다중 AZ 인스턴스를 작업할 때는 `Set Partner Off` 명령을 사용하지 마세요. 블록 수준 복제를 사용하는 인스턴스에서는 이 명령이 지원되지 않습니다. 예를 들어 다음을 수행하지 마십시오.
```
--Don't do this
ALTER DATABASE db1 SET PARTNER off
```
+ 복구 모드를 `simple`로 설정하지 마십시오. 예를 들어 다음을 수행하지 마십시오.
```
--Don't do this
ALTER DATABASE db1 SET RECOVERY simple
```
+ 블록 레벨 복제를 통해 고가용성을 확보하는 경우가 아니라면, 멀티 AZ DB 인스턴스에서 새 로그인을 생성할 때 `DEFAULT_DATABASE` 파라미터를 사용하지 마세요. 이러한 설정은 대기 미러에 적용할 수 없기 때문입니다. 예를 들어 다음을 수행하지 마십시오.
```
--Don't do this
CREATE LOGIN [test_dba] WITH PASSWORD=foo, DEFAULT_DATABASE=[db2]
```
또한 다음 작업을 수행하지 마십시오.
```
--Don't do this
ALTER LOGIN [test_dba] WITH DEFAULT_DATABASE=[db3]
```
# 보조의 위치 확인
AWS Management Console을 사용하여 보조 복제본의 위치를 확인할 수 있습니다. VPC에서 기본 DB 인스턴스를 설정할 경우 보조의 위치를 알아야 합니다.
![\[보조 AZ\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/SQLSvr-MultiAZ.png)
AWS CLI 명령 `describe-db-instances` 또는 RDS API 작업 `DescribeDBInstances`를 사용하여 보조의 가용 영역을 확인할 수도 있습니다. 출력에는 대기 미러가 있는 보조 AZ가 표시됩니다.
# 데이터베이스 미러링에서 상시 작동 가용성 그룹으로 마이그레이션
Microsoft SQL Server Enterprise Edition의 14.00.3049.1 버전에서는 상시 작동 가용성 그룹(AG)이 기본적으로 사용됩니다.
데이터베이스 미러링(DBM)에서 AG로 마이그레이션하려면 먼저 버전을 확인하십시오. 버전이 13.00.5216.0 이전인 DB 인스턴스를 사용하는 경우, 13.00.5216.0으로 패치하도록 인스턴스를 수정합니다. Enterprise Edition 14.00.3049.1 이전 버전의 DB 인스턴스를 사용하는 경우, 14.00.3049.1 이상으로 패치하도록 인스턴스를 수정합니다.
AG를 사용하도록 미러링된 DB 인스턴스를 업그레이드하려면 먼저 업그레이드를 실행하고 다중 AZ를 제거하도록 인스턴스를 수정한 다음 다시 수정하여 다중 AZ를 추가하십시오. 그러면 인스턴스가 상시 작동 AG를 사용하도록 변환됩니다.
# Amazon RDS의 Microsoft SQL Server 추가 기능
다음 섹션에서는 Microsoft SQL Server DB 엔진을 실행하는 Amazon RDS 인스턴스의 강화에 대한 정보를 찾을 수 있습니다.
**Topics**
+ [RDS for SQL Server에서 SQL Server 로그인에 암호 정책 사용](SQLServer.Concepts.General.PasswordPolicy.Using.md)
+ [Amazon RDS for SQL Server DB 인스턴스와 Amazon S3 통합](User.SQLServer.Options.S3-integration.md)
+ [Amazon RDS for SQL Server에 Database Mail 사용](SQLServer.DBMail.md)
+ [Amazon RDS for SQL Server의 tempdb 데이터베이스에 대한 인스턴스 스토어 지원](SQLServer.InstanceStore.md)
+ [Amazon RDS for Microsoft SQL Server에 확장 이벤트 사용](SQLServer.ExtendedEvents.md)
+ [RDS for SQL Server를 사용하여 트랜잭션 로그 백업에 액세스](USER.SQLServer.AddlFeat.TransactionLogAccess.md)
# RDS for SQL Server에서 SQL Server 로그인에 암호 정책 사용
Amazon RDS를 사용하면 Microsoft SQL Server를 실행하는 Amazon RDS DB 인스턴스에 암호 정책을 설정할 수 있습니다. 이를 사용하여 SQL Server 인증으로 DB 인스턴스를 인증하는 로그인의 복잡성, 길이 및 잠금 요구 사항을 설정할 수 있습니다.
## 주요 용어
**로그인**
SQL Server에서는 데이터베이스 인스턴스에 대해 인증할 수 있는 서버 수준 보안 주체를 **로그인**이라고 합니다. 다른 데이터베이스 엔진에서는 이 보안 주체를 사용자로 지칭할 수 있습니다.** RDS for SQL Server에서는 SQL Server 인증 또는 Windows 인증을 사용하여 로그인을 인증할 수 있습니다.
**SQL Server 로그인**
SQL Server 인증을 사용하여 사용자 이름과 암호를 통해 인증하는 로그인은 SQL Server 로그인입니다. DB 파라미터를 통해 구성한 암호 정책은 SQL Server 로그인에만 적용됩니다.
**Windows 로그인**
Windows 보안 주체를 기반으로 하고 Windows 인증을 사용하여 인증하는 로그인은 Windows 로그인입니다. Active Directory에서 Windows 로그인에 대한 암호 정책을 구성할 수 있습니다. 자세한 내용은 [RDS for SQL Server를 사용하여 Active Directory 작업](User.SQLServer.ActiveDirectoryWindowsAuth.md) 단원을 참조하십시오.
## 각 로그인에 대한 정책 활성화 및 비활성화
각 SQL Server 로그인에는 `CHECK_POLICY` 및 `CHECK_EXPIRATION` 플래그가 있습니다. 기본적으로 새 로그인은 `ON`으로 설정된 `CHECK_POLICY`와 `OFF`로 설정된 `CHECK_EXPIRATION`으로 생성됩니다.
로그인에 대해 `CHECK_POLICY`가 활성화된 경우 RDS for SQL Server는 복잡성 및 최소 길이 요구 사항을 기준으로 암호의 유효성을 검사합니다. 잠금 정책 또한 적용됩니다. `CHECK_POLICY` 및 `CHECK_EXPIRATION`을 활성화하기 위한 예제 T-SQL 문:
```
ALTER LOGIN [master_user] WITH CHECK_POLICY = ON, CHECK_EXPIRATION = ON;
```
`CHECK_EXPIRATION`이 활성화된 경우 암호에는 암호 수명 정책이 적용됩니다. `CHECK_POLICY` 및 `CHECK_EXPIRATION` 설정 여부를 확인하기 위한 T-SQL 문:
```
SELECT name, is_policy_checked, is_expiration_checked FROM sys.sql_logins;
```
## 암호 정책 파라미터
모든 암호 정책 파라미터는 동적이므로 DB를 재부팅하지 않아도 적용됩니다. 다음 표에는 SQL Server 로그인에 대한 암호 정책을 수정하기 위해 설정할 수 있는 DB 파라미터가 나열되어 있습니다.
****
| DB 파라미터 | 설명 | 허용된 값 | 기본 값 |
| --- | --- | --- | --- |
| rds.password\$1complexity\$1enabled | SQL Server 로그인을 위한 암호를 만들거나 변경할 때는 암호 복잡성 요구 사항을 충족해야 합니다. 다음 제약 조건을 충족해야 합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/SQLServer.Concepts.General.PasswordPolicy.Using.html) | 0,1 | 0 |
| rds.password\$1min\$1length | SQL Server 로그인을 위한 암호에 필요한 최소 문자 수입니다. | 0\$114 | 0 |
| rds.password\$1min\$1age | 사용자가 SQL Server 로그인 암호를 변경할 수 있기 전에 사용해야 하는 최소 일수입니다. 0으로 설정되어 있는 경우 암호를 즉시 변경할 수 있습니다. | 0\$1998 | 0 |
| rds.password\$1max\$1age | SQL Server 로그인 암호를 사용할 수 있는 최대 일수입니다. 이 기간이 지나면 사용자가 암호를 변경해야 합니다. 0으로 설정되어 있는 경우 암호가 만료되지 않습니다. | 0\$1999 | 42 |
| rds.password\$1lockout\$1threshold | SQL Server 로그인이 잠기기 전에 연속으로 실패할 수 있는 로그인 시도 횟수입니다. | 0\$1999 | 0 |
| rds.password\$1lockout\$1duration | 잠긴 SQL Server 로그인이 잠금 해제될 때까지 기다려야 하는 시간(분)입니다. | 1\$160 | 10 |
| rds.password\$1lockout\$1reset\$1counter\$1after | 로그인 시도 실패 후 로그인 시도 실패 카운터가 0으로 재설정되기 전에 경과해야 하는 시간(분)입니다. | 1\$160 | 10 |
**참고**
SQL Server 암호 정책에 대한 자세한 내용은 [암호 정책](https://learn.microsoft.com/en-us/sql/relational-databases/security/password-policy)을 참조하세요.
암호 복잡성 및 최소 길이 정책은 포함된 데이터베이스의 DB 사용자에게도 적용됩니다. 자세한 내용은 [포함된 데이터베이스](https://learn.microsoft.com/en-us/sql/relational-databases/databases/contained-databases)를 참조하세요.
암호 정책 매개변수에는 다음 제약 조건이 적용됩니다.
+ `rds.password_max_age`가 0으로 설정되어 있지 않는 한 `rds.password_min_age` 파라미터는 `rds.password_max_age parameter`보다 작아야 합니다.
+ `rds.password_lockout_reset_counter_after` 파라미터는 `rds.password_lockout_duration` 파라미터보다 작거나 같아야 합니다.
+ `rds.password_lockout_threshold`가 0으로 설정되어 있으면 `rds.password_lockout_duration` 및 `rds.password_lockout_reset_counter_after`는 적용되지 않습니다.
### 기존 로그인에 대한 고려 사항
인스턴스의 암호 정책을 수정한 후에는 로그인을 위한 기존 암호가 새로운 암호 복잡성 및 길이 요구 사항을 기준으로 소급 평가되지 **않습니다**. 새 암호만 새 정책을 기준으로 검증됩니다.
SQL Server는 수명 요구 사항을 기준으로 기존 암호를 **평가합니다**.
암호 정책이 수정되는 즉시 암호가 만료될 수도 있습니다. 예를 들어 로그인에 `CHECK_EXPIRATION`이 활성화되어 있고 100일 전에 암호를 마지막으로 변경했으며 `rds.password_max_age` 파라미터를 5일로 설정한 경우 암호가 즉시 만료되므로 다음 로그인 시도 시 암호를 변경해야 합니다.
**참고**
RDS for SQL Server는 암호 기록 정책을 지원하지 않습니다. 기록 정책은 로그인이 이전에 사용한 암호를 재사용하지 못하도록 합니다.
### 다중 AZ 배포에 대한 고려 사항
다중 AZ 인스턴스의 로그인 시도 실패 카운터 및 잠금 상태는 노드 간에 복제되지 않습니다. 다중 AZ 인스턴스가 장애 조치될 때 로그인이 잠기는 경우 새 노드에서 로그인이 이미 잠금 해제되어 있을 수 있습니다.
# 마스터 로그인에 대한 암호 고려 사항
RDS for SQL Server DB 인스턴스를 생성하면 마스터 사용자 암호가 암호 정책을 기준으로 평가되지 않습니다. 마스터 사용자에게 작업을 수행할 때, 특히 `ModifyDBInstance` 명령에서 `MasterUserPassword`를 설정할 때도 새 마스터 암호는 암호를 기준으로 평가되지 않습니다. 두 경우 모두 암호 정책을 충족하지 않는 마스터 사용자 암호를 설정할 수 있으며, 이 경우에도 작업은 성공합니다. 정책이 충족되지 않으면 RDS는 강력한 암호를 설정하라는 권장 사항이 포함된 RDS 이벤트를 발생시키려고 시도합니다. 마스터 사용자에는 강력한 암호만 사용해야 합니다.
마스터 사용자 암호가 암호 정책 요구 사항을 충족하지 않는 경우 RDS는 다음 이벤트 메시지를 생성하려고 시도합니다.
+ 마스터 사용자가 생성되었지만 암호가 암호 정책의 최소 길이 요구 사항을 충족하지 않습니다. 더 강력한 암호를 사용해 보세요.
+ 마스터 사용자가 생성되었지만 암호가 암호 정책의 복잡성 요구 사항을 충족하지 않습니다. 더 강력한 암호를 사용해 보세요.
+ 마스터 사용자 암호가 재설정되었지만 암호가 암호 정책의 최소 길이 요구 사항을 충족하지 않습니다. 더 강력한 암호를 사용해 보세요.
+ 마스터 사용자 암호가 재설정되었지만 암호가 암호 정책의 복잡성 요구 사항을 충족하지 않습니다. 더 강력한 암호를 사용해 보세요.
기본적으로 마스터 사용자는 `CHECK_POLICY` 및 `CHECK_EXPIRATION`으로 생성되고 `OFF`로 설정됩니다. 마스터 사용자에게 암호 정책을 적용하려면 DB 인스턴스 생성 후 마스터 사용자에 대해 이러한 플래그를 수동으로 활성화해야 합니다. 이러한 플래그를 활성화한 후에는 SQL Server에서 직접 마스터 사용자 암호를 수정하여(예: T-SQL 문 또는 SSMS를 통해) 암호 정책을 기준으로 새 암호의 유효성을 검사합니다.
**참고**
마스터 사용자가 잠긴 경우 `ModifyDBInstance` 명령으로 마스터 사용자 암호를 재설정하여 사용자를 잠금 해제할 수 있습니다.
## 마스터 사용자 암호 수정
[ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) 명령을 사용하여 마스터 사용자 암호를 수정할 수 있습니다.
**참고**
마스터 사용자 암호를 재설정하면 RDS는 마스터 사용자에 대한 다양한 권한을 재설정하므로 마스터 사용자는 특정 권한을 잃을 수 있습니다. 또한 마스터 사용자 암호를 재설정하면 마스터 사용자의 잠금이 해제됩니다(잠겨 있던 경우).
RDS는 새 마스터 사용자 암호의 유효성을 검사하고 암호가 정책을 충족하지 않는 경우 RDS 이벤트를 내보내려고 시도합니다. RDS는 암호 정책을 충족하지 않는 경우에도 암호를 설정합니다.
# Amazon RDS for SQL Server DB 인스턴스와 Amazon S3 통합
Amazon RDS for SQL Server를 실행 중인 DB 인스턴스와 Amazon S3 버킷 사이에서 파일을 전송할 수 있습니다. 그러면 BULK INSERT와 같은 SQL Server 기능으로 Amazon S3를 사용할 수 있습니다. 예를 들어 Amazon S3의 .csv, .xml, .txt 및 기타 파일을 DB 인스턴스 호스트로 다운로드하고 `D:\S3\`에서 데이터베이스로 데이터를 가져올 수 있습니다. 모든 파일은 DB 인스턴스 기반으로 `D:\S3\`에 저장됩니다.
다음과 같은 제한이 적용됩니다.
**참고**
RDS 호스트와 S3 간의 트래픽은 S3를 사용하는 모든 SQL Server 기능의 경우 RDS 내부 VPC의 VPC 엔드포인트를 통해 라우팅됩니다. 이 트래픽은 RDS 인스턴스 엔드포인트 ENI를 사용하지 않습니다. S3 버킷 정책은 네트워킹 조건에 따라 RDS 트래픽을 제한할 수 없습니다.
+ 다중 AZ 인스턴스에서 장애 조치 후 `D:\S3` 폴더의 파일이 예비 복제본에서 삭제됩니다. 자세한 내용은 [S3 통합에 대한 다중 AZ 제한 사항](#S3-MAZ) 섹션을 참조하세요.
+ DB 인스턴스와 S3 버킷은 같은 AWS 리전에 있어야 합니다.
+ 한 번에 둘 이상의 S3 통합 작업을 실행하는 경우 작업은 병렬이 아닌 순차적으로 실행됩니다.
**참고**
S3 통합 작업은 기본 백업 및 복원 작업과 동일한 대기열을 공유합니다. 이 대기열에서는 언제든 최대 두 개의 작업만 진행할 수 있습니다. 따라서 두 개의 기본 백업 및 복원 작업을 실행하면 S3 통합 작업이 차단됩니다.
+ 복원된 인스턴스에서 S3 통합 기능을 다시 활성화해야 합니다. S3 통합은 소스 인스턴스에서 복원된 인스턴스로 전파되지 않습니다. `D:\S3`의 파일은 복원된 인스턴스에서 삭제됩니다.
+ DB 인스턴스로 다운로드하는 파일은 100개로 제한됩니다. 즉, `D:\S3\`에 있는 파일이 100개를 초과할 수 없습니다.
+ 파일 확장명이 없거나, 파일 확장명이 .abf, .asdatabase, .bcp, .configsettings, .csv, .dat, .deploymentoptions, .deploymenttargets, .fmt, .info, .ispac, .lst, .tbl, .txt, .xml, .xmla인 파일만 다운로드할 수 있습니다.
+ S3 버킷의 소유자는 관련 AWS Identity and Access Management(IAM) 역할과 동일해야 합니다. 따라서 교차 계정 S3 통합은 지원되지 않습니다.
+ S3 버킷은 공개할 수 없습니다.
+ RDS에서 S3로의 업로드 파일 크기는 파일당 50GB로 제한됩니다.
+ S3에서 RDS로의 다운로드 파일 크기는 S3에서 지원하는 최대 크기로 제한됩니다.
**Topics**
+ [RDS for SQL Server와 S3를 통합하기 위한 사전 요구 사항](Appendix.SQLServer.Options.S3-integration.preparing.md)
+ [RDS for SQL Server와 S3 통합 활성화](Appendix.SQLServer.Options.S3-integration.enabling.md)
+ [RDS for SQL Server와 Amazon S3 간 파일 전송](Appendix.SQLServer.Options.S3-integration.using.md)
+ [RDS DB 인스턴스의 파일 나열](Appendix.SQLServer.Options.S3-integration.using.listing-files.md)
+ [RDS DB 인스턴스의 파일 삭제](Appendix.SQLServer.Options.S3-integration.using.deleting-files.md)
+ [파일 전송 작업 상태 모니터링](Appendix.SQLServer.Options.S3-integration.using.monitortasks.md)
+ [작업 취소](Appendix.SQLServer.Options.S3-integration.canceltasks.md)
+ [S3 통합에 대한 다중 AZ 제한 사항](#S3-MAZ)
+ [RDS for SQL Server와 S3 통합 비활성화](Appendix.SQLServer.Options.S3-integration.disabling.md)
Amazon S3의 파일 작업에 대한 자세한 내용은 [Amazon Simple Storage Service 시작하기](https://docs.aws.amazon.com/AmazonS3/latest/userguide/GetStartedWithS3)를 참조하십시오.
# RDS for SQL Server와 S3를 통합하기 위한 사전 요구 사항
시작하기 전에, 사용하려는 S3 버킷을 찾거나 생성하십시오. 또한 RDS DB 인스턴스가 S3 버킷에 액세스할 수 있도록 권한을 추가하십시오. 이 액세스를 구성하려면 IAM 정책과 IAM 역할을 모두 생성하십시오.
## 콘솔
**Amazon S3 액세스를 위한 IAM 정책을 생성하려면**
1. [IAM Management Console](https://console.aws.amazon.com/iam/home?#home)의 탐색 창에서 **정책**을 선택합니다.
1. 새 정책을 생성하고 다음 단계에 대해 **시각적 편집기** 탭을 사용하십시오.
1. **서비스**에 **S3**를 입력한 후 **S3** 서비스를 선택하십시오.
1. **작업**에서 DB 인스턴스에 필요한 액세스 권한을 부여하려면 다음을 선택하십시오.
+ `ListAllMyBuckets` - 필수
+ `ListBucket` - 필수
+ `GetBucketAcl` - 필수
+ `GetBucketLocation` - 필수
+ `GetObject` – S3에서 로 파일을 다운로드하는 데 필요`D:\S3\`
+ `PutObject` – `D:\S3\`에서 S3로 파일을 업로드하는 데 필요
+ `ListMultipartUploadParts` – `D:\S3\`에서 S3로 파일을 업로드하는 데 필요
+ `AbortMultipartUpload` – `D:\S3\`에서 S3로 파일을 업로드하는 데 필요
1. **리소스**의 경우, 표시되는 옵션은 이전 단계에서 선택한 작업에 따라 다릅니다. **버킷**, **객체** 또는 두 항목 모두의 옵션이 표시될 수 있습니다. 이들 각각에 대해 적절한 Amazon 리소스 이름(ARN)을 추가하십시오.
**버킷**의 경우 사용할 버킷의 ARN을 추가하십시오. 예를 들어, 버킷 이름이 *amzn-s3-demo-bucket*인 경우 ARN을 `arn:aws:s3:::amzn-s3-demo-bucket`으로 설정하세요.
**객체**의 경우, 버킷의 ARN을 입력한 후 다음 중 하나를 선택하십시오.
+ 지정된 버킷의 모든 파일에 대한 액세스 권한을 부여하려면 **버킷 이름** 및 **객체 이름**에 대해 동일하게 **모두**를 선택하십시오.
+ 버킷의 특정 파일 또는 폴더에 대한 액세스 권한을 부여하려면 SQL Server가 액세스할 특정 버킷과 객체의 ARN을 제공하십시오.
1. 정책 생성을 완료할 때까지 콘솔의 지침을 따르십시오.
위의 내용은 정책 설정을 위한 약어 형태의 안내서입니다. IAM 정책 생성에 대한 자세한 지침은 *IAM 사용 설명서*에서 [IAM 정책 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)을 참조하세요.
**이전 절차의 IAM 정책을 사용하는 IAM 역할을 생성하려면**
1. [IAM Management Console](https://console.aws.amazon.com/iam/home?#home)의 탐색 창에서 **역할**을 선택합니다.
1. 새 IAM 역할을 생성하고 콘솔에 표시되는 다음 옵션을 선택하십시오.
+ **AWS 서비스**
+ **RDS**
+ **RDS – Add Role to Database(데이터베이스에 역할 추가**
그런 다음 하단의 **다음: 권한**을 선택합니다.
1. **Attach permissions policies(권한 정책 연결)**에 이전에 생성한 IAM 정책의 이름을 입력하십시오. 그런 다음 목록에서 그 정책을 선택합니다.
1. 역할 생성을 완료할 때까지 콘솔의 지침을 따르십시오.
위의 내용은 역할 설정을 위한 약어 형태의 안내서입니다. 역할 생성에 대한 자세한 지침은 *IAM 사용 설명서*에서 [IAM 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)을 참조하세요.
## AWS CLI
Amazon RDS에 Amazon S3 버킷에 대한 액세스 권한을 부여하려면 다음 프로세스를 사용합니다.
1. Amazon RDS에 S3 버킷 액세스 권한을 부여하는 IAM 정책을 생성합니다.
1. Amazon RDS가 S3 버킷에 액세스하기 위해 사용자 대신 가정할 수 있는 IAM 역할을 만듭니다.
자세한 내용은 *IAM 사용 설명서*의 [IAM 사용자에게 권한을 위임하기 위한 역할 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html)을 참조하십시오.
1. 생성한 IAM 역할에 생성한 IAM 정책을 연결합니다.
**IAM 정책을 생성하려면**
DB 인스턴스에 필요한 액세스 권한을 부여하려면 적절한 조치를 포함하십시오.
+ `ListAllMyBuckets` - 필수
+ `ListBucket` - 필수
+ `GetBucketAcl` - 필수
+ `GetBucketLocation` - 필수
+ `GetObject` – S3에서 로 파일을 다운로드하는 데 필요`D:\S3\`
+ `PutObject` – `D:\S3\`에서 S3로 파일을 업로드하는 데 필요
+ `ListMultipartUploadParts` – `D:\S3\`에서 S3로 파일을 업로드하는 데 필요
+ `AbortMultipartUpload` – `D:\S3\`에서 S3로 파일을 업로드하는 데 필요
1. 다음 AWS CLI 명령은 이 옵션으로 `rds-s3-integration-policy`라는 IAM 정책을 만듭니다. *amzn-s3-demo-bucket*이라는 버킷에 대한 액세스 권한을 부여합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws iam create-policy \
--policy-name rds-s3-integration-policy \
--policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetBucketAcl",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:ListMultipartUploadParts",
"s3:AbortMultipartUpload"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/key_prefix/*"
}
]
}'
```
Windows의 경우:
행 끝을 인터페이스에서 지원하는 것으로 바꾸십시오(`^` 대신 `\`). 또한 Windows에서는 `\`로 모든 큰 따옴표를 이스케이프해야 합니다. JSON에서 따옴표를 이스케이프하지 않으려면, 파일에 대신 저장하고 파라미터로 전달하면 됩니다.
먼저 다음 권한 정책을 사용하여 `policy.json` 파일을 생성하십시오.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetBucketACL",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:ListMultipartUploadParts",
"s3:AbortMultipartUpload"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/key_prefix/*"
}
]
}
```
------
그리고 다음 명령을 사용하여 정책을 만듭니다.
```
aws iam create-policy ^
--policy-name rds-s3-integration-policy ^
--policy-document file://file_path/assume_role_policy.json
```
1. 정책을 만든 후에 정책의 Amazon 리소스 이름(ARN)을 기록하십시오. 이후 단계에 이 ARN이 필요합니다.
**IAM 역할을 만들려면**
+ 다음 AWS CLI 명령은 이 목적으로 `rds-s3-integration-role` IAM 역할을 생성합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws iam create-role \
--role-name rds-s3-integration-role \
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}'
```
Windows의 경우:
행 끝을 인터페이스에서 지원하는 것으로 바꾸십시오(`^` 대신 `\`). 또한 Windows에서는 `\`로 모든 큰 따옴표를 이스케이프해야 합니다. JSON에서 따옴표를 이스케이프하지 않으려면, 파일에 대신 저장하고 파라미터로 전달하면 됩니다.
먼저, 다음 정책이 포함된 `assume_role_policy.json` 파일을 생성합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"rds.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
------
그러고 나서 다음 명령을 사용하여 IAM 역할을 만듭니다.
```
aws iam create-role ^
--role-name rds-s3-integration-role ^
--assume-role-policy-document file://file_path/assume_role_policy.json
```
**Example 전역 조건 컨텍스트 키를 사용하여 IAM 역할 생성**
서비스 권한을 특정 리소스로 제한하는 리소스 기반 정책의 [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) 및 [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) 전역 조건 컨텍스트 키를 사용하는 것이 좋습니다. 이는 [혼동된 대리자 문제](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)를 방지하는 가장 효과적인 방법입니다.
전역 조건 컨텍스트 키를 모두 사용하고 `aws:SourceArn` 값에 계정 ID가 포함되도록 할 수 있습니다. 이 경우 `aws:SourceAccount` 값과 `aws:SourceArn` 값의 계정이 동일한 정책 문에서 사용될 때 동일한 계정 ID를 사용해야 합니다.
+ 단일 리소스에 대한 교차 서비스 액세스를 원하는 경우 `aws:SourceArn`을 사용하세요.
+ 해당 계정의 모든 리소스가 교차 서비스 사용과 연결되도록 허용하려는 경우 `aws:SourceAccount`를 사용하세요.
정책에서는 역할에 액세스하는 리소스의 전체 Amazon 리소스 이름(ARN)이 포함된 `aws:SourceArn` 전역 조건 컨텍스트 키를 사용해야 합니다. S3 통합의 경우 다음 예와 같이 DB 인스턴스 ARN을 포함해야 합니다.
대상 LinuxmacOS, 또는Unix:
```
aws iam create-role \
--role-name rds-s3-integration-role \
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceArn":"arn:aws:rds:Region:my_account_ID:db:db_instance_identifier"
}
}
}
]
}'
```
Windows의 경우:
`assume_role_policy.json`에 전역 조건 컨텍스트 키를 추가합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"rds.amazonaws.com"
]
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceArn":"arn:aws:rds:Region:my_account_ID:db:db_instance_identifier"
}
}
}
]
}
```
------
**IAM 역할에 IAM 정책 연결**
+ 다음 AWS CLI 명령은 정책을 `rds-s3-integration-role`이라는 역할에 연결합니다. `your-policy-arn`을 이전 단계에서 기록한 정책 ARN으로 바꾸세요.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws iam attach-role-policy \
--policy-arn your-policy-arn \
--role-name rds-s3-integration-role
```
Windows의 경우:
```
aws iam attach-role-policy ^
--policy-arn your-policy-arn ^
--role-name rds-s3-integration-role
```
# RDS for SQL Server와 S3 통합 활성화
다음 섹션에서는 Amazon S3와 Amazon RDS for SQL Server의 통합을 활성화하는 방법을 배울 수 있습니다. S3 통합 작업을 위해, `S3_INTEGRATION` feature-name 파라미터를 사용하기 전에 생성한 IAM 역할과 DB 인스턴스를 연결해야 합니다.
**참고**
DB 인스턴스에 IAM 역할을 추가하려면 DB 인스턴스 상태가 **사용 가능**이어야 합니다.
## 콘솔
**IAM 역할을 DB 인스턴스와 연결하려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 세부 정보를 표시하고자 하는 RDS for SQL Server DB 인스턴스 이름을 선택합니다.
1. **Connectivity & security(연결성 및 보안)** 탭에 있는 **Manage IAM roles(IAM 역할 관리)** 섹션의 **이 인스턴스에 IAM 역할 추가**에서 추가할 IAM 역할을 선택합니다.
1. **기능**에서 **S3\$1INTEGRATION**을 선택하십시오.
![\[S3_INTEGRATION 역할 추가\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/ora-s3-integration-role.png)
1. [**Add role**]을 선택합니다.
## AWS CLI
**RDS for SQL Server DB 인스턴스에 IAM 역할을 추가하려면**
+ 다음 AWS CLI 명령은 `mydbinstance`라는 RDS for SQL Server DB 인스턴스에 IAM 역할을 추가합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds add-role-to-db-instance \
--db-instance-identifier mydbinstance \
--feature-name S3_INTEGRATION \
--role-arn your-role-arn
```
Windows의 경우:
```
aws rds add-role-to-db-instance ^
--db-instance-identifier mydbinstance ^
--feature-name S3_INTEGRATION ^
--role-arn your-role-arn
```
`your-role-arn`을 이전 단계에서 기록한 역할 ARN으로 바꿉니다. `S3_INTEGRATION` 옵션에 대해 `--feature-name`을 지정해야 합니다.
# RDS for SQL Server와 Amazon S3 간 파일 전송
Amazon RDS 저장 프로시저를 사용하여 Amazon S3와 RDS DB 인스턴스 간에 파일을 다운로드하고 업로드할 수 있습니다. Amazon RDS 저장 프로시저를 사용하여 RDS 인스턴스의 파일을 나열하고 삭제할 수도 있습니다.
S3에서 다운로드 및 업로드한 파일은 `D:\S3` 폴더에 저장됩니다. 파일에 액세스하는 데 사용할 수 있는 유일한 폴더입니다. 다운로드하는 동안 대상 폴더를 포함할 때 생성되는 하위 폴더에 파일을 구성할 수 있습니다.
저장 프로시저 중에는 S3 버킷과 파일에 Amazon 리소스 이름(ARN)을 제공해야 하는 것도 있습니다. ARN의 형식은 `arn:aws:s3:::amzn-s3-demo-bucket/file_name`입니다. Amazon S3에서는 ARN에 계정 번호나 AWS 리전을 요구하지 않습니다.
S3 통합 작업은 순차적으로 실행되며 기본 백업 및 복원 작업과 동일한 대기열을 공유합니다. 이 대기열에서는 언제든 최대 두 개의 작업만 진행할 수 있습니다. 작업이 처리를 시작하는 데 최대 5분이 걸릴 수 있습니다.
## Amazon S3 버킷의 파일을 SQL Server DB 인스턴스로 다운로드
S3 버킷에서 RDS for SQL Server DB 인스턴스로 파일을 다운로드하려면 다음 파라미터와 함께 Amazon RDS 저장 프로시저 `msdb.dbo.rds_download_from_s3`를 사용합니다.
| 파라미터 이름 | 데이터 형식 | 기본값 | 필수 | 설명 |
| --- | --- | --- | --- | --- |
| `@s3_arn_of_file` | NVARCHAR | – | 필수 | 다운로드할 파일의 S3 ARN(예: `arn:aws:s3:::amzn-s3-demo-bucket/mydata.csv`) |
| `@rds_file_path` | NVARCHAR | – | 선택 | RDS 인스턴스의 파일 경로입니다. 지정하지 않으면 파일 경로는 `D:\S3\`입니다. RDS는 절대 경로와 상대 경로를 지원합니다. 하위 폴더를 생성하려면 파일 경로에 포함하십시오. |
| `@overwrite_file` | INT | 0 | 선택 | 기존 파일을 덮어씁니다. 0 = 덮어쓰지 않음 1 = 덮어쓰기 |
파일 확장명이 없는 파일과 파일 확장명이 .bcp, .csv, .dat, .fmt, .info, .lst, .tbl, .txt 및 .xml인 파일을 다운로드할 수 있습니다.
**참고**
SQL Server Integration Services가 활성화된 경우 파일 확장명이 .ispac인 파일을 다운로드할 수 있습니다. SSIS 활성화에 대한 자세한 내용은 [SQL Server Integration Services](Appendix.SQLServer.Options.SSIS.md) 단원을 참조하십시오.
SQL Server Analysis Services가 활성화된 경우 파일 확장명이 .abf, .asdatabase, .configsettings, .deploymentoptions, .deploymenttargets 및 .xmla인 파일을 다운로드할 수 있습니다. SSAS 활성화에 대한 자세한 내용은 [SQL Server Analysis Services](Appendix.SQLServer.Options.SSAS.md) 단원을 참조하십시오.
다음 예는 S3에서 파일을 다운로드하는 저장 프로시저를 보여줍니다.
```
exec msdb.dbo.rds_download_from_s3
@s3_arn_of_file='arn:aws:s3:::amzn-s3-demo-bucket/bulk_data.csv',
@rds_file_path='D:\S3\seed_data\data.csv',
@overwrite_file=1;
```
예제 `rds_download_from_s3` 작업은 폴더가 없는 경우에 `seed_data`에 `D:\S3\`라는 폴더를 만듭니다. 그런 다음 이 예제에서는 S3의 원본 파일 `bulk_data.csv`를 DB 인스턴스에 `data.csv`라는 새 파일로 다운로드합니다. 파일이 이전에 존재한 경우, `@overwrite_file` 파라미터가 `1`로 설정되어 있으므로 덮어쓰기됩니다.
## SQL Server DB 인스턴스의 파일을 Amazon S3 버킷으로 업로드
RDS for SQL Server DB 인스턴스의 파일을 S3 버킷에 업로드하려면 다음 파라미터와 함께 Amazon RDS 저장 프로시저 `msdb.dbo.rds_upload_to_s3`를 사용합니다.
| 파라미터 이름 | 데이터 형식 | 기본값 | 필수 | 설명 |
| --- | --- | --- | --- | --- |
| `@s3_arn_of_file` | NVARCHAR | – | 필수 | S3에 생성할 파일의 S3 ARN(예: `arn:aws:s3:::amzn-s3-demo-bucket/mydata.csv`) |
| `@rds_file_path` | NVARCHAR | – | 필수 | S3에 업로드할 파일의 파일 경로입니다. 절대 경로와 상대 경로가 지원됩니다. |
| `@overwrite_file` | INT | – | 선택 | 기존 파일을 덮어씁니다. 0 = 덮어쓰지 않음 1 = 덮어쓰기 |
다음 예제에서는 `data.csv`에서 지정된 위치의 `D:\S3\seed_data\`라는 파일을 ARN이 지정한 S3 버킷의 파일 `new_data.csv`에 업로드합니다.
```
exec msdb.dbo.rds_upload_to_s3
@rds_file_path='D:\S3\seed_data\data.csv',
@s3_arn_of_file='arn:aws:s3:::amzn-s3-demo-bucket/new_data.csv',
@overwrite_file=1;
```
S3에 파일이 이전에 존재한 경우, @overwrite\$1file 파라미터가 `1`로 설정되어 있으므로 덮어쓰기됩니다.
# RDS DB 인스턴스의 파일 나열
DB 인스턴스에서 사용 가능한 파일을 나열하려면 저장 프로시저와 함수를 모두 사용하십시오. 먼저, 다음 저장 프로시저를 실행하여 `D:\S3\`의 파일에서 파일 세부 정보를 수집하십시오.
```
exec msdb.dbo.rds_gather_file_details;
```
저장 프로시저는 작업 ID를 반환합니다. 다른 작업과 마찬가지로 이 저장 프로시저는 비동기적으로 실행됩니다. 작업 상태가 `SUCCESS`가 되는 즉시, 다음과 같이 `rds_fn_list_file_details` 함수의 작업 ID를 사용하여 D:\$1S3\$1의 기존 파일과 디렉터리를 나열할 수 있습니다.
```
SELECT * FROM msdb.dbo.rds_fn_list_file_details(TASK_ID);
```
이 `rds_fn_list_file_details` 함수는 다음 열이 포함된 테이블을 반환합니다.
| 출력 파라미터 | 설명 |
| --- | --- |
| filepath | 파일의 절대 경로(예: D:\$1S3\$1mydata.csv) |
| size\$1in\$1bytes | 파일 크기(바이트 단위) |
| last\$1modified\$1utc | UTC 형식의 마지막 수정 날짜 및 시간 |
| is\$1directory | 항목이 디렉터리인지 나타내는 옵션(true/false) |
# RDS DB 인스턴스의 파일 삭제
DB 인스턴스에서 사용 가능한 파일을 삭제하려면 다음 파라미터와 함께 Amazon RDS 저장 프로시저 `msdb.dbo.rds_delete_from_filesystem`을 사용하십시오.
| 파라미터 이름 | 데이터 형식 | 기본값 | 필수 | 설명 |
| --- | --- | --- | --- | --- |
| `@rds_file_path` | NVARCHAR | – | 필수 | 삭제할 파일의 파일 경로입니다. 절대 경로와 상대 경로가 지원됩니다. |
| `@force_delete` | INT | 0 | 선택 | 디렉터리를 삭제하려면 이 플래그를 포함하고 `1`로 설정해야 합니다. `1` = 디렉터리 삭제 파일을 삭제하는 경우 이 파라미터는 무시됩니다. |
디렉터리를 삭제하려면 `@rds_file_path`가 백슬래시(`\`)로 끝나야 하며 `@force_delete`가 `1`로 설정되어야 합니다.
다음 예제에서는 `D:\S3\delete_me.txt` 파일을 삭제합니다.
```
exec msdb.dbo.rds_delete_from_filesystem
@rds_file_path='D:\S3\delete_me.txt';
```
다음은 `D:\S3\example_folder\` 디렉터리를 삭제하는 예제입니다.
```
exec msdb.dbo.rds_delete_from_filesystem
@rds_file_path='D:\S3\example_folder\',
@force_delete=1;
```
# 파일 전송 작업 상태 모니터링
S3 통합 작업의 상태를 추적하려면 `rds_fn_task_status` 함수를 호출하십시오. 두 가지 파라미터가 필요합니다. 첫 번째 파라미터는 S3 통합에 적용되지 않기 때문에 항상 `NULL`이어야 합니다. 두 번째 파라미터는 작업 ID를 수락합니다.
모든 작업 목록을 보려면 다음 예와 같이 첫 번째 파라미터를 `NULL`로, 두 번째 파라미터를 `0`으로 설정하십시오.
```
SELECT * FROM msdb.dbo.rds_fn_task_status(NULL,0);
```
특정 작업을 수행하려면 다음 예와 같이 첫 번째 파라미터를 `NULL`로, 두 번째 파라미터를 작업 ID로 설정하십시오.
```
SELECT * FROM msdb.dbo.rds_fn_task_status(NULL,42);
```
`rds_fn_task_status` 함수는 다음 정보를 반환합니다.
| 출력 파라미터 | 설명 |
| --- | --- |
| `task_id` | 작업의 ID입니다. |
| `task_type` | S3 통합의 경우 작업 유형은 다음과 같을 수 있습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/Appendix.SQLServer.Options.S3-integration.using.monitortasks.html) |
| `database_name` | S3 통합 작업에는 적용되지 않습니다. |
| `% complete` | 백분율로 나타낸 작업의 진행률입니다. |
| `duration(mins)` | 작업에 소요된 시간입니다(분). |
| `lifecycle` | 작업의 상태입니다. 가능한 상태는 다음과 같습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/Appendix.SQLServer.Options.S3-integration.using.monitortasks.html) |
| `task_info` | 작업에 대한 추가 정보입니다. 처리 중에 오류가 발생하면 이 열에 오류 정보가 포함됩니다. |
| `last_updated` | 작업 상태를 마지막으로 업데이트한 날짜와 시간입니다. |
| `created_at` | 작업을 생성한 날짜와 시간입니다. |
| `S3_object_arn` | 다운로드하거나 업로드할 S3 객체의 ARN입니다. |
| `overwrite_S3_backup_file` | S3 통합 작업에는 적용되지 않습니다. |
| `KMS_master_key_arn` | S3 통합 작업에는 적용되지 않습니다. |
| `filepath` | RDS DB 인스턴스의 파일 경로입니다. |
| `overwrite_file` | 기존 파일이 덮어쓰기되는지 나타내는 옵션입니다. |
| `task_metadata` | S3 통합 작업에는 적용되지 않습니다. |
# 작업 취소
S3 통합 작업을 취소하려면 `msdb.dbo.rds_cancel_task` 파라미터와 함께 `task_id` 저장 프로시저를 사용하십시오. 진행 중인 작업 삭제 및 나열은 취소할 수 없습니다. 다음은 작업을 취소하는 요청 예제입니다.
```
exec msdb.dbo.rds_cancel_task @task_id = 1234;
```
모든 작업 및 해당 작업 ID에 대한 개요를 보려면 `rds_fn_task_status`에 설명된 [파일 전송 작업 상태 모니터링](Appendix.SQLServer.Options.S3-integration.using.monitortasks.md) 함수를 사용하십시오.
## S3 통합에 대한 다중 AZ 제한 사항
다중 AZ 인스턴스에서 장애 조치 후 `D:\S3` 폴더의 파일이 예비 복제본에서 삭제됩니다. 예를 들어 인스턴스 클래스 변경 또는 엔진 버전 업그레이드와 같은 DB 인스턴스 수정 시 계획된 장애 조치를 수행할 수 있습니다. 또는 주 인스턴스 중단 시 계획되지 않은 장애 조치를 수행할 수 있습니다.
**참고**
파일 저장에 `D:\S3` 폴더를 사용하지 않는 것이 좋습니다. 가장 좋은 방법은 생성한 파일을 Amazon S3에 업로드하여 지속성 있게 만들고 데이터를 가져와야 할 때 파일을 다운로드하는 것입니다.
마지막 장애 조치 시간을 확인하려면 `msdb.dbo.rds_failover_time` 저장 프로시저를 사용합니다. 자세한 내용은 [Amazon RDS for SQL Server의 마지막 장애 조치 시간 결정](Appendix.SQLServer.CommonDBATasks.LastFailover.md) 섹션을 참조하세요.
**Example 최근 장애 조치 없음**
이 예에서는 오류 로그에 최근 장애 조치가 없는 경우의 출력을 보여 줍니다. 2020-04-29 23:59:00.01 이후로 장애 조치가 발생하지 않았습니다.
따라서 이 시간 이후에 다운로드되고 `rds_delete_from_filesystem` 저장 프로시저를 사용하여 삭제되지 않은 모든 파일은 현재 호스트에서 계속 액세스할 수 있습니다. 이 시간 이전에 다운로드한 파일도 사용 가능할 수 있습니다.
| errorlog\$1available\$1from | recent\$1failover\$1time |
| --- | --- |
| 2020-04-29 23:59:00.0100000 | null |
**Example 최근 장애 조치**
이 예에서는 오류 로그에 장애 조치가 있는 경우의 출력을 보여 줍니다. 가장 최근의 장애 조치는 2020-05-05 18:57:51.89에 있었습니다.
이 시간 이후에 다운로드되고 `rds_delete_from_filesystem` 저장 프로시저를 사용하여 삭제되지 않은 모든 파일은 현재 호스트에서 계속 액세스할 수 있습니다.
| errorlog\$1available\$1from | recent\$1failover\$1time |
| --- | --- |
| 2020-04-29 23:59:00.0100000 | 2020-05-05 18:57:51.8900000 |
# RDS for SQL Server와 S3 통합 비활성화
다음으로, Amazon S3와 Amazon RDS for SQL Server의 통합을 비활성화하는 방법을 배울 수 있습니다. S3 통합을 비활성화해도 `D:\S3\`의 파일은 삭제되지 않습니다.
**참고**
DB 인스턴스에서 IAM 역할을 삭제하려면 DB 인스턴스 상태가 `available`이어야 합니다.
## 콘솔
**DB 인스턴스에서 IAM 역할 연결을 해제하려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 세부 정보를 표시하고자 하는 RDS for SQL Server DB 인스턴스 이름을 선택합니다.
1. **Connectivity & security(연결성 및 보안)** 탭에 있는 **Manage IAM roles(IAM 역할 관리)** 섹션에서 삭제할 IAM 역할을 선택합니다.
1. **Delete**(삭제)를 선택합니다.
## AWS CLI
**RDS for SQL Server DB 인스턴스에서 IAM 역할을 제거하려면**
+ 다음 AWS CLI 명령은 `mydbinstance`라는 RDS for SQL Server DB 인스턴스에서 IAM 역할을 삭제합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds remove-role-from-db-instance \
--db-instance-identifier mydbinstance \
--feature-name S3_INTEGRATION \
--role-arn your-role-arn
```
Windows의 경우:
```
aws rds remove-role-from-db-instance ^
--db-instance-identifier mydbinstance ^
--feature-name S3_INTEGRATION ^
--role-arn your-role-arn
```
`your-role-arn`을 `--feature-name` 옵션에 적합한 IAM 역할 ARN으로 바꿉니다.
# Amazon RDS for SQL Server에 Database Mail 사용
Database Mail을 사용하여 Amazon RDS for SQL Server 데이터베이스 인스턴스에서 사용자에게 이메일 메시지를 보낼 수 있습니다. 메시지에는 파일 및 쿼리 결과가 포함될 수 있습니다. Database Mail은 다음 구성 요소를 포함합니다.
+ **구성 및 보안 객체** – 이 객체는 프로파일과 계정을 생성하며 `msdb` 데이터베이스에 저장됩니다.
+ **메시징 객체** – 이 객체에는 메시지를 보내는 데 사용되는 [sp\$1send\$1dbmail](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-send-dbmail-transact-sql) 저장 프로시저, 그리고 메시지에 대한 정보가 들어 있는 데이터 구조가 포함됩니다. 이들 객체는 `msdb` 데이터베이스에 저장됩니다.
+ **로깅 및 감사 객체** – Database Mail은 `msdb` 데이터베이스 및 Microsoft Windows 애플리케이션 이벤트 로그에 로깅 정보를 기록합니다.
+ **Database Mail 실행 파일** – `DatabaseMail.exe`은 `msdb` 데이터베이스의 대기열에서 데이터를 읽고 이메일 메시지를 전송합니다.
RDS는 Web, Standard 및 Enterprise Edition의 모든 SQL Server 버전에 대해 데이터베이스 Database Mail지원합니다.
## 제한 사항
SQL Server DB 인스턴스에 Database Mail을 사용할 경우 다음 제한 사항이 적용됩니다.
+ Database Mail은 SQL Server Express Edition에 대해 지원되지 않습니다.
+ Database Mail 구성 파라미터 수정은 지원되지 않습니다. 사전 설정(기본값) 값을 보려면 [sysmail\$1help\$1configure\$1sp](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sysmail-help-configure-sp-transact-sql) 저장 프로시저를 사용합니다.
+ 첨부 파일은 완전하게 지원되지 않습니다. 자세한 내용은 [첨부 파일 작업](#SQLServer.DBMail.Files) 섹션을 참조하세요.
+ 최대 첨부 파일 크기는 1MB입니다.
+ Database Mail에는 다중 AZ DB 인스턴스에 대한 추가 구성이 필요합니다. 자세한 내용은 [다중 AZ 배포에 대한 고려 사항](#SQLServer.DBMail.MAZ) 섹션을 참조하세요.
+ 미리 정의된 운영자에게 이메일 메시지를 보내도록 SQL Server 에이전트를 구성하는 것은 지원되지 않습니다.
# Database Mail 활성화
DB 인스턴스에 대해 Database Mail을 활성화하려면 다음 프로세스를 따릅니다.
1. 새 파라미터 그룹을 생성해야 합니다.
1. 파라미터 그룹을 수정하여 `database mail xps` 파라미터를 1로 설정합니다.
1. 파라미터 그룹을 DB 인스턴스에 연결합니다.
## Database Mail의 파라미터 그룹 생성
DB 인스턴스의 SQL Server 에디션 및 버전에 해당하는 `database mail xps` 파라미터의 파라미터 그룹을 생성합니다.
**참고**
기존 파라미터 그룹을 수정할 수도 있습니다. [Database Mail을 활성화하는 파라미터 수정](#DBMail.ModifyParamGroup)의 절차를 따르십시오.
### 콘솔
다음 예에서는 SQL Server Standard Edition 2016에 대한 파라미터 그룹을 생성합니다.
**파라미터 그룹을 생성하려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **파라미터 그룹**을 선택합니다.
1. [**Create parameter group**]을 선택합니다.
1. **서브넷 그룹 생성** 창에서 다음을 수행합니다.
1. **파라미터 그룹 패밀리**에서 **sqlserver-se-13.0**을 선택합니다.
1. **그룹 이름**에 파라미터 그룹의 식별자(예: **dbmail-sqlserver-se-13**)를 입력합니다.
1. **설명**에 **Database Mail XPs**를 입력합니다.
1. **생성(Create)**을 선택합니다.
### CLI
다음 예에서는 SQL Server Standard Edition 2016에 대한 파라미터 그룹을 생성합니다.
**파라미터 그룹을 생성하려면**
+ 다음 명령 중 하나를 사용합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds create-db-parameter-group \
--db-parameter-group-name dbmail-sqlserver-se-13 \
--db-parameter-group-family "sqlserver-se-13.0" \
--description "Database Mail XPs"
```
Windows의 경우:
```
aws rds create-db-parameter-group ^
--db-parameter-group-name dbmail-sqlserver-se-13 ^
--db-parameter-group-family "sqlserver-se-13.0" ^
--description "Database Mail XPs"
```
## Database Mail을 활성화하는 파라미터 수정
SQL Server 에디션 및 DB 인스턴스의 버전에 해당하는 파라미터 그룹의 `database mail xps` 파라미터를 수정합니다.
Database Mail을 활성화하려면 `database mail xps` 파라미터를 1로 설정합니다.
### 콘솔
다음 예에서는 SQL Server Standard Edition 2016에 대해 생성한 파라미터 그룹을 수정합니다.
**파라미터 그룹을 수정하려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **파라미터 그룹**을 선택합니다.
1. 파라미터 그룹(예: **ssis-sqlserver-se-13**)을 선택합니다.
1. **파라미터**에서 파라미터 목록을 **mail**로 필터링합니다.
1. [**database mail xps**]를 선택합니다.
1. **파라미터 편집**을 선택합니다.
1. **1**를 입력합니다.
1. **변경 사항 저장**을 선택합니다.
### CLI
다음 예에서는 SQL Server Standard Edition 2016에 대해 생성한 파라미터 그룹을 수정합니다.
**파라미터 그룹을 수정하려면**
+ 다음 명령 중 하나를 사용합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds modify-db-parameter-group \
--db-parameter-group-name dbmail-sqlserver-se-13 \
--parameters "ParameterName='database mail xps',ParameterValue=1,ApplyMethod=immediate"
```
Windows의 경우:
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name dbmail-sqlserver-se-13 ^
--parameters "ParameterName='database mail xps',ParameterValue=1,ApplyMethod=immediate"
```
## 파라미터 그룹과 DB 인스턴스 연결
AWS Management Console 또는 AWS CLI를 사용하여 Database Mail 파라미터 그룹을 DB 인스턴스와 연결할 수 있습니다.
### 콘솔
Database Mail 파라미터 그룹을 신규 또는 기존 DB 인스턴스와 연결할 수 있습니다.
+ 새 DB 인스턴스의 경우 인스턴스를 시작할 때 연결합니다. 자세한 내용은 [Amazon RDS DB 인스턴스 생성](USER_CreateDBInstance.md) 섹션을 참조하세요.
+ 기존 DB 인스턴스의 경우 인스턴스를 수정하여 연결합니다. 자세한 내용은 [Amazon RDS DB 인스턴스 수정](Overview.DBInstance.Modifying.md) 섹션을 참조하세요.
### CLI
Database Mail 파라미터 그룹을 신규 또는 기존 DB 인스턴스와 연결할 수 있습니다.
**Database Mail 파라미터 그룹을 사용하여 DB 인스턴스를 생성하려면**
+ 파라미터 그룹을 생성할 때 사용한 것과 동일한 DB 엔진 유형과 메이저 버전을 지정합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds create-db-instance \
--db-instance-identifier mydbinstance \
--db-instance-class db.m5.2xlarge \
--engine sqlserver-se \
--engine-version 13.00.5426.0.v1 \
--allocated-storage 100 \
--manage-master-user-password \
--master-username admin \
--storage-type gp2 \
--license-model li
--db-parameter-group-name dbmail-sqlserver-se-13
```
Windows의 경우:
```
aws rds create-db-instance ^
--db-instance-identifier mydbinstance ^
--db-instance-class db.m5.2xlarge ^
--engine sqlserver-se ^
--engine-version 13.00.5426.0.v1 ^
--allocated-storage 100 ^
--manage-master-user-password ^
--master-username admin ^
--storage-type gp2 ^
--license-model li ^
--db-parameter-group-name dbmail-sqlserver-se-13
```
**DB 인스턴스를 수정하고 Database Mail 파라미터 그룹을 연결하려면**
+ 다음 명령 중 하나를 사용합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds modify-db-instance \
--db-instance-identifier mydbinstance \
--db-parameter-group-name dbmail-sqlserver-se-13 \
--apply-immediately
```
Windows의 경우:
```
aws rds modify-db-instance ^
--db-instance-identifier mydbinstance ^
--db-parameter-group-name dbmail-sqlserver-se-13 ^
--apply-immediately
```
# Database Mail 구성
Database Mail을 구성하려면 다음 태스크를 수행합니다.
1. Database Mail 프로파일을 생성합니다.
1. Database Mail 계정을 생성합니다.
1. Database Mail 계정을 Database Mail 프로파일에 추가합니다.
1. Database Mail 프로파일에 사용자를 추가합니다.
**참고**
Database Mail을 구성하려면 `execute` 데이터베이스의 저장 프로시저에 대한 `msdb` 권한이 있는지 확인합니다.
## Database Mail 프로파일 생성
Database Mail 프로파일을 생성하려면 [sysmail\$1add\$1profile\$1sp](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sysmail-add-profile-sp-transact-sql) 저장 프로시저를 사용합니다. 다음 예제에서는 `Notifications`라는 프로파일을 생성합니다.
**프로파일을 생성하려면**
+ 다음 SQL 문을 사용합니다.
```
USE msdb
GO
EXECUTE msdb.dbo.sysmail_add_profile_sp
@profile_name = 'Notifications',
@description = 'Profile used for sending outgoing notifications using Amazon SES.';
GO
```
## Database Mail 계정 생성
Database Mail 계정을 생성하려면 [sysmail\$1add\$1account\$1sp](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sysmail-add-account-sp-transact-sql) 저장 프로시저를 사용합니다. 다음 예에서는 Amazon Simple Email Service를 사용하여 프라이빗 VPC 내의 RDS for SQL Server DB 인스턴스에서 `SES`라는 이름의 계정을 생성합니다.
Amazon SES를 사용하려면 다음 파라미터가 필요합니다.
+ `@email_address` - Amazon SES에서 확인된 자격 증명입니다. 자세한 내용은 [Amazon SES에서 확인된 자격 증명](https://docs.aws.amazon.com/ses/latest/dg/verify-addresses-and-domains.html)을 참조하세요.
+ `@mailserver_name` - Amazon SES SMTP 엔드포인트입니다. 자세한 내용은 [Amazon SES SMTP 엔드포인트에 연결](https://docs.aws.amazon.com/ses/latest/dg/smtp-connect.html)을 참조하세요.
+ `@username` - Amazon SES SMTP 사용자 이름입니다. 자세한 내용은 [Amazon SES SMTP 자격 증명 받기](https://docs.aws.amazon.com/ses/latest/dg/smtp-credentials.html)를 참조하세요.
AWS Identity and Access Management 사용자 이름을 사용하지 마세요.
+ `@password` - Amazon SES SMTP 암호입니다. 자세한 내용은 [Amazon SES SMTP 자격 증명 받기](https://docs.aws.amazon.com/ses/latest/dg/smtp-credentials.html)를 참조하세요.
**계정을 생성하려면**
+ 다음 SQL 문을 사용합니다.
```
USE msdb
GO
EXECUTE msdb.dbo.sysmail_add_account_sp
@account_name = 'SES',
@description = 'Mail account for sending outgoing notifications.',
@email_address = 'nobody@example.com',
@display_name = 'Automated Mailer',
@mailserver_name = 'vpce-0a1b2c3d4e5f-01234567.email-smtp.us-west-2.vpce.amazonaws.com',
@port = 587,
@enable_ssl = 1,
@username = 'Smtp_Username',
@password = 'Smtp_Password';
GO
```
**참고**
보안 모범 사례로 여기에 표시된 프롬프트 이외의 보안 인증 정보를 지정하는 것이 좋습니다.
## Database Mail 프로파일에 Database Mail 계정 추가
Database Mail 계정을 Database Mail 프로파일에 추가하려면 [sysmail\$1add\$1profileaccount\$1sp](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sysmail-add-profileaccount-sp-transact-sql) 저장 프로시저를 사용합니다. 다음 예에서는 `SES` 프로파일에 `Notifications` 계정을 추가합니다.
**프로파일에 계정을 추가하려면**
+ 다음 SQL 문을 사용합니다.
```
USE msdb
GO
EXECUTE msdb.dbo.sysmail_add_profileaccount_sp
@profile_name = 'Notifications',
@account_name = 'SES',
@sequence_number = 1;
GO
```
## Database Mail 프로파일에 사용자 추가
`msdb` 데이터베이스 보안 주체에 Database Mail 프로파일을 사용할 권한을 부여하려면 [sysmail\$1add\$1principalprofile\$1sp](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sysmail-add-principalprofile-sp-transact-sql) 저장 프로시저를 사용합니다. *보안 주체*는 SQL Server 리소스를 요청할 수 있는 엔터티입니다. 데이터베이스 보안 주체는 SQL Server 인증 사용자, Windows 인증 사용자 또는 Windows 인증 그룹에 매핑되어야 합니다.
다음 예에서는 `Notifications` 프로파일에 대한 퍼블릭 액세스 권한을 부여합니다.
**프로파일에 사용자를 추가하려면**
+ 다음 SQL 문을 사용합니다.
```
USE msdb
GO
EXECUTE msdb.dbo.sysmail_add_principalprofile_sp
@profile_name = 'Notifications',
@principal_name = 'public',
@is_default = 1;
GO
```
## Amazon RDS Database Mail에 대한 저장 프로시저 및 함수
Microsoft는 계정 및 프로필 생성, 나열, 업데이트, 삭제하는 등, Database Mail을 사용할 수 있도록 [저장 프로시저](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/database-mail-stored-procedures-transact-sql)를 제공합니다. 또한 RDS는 다음 표에 나와 있는 Database Mail용 저장 프로시저 및 함수도 제공합니다.
| 프로시저/함수 | 설명 |
| --- | --- |
| rds\$1fn\$1sysmail\$1allitems | 다른 사용자가 전송한 메시지를 포함하여 전송된 메시지를 표시합니다. |
| rds\$1fn\$1sysmail\$1event\$1log | 다른 사용자가 전송한 메시지에 대한 이벤트를 포함하여 이벤트를 표시합니다. |
| rds\$1fn\$1sysmail\$1mailattachments | 다른 사용자가 전송한 메시지의 첨부 파일을 포함하여 첨부 파일을 표시합니다. |
| rds\$1sysmail\$1control | 메일 대기열을 시작하고 중지합니다(DatabaseMail.exe 프로세스). |
| rds\$1sysmail\$1delete\$1mailitems\$1sp | Database Mail 내부 테이블에서 모든 사용자가 보낸 이메일 메시지를 삭제합니다. |
# Database Mail을 사용하여 이메일 메시지 보내기
[sp\$1send\$1dbmail](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-send-dbmail-transact-sql) 저장 프로시저를 사용하여 Database Mail을 통해 이메일 메시지를 보낼 수 있습니다.
## 사용법
```
EXEC msdb.dbo.sp_send_dbmail
@profile_name = 'profile_name',
@recipients = 'recipient1@example.com[; recipient2; ... recipientn]',
@subject = 'subject',
@body = 'message_body',
[@body_format = 'HTML'],
[@file_attachments = 'file_path1; file_path2; ... file_pathn'],
[@query = 'SQL_query'],
[@attach_query_result_as_file = 0|1]';
```
다음 파라미터는 필수 파라미터입니다.
+ `@profile_name` – 메시지를 보낼 Database Mail 프로파일의 이름입니다.
+ `@recipients` – 메시지를 보낼 이메일 주소의 세미콜론으로 구분된 목록입니다.
+ `@subject` – 메시지의 제목입니다.
+ `@body` – 메시지의 본문입니다. 선언된 변수를 본문으로 사용할 수도 있습니다.
다음 파라미터는 선택적입니다.
+ `@body_format` – 이 파라미터는 HTML 형식으로 이메일을 보내도록 선언된 변수와 함께 사용됩니다.
+ `@file_attachments` – 메시지 첨부 파일의 세미콜론으로 구분된 목록입니다. 파일 경로는 절대 경로여야 합니다.
+ `@query` – 실행할 SQL 쿼리입니다. 쿼리 결과는 파일로 첨부되거나 메시지 본문에 포함될 수 있습니다.
+ `@attach_query_result_as_file` – 쿼리 결과를 파일로 첨부할지 여부를 나타냅니다. 아니요(No)인 경우 0, 예(Yes)인 경우 1로 설정합니다. 기본값은 0입니다.
## 예제
다음 예에서는 이메일 메시지를 보내는 방법을 보여 줍니다.
**Example 한 명의 수신자에게 메시지 전송**
```
USE msdb
GO
EXEC msdb.dbo.sp_send_dbmail
@profile_name = 'Notifications',
@recipients = 'nobody@example.com',
@subject = 'Automated DBMail message - 1',
@body = 'Database Mail configuration was successful.';
GO
```
**Example 여러 수신자에게 메시지 전송**
```
USE msdb
GO
EXEC msdb.dbo.sp_send_dbmail
@profile_name = 'Notifications',
@recipients = 'recipient1@example.com;recipient2@example.com',
@subject = 'Automated DBMail message - 2',
@body = 'This is a message.';
GO
```
**Example SQL 쿼리 결과를 첨부 파일로 전송**
```
USE msdb
GO
EXEC msdb.dbo.sp_send_dbmail
@profile_name = 'Notifications',
@recipients = 'nobody@example.com',
@subject = 'Test SQL query',
@body = 'This is a SQL query test.',
@query = 'SELECT * FROM abc.dbo.test',
@attach_query_result_as_file = 1;
GO
```
**Example HTML 형식으로 메시지 전송**
```
USE msdb
GO
DECLARE @HTML_Body as NVARCHAR(500) = 'Hi,
Heading
See the report. Regards ';
EXEC msdb.dbo.sp_send_dbmail
@profile_name = 'Notifications',
@recipients = 'nobody@example.com',
@subject = 'Test HTML message',
@body = @HTML_Body,
@body_format = 'HTML';
GO
```
**Example 데이터베이스에서 특정 이벤트가 발생할 때 트리거를 사용하여 메시지 전송**
```
USE AdventureWorks2017
GO
IF OBJECT_ID ('Production.iProductNotification', 'TR') IS NOT NULL
DROP TRIGGER Purchasing.iProductNotification
GO
CREATE TRIGGER iProductNotification ON Production.Product
FOR INSERT
AS
DECLARE @ProductInformation nvarchar(255);
SELECT
@ProductInformation = 'A new product, ' + Name + ', is now available for $' + CAST(StandardCost AS nvarchar(20)) + '!'
FROM INSERTED i;
EXEC msdb.dbo.sp_send_dbmail
@profile_name = 'Notifications',
@recipients = 'nobody@example.com',
@subject = 'New product information',
@body = @ProductInformation;
GO
```
# 메시지, 로그 및 첨부 파일 보기
RDS 저장 프로시저를 사용하여 메시지, 이벤트 로그 및 첨부 파일을 볼 수 있습니다.
**모든 이메일 메시지를 보려면**
+ 다음 SQL 쿼리를 사용합니다.
```
SELECT * FROM msdb.dbo.rds_fn_sysmail_allitems(); --WHERE sent_status='sent' or 'failed' or 'unsent'
```
**모든 이메일 이벤트 로그를 보려면**
+ 다음 SQL 쿼리를 사용합니다.
```
SELECT * FROM msdb.dbo.rds_fn_sysmail_event_log();
```
**모든 이메일 첨부 파일을 보려면**
+ 다음 SQL 쿼리를 사용합니다.
```
SELECT * FROM msdb.dbo.rds_fn_sysmail_mailattachments();
```
# 메시지 삭제
`rds_sysmail_delete_mailitems_sp` 저장 프로시저를 사용하여 메시지를 삭제합니다.
**참고**
RDS는 DBMail 기록 데이터의 크기가 1GB에 도달하고 보존 기간이 24시간 이상인 경우 메일 테이블 항목을 자동으로 삭제합니다.
메일 항목을 장기간 보존하려는 경우 아카이빙할 수 있습니다. 자세한 내용은 Microsoft 설명서의 [Database Mail 메시지 및 이벤트 로그를 아카이빙하기 위한 SQL Server 에이전트 작업 생성](https://docs.microsoft.com/en-us/sql/relational-databases/database-mail/create-a-sql-server-agent-job-to-archive-database-mail-messages-and-event-logs)을 참조하세요.
**모든 이메일 메시지를 삭제하려면**
+ 다음 SQL 문을 사용합니다.
```
DECLARE @GETDATE datetime
SET @GETDATE = GETDATE();
EXECUTE msdb.dbo.rds_sysmail_delete_mailitems_sp @sent_before = @GETDATE;
GO
```
**특정 상태의 이메일 메시지를 모두 삭제하려면**
+ 실패한 메시지를 모두 삭제하려면 다음 SQL 문을 사용합니다.
```
DECLARE @GETDATE datetime
SET @GETDATE = GETDATE();
EXECUTE msdb.dbo.rds_sysmail_delete_mailitems_sp @sent_status = 'failed';
GO
```
# 메일 대기열 시작 및 중지
다음 지침을 사용하여 DB 메일 대기열을 시작하고 중지합니다.
**Topics**
+ [메일 대기열 시작](#SQLServer.DBMail.Start)
+ [메일 대기열 중지](#SQLServer.DBMail.Stop)
## 메일 대기열 시작
`rds_sysmail_control` 저장 프로시저를 사용하여 Database Mail 프로세스를 시작합니다.
**참고**
Database Mail을 활성화하면 메일 대기열이 자동으로 시작됩니다.
**메일 대기열을 시작하려면**
+ 다음 SQL 문을 사용합니다.
```
EXECUTE msdb.dbo.rds_sysmail_control start;
GO
```
## 메일 대기열 중지
`rds_sysmail_control` 저장 프로시저를 사용하여 Database Mail 프로세스를 중지합니다.
**메일 대기열을 중지하려면**
+ 다음 SQL 문을 사용합니다.
```
EXECUTE msdb.dbo.rds_sysmail_control stop;
GO
```
## 첨부 파일 작업
다음 첨부 파일 확장명은 RDS on SQL Server에서 보낸 Database Mail 메시지에서 지원되지 않습니다. .ade, .adp, .apk, .appx, .appxbundle, .bat, .bak, .cab, .chm, .cmd, .com, .cpl, .dll, .dmg, .exe, .hta, .inf1, .ins, .isp, .iso, .jar, .job, .js, .jse, .ldf, .lib, .lnk, .mde, .mdf, .msc, .msi, .msix, .msixbundle, .msp, .mst, .nsh, .pif, .ps, .ps1, .psc1, .reg, .rgs, .scr, .sct, .shb, .shs, .svg, .sys, .u3p, .vb, .vbe, .vbs, .vbscript, .vxd, .ws, .wsc, .wsf, .wsh.
Database Mail은 현재 사용자의 Microsoft Windows 보안 컨텍스트를 사용하여 파일에 대한 액세스를 제어합니다. SQL Server 인증을 사용하여 로그인하는 사용자는 `@file_attachments` 저장 프로시저와 함께 `sp_send_dbmail` 파라미터를 사용하여 파일을 첨부할 수 없습니다. Windows에서는 SQL Server가 원격 컴퓨터에서 다른 원격 컴퓨터로 자격 증명을 제공할 수 없습니다. 따라서 SQL Server를 실행하는 컴퓨터가 아닌 다른 컴퓨터에서 이 명령을 실행하면 Database Mail이 네트워크 공유에서 파일을 연결할 수 없습니다.
하지만 SQL Server 에이전트 작업을 사용하면 파일을 첨부할 수 있습니다. SQL Server 에이전트에 대한 자세한 내용은 Microsoft 설명서에서 [Amazon RDS에 SQL Server Agent 사용](Appendix.SQLServer.CommonDBATasks.Agent.md) 및 [SQL Server 에이전트](https://docs.microsoft.com/en-us/sql/ssms/agent/sql-server-agent)를 참조하세요.
## 다중 AZ 배포에 대한 고려 사항
다중 AZ DB 인스턴스에 Database Mail을 구성하면 해당 구성이 보조 인스턴스에 자동으로 전파되지 않습니다. 다중 AZ 인스턴스를 단일 AZ 인스턴스로 변환하고 Database Mail을 구성한 다음 DB 인스턴스를 다시 다중 AZ로 변환하는 것이 좋습니다. 그러면 기본 노드와 보조 노드 모두에 Database Mail 구성이 적용됩니다.
Database Mail이 구성된 다중 AZ 인스턴스에서 읽기 전용 복제본을 생성하는 경우 해당 복제본은 구성을 상속하지만 SMTP 서버에 대한 암호는 상속하지 않습니다. 해당 암호로 Database Mail 계정을 업데이트합니다.
## SMTP(포트 25) 제한 사항 제거
기본적으로 AWS는 RDS for SQL Server DB 인스턴스에 대한 SMTP(포트 25)의 아웃바운드 트래픽을 차단합니다. 이는 탄력적 네트워크 인터페이스 소유자의 정책에 따라 스팸을 방지하기 위해 수행됩니다. 필요한 경우 이 제한사항을 제거할 수 있습니다. 자세한 내용은 에서 [Amazon EC2 인스턴스 또는 Lamda 함수에서 포트 25와 관련한 제한을 없애려면 어떻게 해야 하나요?](https://repost.aws/knowledge-center/ec2-port-25-throttle)를 참조하세요.
# Amazon RDS for SQL Server의 tempdb 데이터베이스에 대한 인스턴스 스토어 지원
*인스턴스 스토어*는 DB 인스턴스에 블록 수준의 임시 스토리지를 제공합니다. 스토리지는 호스트 컴퓨터에 물리적으로 연결된 디스크에 위치합니다. 이러한 디스크에는 SSD(솔리드 스테이트 드라이브)를 기반으로 하는 NVMe(Non-Volatile Memory Express) 인스턴스 스토리지가 있습니다. 이 스토리지는 짧은 지연 시간, 매우 높은 임의 I/O 성능, 높은 순차 읽기 처리량에 최적화되어 있습니다.
인스턴스 스토어에 `tempdb` 데이터 파일과 `tempdb` 로그 파일을 배치하면 Amazon EBS를 기반으로 하는 표준 스토리지에 비해 읽기 및 쓰기 지연 시간을 줄일 수 있습니다.
**참고**
SQL Server 데이터베이스 파일 및 데이터베이스 로그 파일은 인스턴스 스토어에 저장되지 않습니다.
## 인스턴스 스토어 활성화
RDS가 다음 인스턴스 클래스 중 하나로 DB 인스턴스를 프로비저닝하면 `tempdb` 데이터베이스가 인스턴스 스토어에 자동으로 배치됩니다.
+ db.m5d
+ db.r5d
+ db.x2iedn
인스턴스 스토어를 활성화하려면 다음 중 하나를 수행합니다.
+ 이러한 인스턴스 유형 중 하나를 사용하여 SQL Server DB 인스턴스를 생성합니다. 자세한 내용은 [Amazon RDS DB 인스턴스 생성](USER_CreateDBInstance.md) 섹션을 참조하세요.
+ 기존 SQL Server DB 인스턴스 중 하나를 사용할 수 있도록 수정합니다. 자세한 내용은 [Amazon RDS DB 인스턴스 수정](Overview.DBInstance.Modifying.md) 섹션을 참조하세요.
인스턴스 스토어는 이러한 인스턴스 유형 중 하나 이상이 지원되는 모든 AWS 리전에서 사용 가능합니다. `db.m5d` 및 `db.r5d` 인스턴스 클래스에 대한 자세한 내용은 [DB 인스턴스 클래스](Concepts.DBInstanceClass.md) 섹션을 참조하세요. Amazon RDS for SQL Server에서 지원하는 인스턴스 클래스에 대한 자세한 내용은 [Microsoft SQL Server를 위한 DB 인스턴스 클래스 지원](SQLServer.Concepts.General.InstanceClasses.md) 단원을 참조하세요.
## 파일 위치와 크기 고려 사항
인스턴스 스토어가 없는 인스턴스에서는 RDS가 `tempdb` 데이터 및 로그 파일을 `D:\rdsdbdata\DATA` 디렉터리에 저장합니다. 두 파일은 기본적으로 8MB에서 시작합니다.
인스턴스 스토어가 있는 인스턴스에서는 RDS가 `tempdb` 데이터 및 로그 파일을 `T:\rdsdbdata\DATA` 디렉터리에 저장합니다.
`tempdb`에는 하나의 데이터 파일(`tempdb.mdf`)과 하나의 로그 파일(`templog.ldf`)만 있지만, `templog.ldf`는 기본적으로 8MB에서 시작하며, `tempdb.mdf`는 인스턴스 스토리지 용량의 80% 이상에서 시작합니다. 스토리지 용량의 20% 또는 200GB 중 더 적은 용량에서 자유롭게 시작할 수 있습니다. 여러 `tempdb` 데이터 파일은 80% 디스크 공간을 균등하게 분할하지만 로그 파일은 항상 초기 크기가 8MB입니다.
예를 들어 DB 인스턴스 클래스를 `db.m5.2xlarge`에서 `db.m5d.2xlarge`로 수정하면 `tempdb` 데이터 파일 크기가 각각 8MB에서 총 234GB로 늘어납니다.
**참고**
인스턴스 스토어(`tempdb`)의 `T:\rdsdbdata\DATA` 데이터 및 로그 파일 외에, 데이터 볼륨(`tempdb`)에도 `D:\rdsdbdata\DATA` 데이터 및 로그 파일을 추가로 생성할 수 있습니다. 해당 파일의 초기 크기는 항상 8MB입니다.
## 백업 고려 사항
오랫동안 백업을 보존해야 할 수 있으므로 시간이 지나면서 비용이 발생합니다. `tempdb` 데이터와 로그 블록은 워크로드에 따라 매우 자주 변경될 수 있습니다. 이렇게 하면 DB 스냅샷 크기가 크게 증가할 수 있습니다.
`tempdb`이(가) 인스턴스 스토어에 있는 경우 스냅샷에 임시 파일이 포함되지 않습니다. 즉, EBS 전용 스토리지에 비해 스냅샷 크기가 더 작고 더 적은 여유 백업 할당량을 사용합니다.
## 디스크 가득 참 오류
인스턴스 스토어에서 사용 가능한 공간을 모두 사용하면 다음과 같은 오류가 발생할 수 있습니다.
+ 데이터베이스 'tempdb'에 대한 트랜잭션 로그가 'ACTIVE\$1TRANSACTION' 때문에 가득 찼습니다.
+ PRIMARY' 파일 그룹이 가득 찼기 때문에 데이터베이스 'tempdb'에 있는 객체 'dbo.SORT 임시 실행 스토리지: 140738941419520’에 대한 공간을 할당할 수 없습니다. 불필요한 파일을 삭제하거나, 파일 그룹에서 객체를 삭제하거나, 파일 그룹에 파일을 추가하거나, 파일 그룹의 기존 파일에 대해 자동 증가를 설정하여 디스크 공간을 생성합니다.
인스턴스 스토어가 가득 차면 다음 중 하나 이상을 수행할 수 있습니다.
+ 워크로드 또는 `tempdb` 사용 방식을 조정합니다.
+ DB 인스턴스 클래스를 더 많은 NVMe 스토리지와 함께 사용하도록 확장합니다.
+ 인스턴스 스토어 사용을 중지하고, EBS 스토리지만 있는 인스턴스 클래스를 사용합니다.
+ EBS 볼륨에서 `tempdb`에 대한 보조 데이터 또는 로그 파일을 추가하여 혼합 모드를 사용합니다.
## 인스턴스 스토어 제거
인스턴스 스토어를 제거하려면 db.m5, db.r5 또는 db.x1e등 인스턴스 스토어를 지원하지 않는 인스턴스 유형을 사용하도록 SQL Server DB 인스턴스를 수정합니다.
**참고**
인스턴스 스토어를 제거하면 임시 파일이 `D:\rdsdbdata\DATA` 디렉터리로 이동되고 크기가 8MB로 줄어듭니다.
# Amazon RDS for Microsoft SQL Server에 확장 이벤트 사용
Microsoft SQL Server의 확장 이벤트를 사용하여 Amazon RDS for SQL Server에 대한 디버깅 및 문제 해결 정보를 캡처할 수 있습니다. 확장 이벤트는 Microsoft에서 더 이상 사용되지 않는 SQL 추적 및 서버 프로파일러를 대체합니다. 확장 이벤트는 프로파일러 추적과 유사하지만 추적되는 이벤트를 보다 세부적으로 제어할 수 있습니다. Amazon RDS에서 확장 이벤트는 SQL Server 버전 2016 이상에 대해 지원됩니다. 자세한 내용은 Microsoft 설명서의 [Extended events overview](https://docs.microsoft.com/en-us/sql/relational-databases/extended-events/extended-events)를 참조하세요.
확장 이벤트는 Amazon RDS for SQL Server에서 마스터 사용자 권한이 있는 사용자에 대해 자동으로 활성화됩니다.
**Topics**
+ [제한 및 권장 사항](#SQLServer.ExtendedEvents.Limits)
+ [RDS for SQL Server에 대한 확장 이벤트 구성](#SQLServer.ExtendedEvents.Config)
+ [다중 AZ 배포에 대한 고려 사항](#SQLServer.ExtendedEvents.MAZ)
+ [확장 이벤트 파일 쿼리](#SQLServer.ExtendedEvents.Querying)
## 제한 및 권장 사항
RDS for SQL Server에서 확장 이벤트를 사용하는 경우 다음과 같은 제한 사항이 적용됩니다.
+ 확장 이벤트는 Enterprise 및 Standard Edition에 대해서만 지원됩니다.
+ 기본 확장 이벤트 세션은 변경할 수 없습니다.
+ 세션 메모리 파티션 모드를 `NONE`으로 설정해야 합니다.
+ 세션 이벤트 보존 모드는 `ALLOW_SINGLE_EVENT_LOSS` 또는 `ALLOW_MULTIPLE_EVENT_LOSS`일 수 있습니다.
+ ETW(Event Tracing for Windows) 대상은 지원되지 않습니다.
+ 파일 대상이 `D:\rdsdbdata\log` 디렉터리에 있어야 합니다.
+ 페어 매칭 대상의 경우 `respond_to_memory_pressure` 속성을 `1`로 설정합니다.
+ 링 버퍼 대상 메모리는 4MB를 초과할 수 없습니다.
+ 다음은 지원되지 않는 작업입니다.
+ `debug_break`
+ `create_dump_all_threads`
+ `create_dump_single_threads`
+ `rpc_completed` 이벤트는 다음 버전 이상에서 지원됩니다. 15.0.4083.2, 14.0.3370.1, 13.0.5865.1, 12.0.6433.1, 11.0.7507.2.
## RDS for SQL Server에 대한 확장 이벤트 구성
RDS for SQL Server에서 확장 이벤트 세션의 특정 파라미터 값을 구성할 수 있습니다. 다음 표에서는 구성 가능한 파라미터에 대해 설명합니다.
| 파라미터 이름 | 설명 | RDS 기본값 | 최소값 | 최대값 |
| --- | --- | --- | --- | --- |
| xe\$1session\$1max\$1memory | 이벤트 버퍼링을 위해 세션에 할당할 최대 메모리 양을 지정합니다. 이 값은 이벤트 세션의 max\$1memory 설정에 해당합니다. | 4MB | 4MB | 8MB |
| xe\$1session\$1max\$1event\$1size | 큰 이벤트에 허용되는 최대 메모리 크기를 지정합니다. 이 값은 이벤트 세션의 max\$1event\$1size 설정에 해당합니다. | 4MB | 4MB | 8MB |
| xe\$1session\$1max\$1dispatch\$1latency | 이벤트가 확장 이벤트 세션 대상으로 전달되기 전에 메모리에서 버퍼링되는 시간을 지정합니다. 이 값은 이벤트 세션의 max\$1dispatch\$1latency 설정에 해당합니다. | 30초 | 1초 | 30초 |
| xe\$1file\$1target\$1size | 파일 대상의 최대 크기를 지정합니다. 이 값은 파일 대상의 max\$1file\$1size 설정에 해당합니다. | 100MB | 10MB | 1GB |
| xe\$1file\$1retention | 이벤트 세션의 파일 대상에서 생성된 파일의 보존 시간(일)을 지정합니다. | 7일 | 0일 | 7일 |
**참고**
`xe_file_retention`을 0으로 설정하면 SQL Server가 해당 파일에 대한 잠금을 해제한 후에 .xel 파일이 자동으로 제거됩니다. .xel 파일이 `xe_file_target_size`에 설정된 크기 제한에 도달할 때마다 잠금이 해제됩니다.
`rdsadmin.dbo.rds_show_configuration` 저장 프로시저를 사용하여 이러한 파라미터의 현재 값을 표시할 수 있습니다. 예를 들어 `xe_session_max_memory`의 현재 설정을 보려면 다음 SQL 문을 사용합니다.
```
exec rdsadmin.dbo.rds_show_configuration 'xe_session_max_memory'
```
`rdsadmin.dbo.rds_set_configuration` 저장 프로시저를 사용하여 설정을 수정할 수 있습니다. 예를 들어 `xe_session_max_memory`를 4MB로 설정하려면 다음 SQL 문을 사용합니다.
```
exec rdsadmin.dbo.rds_set_configuration 'xe_session_max_memory', 4
```
## 다중 AZ 배포에 대한 고려 사항
기본 DB 인스턴스에서 확장 이벤트 세션을 생성하면 예비 복제본으로 전파되지 않습니다. 장애 조치하고, 새 기본 DB 인스턴스에서 확장 이벤트 세션을 생성할 수 있습니다. 또는 다중 AZ 구성을 제거한 다음 다시 추가하여 확장 이벤트 세션을 대기 복제본에 전파할 수 있습니다. RDS는 대기 복제본에서 기본이 아닌 모든 확장 이벤트 세션을 중지하므로, 이러한 세션은 대기 복제본에서 리소스를 소모하지 않습니다. 따라서 예비 복제본이 기본 DB 인스턴스가 된 후에는 새 기본 복제본에서 확장 이벤트 세션을 수동으로 시작해야 합니다.
**참고**
이 방법은 Always On 가용성 그룹과 데이터베이스 미러링에 모두 적용됩니다.
SQL Server 에이전트 작업을 사용하여 대기 복제본을 추적하고, 대기 복제본이 기본 복제본이 될 경우 세션을 시작할 수도 있습니다. 예를 들어 SQL Server 에이전트 작업 단계에서 다음 쿼리를 사용하여 기본 DB 인스턴스의 이벤트 세션을 다시 시작합니다.
```
BEGIN
IF (DATABASEPROPERTYEX('rdsadmin','Updateability')='READ_WRITE'
AND DATABASEPROPERTYEX('rdsadmin','status')='ONLINE'
AND (DATABASEPROPERTYEX('rdsadmin','Collation') IS NOT NULL OR DATABASEPROPERTYEX('rdsadmin','IsAutoClose')=1)
)
BEGIN
IF NOT EXISTS (SELECT 1 FROM sys.dm_xe_sessions WHERE name='xe1')
ALTER EVENT SESSION xe1 ON SERVER STATE=START
IF NOT EXISTS (SELECT 1 FROM sys.dm_xe_sessions WHERE name='xe2')
ALTER EVENT SESSION xe2 ON SERVER STATE=START
END
END
```
이 쿼리는 해당 세션이 중지 상태인 경우, 기본 DB 인스턴스에서 이벤트 세션 `xe1` 및 `xe2`를 다시 시작합니다. 이 쿼리에 편리한 간격으로 일정을 추가할 수도 있습니다.
## 확장 이벤트 파일 쿼리
SQL Server Management Studio 또는 `sys.fn_xe_file_target_read_file` 함수를 사용하여 파일 대상을 사용하는 확장 이벤트의 데이터를 볼 수 있습니다. 이 함수에 대한 자세한 내용은 Microsoft 설명서의 [sys.fn\$1xe\$1file\$1target\$1read\$1file(Transact-SQL)](https://docs.microsoft.com/en-us/sql/relational-databases/system-functions/sys-fn-xe-file-target-read-file-transact-sql)을 참조하세요.
확장 이벤트 파일 대상은 RDS for SQL Server의 `D:\rdsdbdata\log` 디렉터리에만 파일을 쓸 수 있습니다.
예를 들어 이름이 `xe`로 시작하는 확장 이벤트 세션의 모든 파일의 내용을 나열하려면 다음 SQL 쿼리를 사용합니다.
```
SELECT * FROM sys.fn_xe_file_target_read_file('d:\rdsdbdata\log\xe*', null,null,null);
```
# RDS for SQL Server를 사용하여 트랜잭션 로그 백업에 액세스
RDS for SQL Server 트랜잭션 로그 백업에 액세스하면 데이터베이스의 트랜잭션 로그 백업 파일을 나열하고 대상 Amazon S3 버킷에 복사할 수 있습니다. Amazon S3 버킷의 트랜잭션 로그 백업을 복사하면 전체 및 차등 데이터베이스 백업과 함께 사용하여 특정 시점 데이터베이스 복원을 수행할 수 있습니다. RDS 저장 프로시저를 사용하여 트랜잭션 로그 백업에 대한 액세스를 설정하고, 사용 가능한 트랜잭션 로그 백업을 나열하고, 이를 Amazon S3 버킷에 복사합니다.
트랜잭션 로그 백업에 대한 액세스가 제공하는 기능과 이점은 다음과 같습니다.
+ RDS for SQL Server DB 인스턴스에 있는 데이터베이스의 사용 가능한 트랜잭션 로그 백업의 메타데이터를 나열하고 볼 수 있습니다.
+ RDS for SQL Server에서 대상 Amazon S3 버킷으로 사용 가능한 트랜잭션 로그 백업을 복사합니다.
+ 전체 DB 인스턴스를 복원할 필요 없이 특정 시점 데이터베이스 복원을 수행합니다. DB 인스턴스 특정 시점 복원에 대한 자세한 내용은 [Amazon RDS에서 DB 인스턴스를 지정된 시간으로 복원](USER_PIT.md)을 참조하세요.
## 가용성 및 지원
트랜잭션 로그 백업에 대한 액세스는 모든 AWS 리전에서 지원합니다. 트랜잭션 로그 백업에 대한 액세스는 Amazon RDS에서 지원되는 모든 버전의 Microsoft SQL Server에서 사용할 수 있습니다.
## 요구 사항
트랜잭션 로그 백업에 대한 액세스를 활성화하려면 먼저 다음 요구 사항을 충족해야 합니다.
+ DB 인스턴스에서 자동 백업을 활성화하고 백업 보존을 1일 이상의 값으로 설정해야 합니다. 자동 백업 활성화 및 보존 정책 구성에 대한 자세한 내용은 [자동 백업 활성화](USER_WorkingWithAutomatedBackups.Enabling.md)을 참조하세요.
+ Amazon S3 버킷이 소스 DB 인스턴스와 동일한 계정 및 리전에 있어야 합니다. 트랜잭션 로그 백업에 대한 액세스를 활성화하기 전에 트랜잭션 로그 백업 파일에 사용할 기존 Amazon S3 버킷을 선택하거나 [새 버킷을 생성](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingaBucket.html)합니다.
+ Amazon RDS가 트랜잭션 로그 파일을 복사할 수 있도록 Amazon S3 버킷 권한 정책을 다음과 같이 구성해야 합니다.
1. 버킷의 객체 계정 소유권 속성을 **Bucket Owner Preferred**(버킷 소유자 선호)로 설정합니다.
1. 다음 정책을 추가합니다. 기본적으로 정책이 없으므로 버킷 ACL(액세스 제어 목록)을 사용하여 버킷 정책을 편집하고 추가합니다.
다음 예에서는 ARN을 사용하여 리소스를 지정합니다. 서비스 권한을 특정 리소스로 제한하는 리소스 기반 신뢰 관계의 `SourceArn` 및 `SourceAccount` 전역 조건 컨텍스트 키를 사용하는 것이 좋습니다. ARN 작업에 대한 자세한 내용은 [Amazon 리소스 이름(ARN)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) 및 [Amazon RDS의 Amazon 리소스 이름(ARN)](USER_Tagging.ARN.md)을 참조하세요.
**Example 트랜잭션 로그 백업 액세스를 위한 Amazon S3 권한 정책 예**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Only allow writes to my bucket with bucket owner full control",
"Effect": "Allow",
"Principal": {
"Service": "backups.rds.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/{customer_path}/*",
"Condition": {
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control",
"aws:sourceAccount": "{customer_account}",
"aws:sourceArn": "{db_instance_arn}"
}
}
}
]
}
```
------
+ Amazon S3 버킷에 액세스하기 위한 AWS Identity and Access Management(IAM) 역할. 이미 IAM 역할이 있으면 그 역할을 사용하면 됩니다. AWS Management Console을 사용하여 `SQLSERVER_BACKUP_RESTORE` 옵션을 추가할 때 새 IAM 역할이 생성되도록 선택할 수도 있습니다. 또는 수동으로 역할을 새로 만들 수 있습니다. `SQLSERVER_BACKUP_RESTORE`를 사용하여 IAM 역할을 생성하고 구성하는 방법에 대한 자세한 내용은 [기본 백업 및 복원을 위한 IAM 역할 수동으로 만들기](SQLServer.Procedural.Importing.Native.Enabling.md#SQLServer.Procedural.Importing.Native.Enabling.IAM)을 참조하세요.
+ DB 인스턴스의 옵션 그룹에 `SQLSERVER_BACKUP_RESTORE` 옵션을 추가해야 합니다. `SQLSERVER_BACKUP_RESTORE` 옵션 추가 방법에 대한 자세한 내용은 [SQL Server에서 기본 백업 및 복원 지원](Appendix.SQLServer.Options.BackupRestore.md)을 참조하세요.
**참고**
DB 인스턴스에 스토리지 암호화가 활성화된 경우 기본 백업 및 복원 옵션 그룹에 제공된 IAM 역할에 AWS KMS(KMS) 작업 및 키를 제공해야 합니다.
필요에 따라 `rds_restore_log` 저장 프로시저를 사용하여 특정 시점 데이터베이스 복원을 수행하려는 경우, 기본 백업 및 복원 옵션 그룹과 트랜잭션 로그 백업에 대한 액세스에 동일한 Amazon S3 경로를 사용하는 것이 좋습니다. 이 방법을 사용하면 Amazon RDS가 옵션 그룹의 역할을 맡아 복원 로그 기능을 수행할 때 동일한 Amazon S3 경로에서 트랜잭션 로그 백업을 검색할 수 있습니다.
+ DB 인스턴스가 암호화된 경우 암호화 유형(AWS 관리형 키 또는 고객 관리형 키)과 관계없이 IAM 역할 및`rds_tlog_backup_copy_to_S3` 저장 프로시저에 고객 관리형 KMS 키를 제공해야 합니다.
## 제한 및 권장 사항
트랜잭션 로그 백업에 대한 액세스에는 다음과 같은 제한 및 권장 사항이 있습니다.
+ 백업 보존 기간이 1\$135일로 구성된 DB 인스턴스의 경우 최대 지난 7일간의 트랜잭션 로그 백업을 나열하고 복사할 수 있습니다.
+ 트랜잭션 로그 백업 액세스에 사용되는 Amazon S3 버킷은 소스 DB 인스턴스와 동일한 계정 및 리전에 있어야 합니다. 계정 간 및 리전 간 복사는 지원되지 않습니다.
+ 하나의 Amazon S3 버킷만 트랜잭션 로그 백업을 복사할 대상으로 구성할 수 있습니다. `rds_tlog_copy_setup` 저장 프로시저를 사용하여 새 대상 Amazon S3 버킷을 선택할 수 있습니다. 새 대상 Amazon S3 버킷 선택에 대한 자세한 내용은 [트랜잭션 로그 백업에 대한 액세스 설정](USER.SQLServer.AddlFeat.TransactionLogAccess.Enabling.md)을 참조하세요.
+ RDS 인스턴스에 스토리지 암호화가 활성화되지 않은 경우 `rds_tlog_backup_copy_to_S3` 저장 프로시저를 사용할 때 KMS 키를 지정할 수 없습니다.
+ 다중 계정 복사는 지원되지 않습니다. 복사에 사용되는 IAM 역할은 DB 인스턴스 소유자 계정 내의 Amazon S3 버킷에 대한 쓰기 액세스만 허용합니다.
+ RDS for SQL Server DB 인스턴스에서는 유형에 관계없이 두 개의 동시 작업만 실행할 수 있습니다.
+ 지정된 시간에 단일 데이터베이스에 대해 하나의 복사 작업만 실행할 수 있습니다. DB 인스턴스에 있는 여러 데이터베이스의 트랜잭션 로그 백업을 복사하려면 각 데이터베이스마다 별도의 복사 작업을 사용하세요.
+ Amazon S3 버킷에 동일한 이름으로 이미 존재하는 트랜잭션 로그 백업을 복사하는 경우 기존 트랜잭션 로그 백업을 덮어씁니다.
+ 기본 DB 인스턴스의 트랜잭션 로그 백업에 액세스할 수 있는 저장 프로시저만 실행할 수 있습니다. RDS for SQL Server 읽기 전용 복제본이나 다중 AZ DB 클러스터의 보조 인스턴스에서는 이러한 저장 프로시저를 실행할 수 없습니다.
+ `rds_tlog_backup_copy_to_S3` 저장 프로시저가 실행되는 동안 RDS for SQL Server DB 인스턴스를 재부팅하면 DB 인스턴스가 다시 온라인 상태가 될 때 작업이 처음부터 자동으로 다시 시작됩니다. 재부팅 전에 작업이 실행되는 동안 Amazon S3 버킷에 복사된 모든 트랜잭션 로그 백업이 덮어쓰기됩니다.
+ Microsoft SQL Server 시스템 데이터베이스와 `RDSAdmin` 데이터베이스는 트랜잭션 로그 백업에 액세스하도록 구성할 수 없습니다.
+ SSE-KMS로 암호화된 버킷에 복사하는 것은 지원되지 않습니다.
# 트랜잭션 로그 백업에 대한 액세스 설정
트랜잭션 로그 백업에 대한 액세스를 설정하려면 [요구 사항](USER.SQLServer.AddlFeat.TransactionLogAccess.md#USER.SQLServer.AddlFeat.TransactionLogAccess.Requirements) 섹션의 요구 사항 목록을 완료한 다음 `rds_tlog_copy_setup` 저장 프로시저를 실행합니다. 이 프로시저를 통해 DB 인스턴스 수준에서 트랜잭션 로그 백업 기능에 액세스할 수 있습니다. DB 인스턴스의 개별 데이터베이스마다 이를 실행할 필요는 없습니다.
**중요**
각 데이터베이스의 SQL Server 내에서 트랜잭션 로그 백업에 대한 액세스를 구성하고 사용할 수 있는 `db_owner` 역할을 데이터베이스 사용자에게 부여해야 합니다.
**Example 사용법:**
```
exec msdb.dbo.rds_tlog_copy_setup
@target_s3_arn='arn:aws:s3:::amzn-s3-demo-bucket/myfolder';
```
다음 파라미터는 필수입니다.
+ `@target_s3_arn` - 트랜잭션 로그 백업 파일을 복사할 대상 Amazon S3 버킷의 ARN입니다.
**Example Amazon S3 대상 버킷 설정 예:**
```
exec msdb.dbo.rds_tlog_copy_setup @target_s3_arn='arn:aws:s3:::amzn-s3-demo-logging-bucket/mytestdb1';
```
구성을 검증하려면 `rds_show_configuration` 저장 프로시저를 호출합니다.
**Example 구성 검증 예:**
```
exec rdsadmin.dbo.rds_show_configuration @name='target_s3_arn_for_tlog_copy';
```
트랜잭션 로그 백업에 대한 액세스를 수정하여 다른 Amazon S3 버킷을 가리키도록 하려면 현재 Amazon S3 버킷 값을 확인하고 `@target_s3_arn`의 새 값을 사용하여 `rds_tlog_copy_setup` 저장 프로시저를 다시 실행하면 됩니다.
**Example 트랜잭션 로그 백업 액세스가 구성된 기존 Amazon S3 버킷 보기 예**
```
exec rdsadmin.dbo.rds_show_configuration @name='target_s3_arn_for_tlog_copy';
```
**Example 새 대상 Amazon S3 버킷으로 업데이트 예**
```
exec msdb.dbo.rds_tlog_copy_setup @target_s3_arn='arn:aws:s3:::amzn-s3-demo-logging-bucket1/mynewfolder';
```
# 사용 가능한 트랜잭션 로그 백업 나열
RDS for SQL Server를 사용하면 전체 복구 모델과 백업 보존 기간이 1일 이상으로 설정된 DB 인스턴스를 사용하도록 구성된 데이터베이스는 트랜잭션 로그 백업이 자동으로 활성화됩니다. 트랜잭션 로그 백업에 대한 액세스를 활성화하면 최대 7일간의 해당 트랜잭션 로그 백업을 Amazon S3 버킷에 복사할 수 있습니다.
트랜잭션 로그 백업에 대한 액세스를 활성화한 후에는 이를 사용하여 사용 가능한 트랜잭션 로그 백업 파일을 나열하고 복사할 수 있습니다.
**트랜잭션 로그 백업 나열**
개별 데이터베이스에 사용할 수 있는 모든 트랜잭션 로그 백업을 나열하려면 `rds_fn_list_tlog_backup_metadata` 함수를 호출합니다. 함수를 호출할 때 `ORDER BY` 또는 `WHERE` 절을 사용할 수 있습니다.
**Example 사용 가능한 트랜잭션 로그 백업 파일 나열 및 필터링 예**
```
SELECT * from msdb.dbo.rds_fn_list_tlog_backup_metadata('mydatabasename');
SELECT * from msdb.dbo.rds_fn_list_tlog_backup_metadata('mydatabasename') WHERE rds_backup_seq_id = 3507;
SELECT * from msdb.dbo.rds_fn_list_tlog_backup_metadata('mydatabasename') WHERE backup_file_time_utc > '2022-09-15 20:44:01' ORDER BY backup_file_time_utc DESC;
```
![\[rds_fn_list_tlog_backup_metadata의 출력\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/sql_accesstransactionlogs_func.png)
`rds_fn_list_tlog_backup_metadata` 함수는 다음과 같은 출력을 반환합니다.
****
| 열 이름 | 데이터 유형 | 설명 |
| --- | --- | --- |
| `db_name` | sysname | 트랜잭션 로그 백업을 나열하기 위해 제공된 데이터베이스 이름입니다. |
| `db_id` | int | 입력 파라미터 `db_name`의 내부 데이터베이스 식별자입니다. |
| `family_guid` | uniqueidentifier | 생성 시 원본 데이터베이스의 고유 ID입니다. 이 값은 데이터베이스가 복원될 때 동일하게 유지되며 다른 데이터베이스 이름으로 복원되더라도 마찬가지입니다. |
| `rds_backup_seq_id` | int | RDS가 각 트랜잭션 로그 백업 파일의 시퀀스 번호를 유지하기 위해 내부적으로 사용하는 ID입니다. |
| `backup_file_epoch` | bigint | 트랜잭션 백업 파일이 생성된 에포크 시간입니다. |
| `backup_file_time_utc` | datetime | `backup_file_epoch` 값의 UTC 시간 변환 값입니다. |
| `starting_lsn` | numeric(25,0) | 트랜잭션 로그 백업 파일의 첫 번째 또는 가장 오래된 로그 레코드의 로그 시퀀스 번호입니다. |
| `ending_lsn` | numeric(25,0) | 트랜잭션 로그 백업 파일의 마지막 또는 다음 로그 레코드의 로그 시퀀스 번호입니다. |
| `is_log_chain_broken` | bit | 현재 트랜잭션 로그 백업 파일과 이전 트랜잭션 로그 백업 파일 간의 로그 체인이 끊어졌는지 여부를 나타내는 부울 값입니다. |
| `file_size_bytes` | bigint | 트랜잭션 백업 세트의 크기(바이트)입니다. |
| `Error` | varchar(4000) | `rds_fn_list_tlog_backup_metadata` 함수에서 예외가 발생하는 경우의 오류 메시지입니다. 예외가 없는 경우 NULL입니다. |
# 트랜잭션 로그 백업 복사
개별 데이터베이스의 사용 가능한 트랜잭션 로그 백업 세트를 Amazon S3 버킷에 복사하려면 `rds_tlog_backup_copy_to_S3` 저장 프로시저를 호출합니다. `rds_tlog_backup_copy_to_S3` 저장 프로시저는 트랜잭션 로그 백업을 복사하는 새 작업을 시작합니다.
**참고**
`rds_tlog_backup_copy_to_S3` 저장 프로시저는 `is_log_chain_broken` 속성에 대한 검증 없이 트랜잭션 로그 백업을 복사합니다. 따라서 `rds_tlog_backup_copy_to_S3` 저장 프로시저를 실행하기 전에 끊어지지 않은 로그 체인을 수동으로 확인해야 합니다. 자세한 설명은 [트랜잭션 로그 백업 로그 체인 검증](#USER.SQLServer.AddlFeat.TransactionLogAccess.Copying.LogChain)을 참조하세요.
**Example `rds_tlog_backup_copy_to_S3` 저장 프로시저 사용 예**
```
exec msdb.dbo.rds_tlog_backup_copy_to_S3
@db_name='mydatabasename',
[@kms_key_arn='arn:aws:kms:region:account-id:key/key-id'],
[@backup_file_start_time='2022-09-01 01:00:15'],
[@backup_file_end_time='2022-09-01 21:30:45'],
[@starting_lsn=149000000112100001],
[@ending_lsn=149000000120400001],
[@rds_backup_starting_seq_id=5],
[@rds_backup_ending_seq_id=10];
```
다음 입력 파라미터를 사용할 수 있습니다.
****
| 파라미터 | 설명 |
| --- | --- |
| `@db_name` | 트랜잭션 로그 백업을 복사할 데이터베이스의 이름입니다. |
| `@kms_key_arn` | 고객 관리형 KMS 키. AWS 관리형 KMS 키로 DB 인스턴스를 암호화하는 경우 고객 관리형 키를 생성해야 합니다. 고객 관리형 키로 DB 인스턴스를 암호화하는 경우 동일한 KMS 키 ARN을 사용할 수 있습니다. |
| `@backup_file_start_time` | `rds_fn_list_tlog_backup_metadata` 함수의 `[backup_file_time_utc]` 열에서 제공된 UTC 타임스탬프입니다. |
| `@backup_file_end_time` | `rds_fn_list_tlog_backup_metadata` 함수의 `[backup_file_time_utc]` 열에서 제공된 UTC 타임스탬프입니다. |
| `@starting_lsn` | `rds_fn_list_tlog_backup_metadata` 함수의 `[starting_lsn]` 열에서 제공된 LSN(로그 시퀀스 번호)입니다. |
| `@ending_lsn` | `rds_fn_list_tlog_backup_metadata` 함수의 `[ending_lsn]` 열에서 제공된 LSN(로그 시퀀스 번호)입니다. |
| `@rds_backup_starting_seq_id` | `rds_fn_list_tlog_backup_metadata` 함수의 `[rds_backup_seq_id]` 열에서 제공된 시퀀스 ID입니다. |
| `@rds_backup_ending_seq_id` | `rds_fn_list_tlog_backup_metadata` 함수의 `[rds_backup_seq_id]` 열에서 제공된 시퀀스 ID입니다. |
시간, LSN 또는 시퀀스 ID 파라미터 세트를 지정할 수 있습니다. 한 세트의 파라미터만 필요합니다.
모든 세트에 하나의 파라미터만 지정할 수도 있습니다. 예를 들어 `backup_file_end_time` 파라미터의 값만 제공하면 7일 한도 내에서 해당 시간 이전에 사용 가능한 모든 트랜잭션 로그 백업 파일이 Amazon S3 버킷에 복사됩니다.
다음은 `rds_tlog_backup_copy_to_S3` 저장 프로시저의 유효한 입력 파라미터 조합입니다.
****
| 제공된 파라미터 | 예상 결과 |
| --- | --- |
|
| 제공된 `backup_file_start_time`과 `backup_file_end_time` 범위 사이에 존재하는 지난 7일간의 트랜잭션 로그 백업을 복사합니다. 이 예에서 저장 프로시저는 '2022-08-23 00:00:00'과 '2022-08-30 00:00:00' 사이에 생성된 트랜잭션 로그 백업을 복사합니다. |
|
| 제공된 `starting_lsn`과 `ending_lsn` 범위 사이의 지난 7일간의 사용 가능한 트랜잭션 로그 백업을 복사합니다. 이 예에서 저장 프로시저는 LSN 범위가 1490000000040007에서 1490000000050009 사이인 지난 7일간의 트랜잭션 로그 백업을 복사합니다. |
|
| 제공된 `rds_backup_starting_seq_id`과 `rds_backup_ending_seq_id` 범위 사이에 존재하는 지난 7일간의 사용 가능한 트랜잭션 로그 백업을 복사합니다. 이 예에서 저장 프로시저는 지난 7일부터 시작하여 seq\$1id 2000부터 seq\$1id 5000까지의 제공된 rds 백업 시퀀스 id 범위 내에 있는 트랜잭션 로그 백업을 복사합니다. |
|
| 제공된 `rds_backup_starting_seq_id`에서 시작하는 지난 7일간의 사용 가능한 트랜잭션 로그 백업을 복사합니다. 이 예에서 저장 프로시저는 seq\$1id 2000부터 시작하여 최신 트랜잭션 로그 백업까지의 트랜잭션 로그 백업을 복사합니다. |
|
| 지난 7일 내에 사용 가능한 경우 제공된 `rds_backup_starting_seq_id`와 함께 단일 트랜잭션 로그 백업을 복사합니다. 이 예에서 저장 프로시저는 seq\$1id가 2000인 단일 트랜잭션 로그 백업을 복사합니다(지난 7일 내에 존재하는 경우). |
## 트랜잭션 로그 백업 로그 체인 검증
트랜잭션 로그 백업 액세스가 구성된 데이터베이스는 자동 백업 보존이 활성화되어 있어야 합니다. 자동 백업 보존은 DB 인스턴스의 데이터베이스를 `FULL` 복구 모델로 설정합니다. 데이터베이스의 특정 시점 복원을 지원하려면 데이터베이스 복구 모델을 변경하지 마세요. 로그 체인이 끊어질 수 있습니다. 데이터베이스를 `FULL` 복구 모델로 설정한 상태로 유지하는 것이 좋습니다.
트랜잭션 로그 백업을 복사하기 전에 로그 체인을 수동으로 검증하려면 `rds_fn_list_tlog_backup_metadata` 함수를 호출하고 `is_log_chain_broken` 열의 값을 검토하세요. 값이 ‘1’이면 현재 로그 백업과 이전 로그 백업 간 로그 체인이 끊어졌음을 나타냅니다.
다음 예는 `rds_fn_list_tlog_backup_metadata` 저장 프로시저의 출력에서 끊어진 로그 체인을 보여 줍니다.
![\[끊어진 로그 체인을 보여 주는 rds_fn_list_tlog_backup_metadata 출력.\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/sql_accesstransactionlogs_logchain_error.png)
일반적 로그 체인에서는 주어진 rds\$1sequence\$1id의 first\$1lsn 로그 시퀀스 번호(LSN) 값이 이전 rds\$1sequence\$1id의 last\$1lsn 값과 일치해야 합니다. 이미지에서 rds\$1sequence\$1id 45의 first\$1lsn 값 90987은 이전 rds\$1sequence\$1id 44의 last\$1lsn 값 90985와 일치하지 않습니다.
SQL Server 트랜잭션 로그 아키텍처 및 로그 시퀀스 번호에 대한 자세한 내용은 Microsoft SQL Server 설명서의 [트랜잭션 로그 논리적 아키텍처](https://learn.microsoft.com/en-us/sql/relational-databases/sql-server-transaction-log-architecture-and-management-guide?view=sql-server-ver15#Logical_Arch)를 참조하세요.
# Amazon S3 버킷 폴더 및 파일 구조
트랜잭션 로그 백업은 Amazon S3 버킷 내에서 다음과 같은 표준 구조 및 명명 규칙을 사용합니다.
+ 각 데이터베이스의 `target_s3_arn` 경로 아래에 `{db_id}.{family_guid}`와 같은 이름 지정 구조의 새 폴더가 생성됩니다.
+ 폴더 내에서 트랜잭션 로그 백업의 파일 이름 구조는 `{db_id}.{family_guid}.{rds_backup_seq_id}.{backup_file_epoch}`와 같습니다.
+ `rds_fn_list_tlog_backup_metadata` 함수를 사용하여 `family_guid,db_id,rds_backup_seq_id and backup_file_epoch` 세부 정보를 볼 수 있습니다.
다음 예는 Amazon S3 버킷에 있는 트랜잭션 로그 백업 세트의 폴더 및 파일 구조를 보여 줍니다.
![\[트랜잭션 로그에 액세스할 수 있는 Amazon S3 버킷 구조\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/sql_accesstransactionlogs_s3.png)
# 작업 상태 추적
복사 작업의 상태를 추적하려면 `rds_task_status` 저장 프로시저를 호출합니다. 파라미터를 제공하지 않으면 이 저장 프로시저는 모든 작업의 상태를 반환합니다.
**Example 사용법:**
```
exec msdb.dbo.rds_task_status
@db_name='database_name',
@task_id=ID_number;
```
다음 파라미터는 선택적입니다.
+ `@db_name` – 작업 상태를 표시할 데이터베이스의 이름입니다.
+ `@task_id` – 작업 상태를 표시할 작업의 ID입니다.
**Example 특정 작업의 상태 나열 예:**
```
exec msdb.dbo.rds_task_status @task_id=5;
```
**Example 특정 데이터베이스 및 작업의 상태 나열 예:**
```
exec msdb.dbo.rds_task_status@db_name='my_database',@task_id=5;
```
**Example 특정 데이터베이스의 모든 작업 및 상태 나열 예:**
```
exec msdb.dbo.rds_task_status @db_name='my_database';
```
**Example 현재 DB 인스턴스의 모든 작업 및 상태 나열 예:**
```
exec msdb.dbo.rds_task_status;
```
# 작업 취소
실행 중인 작업을 취소하려면 `rds_cancel_task` 저장 프로시저를 호출합니다.
**Example 사용법:**
```
exec msdb.dbo.rds_cancel_task @task_id=ID_number;
```
다음 파라미터는 필수입니다.
+ `@task_id` – 취소할 작업의 ID입니다. `rds_task_status` 저장 프로시저를 호출하여 작업 ID를 볼 수 있습니다.
실행 중인 작업 보기 및 취소에 대한 자세한 내용은 [기본 백업 및 복원 기능을 사용하여 SQL Server 데이터베이스 가져오기 및 내보내기](SQLServer.Procedural.Importing.md)를 참조하세요.
# 트랜잭션 로그 백업 액세스 문제 해결
다음은 트랜잭션 로그 백업 액세스에 저장 프로시저를 사용할 때 발생할 수 있는 문제입니다.
****
| 저장 프로시저 | 오류 메시지 | 문제 | 문제 해결 제안 |
| --- | --- | --- | --- |
| rds\$1tlog\$1copy\$1setup | 이 DB 인스턴스에서 백업이 비활성화되었습니다. 보존 기간이 ‘1’ 이상인 DB 인스턴스 백업을 활성화하고 다시 시도하십시오. | DB 인스턴스에서 자동 백업이 활성화되지 않았습니다. | DB 인스턴스 백업 보존은 최소 1일 이상의 보존 기간으로 활성화해야 합니다. 자동 백업 활성화 및 백업 보존 구성에 대한 자세한 내용은 [백업 보존 기간](USER_WorkingWithAutomatedBackups.BackupRetention.md)을 참조하세요. |
| rds\$1tlog\$1copy\$1setup | rds\$1tlog\$1copy\$1setup 저장 프로시저를 실행하는 동안 오류가 발생했습니다. RDS 엔드포인트에 다시 연결하고 다시 시도하십시오. | 내부 오류가 발생했습니다. | RDS 엔드포인트에 다시 연결하고 `rds_tlog_copy_setup` 저장 프로시저를 다시 실행합니다. |
| rds\$1tlog\$1copy\$1setup | 트랜잭션 내에서 rds\$1tlog\$1backup\$1copy\$1setup 저장 프로시저를 실행하는 것은 지원되지 않습니다. 세션에 진행 중인 트랜잭션이 없는지 확인하고 다시 시도하십시오. | `BEGIN` 및 `END`를 사용하여 트랜잭션 내에서 저장 프로시저를 시도했습니다. | `rds_tlog_copy_setup` 저장 프로시저를 실행할 때는 `BEGIN` 및 `END`를 사용하지 마세요. |
| rds\$1tlog\$1copy\$1setup | 입력 파라미터 `@target_s3_arn`의 S3 버킷 이름에는 공백 이외의 문자가 한 개 이상 포함되어야 합니다. | 입력 파라미터 `@target_s3_arn`에 잘못된 값이 제공되었습니다. | 입력 파라미터 `@target_s3_arn`이 완전한 Amazon S3 버킷 ARN을 지정하는지 확인하세요. |
| rds\$1tlog\$1copy\$1setup | `SQLSERVER_BACKUP_RESTORE` 옵션이 활성화되지 않았거나 활성화되는 중입니다. 이 옵션을 활성화하거나 나중에 다시 시도하십시오. | `SQLSERVER_BACKUP_RESTORE` 옵션이 DB 인스턴스에서 활성화되지 않았거나 방금 활성화되어 내부 활성화 보류 중입니다. | 요구 사항 섹션에 지정된 대로 `SQLSERVER_BACKUP_RESTORE` 옵션을 활성화합니다. 몇 분 기다린 후 `rds_tlog_copy_setup` 저장 프로시저를 다시 실행합니다. |
| rds\$1tlog\$1copy\$1setup | 입력 파라미터 `@target_s3_arn`의 대상 S3 arn은 비어 있거나 null일 수 없습니다. | 입력 파라미터 `@target_s3_arn`에 `NULL` 값이 제공되었거나 값이 제공되지 않았습니다. | 입력 파라미터 `@target_s3_arn`이 완전한 Amazon S3 버킷 ARN을 지정하는지 확인하세요. |
| rds\$1tlog\$1copy\$1setup | 입력 파라미터 `@target_s3_arn`의 대상 S3 arn은 arn:aws로 시작해야 합니다. | 입력 파라미터 `@target_s3_arn`이 앞에 `arn:aws` 없이 제공되었습니다. | 입력 파라미터 `@target_s3_arn`이 완전한 Amazon S3 버킷 ARN을 지정하는지 확인하세요. |
| rds\$1tlog\$1copy\$1setup | 대상 S3 ARN이 이미 제공된 값으로 설정되어 있습니다. | `rds_tlog_copy_setup` 저장 프로시저가 이전에 실행되었고 Amazon S3 버킷 ARN으로 구성되었습니다. | 트랜잭션 로그 백업에 액세스할 수 있도록 Amazon S3 버킷 값을 수정하려면 다른 `target S3 ARN`을 제공하세요. |
| rds\$1tlog\$1copy\$1setup | 트랜잭션 로그 백업에 대한 액세스를 활성화하기 위한 자격 증명을 생성할 수 없습니다. `rds_tlog_copy_setup`와 함께 제공된 S3 경로 ARN을 확인하고 나중에 다시 시도하십시오. | 트랜잭션 로그 백업 액세스를 활성화하기 위해 자격 증명을 생성하는 동안 지정되지 않은 오류가 발생했습니다. | 설정 구성을 검토하고 다시 시도하세요. |
| rds\$1tlog\$1copy\$1setup | 보류 중인 작업이 있는 동안에는 rds\$1tlog\$1copy\$1setup 저장 프로시저를 실행할 수 없습니다. 보류 중인 작업이 완료될 때까지 기다렸다가 다시 시도하십시오. | 한 번에 두 개의 작업만 실행할 수 있습니다. 완료를 기다리고 있는 보류 중인 작업이 있습니다. | 보류 중인 작업을 보고 완료될 때까지 기다리세요. 작업 상태 모니터링에 대한 자세한 내용은 [작업 상태 추적](USER.SQLServer.AddlFeat.TransactionLogAccess.TrackTaskStatus.md)을 참조하세요. |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | 작업 ID: %d의 데이터베이스: %s에 대해 T-log 백업 파일 복사 작업이 이미 실행되었습니다. 나중에 다시 시도하십시오. | 지정된 데이터베이스에 대해 언제든 하나의 복사 작업만 실행할 수 있습니다. 완료를 기다리고 있는 보류 중인 복사 작업이 있습니다. | 보류 중인 작업을 보고 완료될 때까지 기다리세요. 작업 상태 모니터링에 대한 자세한 내용은 [작업 상태 추적](USER.SQLServer.AddlFeat.TransactionLogAccess.TrackTaskStatus.md)을 참조하세요. |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | 다음 세 가지 파라미터 세트 중 하나 이상을 제공해야 합니다. SET-1:(@backup\$1file\$1start\$1time, @backup\$1file\$1end\$1time) \$1 SET-2:(@starting\$1lsn, @ending\$1lsn) \$1 SET-3:(@rds\$1backup\$1starting\$1seq\$1id, @rds\$1backup\$1ending\$1seq\$1id) | 세 가지 파라미터 세트가 모두 제공되지 않았거나 제공된 파라미터 세트에 필수 파라미터가 누락되었습니다. | 시간, lsn 또는 시퀀스 ID 파라미터를 지정할 수 있습니다. 이 세 가지 파라미터 세트 중 한 세트가 필요합니다. 필수 파라미터에 대한 자세한 내용은 [트랜잭션 로그 백업 복사](USER.SQLServer.AddlFeat.TransactionLogAccess.Copying.md)를 참조하세요. |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | 인스턴스에서 백업이 비활성화되었습니다. 백업을 활성화하고 잠시 후 다시 시도하십시오. | DB 인스턴스에서 자동 백업이 활성화되지 않았습니다. | 자동 백업 활성화 및 백업 보존 구성에 대한 자세한 내용은 [백업 보존 기간](USER_WorkingWithAutomatedBackups.BackupRetention.md)을 참조하세요. |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | 지정된 데이터베이스 %s을(를) 찾을 수 없습니다. | 입력 파라미터 `@db_name`에 제공된 값이 DB 인스턴스의 데이터베이스 이름과 일치하지 않습니다. | 올바른 데이터베이스 이름을 사용합니다. 모든 데이터베이스를 이름순으로 나열하려면 `SELECT * from sys.databases`를 실행합니다. |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | SQL Server 시스템 데이터베이스 또는 rdsadmin 데이터베이스에 대해 rds\$1tlog\$1backup\$1copy\$1to\$1S3 저장 프로시저를 실행할 수 없습니다. | 입력 파라미터 `@db_name`에 제공된 값이 SQL Server 시스템 데이터베이스 이름 또는 RDSAdmin 데이터베이스와 일치합니다. | 다음 데이터베이스는 트랜잭션 로그 백업 액세스에 사용할 수 없습니다. `master, model, msdb, tempdb, RDSAdmin.` |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | 입력 파라미터 @db\$1name의 데이터베이스 이름은 비어 있거나 null일 수 없습니다. | 입력 파라미터 `@db_name`에 제공된 값이 비어 있거나 `NULL`입니다. | 올바른 데이터베이스 이름을 사용합니다. 모든 데이터베이스를 이름순으로 나열하려면 `SELECT * from sys.databases`를 실행합니다. |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | rds\$1tlog\$1backup\$1copy\$1setup 저장 프로시저를 실행하려면 DB 인스턴스 백업 보존 기간을 1 이상으로 설정해야 합니다. | DB 인스턴스에서 자동 백업이 활성화되지 않았습니다. | 자동 백업 활성화 및 백업 보존 구성에 대한 자세한 내용은 [백업 보존 기간](USER_WorkingWithAutomatedBackups.BackupRetention.md)을 참조하세요. |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | 저장 프로시저 rds\$1tlog\$1backup\$1copy\$1to\$1S3를 실행하는 동안 오류가 발생했습니다. RDS 엔드포인트에 다시 연결하고 다시 시도하십시오. | 내부 오류가 발생했습니다. | RDS 엔드포인트에 다시 연결하고 `rds_tlog_backup_copy_to_S3` 저장 프로시저를 다시 실행합니다. |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | 다음 세 가지 파라미터 세트 중 하나만 제공할 수 있습니다. SET-1:(@backup\$1file\$1start\$1time, @backup\$1file\$1end\$1time) \$1 SET-2:(@starting\$1lsn, @ending\$1lsn) \$1 SET-3:(@rds\$1backup\$1starting\$1seq\$1id, @rds\$1backup\$1ending\$1seq\$1id) | 여러 파라미터 세트가 제공되었습니다. | 시간, lsn 또는 시퀀스 ID 파라미터를 지정할 수 있습니다. 이 세 가지 파라미터 세트 중 한 세트가 필요합니다. 필수 파라미터에 대한 자세한 내용은 [트랜잭션 로그 백업 복사](USER.SQLServer.AddlFeat.TransactionLogAccess.Copying.md)를 참조하세요. |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | 트랜잭션 내에서 rds\$1tlog\$1backup\$1copy\$1to\$1S3 저장 프로시저를 실행하는 것은 지원되지 않습니다. 세션에 진행 중인 트랜잭션이 없는지 확인하고 다시 시도하십시오. | `BEGIN` 및 `END`를 사용하여 트랜잭션 내에서 저장 프로시저를 시도했습니다. | `rds_tlog_backup_copy_to_S3` 저장 프로시저를 실행할 때는 `BEGIN` 및 `END`를 사용하지 마세요. |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | 제공된 파라미터가 트랜잭션 백업 로그 보존 기간을 벗어납니다. 사용 가능한 트랜잭션 로그 백업 파일을 나열하려면 rds\$1fn\$1list\$1tlog\$1backup\$1메타데이터 함수를 실행합니다. | 제공된 입력 파라미터에 대해 복사본 보존 기간에 맞는 사용 가능한 트랜잭션 로그 백업이 없습니다. | 유효한 파라미터 세트를 사용하여 다시 시도하세요. 필수 파라미터에 대한 자세한 내용은 [트랜잭션 로그 백업 복사](USER.SQLServer.AddlFeat.TransactionLogAccess.Copying.md)를 참조하세요. |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | 요청을 처리하는 동안 권한 오류가 발생했습니다. 버킷이 DB 인스턴스와 동일한 계정 및 지역에 있는지 확인하고, 공개 설명서의 템플릿과 비교하여 S3 버킷 정책 권한을 확인합니다. | 제공된 S3 버킷 또는 해당 정책 권한에서 문제가 감지되었습니다. | 트랜잭션 로그 백업에 대한 액세스 설정이 올바른지 확인하세요. S3 버킷의 설정 요구 사항에 대한 자세한 내용은 [요구 사항](USER.SQLServer.AddlFeat.TransactionLogAccess.md#USER.SQLServer.AddlFeat.TransactionLogAccess.Requirements)을 참조하세요. |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | RDS 읽기 전용 복제본 인스턴스에서 `rds_tlog_backup_copy_to_S3` 저장 프로시저를 실행하는 것은 허용되지 않습니다. | RDS 읽기 전용 복제본 인스턴스에서 저장 프로시저를 시도했습니다. | RDS 기본 DB 인스턴스에 연결하여 `rds_tlog_backup_copy_to_S3` 저장 프로시저를 실행합니다. |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | 입력 파라미터 `@starting_lsn`의 LSN은 `@ending_lsn`보다 작아야 합니다. | 입력 파라미터 `@starting_lsn`에 제공된 값이 입력 파라미터 `@ending_lsn`에 제공된 값보다 큽니다. | 입력 파라미터 `@starting_lsn`에 제공된 값이 입력 파라미터 `@ending_lsn`에 제공된 값보다 작은지 확인합니다. |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | `rds_tlog_backup_copy_to_S3` 저장 프로시저는 소스 데이터베이스의 `db_owner` 역할 멤버만 수행할 수 있습니다. | 제공된 `db_name`에서 `rds_tlog_backup_copy_to_S3` 저장 프로시저를 실행하려고 시도하는 계정에 `db_owner` 역할이 부여되지 않았습니다. | 저장 프로시저를 실행하는 계정에 제공된 `db_name`에 대한 `db_owner` 역할이 허용되었는지 확인하세요. |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | 입력 파라미터 `@rds_backup_starting_seq_id`의 시퀀스 ID는 `@rds_backup_ending_seq_id` 이하여야 합니다. | 입력 파라미터 `@rds_backup_starting_seq_id`에 제공된 값이 입력 파라미터 `@rds_backup_ending_seq_id`에 제공된 값보다 큽니다. | 입력 파라미터 `@rds_backup_starting_seq_id`에 제공된 값이 입력 파라미터 `@rds_backup_ending_seq_id`에 제공된 값보다 작은지 확인합니다. |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | SQLSERVER\$1BACKUP\$1RESTORE 옵션이 활성화되지 않았거나 활성화되는 중입니다. 이 옵션을 활성화하거나 나중에 다시 시도하십시오. | `SQLSERVER_BACKUP_RESTORE` 옵션이 DB 인스턴스에서 활성화되지 않았거나 방금 활성화되어 내부 활성화 보류 중입니다. | 요구 사항 섹션에 지정된 대로 `SQLSERVER_BACKUP_RESTORE` 옵션을 활성화합니다. 몇 분 기다린 후 `rds_tlog_backup_copy_to_S3` 저장 프로시저를 다시 실행합니다. |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | 입력 매개변수 `@backup_file_start_time`의 시작 시간은 `@backup_file_end_time`보다 작아야 합니다. | 입력 파라미터 `@backup_file_start_time`에 제공된 값이 입력 파라미터 `@backup_file_end_time`에 제공된 값보다 큽니다. | 입력 파라미터 `@backup_file_start_time`에 제공된 값이 입력 파라미터 `@backup_file_end_time`에 제공된 값보다 작은지 확인합니다. |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | 액세스 권한이 부족하여 요청을 처리할 수 없었습니다. 기능에 대한 설정 및 권한을 확인하십시오. | Amazon S3 버킷 권한에 문제가 있거나 제공된 Amazon S3 버킷이 다른 계정 또는 리전에 있을 수 있습니다. | Amazon S3 버킷 정책 권한이 RDS 액세스를 허용하도록 승인되었는지 확인합니다. Amazon S3 버킷이 소스 DB 인스턴스와 동일한 계정 및 리전에 있는지 확인합니다. |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | 스토리지 암호화되지 않은 인스턴스의 경우 KMS Key ARN을 저장 프로시저의 입력 파라미터로 제공할 수 없습니다. | DB 인스턴스에서 스토리지 암호화가 활성화되지 않은 경우 입력 파라미터 `@kms_key_arn`을 제공하면 안 됩니다. | `@kms_key_arn`의 입력 파라미터를 제공하지 마세요. |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | 암호화된 스토리지 인스턴스의 경우 KMS Key ARN을 저장 프로시저의 입력 파라미터로 제공해야 합니다. | DB 인스턴스에서 스토리지 암호화가 활성화된 경우 입력 파라미터 `@kms_key_arn`을 제공해야 합니다. | 트랜잭션 로그 백업에 사용할 Amazon S3 버킷의 ARN과 일치하는 값을 `@kms_key_arn`의 입력 파라미터에 제공합니다. |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | `rds_tlog_backup_copy_to_S3` 저장 프로시저를 실행하기 전에 `rds_tlog_copy_setup` 저장 프로시저를 실행하고 `@target_s3_arn`을 설정해야 합니다. | `rds_tlog_backup_copy_to_S3` 저장 프로시저를 실행하기 전에 트랜잭션 로그 백업에 대한 액세스 설정 절차가 완료되지 않았습니다. | `rds_tlog_backup_copy_to_S3` 저장 프로시저를 실행하기 전에 `rds_tlog_copy_setup` 저장 프로시저를 실행합니다. 트랜잭션 로그 백업 액세스 설정 프로시저 실행에 대한 자세한 내용은 [트랜잭션 로그 백업에 대한 액세스 설정](USER.SQLServer.AddlFeat.TransactionLogAccess.Enabling.md)을 참조하세요. |
# Microsoft SQL Server 데이터베이스 엔진의 옵션
이 단원에서는 Microsoft SQL Server DB 엔진을 실행하는 Amazon RDS 인스턴스에 사용할 수 있는 옵션에 대한 설명을 볼 수 있습니다. 이러한 옵션을 활성화하려면 먼저 옵션 그룹에 추가한 다음 옵션 그룹을 DB 인스턴스에 연결해야 합니다. 자세한 내용은 [옵션 그룹 작업](USER_WorkingWithOptionGroups.md) 섹션을 참조하세요.
SSL, Microsoft Windows 인증 및 Amazon S3 통합과 같은 RDS 옵션 그룹을 통해 추가되지 않은 선택적 기능을 찾으려면 [Amazon RDS의 Microsoft SQL Server 추가 기능](User.SQLServer.AdditionalFeatures.md) 단원을 참조하십시오.
Amazon RDS는 Microsoft SQL Server DB 인스턴스에 대해 다음 옵션을 지원합니다.
****
| 옵션 | 옵션 ID | 엔진 버전 |
| --- | --- | --- |
| [Oracle OLEDB 포함 연결된 서버](Appendix.SQLServer.Options.LinkedServers_Oracle_OLEDB.md) | `OLEDB_ORACLE` | SQL Server Enterprise Edition SQL Server Standard Edition |
| [기본 백업 및 복원](Appendix.SQLServer.Options.BackupRestore.md) | `SQLSERVER_BACKUP_RESTORE` | SQL Server Enterprise Edition SQL Server Standard Edition SQL Server Web Edition SQL Server Express Edition |
| [투명한 데이터 암호화](Appendix.SQLServer.Options.TDE.md) | `TRANSPARENT_DATA_ENCRYPTION`(RDS 콘솔) `TDE`(AWS CLI 및 RDS API) | SQL Server 2016–2022 Enterprise Edition SQL Server 2022 Standard Edition |
| [SQL Server Audit](Appendix.SQLServer.Options.Audit.md) | `SQLSERVER_AUDIT` | SQL Server 2016부터는 RDS에서 모든 버전의 SQL Server가 서버 수준 감사를 지원하고 Enterprise Edition은 데이터베이스 수준 감사도 지원합니다. SQL Server SQL Server 2016(13.x) SP1부터는 모든 버전이 서버 수준 및 데이터베이스 수준 감사를 모두 지원합니다. 자세한 내용은 SQL Server 설명서의 [SQL Server Audit(데이터베이스 엔진)](https://docs.microsoft.com/sql/relational-databases/security/auditing/sql-server-audit-database-engine?view=sql-server-2017)를 참조하십시오. |
| [SQL Server Analysis Services](Appendix.SQLServer.Options.SSAS.md) | `SSAS` | SQL Server Enterprise Edition SQL Server Standard Edition |
| [SQL Server Integration Services](Appendix.SQLServer.Options.SSIS.md) | `SSIS` | SQL Server Enterprise Edition SQL Server Standard Edition |
| [SQL Server Reporting Services](Appendix.SQLServer.Options.SSRS.md) | `SSRS` | SQL Server Enterprise Edition SQL Server Standard Edition |
| [Microsoft Distributed Transaction Coordinator](Appendix.SQLServer.Options.MSDTC.md) | `MSDTC` | RDS에서는 SQL Server 2016부터 모든 버전의 SQL Server가 분산 트랜잭션을 지원합니다. |
| [SQL Server 리소스 거버너](Appendix.SQLServer.Options.ResourceGovernor.md) | `RESOURCE_GOVERNOR` | SQL Server Enterprise Edition SQL Server 2022 Developer 버전 |
## SQL Server 버전 및 에디션에 사용할 수 있는 옵션 나열
`describe-option-group-options` AWS CLI명령을 사용하여 SQL Server 버전 및 에디션에 사용할 수 있는 옵션과 해당 옵션의 설정을 나열할 수 있습니다.
다음 예에서는 SQL Server 2019 Enterprise Edition에 대한 옵션 및 옵션 설정을 보여 줍니다. `--engine-name` 옵션은 필수입니다.
```
aws rds describe-option-group-options --engine-name sqlserver-ee --major-engine-version 15.00
```
출력은 다음과 유사합니다.
```
{
"OptionGroupOptions": [
{
"Name": "MSDTC",
"Description": "Microsoft Distributed Transaction Coordinator",
"EngineName": "sqlserver-ee",
"MajorEngineVersion": "15.00",
"MinimumRequiredMinorEngineVersion": "4043.16.v1",
"PortRequired": true,
"DefaultPort": 5000,
"OptionsDependedOn": [],
"OptionsConflictsWith": [],
"Persistent": false,
"Permanent": false,
"RequiresAutoMinorEngineVersionUpgrade": false,
"VpcOnly": false,
"OptionGroupOptionSettings": [
{
"SettingName": "ENABLE_SNA_LU",
"SettingDescription": "Enable support for SNA LU protocol",
"DefaultValue": "true",
"ApplyType": "DYNAMIC",
"AllowedValues": "true,false",
"IsModifiable": true,
"IsRequired": false,
"MinimumEngineVersionPerAllowedValue": []
},
...
{
"Name": "TDE",
"Description": "SQL Server - Transparent Data Encryption",
"EngineName": "sqlserver-ee",
"MajorEngineVersion": "15.00",
"MinimumRequiredMinorEngineVersion": "4043.16.v1",
"PortRequired": false,
"OptionsDependedOn": [],
"OptionsConflictsWith": [],
"Persistent": true,
"Permanent": false,
"RequiresAutoMinorEngineVersionUpgrade": false,
"VpcOnly": false,
"OptionGroupOptionSettings": []
}
]
}
```
# Amazon RDS for SQL Server의 Oracle OLEDB 포함 연결된 서버 지원
RDS for SQL Server의 OLEDB에 대한 Oracle Provider를 지원하는 연결된 서버를 사용하면 Oracle 데이터베이스의 외부 데이터 소스에 액세스할 수 있습니다. 원격 Oracle 데이터 소스의 데이터를 읽고 RDS for SQL Server DB 인스턴스 외부에 있는 원격 Oracle 데이터베이스 서버를 상대로 명령을 실행할 수 있습니다. Oracle OLEDB 포함 연결된 서버를 사용하면 다음을 수행할 수 있습니다.
+ SQL Server 이외의 데이터 소스에 바로 액세스
+ 데이터를 옮기지 않고도 동일한 쿼리를 이용해 다양한 Oracle 데이터 소스를 쿼리
+ 엔터프라이즈 에코시스템 전반의 데이터 소스에 대한 분산 쿼리, 업데이트, 명령 및 트랜잭션 실행
+ Microsoft 비즈니스 인텔리전스 제품군(SSIS, SSRS, SSAS) 내에서 Oracle 데이터베이스로의 연결 통합
+ Oracle 데이터베이스에서 RDS for SQL Server로의 마이그레이션
기존 또는 새 RDS for SQL Server DB 인스턴스에서 Oracle용 연결된 서버를 하나 이상 활성화할 수 있습니다. 그런 다음 외부 Oracle 데이터 소스를 DB 인스턴스와 통합할 수 있습니다.
**Contents**
+ [지원되는 버전 및 리전](#LinkedServers_Oracle_OLEDB.VersionRegionSupport)
+ [제한 및 권장 사항](#LinkedServers_Oracle_OLEDB.Limitations)
+ [Oracle이 포함된 연결된 서버 활성화](#LinkedServers_Oracle_OLEDB.Enabling)
+ [OLEDB\$1ORACLE용 옵션 그룹 생성](#LinkedServers_Oracle_OLEDB.OptionGroup)
+ [옵션 그룹에 `OLEDB_ORACLE` 옵션 추가](#LinkedServers_Oracle_OLEDB.Add)
+ [`OLEDB_ORACLE` 버전 옵션을 다른 버전으로 수정](#LinkedServers_Oracle_OLEDB.Modify)
+ [옵션 그룹을 DB 인스턴스와 연결](#LinkedServers_Oracle_OLEDB.Apply)
+ [OLEDB 제공자 속성 수정](#LinkedServers_Oracle_OLEDB.ModifyProviderProperties)
+ [OLEDB 드라이버 속성 수정](#LinkedServers_Oracle_OLEDB.ModifyDriverProperties)
+ [Oracl이 포함된 연결된 서버 비활성화](#LinkedServers_Oracle_OLEDB.Disable)
## 지원되는 버전 및 리전
RDS for SQL Server는 다음 버전의 SQL Server Standard 및 Enterprise Edition에 대해 모든 리전에서 Oracle OLEDB가 포함된 연결된 서버를 지원합니다.
+ SQL Server 2022, 모든 버전
+ SQL Server 2019, 모든 버전
+ SQL Server 2017, 모든 버전
Oracle OLEDB가 포함된 연결된 서버는 다음 Oracle Database 버전에서 지원됩니다.
+ Oracle Database 21c, 모든 버전
+ Oracle Database 19c, 모든 버전
+ Oracle Database 18c, 모든 버전
Oracle OLEDB가 포함된 연결된 서버는 다음 OLEDB Oracle 드라이버 버전에서 지원됩니다.
+ 21.7
+ 21.16
## 제한 및 권장 사항
Oracle OLEDB가 포함된 연결된 서버에 적용되는 다음과 같은 제한 및 권장 사항을 염두에 두십시오.
+ 각 RDS for SQL Server DB인스턴스의 보안 그룹에 적절한 TCP 포트를 추가하여 네트워크 트래픽을 허용하십시오. 예를 들어 EC2 Oracle DB 인스턴스와 RDS for SQL Server DB 인스턴스 간에 연결된 서버를 구성하는 경우, EC2 Oracle DB 인스턴스의 IP 주소에서 오는 트래픽을 허용해야 합니다. 또한 SQL Server가 데이터베이스 통신을 수신하는 데 사용하는 포트에서 트래픽을 허용해야 합니다. 보안 그룹에 대한 자세한 정보는 [보안 그룹을 통한 액세스 제어](Overview.RDSSecurityGroups.md) 단원을 참조하세요.
+ 옵션 그룹에서 `OLEDB_ORACLE` 옵션을 켜거나, 해제하거나, 수정한 후에는 RDS for SQL Server DB 인스턴스를 재부팅합니다. 옵션 그룹 상태에 이러한 이벤트의 `pending_reboot`와 필수 여부가 표시됩니다. AlwaysOn 또는 미러링 옵션이 활성화된 RDS for SQL Server 다중 AZ 인스턴스의 경우 새 인스턴스 생성 또는 복원 작업 후 인스턴스를 재부팅하면 장애 조치가 수행될 수 있습니다.
+ Oracle 데이터 소스의 사용자 이름과 암호를 사용한 단순 인증만 지원됩니다.
+ Open Database Connectivity(ODBC) 드라이버는 지원되지 않습니다. 위에 나열된 OLEDB 드라이버 버전만 지원됩니다.
+ 분산 트랜잭션(XA)은 지원됩니다. 분산 트랜잭션을 활성화하려면 DB 인스턴스의 Option Group(옵션 그룹)에서 `MSDTC` 옵션을 켜고 XA 트랜잭션이 켜져 있는지 확인합니다. 자세한 내용은 [RDS for SQL Server에서 Microsoft Distributed Transaction Coordinator 지원](Appendix.SQLServer.Options.MSDTC.md) 섹션을 참조하세요.
+ 연결 문자열의 바로가기로 사용할 데이터 소스 이름(DSN) 생성은 지원되지 않습니다.
+ OLEDB 드라이버 추적은 지원되지 않습니다. SQL Server 확장 이벤트를 사용하여 OLEDB 이벤트를 추적할 수 있습니다. 자세한 내용은 [RDS for SQL Server에서 확장 이벤트 설정](https://aws.amazon.com/blogs/database/set-up-extended-events-in-amazon-rds-for-sql-server/) 섹션을 참조하세요.
+ SQL Server Management Studio(SSMS) 를 사용하여 Oracle 연결된 서버의 카탈로그 폴터에 액세스하는 작업은 지원되지 않습니다.
## Oracle이 포함된 연결된 서버 활성화
`OLEDB_ORACLE` 옵션을 RDS for SQL Server DB 인스턴스에 추가하여 Oracle이 포함된 연결된 서버를 활성화합니다. 다음 프로세스를 사용합니다.
1. 새 옵션 그룹을 생성하거나 기존 옵션 그룹을 선택합니다.
1. [`OLEDB_ORACLE`] 옵션을 옵션 그룹에 추가합니다.
1. 사용할 OLEDB 드라이버 버전을 선택합니다.
1. 옵션 그룹을 DB 인스턴스에 연결합니다.
1. DB 인스턴스를 재부팅합니다.
### OLEDB\$1ORACLE용 옵션 그룹 생성
Oracle이 포함된 연결된 서버를 사용하려면 사용할 DB 인스턴스의 SQL Server 에디션 및 버전에 해당하는 옵션 그룹을 생성하거나 수정합니다. 이 절차를 완료하려면 AWS Management Console 또는 AWS CLI를 사용합니다.
#### 콘솔
다음 절차에서는 SQL Server Standard Edition 2019에 대한 옵션 그룹을 생성합니다.
**옵션 그룹을 생성하려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **옵션 그룹**을 선택합니다.
1. **그룹 생성**을 선택합니다.
1. **보안 그룹 생성** 창에서 다음과 같이 합니다.
1. [**이름(Name)**]에 AWS 계정 내에서 쉽게 식별할 수 있는 옵션 그룹 이름을 입력합니다(예: **oracle-oledb-se-2019**). 이름은 글자, 숫자 및 하이픈만 사용 가능합니다.
1. **설명**에 옵션 그룹에 대한 간단한 설명을 입력합니다(예: **OLEDB\$1ORACLE option group for SQL Server SE 2019**). 이 설명은 표시 용도로만 사용됩니다.
1. **엔진**에 대해 **sqlserver-se**를 선택합니다.
1. **Major engine version**(메이저 엔진 버전)에 **15.00**을 선택합니다.
1. **생성(Create)**을 선택합니다.
#### CLI
다음 절차에서는 SQL Server Standard Edition 2019에 대한 옵션 그룹을 생성합니다.
**옵션 그룹을 생성하려면**
+ 다음 명령 중 하나를 실행합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds create-option-group \
--option-group-name oracle-oledb-se-2019 \
--engine-name sqlserver-se \
--major-engine-version 15.00 \
--option-group-description "OLEDB_ORACLE option group for SQL Server SE 2019"
```
Windows의 경우:
```
aws rds create-option-group ^
--option-group-name oracle-oledb-se-2019 ^
--engine-name sqlserver-se ^
--major-engine-version 15.00 ^
--option-group-description "OLEDB_ORACLE option group for SQL Server SE 2019"
```
### 옵션 그룹에 `OLEDB_ORACLE` 옵션 추가
그런 다음 AWS Management Console 또는 AWS CLI를 사용하여 `OLEDB_ORACLE` 옵션을 옵션 그룹에 추가합니다.
#### 콘솔
**OLEDB\$1ORACLE 옵션을 추가하려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **옵션 그룹**을 선택합니다.
1. 이 예제에서는 방금 생성한 옵션 그룹인 **oracle-oledb-se-2019**를 선택합니다.
1. **옵션 추가**를 선택합니다.
1. **Option details**(옵션 세부 정보)에서 **Option name**(옵션 이름)으로 **OLEDB\$1ORACL**를 선택합니다.
1. **버전**에서 설치할 OLEDB Oracle 드라이버의 버전을 선택합니다.
1. **예약**에서 옵션을 즉시 추가할지 또는 다음 유지 관리 기간에 추가할지를 선택합니다.
1. **옵션 추가**를 선택합니다.
#### CLI
**OLEDB\$1ORACLE 옵션을 추가하려면**
+ [`OLEDB_ORACLE`] 옵션을 옵션 그룹에 추가합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds add-option-to-option-group \
--option-group-name oracle-oledb-se-2019 \
--options OptionName=OLEDB_ORACLE, OptionVersion=21.16 \
--apply-immediately
```
Windows의 경우:
```
aws rds add-option-to-option-group ^
--option-group-name oracle-oledb-se-2019 ^
--options OptionName=OLEDB_ORACLE, OptionVersion=21.16 ^
--apply-immediately
```
### `OLEDB_ORACLE` 버전 옵션을 다른 버전으로 수정
`OLEDB_ORACLE` 옵션 버전을 다른 버전으로 수정하려면 AWS Management Console 또는 AWS CLI를 사용합니다.
#### 콘솔
**OLEDB\$1ORACLE 옵션을 수정하는 방법**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **옵션 그룹**을 선택합니다.
1. `OLEDB_ORACLE` 옵션이 있는 옵션 그룹을 선택합니다(이전 예시의 경우 **oledb-se-2019**).
1. **옵션 수정(Modify option)**을 선택합니다.
1. **Option details**(옵션 세부 정보)에서 **Option name**(옵션 이름)으로 **OLEDB\$1ORACL**를 선택합니다.
1. **버전**에서 사용하려는 OLEDB Oracle 드라이버의 버전을 선택합니다.
1. **예약**에서 옵션을 즉시 수정할지 또는 다음 유지 관리 기간에 수정할지를 선택합니다.
1. **옵션 수정(Modify option)**을 선택합니다.
#### CLI
`OLEDB_ORACLE` 옵션 버전을 수정하려면 사용할 옵션 그룹 및 옵션 버전과 함께 [https://docs.aws.amazon.com/cli/latest/reference/rds/add-option-to-option-group.html](https://docs.aws.amazon.com/cli/latest/reference/rds/add-option-to-option-group.html) AWS CLI 명령을 사용합니다.
**OLEDB\$1ORACLE 옵션을 수정하는 방법**
+
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds add-option-to-option-group \
--option-group-name oracle-oledb-se-2019 \
--options OptionName=OLEDB_ORACLE, OptionVersion=21.7 \
--apply-immediately
```
Windows의 경우:
```
aws rds add-option-to-option-group ^
--option-group-name oracle-oledb-se-2019 ^
--options OptionName=OLEDB_ORACLE, OptionVersion=21.7 ^
--apply-immediately
```
### 옵션 그룹을 DB 인스턴스와 연결
`OLEDB_ORACLE` 옵션 그룹 및 파라미터 그룹을 DB 인스턴스와 연결하려면 AWS Management Console 또는 AWS CLI를 사용합니다.
#### 콘솔
Oracle용 연결된 서버 활성화를 완료하려면 `OLEDB_ORACLE` 옵션 그룹을 새 DB 인스턴스 또는 기존 DB 인스턴스와 연결합니다.
+ 새 DB 인스턴스의 경우 인스턴스를 시작할 때 이러한 그룹을 연결합니다. 자세한 내용은 [Amazon RDS DB 인스턴스 생성](USER_CreateDBInstance.md) 섹션을 참조하세요.
+ 기존 DB 인스턴스의 경우 인스턴스를 수정하여 그룹을 연결합니다. 자세한 내용은 [Amazon RDS DB 인스턴스 수정](Overview.DBInstance.Modifying.md) 섹션을 참조하세요.
#### CLI
`OLEDB_ORACLE` 옵션 그룹 및 파라미터 그룹을 새 DB 인스턴스 또는 기존 DB 인스턴스와 연결할 수 있습니다.
**`OLEDB_ORACLE` 옵션 그룹 및 파라미터 그룹을 사용하여 인스턴스를 생성하려면**
+ 옵션 그룹을 생성할 때 사용한 것과 동일한 DB 엔진 유형과 메이저 버전을 지정합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds create-db-instance \
--db-instance-identifier mytestsqlserveroracleoledbinstance \
--db-instance-class db.m5.2xlarge \
--engine sqlserver-se \
--engine-version 15.0.4236.7.v1 \
--allocated-storage 100 \
--manage-master-user-password \
--master-username admin \
--storage-type gp2 \
--license-model li \
--domain-iam-role-name my-directory-iam-role \
--domain my-domain-id \
--option-group-name oracle-oledb-se-2019 \
--db-parameter-group-name my-parameter-group-name
```
Windows의 경우:
```
aws rds create-db-instance ^
--db-instance-identifier mytestsqlserveroracleoledbinstance ^
--db-instance-class db.m5.2xlarge ^
--engine sqlserver-se ^
--engine-version 15.0.4236.7.v1 ^
--allocated-storage 100 ^
--manage-master-user-password ^
--master-username admin ^
--storage-type gp2 ^
--license-model li ^
--domain-iam-role-name my-directory-iam-role ^
--domain my-domain-id ^
--option-group-name oracle-oledb-se-2019 ^
--db-parameter-group-name my-parameter-group-name
```
**인스턴스를 수정하여 `OLEDB_ORACLE` 옵션 그룹을 연결하려면**
+ 다음 명령 중 하나를 실행합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds modify-db-instance \
--db-instance-identifier mytestsqlserveroracleoledbinstance \
--option-group-name oracle-oledb-se-2019 \
--db-parameter-group-name my-parameter-group-name \
--apply-immediately
```
Windows의 경우:
```
aws rds modify-db-instance ^
--db-instance-identifier mytestsqlserveroracleoledbinstance ^
--option-group-name oracle-oledb-se-2019 ^
--db-parameter-group-name my-parameter-group-name ^
--apply-immediately
```
## OLEDB 제공자 속성 수정
OLEDB 공급자의 속성을 보고 변경할 수 있습니다. 이 작업은 `master` 사용자만 수행할 수 있습니다. DB 인스턴스에서 생성한 모든 Oracle용 연결 서버는 관련 OLEDB 공급자와 동일한 속성을 사용합니다. `sp_MSset_oledb_prop` 저장 프로시저를 호출하여 OLEDB 공급자의 속성을 변경합니다.
OLEDB 공급자 속성을 변경하려면
```
USE [master]
GO
EXEC sp_MSset_oledb_prop N'OraOLEDB.Oracle', N'AllowInProcess', 1
EXEC sp_MSset_oledb_prop N'OraOLEDB.Oracle', N'DynamicParameters', 0
GO
```
다음 속성을 수정할 수 있습니다.
****
| 속성 이름 | 권장 값(1 = 켜기, 0 = 해제) | 설명 |
| --- | --- | --- |
| `Dynamic parameter` | 1 | 파라미터화된 쿼리에서 ('? '로 표시하는) SQL 플레이스홀더 허용 |
| `Nested queries` | 1 | `FROM` 절에 중첩된 `SELECT` 문(예: 하위 쿼리)을 허용합니다. |
| `Level zero only` | 0 | 기본 수준 OLEDB 인터페이스만 공급자에 대해 호출됩니다. |
| `Allow inprocess` | 1 | 이 기능을 켜면 Microsoft SQL Server는 공급자를 진행 중 서버로 인스턴스화할 수 있습니다. Oracle 연결된 서버를 사용하려면 이 속성을 1로 설정합니다. |
| `Non transacted updates` | 0 | 0이 아닌 경우 SQL Server는 업데이트를 허용합니다. |
| `Index as access path` | False | 0이 아닌 경우 SQL Server는 공급자의 인덱스를 사용하여 데이터를 가져옵니다. |
| `Disallow adhoc access` | False | 설정하면 SQL Server는 OLEDB 공급자를 대상으로 한 패스스루 쿼리 실행을 허용하지 않습니다. 이 옵션을 선택해도 되지만, 패스스루 쿼리를 실행하는 것이 적절할 때도 있습니다. |
| `Supports LIKE operator` | 1 | 공급자가 LIKE 키워드를 사용하는 쿼리를 지원한다는 뜻입니다. |
## OLEDB 드라이버 속성 수정
Oracle용 연결된 서버를 만들 때 OLEDB 드라이버의 속성을 보고 변경할 수 있습니다. 이 작업은 `master` 사용자만 수행할 수 있습니다. 드라이버 속성은 원격 Oracle 데이터 소스를 작업할 때 OLEDB 드라이버가 데이터를 처리하는 방법을 정의합니다. 드라이버 속성은 DB 인스턴스에서 생성한 각 Oracle 연결된 서버에만 적용됩니다. `master.dbo.sp_addlinkedserver` 저장 프로시저를 호출하여 OLEDB 드라이버의 속성을 변경합니다.
예: 연결된 서버를 만들고 OLEDB 드라이버 `FetchSize` 속성을 변경하려면
```
EXEC master.dbo.sp_addlinkedserver
@server = N'Oracle_link2',
@srvproduct=N'Oracle',
@provider=N'OraOLEDB.Oracle',
@datasrc=N'my-oracle-test.cnetsipka.us-west-2.rds.amazonaws.com:1521/ORCL',
@provstr='FetchSize=200'
GO
```
```
EXEC master.dbo.sp_addlinkedsrvlogin
@rmtsrvname=N'Oracle_link2',
@useself=N'False',
@locallogin=NULL,
@rmtuser=N'master',
@rmtpassword='Test#1234'
GO
```
**참고**
보안 모범 사례로 여기에 표시된 프롬프트 이외의 암호를 지정하는 것이 좋습니다.
## Oracl이 포함된 연결된 서버 비활성화
Oracle이 포함된 연결된 서버를 비활성화하려면 해당 옵션 그룹에서 `OLEDB_ORACLE` 옵션을 제거합니다.
**중요**
옵션을 제거해도 DB 인스턴스의 기존 연결된 서버 구성은 삭제되지 않습니다. DB 인스턴스에서 제거하려면 수동으로 삭제해야 합니다.
제거 후 `OLEDB_ORACLE` 옵션을 다시 활성화하여 DB 인스턴스에서 이전에 구성한 연결된 서버 구성을 재사용할 수 있습니다.
### 콘솔
다음 절차에서는 `OLEDB_ORACLE` 옵션을 제거합니다.
**옵션 그룹에서 OLEDB\$1ORACLE 옵션을 제거하려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **옵션 그룹**을 선택합니다.
1. `OLEDB_ORACLE` 옵션이 있는 옵션 그룹을 선택합니다(이전 예제의 경우 `oracle-oledb-se-2019`).
1. **옵션 삭제**를 선택합니다.
1. **Deletion options**(옵션 삭제)에서 **Options to delete**(삭제할 옵션)에 **OLEDB\$1ORACLE**를 선택합니다.
1. **Apply immediately**(즉시 적용)에서 **Yes**(예)를 선택하여 옵션을 즉시 삭제하거나 **No**(아니오)를 선택하여 다음 유지 관리 기간에 삭제합니다.
1. **삭제**를 선택합니다.
### CLI
다음 절차에서는 `OLEDB_ORACLE` 옵션을 제거합니다.
**옵션 그룹에서 OLEDB\$1ORACLE 옵션을 제거하려면**
+ 다음 명령 중 하나를 실행합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds remove-option-from-option-group \
--option-group-name oracle-oledb-se-2019 \
--options OLEDB_ORACLE \
--apply-immediately
```
Windows의 경우:
```
aws rds remove-option-from-option-group ^
--option-group-name oracle-oledb-se-2019 ^
--options OLEDB_ORACLE ^
--apply-immediately
```
# RDS for SQL Server에서 Teradata ODBC와 연결된 서버
RDS for SQL Server에서 Teradata ODBC 드라이버와 연결된 서버를 지원하므로 Teradata 데이터베이스의 외부 데이터 소스에 액세스할 수 있습니다. RDS for SQL Server 인스턴스 외부에 있는 원격 Teradata 데이터베이스 서버에서 데이터를 읽고 명령을 실행할 수 있습니다. Teradata ODBC와 연결된 서버를 사용하여 다음 기능을 활성화합니다.
+ SQL Server 이외의 데이터 소스에 바로 액세스합니다.
+ 데이터를 옮기지 않고도 동일한 쿼리를 이용해 다양한 Teradata 데이터 소스를 쿼리합니다.
+ 엔터프라이즈 에코시스템 전반의 데이터 소스에 대한 분산 쿼리, 업데이트, 명령 및 트랜잭션을 실행합니다.
+ Microsoft 비즈니스 인텔리전스 제품군(SSIS, SSRS, SSAS) 내에서 Teradata 데이터베이스로의 연결을 통합합니다.
+ Teradata 데이터베이스에서 RDS for SQL Server로의 마이그레이션
기존 또는 새 RDS for SQL Server DB 인스턴스에서 Teradata용 연결된 서버를 하나 이상 활성화할 수 있습니다. 그런 다음 외부 Teradata 데이터 소스를 DB 인스턴스와 통합할 수 있습니다.
**Topics**
+ [지원되는 버전 및 리전](#USER_SQLServerTeradata.VersionRegionSupport)
+ [제한 및 권장 사항](#USER_SQLServerTeradata.LimitsandRecommendations)
+ [다중 AZ 배포에 대한 고려 사항](#USER_SQLServerTeradata.MultiAZ)
+ [Teradata와 연결된 서버 활성화](USER_SQLServerTeradata.Activate.md)
+ [Teradata와 연결된 서버 만들기](USER_SQLServerTeradata.CreateLinkedServers.md)
+ [Teradata에 연결된 서버 비활성화](USER_SQLServerTeradata.Deactivate.md)
## 지원되는 버전 및 리전
RDS for SQL Server는 다음 버전의 SQL Server Standard 및 Enterprise Edition에 대해 모든 AWS 리전에서 Teradata ODBC와 연결된 서버를 지원합니다.
+ SQL Server 2022, 모든 버전
+ SQL Server 2019, 모든 버전
+ SQL Server 2017, 모든 버전
다음 Teradata 데이터베이스 버전은 RDS for SQL Server와의 연결을 지원합니다.
+ Teradata 17.20, 모든 버전
## 제한 및 권장 사항
Teradata ODBC와 연결된 서버에는 다음 제한 사항이 적용됩니다.
+ RDS for SQL Server는 Teradata 데이터 소스에 대해 사용자 이름과 암호를 사용한 단순 인증만 지원합니다.
+ RDS for SQL Server는 Teradata ODBC 드라이버 버전 17.20.0.33만 지원합니다.
+ RDS for SQL Server는 연결 문자열의 바로 가기로 사용할 데이터 소스 이름(DSN) 생성을 지원하지 않습니다.
+ RDS for SQL Server는 ODBC 드라이버 추적을 지원하지 않습니다. SQL Server 확장 이벤트를 사용하여 OLEDB 이벤트를 추적하세요. 자세한 내용은 [RDS for SQL Server에서 확장 이벤트 설정](https://aws.amazon.com/blogs/database/set-up-extended-events-in-amazon-rds-for-sql-server/) 섹션을 참조하세요.
+ RDS for SQL Server는 SQL Server Management Studio(SSMS)를 사용하여 Teradata에 연결된 서버의 카탈로그 폴터에 액세스하는 작업을 지원하지 않습니다.
Teradata ODBC와 연결된 서버를 사용할 때는 다음 권장 사항을 고려하세요.
+ 각 RDS for SQL Server DB인스턴스의 보안 그룹에 적절한 TCP 포트를 추가하여 네트워크 트래픽을 허용하십시오. EC2 Teradata DB 인스턴스와 RDS for SQL Server DB 인스턴스 간에 연결된 서버를 구성하는 경우, EC2 Teradata DB 인스턴스의 IP 주소에서 오는 트래픽을 허용해야 합니다. 또한 RDS for SQL Server DB 인스턴스가 데이터베이스 통신을 수신하는 데 사용하는 포트에서 트래픽을 허용해야 합니다. 보안 그룹에 대한 자세한 정보는 [보안 그룹을 통한 액세스 제어](Overview.RDSSecurityGroups.md) 단원을 참조하세요.
+ 분산 트랜잭션(XA)은 지원됩니다. 분산 트랜잭션을 활성화하려면 DB 인스턴스의 옵션 그룹에서 `MSDTC` 옵션을 켜고 XA 트랜잭션이 켜져 있는지 확인합니다. 자세한 내용은 [RDS for SQL Server에서 Microsoft Distributed Transaction Coordinator 지원](Appendix.SQLServer.Options.MSDTC.md) 섹션을 참조하세요.
+ 연결된 Teradata ODBC는 Teradata Server에서 구성된 경우 SSL/TLS를 지원합니다. 자세한 내용은 [Teradata Vantage에서 TLS 연결 활성화](https://docs.teradata.com/r/Enterprise_IntelliFlex_Lake_VMware/Teradata-Call-Level-Interface-Version-2-Reference-for-Workstation-Attached-Systems-20.00/Mainframe-TLS-Connectivity-Supplement/Enable-TLS-Connectivity-on-Teradata-Vantage)를 참조하세요.
## 다중 AZ 배포에 대한 고려 사항
RDS for SQL Server는 현재 다중 AZ 배포에서 연결된 서버를 미러링된 데이터베이스 서버(또는 상시 작동 가용성 그룹 보조 서버)에 복제하지 않습니다. 미러링 또는 상시 작동을 추가하도록 구성을 변경하기 전에 연결된 서버를 추가하면 연결된 서버가 기존 연결된 서버에 대해 복사됩니다.
또는 기본 인스턴스에서 연결된 서버를 만들고 고가용성 서버 인스턴스로 장애 조치한 다음 연결된 서버를 다시 만들어 두 RDS for SQL Server 인스턴스 모두에 연결된 서버가 있도록 할 수 있습니다.
# Teradata와 연결된 서버 활성화
`ODBC_TERADATA` 옵션을 RDS for SQL Server DB 인스턴스에 추가하여 Teradata와 연결된 서버를 활성화합니다. 다음 프로세스를 사용합니다.
**Topics**
+ [`ODBC_TERADATA`용 옵션 그룹 만들기](#USER_SQLServerTeradata.Activate.CreateOG)
+ [옵션 그룹에 `ODBC_TERADATA` 옵션 추가](#USER_SQLServerTeradata.Activate.AddOG)
+ [`ODBC_TERADATA` 옵션을 DB 인스턴스와 연결](#USER_SQLServerTeradata.Activate.AssociateOG)
## `ODBC_TERADATA`용 옵션 그룹 만들기
Teradata와 연결된 서버를 사용하려면 사용할 DB 인스턴스의 SQL Server 에디션 및 버전에 해당하는 옵션 그룹을 만들거나 수정합니다. 이 절차를 완료하려면 AWS Management Console 또는 AWS CLI를 사용합니다.
### 콘솔
다음 절차를 사용하여 SQL Server Standard Edition 2019에 대한 옵션 그룹을 만듭니다.
**옵션 그룹을 생성하려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **옵션 그룹**을 선택합니다.
1. **그룹 생성**을 선택합니다.
1. **보안 그룹 생성** 창에서 다음과 같이 합니다.
1. **이름**에 AWS 계정 계정 내에서 쉽게 식별할 수 있는 옵션 그룹 이름을 입력합니다(예: `teradata-odbc-se-2019`). 이름은 글자, 숫자 및 하이픈만 사용 가능합니다.
1. **설명**에 옵션 그룹에 대한 간단한 설명을 입력합니다.
1. **엔진**에 대해 **sqlserver-se**를 선택합니다.
1. **Major engine version**(메이저 엔진 버전)에 **15.00**을 선택합니다.
1. **생성(Create)**을 선택합니다.
### AWS CLI
다음 절차에서는 SQL Server Standard Edition 2019에 대한 옵션 그룹을 생성합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds create-option-group \
--option-group-name teradata-odbc-se-2019 \
--engine-name sqlserver-se \
--major-engine-version 15.00 \
--option-group-description "ODBC_TERADATA option group for SQL Server SE 2019"
```
**Example**
Windows의 경우:
```
aws rds create-option-group ^
--option-group-name teradata-odbc-se-2019 ^
--engine-name sqlserver-se ^
--major-engine-version 15.00 ^
--option-group-description "ODBC_TERADATA option group for SQL Server SE 2019"
```
## 옵션 그룹에 `ODBC_TERADATA` 옵션 추가
그런 다음 AWS Management Console 또는 AWS CLI를 사용하여 `ODBC_Teradata` 옵션을 옵션 그룹에 추가합니다.
### 콘솔
다음 절차를 사용하여 SQL Server Standard Edition 2019에 대한 옵션 그룹을 만듭니다.
**`ODBC_TERADATA` 옵션을 추가하려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **옵션 그룹**을 선택합니다.
1. 새 옵션 그룹을 선택합니다.
1. **옵션 추가**를 선택합니다.
1. **옵션 세부 정보**에서 다음을 수행합니다.
1. **옵션 이름**으로 **ODBC\$1TERADATA**를 선택합니다.
1. **옵션 버전**으로 `17.20.33.00`을 입력합니다.
1. 예약에서 옵션을 즉시 추가할지 또는 다음 유지 관리 기간에 추가할지를 선택합니다.
1. **옵션 추가**를 선택합니다.
### AWS CLI
다음 절차에서는 `ODBC_TERADATA` 옵션을 옵션 그룹에 추가합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds add-option-to-option-group \
--option-group-name teradata-odbc-se-2019 \
--options "OptionName=ODBC_TERADATA,OptionVersion=17.20.33.00" \
--apply-immediately
```
**Example**
Windows의 경우:
```
aws rds add-option-to-option-group ^
--option-group-name teradata-odbc-se-2019 ^
--options "OptionName=ODBC_TERADATA,OptionVersion=17.20.33.00" ^
--apply-immediately
```
## `ODBC_TERADATA` 옵션을 DB 인스턴스와 연결
AWS Management Console 또는 AWS CLI를 사용하여 `ODBC_TERADATA` 옵션 그룹을 DB 인스턴스와 연결할 수 있습니다.
### 콘솔
Teradata용 연결된 서버 활성화를 완료하려면 옵션 그룹을 새 DB 인스턴스 또는 기존 DB 인스턴스와 연결합니다.
+ 새 DB 인스턴스의 경우 인스턴스를 시작할 때 연결합니다. 자세한 내용은 [Amazon RDS DB 인스턴스 생성](USER_CreateDBInstance.md) 섹션을 참조하세요.
+ 기존 DB 인스턴스의 경우 인스턴스를 수정하여 연결합니다. 자세한 내용은 [Amazon RDS DB 인스턴스 수정](Overview.DBInstance.Modifying.md) 섹션을 참조하세요.
### AWS CLI
옵션 그룹을 생성할 때 사용한 것과 동일한 DB 엔진 유형과 메이저 버전을 지정합니다.
대상 LinuxmacOS, 또는Unix:
```
aws rds create-db-instance \
--db-instance-identifier mytestsqlserverteradataodbcinstance \
--db-instance-class db.m5.2xlarge \
--engine sqlserver-se \
--engine-version 15.00 \
--license-model license-included \
--allocated-storage 100 \
--master-username admin \
--master-user-password password \
--storage-type gp2 \
--option-group-name teradata-odbc-se-2019
```
Windows의 경우:
```
aws rds create-db-instance ^
--db-instance-identifier mytestsqlserverteradataodbcinstance ^
--db-instance-class db.m5.2xlarge ^
--engine sqlserver-se ^
--engine-version 15.00 ^
--license-model license-included ^
--allocated-storage 100 ^
--master-username admin ^
--master-user-password password ^
--storage-type gp2 ^
--option-group-name teradata-odbc-se-2019
```
인스턴스를 수정하여 새로운 옵션 그룹을 연결하려면:
대상 LinuxmacOS, 또는Unix:
```
aws rds modify-db-instance \
--db-instance-identifier mytestsqlserverteradataodbcinstance \
--option-group-name teradata-odbc-se-2019 \
--apply-immediately
```
Windows의 경우:
```
aws rds modify-db-instance ^
--db-instance-identifier mytestsqlserverteradataodbcinstance ^
--option-group-name teradata-odbc-se-2019 ^
--apply-immediately
```
# Teradata와 연결된 서버 만들기
Teradata와 연결된 서버를 만들려면 다음 명령을 실행합니다.
```
EXECUTE master.dbo.sp_addlinkedserver
@server = N'LinkedServer_NAME',
@srvproduct=N'',
@provider=N'MSDASQL',
@provstr=N'"PROVIDER=MSDASQL;DRIVER={Teradata Database ODBC Driver 17.20};
DBCName=Server;UID=user_name;PWD=user_password;
UseDataEncryption=YES/NO;SSLMODE=PREFER/ALLOW/DISABLE>;"',
@catalog='database'
```
```
EXECUTE master.dbo.sp_addlinkedsrvlogin
@rmtsrvname = N'LinkedServer_NAME',
@locallogin = NULL ,
@useself = N'False',
@rmtuser = N'user_name',
@rmtpassword = N'user_password'
```
위 명령의 예는 다음과 같습니다.
```
EXECUTE master.dbo.sp_addlinkedserver
@server = N'LinkedServerToTeradata',
@srvproduct=N'',
@provider=N'MSDASQL',
@provstr=N'"PROVIDER=MSDASQL;DRIVER={Teradata Database ODBC Driver 17.20};
DBCName=my-teradata-test.cnetsipka.us-west-2.rds.amazonaws.com;
UID=master;
PWD=Test#1234;
UseDataEncryption=YES;
SSLMODE=PREFER;"',
@catalog='MyTestTeradataDB'
EXECUTE master.dbo.sp_addlinkedsrvlogin
@rmtsrvname = N'LinkedServerToTeradata',
@locallogin = NULL ,
@useself = N'False',
@rmtuser = N'master',
@rmtpassword = N'Test#1234'
```
**참고**
보안 모범 사례로 여기에 표시된 프롬프트 이외의 암호를 지정하는 것이 좋습니다.
# Teradata에 연결된 서버 비활성화
Teradata와 연결된 서버를 비활성화하려면 해당 옵션 그룹에서 `ODBC_TERADATA` 옵션을 제거합니다.
**중요**
옵션을 제거해도 DB 인스턴스의 연결된 서버 구성은 삭제되지 않습니다. DB 인스턴스에서 제거하려면 수동으로 삭제해야 합니다.
제거 후 `ODBC_TERADATA`를 재활성화하여 DB 인스턴스에서 이전에 구성한 연결된 서버 구성을 재사용할 수 있습니다.
## 콘솔
옵션 그룹에서 `ODBC_TERADATA` 옵션을 제거합니다.
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **옵션 그룹**을 선택합니다.
1. `ODBC_TERADATA` 옵션을 사용하여 옵션 그룹을 선택합니다.
1. **삭제**를 선택합니다.
1. **삭제 옵션**에서 **삭제할 옵션** 아래의 `ODBC_TERADATA`를 선택합니다.
1. **Apply immediately**(즉시 적용)에서 **Yes**(예)를 선택하여 옵션을 즉시 삭제하거나 **No**(아니오)를 선택하여 다음 유지 관리 기간에 삭제합니다.
1. **삭제**를 선택합니다.
## AWS CLI
다음 절차에서는 `ODBC_TERADATA` 옵션을 제거합니다.
대상 LinuxmacOS, 또는Unix:
```
aws rds remove-option-from-option-group \
--option-group-name teradata-odbc-se-2019 \
--options ODBC_TERADATA \
--apply-immediately
```
Windows의 경우:
```
aws rds remove-option-from-option-group ^
--option-group-name teradata-odbc-se-2019 ^
--options ODBC_TERADATA ^
--apply-immediately
```
# SQL Server에서 기본 백업 및 복원 지원
SQL Server 데이터베이스에 대한 기본 백업 및 복원을 사용하여 온프레미스 데이터베이스의 차등 백업 또는 전체 백업을 생성하고 Amazon S3에 백업 파일을 저장할 수 있습니다. 그런 다음 SQL Server를 실행하는 기존 Amazon RDS DB 인스턴스로 복원할 수 있습니다. RDS for SQL Server 데이터베이스를 백업하고 Amazon S3에 저장하고 다른 위치에 복원할 수도 있습니다. 또한 온프레미스 서버 또는 SQL Server를 실행 중인 다른 Amazon RDS DB 인스턴스로 백업을 복원할 수 있습니다. 자세한 내용은 [기본 백업 및 복원 기능을 사용하여 SQL Server 데이터베이스 가져오기 및 내보내기](SQLServer.Procedural.Importing.md) 섹션을 참조하세요.
Amazon RDS는 차등 및 전체 백업 파일(.bak 파일)을 사용하여 Microsoft SQL Server 데이터베이스에 기본 백업 및 복원을 할 수 있도록 지원합니다.
## 기본 백업 및 복원 옵션 추가
기본 백업 및 복원 옵션을 DB 인스턴스에 추가하는 일반적인 프로세스는 다음과 같습니다.
1. 새 옵션 그룹을 생성하거나 기존 옵션 그룹을 복사 또는 수정합니다.
1. [`SQLSERVER_BACKUP_RESTORE`] 옵션을 옵션 그룹에 추가합니다.
1. AWS Identity and Access Management(IAM) 역할을 옵션과 연결합니다. 데이터베이스 백업을 저장하려면 IAM 역할에 S3 버킷에 대한 액세스 권한이 있어야 합니다.
즉, `arn:aws:iam::account-id:role/role-name` 형식으로 유효한 Amazon 리소스 이름(ARN)을 설정하는 옵션이 있어야 합니다. 자세한 내용은 *AWS 일반 참조*의 [Amazon 리소스 이름(ARN)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html#arn-syntax-iam)을 참조하세요.
또한 IAM 역할에는 신뢰 관계와 권한 정책이 연결되어 있어야 합니다. RDS는 신뢰 관계를 사용하여 역할을 수임할 수 있으며 권한 정책은 역할이 수행할 수 있는 작업을 정의합니다. 자세한 내용은 [기본 백업 및 복원을 위한 IAM 역할 수동으로 만들기](SQLServer.Procedural.Importing.Native.Enabling.md#SQLServer.Procedural.Importing.Native.Enabling.IAM) 섹션을 참조하세요.
1. 옵션 그룹을 DB 인스턴스에 연동시킵니다.
기본 백업 및 복원 옵션을 추가한 후 DB 인스턴스를 다시 시작할 필요가 없습니다. 옵션 그룹이 활성화되는 즉시 백업 및 복원을 시작할 수 있습니다.
### 콘솔
**기본 백업 및 복원 옵션을 추가하려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **옵션 그룹**을 선택합니다.
1. 새 옵션 그룹을 생성하거나 기존 옵션 그룹을 사용합니다. 사용자 지정 DB 옵션 그룹을 생성하는 방법에 대한 자세한 내용은 [옵션 그룹 생성](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Create) 단원을 참조하십시오.
기존 옵션 그룹을 사용하려면 다음 단계로 건너뛰십시오.
1. 옵션 그룹에 **SQLSERVER\$1BACKUP\$1RESTORE** 옵션을 추가합니다. 옵션 추가에 대한 자세한 내용은 [옵션 그룹에 옵션 추가](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.AddOption) 섹션을 참조하세요.
1. 다음 중 하나를 수행하십시오.
+ 기존 IAM 역할 및 Amazon S3 설정을 사용하려면 **IAM 역할**에 대해 기존 IAM 역할을 선택합니다. 기존 IAM 역할을 사용하는 경우 RDS는 이 역할에 구성된 Amazon S3 설정을 사용합니다.
+ 새 역할을 생성하고 새 Amazon S3 설정을 구성하려면 다음을 수행하세요.
1. **IAM 역할**에서 **새 역할 생성**을 선택합니다.
1. **S3 버킷(S3 bucket)**에서 목록의 S3 버킷을 선택합니다.
1. **S3 접두사(선택 사항)(S3 prefix (optional))**에서 Amazon S3 버킷에 저장된 파일에 사용할 접두사를 지정합니다.
이 접두사에 파일 경로를 포함할 수 있지만 필수는 아닙니다. 접두사를 제공하면 RDS가 해당 접두사를 모든 백업 파일에 첨부합니다. 그런 다음 RDS는 복원 중에 접두사를 사용하여 관련 파일을 식별하고 관련 없는 파일을 무시합니다. 예를 들어 백업 파일을 보관하는 것 이외의 목적으로 S3 버킷을 사용할 수 있습니다. 이 경우 접두사를 사용하여 RDS가 특정 폴더와 해당 하위 폴더에서만 기본 백업 및 복원을 수행하도록 할 수 있습니다.
접두사를 비워 두면 RDS가 접두사를 사용하여 백업 파일 또는 복원할 파일을 식별하지 않습니다. 결과적으로 다중 파일 복원 중에 RDS는 S3 버킷의 모든 폴더에 있는 모든 파일을 복원하려고 시도합니다.
1. **암호화 활성화(Enable Encryption)** 체크박스를 선택하여 백업 파일을 암호화합니다. 백업 파일을 암호화하지 않도록 하려면 확인란의 선택을 취소한 상태로 둡니다(기본값).
**암호화 활성화(Enable encryption)**를 선택한 경우, **AWS KMS key**을 위한 암호화 키를 선택합니다. 암호화 키에 대한 자세한 내용은 *AWS Key Management Service 개발자 안내서*에서 [시작하기](https://docs.aws.amazon.com/kms/latest/developerguide/getting-started.html)를 참조하세요.
1. **옵션 추가**를 선택합니다.
1. 옵션 그룹을 새 DB 인스턴스 또는 기존 DB 인스턴스에 적용합니다:
+ 새 DB 인스턴스의 경우, 인스턴스를 시작할 때 옵션 그룹을 적용하십시오. 자세한 내용은 [Amazon RDS DB 인스턴스 생성](USER_CreateDBInstance.md) 섹션을 참조하세요.
+ 기존 DB 인스턴스의 경우, 해당 인스턴스를 수정하고 새 옵션 그룹을 연결하여 옵션 그룹을 적용하십시오. 자세한 내용은 [Amazon RDS DB 인스턴스 수정](Overview.DBInstance.Modifying.md) 단원을 참조하세요.
### CLI
이 절차에서는 다음과 같이 가정합니다.
+ SQLSERVER\$1BACKUP\$1RESTORE 옵션을 이미 존재하는 옵션 그룹에 추가하려고 합니다. 옵션 추가에 대한 자세한 내용은 [옵션 그룹에 옵션 추가](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.AddOption) 섹션을 참조하세요.
+ 이 옵션을 이미 존재하고 백업 저장을 위해 S3 버킷에 액세스할 수 있는 IAM 역할과 연결합니다.
+ 이미 존재하는 DB 인스턴스에 옵션 그룹을 적용하려고 합니다. 자세한 내용은 [Amazon RDS DB 인스턴스 수정](Overview.DBInstance.Modifying.md) 섹션을 참조하세요.
**기본 백업 및 복원 옵션을 추가하려면**
1. [`SQLSERVER_BACKUP_RESTORE`] 옵션을 옵션 그룹에 추가합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds add-option-to-option-group \
--apply-immediately \
--option-group-name mybackupgroup \
--options "OptionName=SQLSERVER_BACKUP_RESTORE, \
OptionSettings=[{Name=IAM_ROLE_ARN,Value=arn:aws:iam::account-id:role/role-name}]"
```
Windows의 경우:
```
aws rds add-option-to-option-group ^
--option-group-name mybackupgroup ^
--options "[{\"OptionName\": \"SQLSERVER_BACKUP_RESTORE\", ^
\"OptionSettings\": [{\"Name\": \"IAM_ROLE_ARN\", ^
\"Value\": \"arn:aws:iam::account-id:role/role-name"}]}]" ^
--apply-immediately
```
**참고**
Windows 명령 프롬프트를 사용하는 경우 백슬래시(\$1)를 접두사로 추가하여 JSON 코드에서 큰 따옴표(")를 이스케이프해야 합니다.
1. 옵션 그룹을 DB 인스턴스에 적용합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds modify-db-instance \
--db-instance-identifier mydbinstance \
--option-group-name mybackupgroup \
--apply-immediately
```
Windows의 경우:
```
aws rds modify-db-instance ^
--db-instance-identifier mydbinstance ^
--option-group-name mybackupgroup ^
--apply-immediately
```
## 기본 백업 및 복원 옵션 설정 수정
기본 백업 및 복원 옵션을 활성화한 후 옵션의 설정을 수정할 수 있습니다. 옵션 설정을 변경하는 방법에 대한 자세한 내용은 [옵션 설정 수정](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.ModifyOption)을(를) 참조하십시오.
## 기본 백업 및 복원 옵션 제거
DB 인스턴스에서 옵션을 제거하여 기본 백업 및 복원 기능을 끌 수 있습니다. 기본 백업 및 복원 옵션을 제거한 후 DB 인스턴스를 다시 시작할 필요가 없습니다.
DB 인스턴스에서 기본 백업 및 복원 옵션을 제거하려면 다음 중 하나를 수행합니다.
+ 소속 옵션 그룹에서 옵션을 제거합니다. 이 변경은 해당 옵션 그룹을 사용하는 모든 DB 인스턴스에 영향을 미칩니다. 자세한 내용은 [옵션 그룹에서 옵션 제거](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.RemoveOption) 섹션을 참조하세요.
+ DB 인스턴스를 수정하고, 기본 백업 및 복원 옵션이 포함되지 않은 다른 옵션 그룹을 지정합니다. 이 변경은 단일 DB 인스턴스에 영향을 미칩니다. 기본(빈) 옵션 그룹을 지정하거나 다른 사용자 지정 옵션 그룹을 지정할 수 있습니다. 자세한 내용은 [Amazon RDS DB 인스턴스 수정](Overview.DBInstance.Modifying.md) 섹션을 참조하세요.
# SQL Server에서 TDE(투명한 데이터 암호화) 지원
Amazon RDS는 Microsoft SQL Server를 실행하는 DB 인스턴스에 저장된 데이터를 암호화하기 위하여 Transparent Data Encryption(TDE) 이용을 지원합니다. TDE는 스토리지에 데이터를 쓰기 전에 자동으로 데이터를 암호화한 뒤에 데이터를 스토리지에서 읽을 때 다시 자동으로 복호화합니다.
Amazon RDS는 다음 SQL Server 버전에 TDE를 지원합니다.
+ SQL Server 2022 Standard Edition 및 Enterprise Edition
+ SQL Server 2019 Standard Edition 및 Enterprise Edition
+ SQL Server 2017 Enterprise Edition
+ SQL Server 2016 Enterprise Edition
**참고**
RDS for SQL Server는 읽기 전용 데이터베이스에 대한 TDE를 지원하지 않습니다.
SQL Server의 TDE는 2계층 키 아키텍처를 사용하여 암호화 키 관리 기능을 지원합니다. 데이터베이스 마스터 키에서 생성된 인증서는 데이터 암호화 키를 보호하는 데 사용됩니다. 데이터베이스 암호화 키는 사용자 데이터베이스의 데이터를 실제로 암호화 및 복호화합니다. Amazon RDS는 데이터베이스 마스터 키와 TDE 인증서를 백업하고 관리합니다.
Transparent Data Encryption은 중요한 데이터를 암호화해야 하는 경우에 사용됩니다. 예를 들어 타사에 데이터 파일과 백업을 제공하거나 보안 관련 규정 준수 문제를 해결하고 싶을 수 있습니다. `model` 또는 `master` 데이터베이스와 같은 SQL Server의 시스템 데이터베이스를 암호화할 수 없습니다.
투명한 데이터 암호화에 대한 자세한 설명은 본 문서의 범위에서 벗어나지만, 보안과 관련하여 각 암호화 알고리즘과 키의 장단점은 잘 알고 있어야 합니다. SQL Server의 투명한 데이터 암호화(TDE)에 대한 자세한 내용은 Microsoft 설명서의 [투명한 데이터 암호화(TDE)](http://msdn.microsoft.com/en-us/library/bb934049.aspx)를 참조하세요.
**Topics**
+ [RDS for SQL Server에 대한 TDE 활성화](#TDE.Enabling)
+ [RDS for SQL Server의 데이터 암호화](TDE.Encrypting.md)
+ [RDS for SQL Server에서 TDE 인증서 백업 및 복원](TDE.BackupRestoreRDS.md)
+ [온프레미스 데이터베이스에 대한 TDE 인증서 백업 및 복원](TDE.BackupRestoreOnPrem.md)
+ [RDS for SQL Server에 대한 TDE 비활성화](TDE.Disabling.md)
## RDS for SQL Server에 대한 TDE 활성화
RDS for SQL Server DB 인스턴스에서 투명한 데이터 암호화를 활성화하려면 해당 DB 인스턴스와 연동되어 있는 RDS 옵션 그룹에서 TDE 옵션을 지정해야 합니다.
1. 혹시 DB 인스턴스가 TDE 옵션이 추가된 옵션 그룹과 이미 연동되어 있는지 먼저 확인합니다. DB 인스턴스와 연동되어 있는 옵션 그룹은 RDS 콘솔, [describe-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) AWS CLI 명령 또는 API 작업 [DescribeDBInstances](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBInstances.html)를 사용하여 확인할 수 있습니다.
1. DB 인스턴스가 TDE가 활성화된 옵션 그룹과 연결되어 있지 않으면 2가지 옵션을 사용할 수 있습니다. 옵션 그룹을 생성하고 TDE 옵션을 추가하거나, 연결된 옵션 그룹을 수정하여 추가할 수 있습니다.
**참고**
RDS 콘솔에서는 옵션의 이름이 `TRANSPARENT_DATA_ENCRYPTION`입니다. AWS CLI 및 RDS API에서는 이 이름이 `TDE`입니다.
옵션 그룹의 생성 및 변경에 대한 자세한 내용은 [옵션 그룹 작업](USER_WorkingWithOptionGroups.md) 섹션을 참조하십시오. 옵션 그룹에 옵션을 추가하는 방법에 대한 자세한 내용은 [옵션 그룹에 옵션 추가](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.AddOption) 섹션을 참조하십시오.
1. DB 인스턴스를 TDE 옵션이 있는 옵션 그룹과 연결합니다. DB 인스턴스와 옵션 그룹의 연동에 대한 자세한 내용은 [Amazon RDS DB 인스턴스 수정](Overview.DBInstance.Modifying.md) 섹션을 참조하십시오.
### 옵션 그룹 고려 사항
TDE 옵션은 영구 옵션입니다. 모든 DB 인스턴스 및 백업이 옵션 그룹과 연결되어 있지 않은 경우를 제외하고 옵션 그룹에서 DB 인스턴스 및 백업을 제거할 수 없습니다. TDE 옵션을 옵션 그룹에 추가하면 이 옵션 그룹은 TDE를 사용하는 DB 인스턴스에 한해 연동이 가능합니다. 옵션 그룹의 영구 옵션에 대한 자세한 내용은 [옵션 그룹 개요](USER_WorkingWithOptionGroups.md#Overview.OptionGroups) 섹션을 참조하십시오.
TDE 옵션은 영구 옵션이기 때문에 옵션 그룹과 연결된 DB 인스턴스 사이에 충돌이 일어날 수 있습니다. 다음 상황에서 충돌이 발생할 수 있습니다.
+ 현재 TDE 옵션을 설정한 옵션 그룹을 TDE 옵션을 사용하지 않는 옵션 그룹으로 변경하는 경우
+ DB 스냅샷에서 TDE 옵션을 포함하는 옵션 그룹이 연결되지 않은 새 DB 인스턴스로 복원하는 경우 이 시나리오에 대한 자세한 내용은 [옵션 그룹에 대한 고려 사항](USER_CopySnapshot.md#USER_CopySnapshot.Options)를 참조하십시오.
### SQL Server 성능 고려 사항
투명한 데이터 암호화를 사용하면 SQL Server DB 인스턴스의 성능에 영향을 미칠 수 있습니다.
DB 인스턴스의 데이터베이스 중 암호화된 데이터베이스가 하나 이상만 있어도 마찬가지로 암호화되지 않은 데이터베이스의 성능이 떨어질 수 있습니다. 따라서 암호화되지 않은 데이터베이스와 암호화된 데이터베이스는 별도의 DB 인스턴스에서 관리하는 것이 좋습니다.
# RDS for SQL Server의 데이터 암호화
TDE 옵션을 옵션 그룹에 추가하면 Amazon RDS가 암호화 프로세스에 사용할 인증서를 생성합니다. 그러면 이 인증서를 사용하여 DB 인스턴스의 데이터베이스에 저장된 데이터를 암호화하는 SQL 문을 실행할 수 있습니다.
다음은 `RDSTDECertificateName`이라고 하는 RDS 생성 인증서를 사용하여 `myDatabase`라는 데이터베이스를 암호화하는 예제입니다.
```
1. ---------- Turning on TDE -------------
2.
3. -- Find an RDS TDE certificate to use
4. USE [master]
5. GO
6. SELECT name FROM sys.certificates WHERE name LIKE 'RDSTDECertificate%'
7. GO
8.
9. USE [myDatabase]
10. GO
11. -- Create a database encryption key (DEK) using one of the certificates from the previous step
12. CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_256
13. ENCRYPTION BY SERVER CERTIFICATE [RDSTDECertificateName]
14. GO
15.
16. -- Turn on encryption for the database
17. ALTER DATABASE [myDatabase] SET ENCRYPTION ON
18. GO
19.
20. -- Verify that the database is encrypted
21. USE [master]
22. GO
23. SELECT name FROM sys.databases WHERE is_encrypted = 1
24. GO
25. SELECT db_name(database_id) as DatabaseName, * FROM sys.dm_database_encryption_keys
26. GO
```
TDE를 사용하여 SQL Server 데이터베이스를 암호화하는 데 걸리는 시간은 몇 가지 요인에 따라 다릅니다. 여기에는 DB 인스턴스의 크기, 인스턴스가 프로비저닝된 IOPS 스토리지를 사용하는지 여부, 데이터 양 및 기타 요소가 포함됩니다.
# RDS for SQL Server에서 TDE 인증서 백업 및 복원
RDS for SQL Server는 TDE 인증서를 백업, 복원 및 삭제하기 위한 저장 프로시저를 제공합니다. RDS for SQL Server는 복원된 사용자 TDE 인증서를 보는 기능도 제공합니다.
사용자 TDE 인증서는 온프레미스에 있고 TDE가 설정된 RDS for SQL Server로 데이터베이스를 복원하는 데 사용됩니다. 이러한 인증서에는 접두사 `UserTDECertificate_`가 붙습니다. RDS는 데이터베이스를 복원한 후 사용할 수 있게 하기 전에 TDE가 활성화된 데이터베이스를 수정하여 RDS 생성 TDE 인증서를 사용합니다. 이러한 인증서에는 접두사 `RDSTDECertificate`가 붙습니다.
사용자 TDE 인증서는 `rds_drop_tde_certificate` 저장 프로시저를 사용하여 삭제하지 않는 한 RDS for SQL Server DB 인스턴스에 남아 있습니다. 자세한 내용은 [복원된 TDE 인증서 삭제](#TDE.BackupRestoreRDS.Drop) 섹션을 참조하세요.
사용자 TDE 인증서를 사용하여 소스 DB 인스턴스에서 다른 데이터베이스를 복원할 수 있습니다. 복원할 데이터베이스는 동일한 TDE 인증서를 사용해야 하며, TDE가 활성화되어 있어야 합니다. 동일한 인증서를 다시 가져올(복원) 필요가 없습니다.
**Topics**
+ [사전 조건](#TDE.BackupRestoreRDS.Prereqs)
+ [제한 사항](#TDE.Limitations)
+ [TDE 인증서 백업](#TDE.BackupRestoreRDS.Backup)
+ [TDE 인증서 복원](#TDE.BackupRestoreRDS.Restore)
+ [복원된 TDE 인증서 보기](#TDE.BackupRestoreRDS.Show)
+ [복원된 TDE 인증서 삭제](#TDE.BackupRestoreRDS.Drop)
## 사전 조건
RDS for SQL Server에 TDE 인증서를 백업하거나 복원하려면 먼저 다음 태스크를 수행해야 합니다. 처음 3개는 [기본 백업 및 복원 설정](SQLServer.Procedural.Importing.Native.Enabling.md)에 설명되어 있습니다.
1. 백업 및 복원을 위해 파일을 저장할 Amazon S3 일반용 버킷 또는 디렉터리 버킷을 생성합니다.
데이터베이스 백업 및 TDE 인증서 백업에는 별도의 버킷을 사용하는 것이 좋습니다.
1. 파일 백업 및 복원을 위한 IAM 역할을 생성합니다.
IAM 역할은 AWS KMS key의 관리자이며 사용자여야 합니다.
디렉터리 버킷을 사용하는 경우 디렉터리 버킷을 사용하는 [기본 백업 및 복원을 위한 IAM 역할 수동으로 만들기](SQLServer.Procedural.Importing.Native.Enabling.md#SQLServer.Procedural.Importing.Native.Enabling.IAM)에 필요한 권한 외에는 추가 권한이 필요하지 않습니다.
S3 리소스를 사용할 때, IAM 역할은 [기본 백업 및 복원을 위한 IAM 역할 수동으로 만들기](SQLServer.Procedural.Importing.Native.Enabling.md#SQLServer.Procedural.Importing.Native.Enabling.IAM)에 필요한 권한 외에도 다음 권한이 필요합니다.
+ S3 버킷 리소스의 `s3:GetBucketAcl`, `s3:GetBucketLocation`, `s3:ListBucket`
1. DB 인스턴스의 옵션 그룹에 `SQLSERVER_BACKUP_RESTORE` 옵션을 추가합니다.
이는 `TRANSPARENT_DATA_ENCRYPTION`(`TDE`) 옵션에 추가됩니다.
1. 대칭 암호화 KMS 키가 있는지 확인합니다. 다음과 같은 옵션이 있습니다.
+ 계정에 기존 KMS 키가 있는 경우 사용할 수 있습니다. 별도로 조치를 취할 필요가 없습니다.
+ 계정에 사용 중이던 대칭 암호화 KMS 키가 없는 경우 *AWS Key Management Service 개발자 가이드*의 [키 생성](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-symmetric-cmk) 지침에 따라 KMS 키를 생성합니다.
1. Amazon S3 통합을 활성화하여 DB 인스턴스와 Amazon S3 간에 파일을 전송합니다.
Amazon S3 통합에 대한 자세한 내용은 [Amazon RDS for SQL Server DB 인스턴스와 Amazon S3 통합](User.SQLServer.Options.S3-integration.md) 섹션을 참조하세요.
디렉터리 버킷은 S3 통합에 지원되지 않습니다. 이 단계는 [온프레미스 데이터베이스에 대한 TDE 인증서 백업 및 복원](TDE.BackupRestoreOnPrem.md)에만 필요합니다.
## 제한 사항
저장 프로시저를 사용하여 TDE 인증서를 백업 및 복원하는 데는 다음과 같은 제한이 있습니다.
+ `SQLSERVER_BACKUP_RESTORE` 및 `TRANSPARENT_DATA_ENCRYPTION`(`TDE`) 옵션을 모두 DB 인스턴스에 연결된 옵션 그룹에 추가해야 합니다.
+ 다중 AZ DB 인스턴스에는 TDE의 인증서 백업 및 복원이 지원되지 않습니다.
+ TDE 인증서 백업 및 복원 태스크는 취소할 수 없습니다.
+ RDS for SQL Server DB 인스턴스에 있는 다른 데이터베이스의 TDE 암호화에 사용자 TDE 인증서를 사용할 수 없습니다. 이를 사용하여 TDE가 활성화되어 있고 동일한 TDE 인증서를 사용하는 소스 DB 인스턴스에서 다른 데이터베이스만 복원할 수 있습니다.
+ 사용자 TDE 인증서만 삭제할 수 있습니다.
+ RDS에서 지원되는 최대 사용자 TDE 인증서 수는 10개입니다. 개수가 10개를 초과하면 사용하지 않는 TDE 인증서를 삭제하고 다시 시도하세요.
+ 인증서 이름은 비어 있거나 null일 수 없습니다.
+ 인증서를 복원할 때 인증서 이름에 `RDSTDECERTIFICATE` 키워드를 포함할 수 없으며, `UserTDECertificate_` 접두사로 시작해야 합니다.
+ `@certificate_name` 파라미터에는 a-z, 0-9, @, \$1, \$1, 밑줄(\$1) 문자만 포함할 수 있습니다.
+ `@certificate_file_s3_arn` 파일 확장명은 .cer(대/소문자를 구분하지 않음)이어야 합니다.
+ `@private_key_file_s3_arn` 파일 확장명은 .pvk(대/소문자를 구분하지 않음)이어야 합니다.
+ 프라이빗 키 파일의 S3 메타데이터에는 `x-amz-meta-rds-tde-pwd` 태그가 포함되어야 합니다. 자세한 내용은 [온프레미스 데이터베이스에 대한 TDE 인증서 백업 및 복원](TDE.BackupRestoreOnPrem.md) 섹션을 참조하세요.
+ RDS for SQL Server는 TDE에 대한 교차 계정 키 사용을 지원하지 않습니다.
## TDE 인증서 백업
TDE 인증서를 백업하려면 `rds_backup_tde_certificate` 저장 프로시저를 사용하면 됩니다. 다음 구문을 사용합니다.
```
EXECUTE msdb.dbo.rds_backup_tde_certificate
@certificate_name='UserTDECertificate_certificate_name | RDSTDECertificatetimestamp',
@certificate_file_s3_arn='arn:aws:s3:::bucket_name/certificate_file_name.cer',
@private_key_file_s3_arn='arn:aws:s3:::bucket_name/key_file_name.pvk',
@kms_password_key_arn='arn:aws:kms:region:account-id:key/key-id',
[@overwrite_s3_files=0|1];
```
다음 파라미터는 필수 파라미터입니다.
+ `@certificate_name` - 백업할 TDE 인증서의 이름입니다.
+ `@certificate_file_s3_arn` - Amazon S3의 인증서 백업 파일에 대한 대상 Amazon 리소스 이름(ARN)입니다.
+ `@private_key_file_s3_arn` - TDE 인증서를 보호하는 프라이빗 키 파일의 대상 S3 ARN입니다.
+ `@kms_password_key_arn` - 프라이빗 키 암호를 암호화하는 데 사용되는 대칭 KMS 키의 ARN입니다.
다음 파라미터는 선택 사항입니다.
+ `@overwrite_s3_files` - S3의 기존 인증서 및 프라이빗 키 파일을 덮어쓸지를 나타냅니다.
+ `0` – 기존 파일을 덮어쓰지 않습니다. 이 값이 기본값입니다.
`@overwrite_s3_files`를 0으로 설정하면 파일이 이미 존재할 경우 오류를 반환합니다.
+ `1` – 백업 파일이 아니더라도 지정된 이름이 있는 기존 파일을 덮어씁니다.
**Example TDE 인증서 백업**
```
EXECUTE msdb.dbo.rds_backup_tde_certificate
@certificate_name='RDSTDECertificate20211115T185333',
@certificate_file_s3_arn='arn:aws:s3:::TDE_certs/mycertfile.cer',
@private_key_file_s3_arn='arn:aws:s3:::TDE_certs/mykeyfile.pvk',
@kms_password_key_arn='arn:aws:kms:us-west-2:123456789012:key/AKIAIOSFODNN7EXAMPLE',
@overwrite_s3_files=1;
```
## TDE 인증서 복원
`rds_restore_tde_certificate` 저장 프로시저를 통해 사용자 TDE 인증서를 복원(가져오기)할 수 있습니다. 다음 구문을 사용합니다.
```
EXECUTE msdb.dbo.rds_restore_tde_certificate
@certificate_name='UserTDECertificate_certificate_name',
@certificate_file_s3_arn='arn:aws:s3:::bucket_name/certificate_file_name.cer',
@private_key_file_s3_arn='arn:aws:s3:::bucket_name/key_file_name.pvk',
@kms_password_key_arn='arn:aws:kms:region:account-id:key/key-id';
```
다음 파라미터는 필수 파라미터입니다.
+ `@certificate_name` - 복원할 TDE 인증서의 이름입니다. 이름이 `UserTDECertificate_` 접두사로 시작해야 합니다.
+ `@certificate_file_s3_arn` - TDE 인증서를 복원하는 데 사용된 백업 파일의 S3 ARN입니다.
+ `@private_key_file_s3_arn` - 복원할 TDE 인증서에 대한 프라이빗 키 백업 파일의 S3 ARN입니다.
+ `@kms_password_key_arn` - 프라이빗 키 암호를 암호화하는 데 사용되는 대칭 KMS 키의 ARN입니다.
**Example TDE 인증서 복원**
```
EXECUTE msdb.dbo.rds_restore_tde_certificate
@certificate_name='UserTDECertificate_myTDEcertificate',
@certificate_file_s3_arn='arn:aws:s3:::TDE_certs/mycertfile.cer',
@private_key_file_s3_arn='arn:aws:s3:::TDE_certs/mykeyfile.pvk',
@kms_password_key_arn='arn:aws:kms:us-west-2:123456789012:key/AKIAIOSFODNN7EXAMPLE';
```
## 복원된 TDE 인증서 보기
`rds_fn_list_user_tde_certificates` 함수를 통해 복원된(가져온) 사용자 TDE 인증서를 볼 수 있습니다. 다음 구문을 사용합니다.
```
SELECT * FROM msdb.dbo.rds_fn_list_user_tde_certificates();
```
다음과 유사하게 출력됩니다. 여기에는 일부 열이 표시되지 않습니다.
| | | | | | | | | | | |
| --- |--- |--- |--- |--- |--- |--- |--- |--- |--- |--- |
| name | certificate\$1id | principal\$1id | pvt\$1key\$1encryption\$1type\$1desc | issuer\$1name | cert\$1serial\$1number | thumbprint | subject | start\$1date | expiry\$1date | pvt\$1key\$1last\$1backup\$1date |
| UserTDECertificate\$1tde\$1cert | 343 | 1 | ENCRYPTED\$1BY\$1MASTER\$1KEY | AnyCompany Shipping | 79 3e 57 a3 69 fd 1d 9e 47 2c 32 67 1d 9c ca af | 0x6BB218B34110388680B FE1BA2D86C695096485B5 | AnyCompany Shipping | 2022-04-05 19:49:45.0000000 | 2023-04-05 19:49:45.0000000 | NULL |
## 복원된 TDE 인증서 삭제
사용하지 않는 복원된(가져온) 사용자 TDE 인증서를 삭제하려면 `rds_drop_tde_certificate` 저장 프로시저를 사용합니다. 다음 구문을 사용합니다.
```
EXECUTE msdb.dbo.rds_drop_tde_certificate @certificate_name='UserTDECertificate_certificate_name';
```
다음 파라미터는 필수입니다.
+ `@certificate_name` - 삭제할 TDE 인증서의 이름입니다.
복원된(가져온) TDE 인증서만 삭제할 수 있습니다. RDS 생성 인증서는 삭제할 수 없습니다.
**Example TDE 인증서 삭제**
```
EXECUTE msdb.dbo.rds_drop_tde_certificate @certificate_name='UserTDECertificate_myTDEcertificate';
```
# 온프레미스 데이터베이스에 대한 TDE 인증서 백업 및 복원
온프레미스 데이터베이스에 대한 TDE 인증서를 백업한 다음 나중에 RDS for SQL Server로 복원할 수 있습니다. RDS for SQL Server TDE 인증서를 온프레미스 DB 인스턴스로 복원할 수도 있습니다.
**참고**
RDS for SQL Server는 TDE에 대한 교차 계정 키 사용을 지원하지 않습니다.
다음 절차에서는 TDE 인증서 및 프라이빗 키를 백업합니다. 프라이빗 키는 대칭 암호화 KMS 키에서 생성된 데이터 키를 사용하여 암호화됩니다.
**온프레미스 TDE 인증서를 백업하려면**
1. AWS CLI [generate-data-key](https://docs.aws.amazon.com/cli/latest/reference/kms/generate-data-key.html) 명령을 사용하여 데이터 키를 생성합니다.
```
aws kms generate-data-key \
--key-id my_KMS_key_ID \
--key-spec AES_256
```
다음과 유사하게 출력됩니다.
```
{
"CiphertextBlob": "AQIDAHimL2NEoAlOY6Bn7LJfnxi/OZe9kTQo/XQXduug1rmerwGiL7g5ux4av9GfZLxYTDATAAAAfjB8BgkqhkiG9w0B
BwagbzBtAgEAMGgGCSqGSIb3DQEHATAeBglghkgBZQMEAS4wEQQMyCxLMi7GRZgKqD65AgEQgDtjvZLJo2cQ31Vetngzm2ybHDc3d2vI74SRUzZ
2RezQy3sAS6ZHrCjfnfn0c65bFdhsXxjSMnudIY7AKw==",
"Plaintext": "U/fpGtmzGCYBi8A2+0/9qcRQRK2zmG/aOn939ZnKi/0=",
"KeyId": "arn:aws:kms:us-west-2:123456789012:key/1234abcd-00ee-99ff-88dd-aa11bb22cc33"
}
```
다음 단계에서 일반 텍스트 출력을 프라이빗 키 암호로 사용합니다.
1. 다음 예와 같이 TDE 인증서를 백업합니다.
```
BACKUP CERTIFICATE myOnPremTDEcertificate TO FILE = 'D:\tde-cert-backup.cer'
WITH PRIVATE KEY (
FILE = 'C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\DATA\cert-backup-key.pvk',
ENCRYPTION BY PASSWORD = 'U/fpGtmzGCYBi8A2+0/9qcRQRK2zmG/aOn939ZnKi/0=');
```
1. Amazon S3 인증서 버킷에 인증서 백업 파일을 저장합니다.
1. 파일의 메타데이터에 다음 태그를 사용하여 프라이빗 키 백업 파일을 S3 인증서 버킷에 저장합니다.
+ 키 - `x-amz-meta-rds-tde-pwd`
+ 값 - 다음 예와 같이 데이터 키를 생성할 때의 `CiphertextBlob` 값입니다.
```
AQIDAHimL2NEoAlOY6Bn7LJfnxi/OZe9kTQo/XQXduug1rmerwGiL7g5ux4av9GfZLxYTDATAAAAfjB8BgkqhkiG9w0B
BwagbzBtAgEAMGgGCSqGSIb3DQEHATAeBglghkgBZQMEAS4wEQQMyCxLMi7GRZgKqD65AgEQgDtjvZLJo2cQ31Vetngzm2ybHDc3d2vI74SRUzZ
2RezQy3sAS6ZHrCjfnfn0c65bFdhsXxjSMnudIY7AKw==
```
다음 절차에서는 RDS for SQL Server TDE 인증서를 온프레미스 DB 인스턴스에 복원합니다. 인증서 백업, 해당 프라이빗 키 파일 및 데이터 키를 사용하여 대상 DB 인스턴스에서 TDE 인증서를 복사하고 복원합니다. 복원된 인증서는 새 서버의 데이터베이스 마스터 키로 암호화됩니다.
**TDE 인증서를 복원하려면**
1. Amazon S3에서 대상 인스턴스로 TDE 인증서 백업 파일과 프라이빗 키 파일을 복사합니다. Amazon S3에서 파일 복사에 대한 자세한 내용은 [RDS for SQL Server와 Amazon S3 간 파일 전송](Appendix.SQLServer.Options.S3-integration.using.md) 섹션을 참조하세요.
1. KMS 키로 출력 암호 텍스트를 해독하여 데이터 키의 일반 텍스트를 검색합니다. 암호 텍스트는 프라이빗 키 백업 파일의 S3 메타데이터에 있습니다.
```
aws kms decrypt \
--key-id my_KMS_key_ID \
--ciphertext-blob fileb://exampleCiphertextFile | base64 -d \
--output text \
--query Plaintext
```
다음 단계에서 일반 텍스트 출력을 프라이빗 키 암호로 사용합니다.
1. TDE 인증서를 복원하려면 다음 SQL 명령을 사용합니다.
```
CREATE CERTIFICATE myOnPremTDEcertificate FROM FILE='D:\tde-cert-backup.cer'
WITH PRIVATE KEY (FILE = N'D:\tde-cert-key.pvk',
DECRYPTION BY PASSWORD = 'plain_text_output');
```
KMS 해독에 대한 자세한 내용은 *AWS CLI 명령 참조*의 KMS 섹션에서 [해독](https://docs.aws.amazon.com/cli/latest/reference/kms/decrypt.html)을 참조하세요.
TDE 인증서가 대상 DB 인스턴스에 복원된 후 해당 인증서를 사용하여 암호화된 데이터베이스를 복원할 수 있습니다.
**참고**
동일한 TDE 인증서를 사용하여 소스 DB 인스턴스의 여러 SQL Server 데이터베이스를 암호화할 수 있습니다. 여러 데이터베이스를 대상 인스턴스로 마이그레이션하려면 연결된 TDE 인증서를 대상 인스턴스에 한 번만 복사합니다.
# RDS for SQL Server에 대한 TDE 비활성화
RDS for SQL Server DB 인스턴스에서 TDE를 비활성화하려면 먼저 DB 인스턴스에 암호화된 객체가 하나도 없어야 합니다. 이렇게 하려면 객체의 암호를 해독하거나 삭제하면 됩니다. DB 인스턴스에 암호화된 객체가 남아 있을 경우에는 DB 인스턴스에서 TDE를 비활성할 수 없습니다. 암호화를 위한 사용자 TDE 인증서가 복원된(가져오기된) 경우 삭제해야 합니다. 콘솔을 사용하여 옵션 그룹에서 TDE 옵션을 제거하면 콘솔에 처리 중으로 표시됩니다. 또한 옵션 그룹이 암호화된 DB 인스턴스 또는 DB 스냅샷과 연결되어 있으면 오류 이벤트가 생성됩니다.
다음은 `customerDatabase`라고 하는 데이터베이스에서 TDE 암호화를 제거하는 예제입니다.
```
1. ------------- Removing TDE ----------------
2.
3. USE [customerDatabase]
4. GO
5.
6. -- Turn off encryption of the database
7. ALTER DATABASE [customerDatabase]
8. SET ENCRYPTION OFF
9. GO
10.
11. -- Wait until the encryption state of the database becomes 1. The state is 5 (Decryption in progress) for a while
12. SELECT db_name(database_id) as DatabaseName, * FROM sys.dm_database_encryption_keys
13. GO
14.
15. -- Drop the DEK used for encryption
16. DROP DATABASE ENCRYPTION KEY
17. GO
18.
19. -- Drop a user TDE certificate if it was restored (imported)
20. EXECUTE msdb.dbo.rds_drop_tde_certificate @certificate_name='UserTDECertificate_certificate_name';
21.
22. -- Alter to SIMPLE Recovery mode so that your encrypted log gets truncated
23. USE [master]
24. GO
25. ALTER DATABASE [customerDatabase] SET RECOVERY SIMPLE
26. GO
```
모든 객체의 암호를 해독할 때는 2가지 옵션을 사용할 수 있습니다.
1. TDE 옵션 없이 옵션 그룹과 연결되도록 DB 인스턴스를 수정할 수 있습니다.
1. 옵션 그룹에서 TDE 옵션을 제거할 수 있습니다.
# SQL Server Audit
Amazon RDS에서는 기본 제공 SQL Server Audit 메커니즘을 사용하여 Microsoft SQL Server 데이터베이스를 감사할 수 있습니다. 온프레미스 데이터베이스 서버용으로 생성하는 경우와 같은 방식으로 감사 및 감사 사양을 생성할 수 있습니다.
RDS는 사용자가 제공한 IAM 역할을 사용하여 완료된 감사 로그를 S3 버킷에 업로드합니다. 보존을 활성화하면 RDS는 구성된 기간 동안 DB 인스턴스에 대한 감사 로그를 유지합니다.
자세한 내용은 Microsoft SQL Server 설명서의 [SQL Server Audit(데이터베이스 엔진)](https://docs.microsoft.com/sql/relational-databases/security/auditing/sql-server-audit-database-engine)를 참조하십시오.
## SQL Server Audit와 데이터베이스 활동 스트림 함께 사용
RDS용 데이터베이스 활동 스트림을 사용하여 SQL Server Audit 이벤트를 Imperva, McAfee 및 IBM의 데이터베이스 활동 모니터링 도구와 통합할 수 있습니다. RDS SQL Server에 대해 데이터베이스 활동 스트림을 사용하여 감사를 수행하는 방법에 대한 자세한 내용은 [Microsoft SQL Server에서의 감사](DBActivityStreams.md#DBActivityStreams.Overview.SQLServer-auditing) 섹션을 참조하세요.
**Topics**
+ [SQL Server Audit와 데이터베이스 활동 스트림 함께 사용](#Appendix.SQLServer.DAS.Audit)
+ [SQL Server Audit 지원](#Appendix.SQLServer.Options.Audit.Support)
+ [DB 인스턴스 옵션에 SQL Server Audit 추가](Appendix.SQLServer.Options.Audit.Adding.md)
+ [SQL Server Audit의 사용](Appendix.SQLServer.Options.Audit.CreateAuditsAndSpecifications.md)
+ [감사 로그 보기](Appendix.SQLServer.Options.Audit.AuditRecords.md)
+ [다중 AZ 인스턴스에서 SQL Server Audit 사용](#Appendix.SQLServer.Options.Audit.Multi-AZ)
+ [S3 버킷 구성](Appendix.SQLServer.Options.Audit.S3bucket.md)
+ [수동으로 SQL Server Audit에 대한 IAM 역할 생성](Appendix.SQLServer.Options.Audit.IAM.md)
## SQL Server Audit 지원
SQL Server 2016부터는 Amazon RDS에서 모든 버전의 SQL Server가 서버 수준 감사를 지원하고 Enterprise Edition은 데이터베이스 수준 감사도 지원합니다. SQL Server 2016(13.x) SP1부터는 모든 버전이 서버 및 데이터베이스 수준 감사를 모두 지원합니다. 자세한 내용은 SQL Server 설명서의 [SQL Server Audit(데이터베이스 엔진)](https://docs.microsoft.com/sql/relational-databases/security/auditing/sql-server-audit-database-engine)를 참조하십시오.
RDS는 SQL Server Audit에 대한 다음 옵션 설정 구성을 지원합니다.
| 옵션 설정 | 유효한 값 | 설명 |
| --- | --- | --- |
| IAM\$1ROLE\$1ARN | arn:aws:iam::account-id:role/role-name 형식의 유효한 ARN(Amazon 리소스 이름). | 감사 로그를 저장할 S3 버킷에 액세스 권한을 부여하는 IAM 역할의 ARN입니다. 자세한 내용은 AWS 일반 참조의 [Amazon 리소스 이름(ARN)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html#arn-syntax-iam)을 참조하세요. |
| S3\$1BUCKET\$1ARN | arn:aws:s3:::amzn-s3-demo-bucket 또는 arn:aws:s3:::amzn-s3-demo-bucket/key-prefix 형식의 유효한 ARN | 감사 로그를 저장할 S3 버킷의 ARN입니다. |
| ENABLE\$1COMPRESSION | true 또는 false | 감사 로그 압축을 제어합니다. 기본적으로 압축은 활성화됩니다(true로 설정). |
| RETENTION\$1TIME | 0\$1840 | SQL Server Audit 레코드가 RDS 인스턴스에 유지되는 보존 기간(시간 단위)입니다. 기본적으로 보존은 비활성화됩니다. |
# DB 인스턴스 옵션에 SQL Server Audit 추가
SQL Server Audit를 활성화하려면 DB 인스턴스에 옵션을 활성화하고 SQL Server 내에서 이 기능을 활성화하는 두 단계가 필요합니다. SQL Server Audit 옵션을 DB 인스턴스에 추가하는 프로세스는 다음과 같습니다.
1. 새 옵션 그룹을 생성하거나 기존 옵션 그룹을 복사 또는 수정합니다.
1. 필요한 모든 옵션을 추가하고 구성하십시오.
1. 옵션 그룹을 DB 인스턴스에 연동시킵니다.
SQL Server Audit 옵션을 추가한 후 DB 인스턴스를 다시 시작할 필요가 없습니다. 옵션 그룹이 활성화되면 S3 버킷에 감사를 생성하고 감사 로그를 저장할 수 있습니다.
**DB 인스턴스의 옵션 그룹에 SQL Server Audit을 추가하고 구성하려면**
1. 다음 중 하나를 선택합니다.
+ 기존 옵션 그룹을 사용합니다.
+ 사용자 지정 DB 옵션 그룹을 생성하고 해당 옵션 그룹을 사용합니다. 자세한 내용은 [옵션 그룹 생성](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Create) 섹션을 참조하세요.
1. 옵션 그룹에 **SQLSERVER\$1AUDIT** 옵션을 추가하고 옵션 설정을 구성합니다. 옵션 추가에 대한 자세한 내용은 [옵션 그룹에 옵션 추가](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.AddOption) 섹션을 참조하세요.
+ **IAM 역할**에 필요한 정책의 IAM 역할이 이미 있는 경우 해당 역할을 선택할 수 있습니다. 새 IAM 역할을 만들려면 **새 역할 생성**을 선택하십시오. 필요한 정책에 대한 자세한 내용은 [수동으로 SQL Server Audit에 대한 IAM 역할 생성](Appendix.SQLServer.Options.Audit.IAM.md) 단원을 참조하십시오.
+ **S3 대상 선택**의 경우 사용할 S3 버킷이 이미 있는 경우 선택합니다. S3 버킷을 생성하려면 **S3 버킷 새로 만들기**를 선택하십시오.
+ **압축 활성화**의 경우 감사 파일을 압축하려면 이 옵션을 선택한 상태로 둡니다. 압축은 기본적으로 활성화되어 있습니다. 압축을 비활성화하려면 **Enable Compression(압축 활성화)** 선택을 취소하십시오.
+ **감사 로그 보존**의 경우 DB 인스턴스에 감사 레코드를 보존하려면 이 옵션을 선택합니다. 보존 시간을 시간 단위로 지정하십시오. 최대 보존 기간은 35일입니다.
1. 옵션 그룹을 새 DB 인스턴스 또는 기존 DB 인스턴스에 적용합니다. 다음 중 하나를 선택합니다.
+ 새 DB 인스턴스를 생성하는 경우, 인스턴스를 시작할 때 옵션 그룹을 적용하십시오.
+ 기존 DB 인스턴스의 경우, 해당 인스턴스를 수정한 후 새 옵션 그룹을 연결하여 옵션 그룹을 적용하십시오. 자세한 내용은 [Amazon RDS DB 인스턴스 수정](Overview.DBInstance.Modifying.md) 섹션을 참조하세요.
## SQL Server Audit 옵션 수정
SQL Server Audit 옵션을 활성화하면 설정을 수정할 수 있습니다. 옵션 설정을 변경하는 방법에 대한 자세한 내용은 [옵션 설정 수정](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.ModifyOption) 단원을 참조하십시오.
## DB 인스턴스 옵션에서 SQL Server Audit 제거
감사를 비활성화한 다음 옵션을 삭제하여 SQL Server Audit 기능을 해제할 수 있습니다.
**감사를 제거하려면**
1. SQL Server 내부의 모든 감사 설정을 비활성화합니다. 감사가 실행되는 위치를 확인하려면 SQL Server 보안 카탈로그 보기를 쿼리하십시오. 자세한 내용은 Microsoft SQL Server 설명서의 [보안 카탈로그 보기](https://docs.microsoft.com/sql/relational-databases/system-catalog-views/security-catalog-views-transact-sql)를 참조하십시오.
1. DB 인스턴스에서 SQL Server Audit 옵션을 삭제하십시오. 다음 중 하나를 선택합니다.
+ DB 인스턴스가 사용하는 옵션 그룹에서 SQL Server Audit 옵션을 삭제하십시오. 이 변경은 동일한 옵션 그룹을 사용하는 모든 DB 인스턴스에 영향을 미칩니다. 자세한 내용은 [옵션 그룹에서 옵션 제거](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.RemoveOption) 섹션을 참조하세요.
+ DB 인스턴스를 수정한 다음 SQL Server Audit 옵션이 없는 옵션 그룹을 선택합니다. 이 변경은 수정하는 DB 인스턴스에만 영향을 줍니다. 기본(빈) 옵션 그룹을 지정하거나 다른 사용자 지정 옵션 그룹을 지정할 수 있습니다. 자세한 내용은 [Amazon RDS DB 인스턴스 수정](Overview.DBInstance.Modifying.md) 섹션을 참조하세요.
1. DB 인스턴스에서 SQL Server Audit 옵션을 삭제한 후 인스턴스를 다시 시작할 필요가 없습니다. S3 버킷에서 불필요한 감사 파일을 제거하십시오.
# SQL Server Audit의 사용
온프레미스 데이터베이스 서버에서 제어하는 것과 동일한 방식으로 서버 감사, 서버 감사 사양 및 데이터베이스 감사 사양을 제어할 수 있습니다.
## 감사 생성
온프레미스 데이터베이스 서버에 대해 생성하는 것과 같은 방법으로 서버 감사를 생성합니다. 서버 감사를 생성하는 방법에 대한 자세한 내용은 Microsoft SQL Server 설명서에서 [서버 감사 생성](https://docs.microsoft.com/sql/t-sql/statements/create-server-audit-transact-sql)을 참조하십시오.
오류를 방지하려면 다음 제한 사항을 준수하십시오.
+ 인스턴스당 지원되는 최대 50개의 서버 감사를 초과하지 마십시오.
+ 이진 파일에 데이터를 쓰도록 SQL Server에 지시하십시오.
+ 서버 감사 이름의 접두사로 `RDS_`를 사용하지 마십시오.
+ `FILEPATH`에 `D:\rdsdbdata\SQLAudit`을 지정합니다.
+ `MAXSIZE`에 2MB \$1 50MB 사이의 크기를 지정하십시오.
+ `MAX_ROLLOVER_FILES` 또는 `MAX_FILES`를 구성하지 마십시오.
+ SQL Server가 감사 레코드를 쓰지 못할 경우 DB 인스턴스를 종료하도록 구성하지 마십시오.
## 감사 사양 생성
온프레미스 데이터베이스 서버에서 생성하는 것과 동일한 방식으로 서버 감사 사양 및 데이터베이스 감사 사양을 생성합니다. 감사 사양 생성에 대한 자세한 내용은 Microsoft SQL Server 설명서에서 [서버 감사 사양 생성](https://docs.microsoft.com/sql/t-sql/statements/create-server-audit-specification-transact-sql) 및 [데이터베이스 감사 사양 생성](https://docs.microsoft.com/sql/t-sql/statements/create-database-audit-specification-transact-sql)을 참조하십시오.
오류를 피하려면 데이터베이스 감사 사양 또는 서버 감사 사양의 접두사로 `RDS_`를 사용하지 마십시오.
# 감사 로그 보기
감사 로그는 `D:\rdsdbdata\SQLAudit`에 저장됩니다.
SQL Server가 감사 로그 파일에 파일 쓰기를 완료하면—파일이 크기 제한에 도달하면—Amazon RDS가 S3 버킷에 파일을 업로드합니다. 보존을 활성화하면 Amazon RDS가 파일을 보존 폴더 `D:\rdsdbdata\SQLAudit\transmitted`로 옮깁니다.
보존 구성에 대한 자세한 내용은 [DB 인스턴스 옵션에 SQL Server Audit 추가](Appendix.SQLServer.Options.Audit.Adding.md) 단원을 참조하십시오.
감사 레코드는 감사 로그 파일이 업로드될 때까지 DB 인스턴스에 보관됩니다. 다음 명령을 실행하여 감사 레코드를 볼 수 있습니다.
```
SELECT *
FROM msdb.dbo.rds_fn_get_audit_file
('D:\rdsdbdata\SQLAudit\*.sqlaudit'
, default
, default )
```
같은 명령을 사용하여 필터를 `D:\rdsdbdata\SQLAudit\transmitted\*.sqlaudit`로 변경하여 보존 폴더의 감사 레코드를 볼 수 있습니다.
```
SELECT *
FROM msdb.dbo.rds_fn_get_audit_file
('D:\rdsdbdata\SQLAudit\transmitted\*.sqlaudit'
, default
, default )
```
## 다중 AZ 인스턴스에서 SQL Server Audit 사용
다중 AZ 인스턴스의 경우 감사 로그 파일을 Amazon S3으로 보내는 프로세스는 단일 AZ 인스턴스의 프로세스와 유사합니다. 그러나 몇 가지 중요한 차이점이 있습니다.
+ 데이터베이스 감사 사양 객체는 모든 노드에 복제됩니다.
+ 서버 감사 및 서버 감사 사양은 보조 노드에 복제되지 않습니다. 대신, 수동으로 생성하거나 수정해야 합니다.
두 노드에서 서버 감사 사양 또는 서버 감사를 캡처하려면
1. 기본 노드에서 서버 감사 또는 서버 감사 사양을 생성하십시오.
1. 보조 노드로 장애 조치하고 보조 노드에서 동일한 이름과 GUID로 서버 감사 또는 서버 감사 사양을 생성합니다. `AUDIT_GUID` 파라미터를 사용하여 GUID를 지정합니다.
# S3 버킷 구성
감사 로그 파일은 DB 인스턴스에서 S3 버킷으로 자동 업로드됩니다. 감사 파일의 대상으로 사용하는 S3 버킷에는 다음 제한이 적용됩니다.
+ DB 인스턴스와 동일한 AWS 리전 및 AWS 계정에 있어야 합니다.
+ 대중에게 공개되어서는 안 됩니다.
+ 버킷 소유자는 IAM 역할 소유자여야 합니다.
+ IAM 역할에는 S3 버킷 서버 측 암호화와 관련된 고객 관리형 KMS 키에 대한 권한이 있어야 합니다.
데이터를 저장하는 데 사용되는 대상 키는 `amzn-s3-demo-bucket/key-prefix/instance-name/audit-name/node_file-name.ext` 명명 스키마를 따릅니다.
**참고**
버킷 이름과 키 접두사 값을 모두 `S3_BUCKET_ARN` 옵션 설정을 사용하여 설정합니다.
스키마는 다음 요소로 구성됩니다.
+ ***amzn-s3-demo-bucket*** – S3 버킷의 이름입니다.
+ **`key-prefix`** – 감사 로그에 사용할 사용자 지정 키 접두사.
+ **`instance-name`** – Amazon RDS 인스턴스의 이름.
+ **`audit-name`** – 감사의 이름.
+ **`node`** – 감사 로그의 소스인 노드의 식별자(`node1` 또는 `node2`). 단일 AZ 인스턴스에는 하나의 노드가 있고 다중 AZ 인스턴스에는 두 개의 복제 노드가 있습니다. 기본 노드와 보조 노드의 역할은 시간이 지남에 따라 변하기 때문에 이들은 기본 노드와 보조 노드가 아닙니다. 대신, 노드 식별자는 단순한 레이블입니다.
+ **`node1`** – 첫 번째 복제 노드(단일 AZ에는 하나의 노드만 있음).
+ **`node2`** – 두 번째 복제 노드(다중 AZ에는 두 개의 노드가 있음).
+ **`file-name`** – 대상 파일 이름. 파일 이름은 SQL Server에서 그대로 가져옵니다.
+ **`ext`** – 파일 확장자(`zip` 또는 `sqlaudit`):
+ **`zip`** – 압축이 활성화된 경우(기본값).
+ **`sqlaudit`** – 압축이 비활성화된 경우.
# 수동으로 SQL Server Audit에 대한 IAM 역할 생성
일반적으로 새 옵션을 만들면 AWS Management Console은 IAM 역할 및 IAM 신뢰 정책을 생성합니다. 그러나 SQL Server Audit에서 사용할 새로운 IAM 역할을 수동으로 생성할 수 있으므로 추가 요구 사항에 맞게 사용자 지정할 수 있습니다. 그러려면 IAM 역할을 생성하고 Amazon RDS 서비스가 Amazon S3 버킷을 사용할 수 있도록 권한을 위임합니다. IAM 역할을 만들 때 신뢰 및 권한 정책을 연결합니다. 신뢰 정책은 Amazon RDS가 이 역할을 맡도록 허용합니다. 권한 정책은 이 역할이 수행할 수 있는 작업을 정의합니다. 자세한 내용은 *AWS Identity and Access Management 사용 설명서*에서 [AWS 서비스에 대한 권한을 위임할 역할 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)을 참조하세요.
이 섹션의 예를 사용하여 필요한 신뢰 관계와 사용 권한 정책을 생성할 수 있습니다.
다음 예는 SQL Server Audit에 대한 신뢰 관계를 보여줍니다. 이 관계는 *서비스 원칙* `rds.amazonaws.com`을 사용하여 RDS가 S3 버킷에 쓸 수 있도록 허용합니다. *서비스 보안 주체*는 서비스에 권한을 부여하는 데 사용되는 식별자입니다. 이러한 방식으로 `rds.amazonaws.com`에 대한 액세스를 허용할 때마다 RDS가 사용자를 대신하여 작업을 수행하도록 허용합니다. 서비스 보안 주체에 대한 자세한 내용은 [AWS JSON 정책 요소: 보안 주체](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)를 참조하세요.
**Example SQL Server Audit에 대한 신뢰 관계**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
서비스 권한을 특정 리소스로 제한하는 리소스 기반 신뢰 관계의 [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) 및 [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) 전역 조건 컨텍스트 키를 사용하는 것이 좋습니다. 이는 [혼동된 대리자 문제](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)를 방지하는 가장 효과적인 방법입니다.
전역 조건 컨텍스트 키를 모두 사용하고 `aws:SourceArn` 값에 계정 ID가 포함되도록 할 수 있습니다. 이 경우 `aws:SourceAccount` 값과 `aws:SourceArn` 값의 계정이 동일한 문에서 사용될 때 동일한 계정 ID를 사용해야 합니다.
+ 단일 리소스에 대한 교차 서비스 액세스를 원하는 경우 `aws:SourceArn`을 사용하세요.
+ 해당 계정의 모든 리소스가 교차 서비스 사용과 연결되도록 허용하려는 경우 `aws:SourceAccount`를 사용하세요.
신뢰 정책에서는 역할에 액세스하는 리소스의 전체 Amazon 리소스 이름(ARN)이 포함된 `aws:SourceArn` 전역 조건 컨텍스트 키를 사용해야 합니다. SQL Server Audit의 경우 다음 예와 같이 DB 옵션 그룹과 DB 인스턴스를 모두 포함해야 합니다.
**Example SQL Server Audit에 대한 전역 조건 컨텍스트 키와의 신뢰 관계**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceArn": [
"arn:aws:rds:Region:my_account_ID:db:db_instance_identifier",
"arn:aws:rds:Region:my_account_ID:og:option_group_name"
]
}
}
}
]
}
```
SQL Server Audit에 대한 권한 정책의 다음 예에서는 Amazon S3 버킷에 대한 ARN을 지정합니다. ARN을 사용하여 액세스 권한을 부여할 특정 계정, 사용자 또는 역할을 식별할 수 있습니다. ARN 사용에 대한 자세한 내용은 [Amazon 리소스 이름(ARN)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html)을 참조하세요.
**Example SQL Server Audit에 대한 권한 정책**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetBucketACL",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket"
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:ListMultipartUploadParts",
"s3:AbortMultipartUpload"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/key_prefix/*"
}
]
}
```
**참고**
`s3:ListAllMyBuckets` 작업은 동일한 AWS 계정이 S3 버킷과 SQL Server DB 인스턴스를 모두 소유하고 있는지 확인하는 데 필요합니다. 이 작업은 계정에 있는 버킷의 이름을 나열합니다.
S3 버킷 네임스페이스는 글로벌입니다. 실수로 버킷을 삭제한 경우 다른 사용자가 동일한 이름의 버킷을 다른 계정에서 만들 수 있습니다. 그런 다음 SQL Server 감사 데이터가 새 버킷에 기록됩니다.
# Amazon RDS for SQL Server에서 SQL Server Analysis Services 지원
Microsoft SQL Server Analysis Services(SSAS)는 Microsoft Business Intelligence(MSBI) 제품군의 일부입니다. SSAS는 SQL Server 내에 설치된 온라인 분석 처리(OLAP) 및 데이터 마이닝 도구입니다. SSAS를 사용해 데이터를 분석하여 비즈니스 의사 결정을 내릴 수 있습니다. SSAS는 비즈니스 인텔리전스 환경에서 일반적인 쿼리 및 계산에 최적화되어 있기 때문에 SQL Server 관계형 데이터베이스와 다릅니다.
기존 DB 인스턴스 또는 새 DB 인스턴스에 대해 SSAS를 설정할 수 있습니다. 이 인스턴스는 데이터베이스 엔진과 동일한 DB 인스턴스에 설치됩니다. SSAS에 대한 자세한 내용은 Microsoft [Analysis Services 설명서](https://docs.microsoft.com/en-us/analysis-services)를 참조하십시오.
Amazon RDS는 다음 버전에서 SQL Server Standard 및 Enterprise Edition용 SSAS를 지원합니다.
+ 테이블 형식 모드:
+ SQL Server 2019, 버전 15.00.4043.16.v1 이상
+ SQL Server 2017, 버전 14.00.3223.3.v1 이상
+ SQL Server 2016, 버전 13.00.5426.0.v1 이상
+ 다차원 모드:
+ SQL Server 2019, 버전 15.00.4153.1.v1 이상
+ SQL Server 2017, 버전 14.00.3381.3.v1 이상
+ SQL Server 2016, 버전 13.00.5882.1.v1 이상
**Contents**
+ [제한 사항](#SSAS.Limitations)
+ [SSAS 설정](SSAS.Enabling.md)
+ [SSAS용 옵션 그룹 생성](SSAS.Enabling.md#SSAS.OptionGroup)
+ [옵션 그룹에 SSAS 옵션 추가](SSAS.Enabling.md#SSAS.Add)
+ [옵션 그룹을 DB 인스턴스와 연결](SSAS.Enabling.md#SSAS.Apply)
+ [VPC 보안 그룹에 대한 인바운드 액세스 허용](SSAS.Enabling.md#SSAS.InboundRule)
+ [Amazon S3 통합 사용 설정](SSAS.Enabling.md#SSAS.EnableS3)
+ [Amazon RDS에 SSAS 프로젝트 배포](SSAS.Deploy.md)
+ [배포 작업의 상태 모니터링](SSAS.Monitor.md)
+ [Amazon RDS에서 SSAS 사용](SSAS.Use.md)
+ [SSAS용 Windows 인증 사용자 설정](SSAS.Use.md#SSAS.Use.Auth)
+ [도메인 사용자를 데이터베이스 관리자로 추가](SSAS.Use.md#SSAS.Admin)
+ [SSAS 프록시 생성](SSAS.Use.md#SSAS.Use.Proxy)
+ [SQL Server 에이전트를 사용하여 SSAS 데이터베이스 처리 예약](SSAS.Use.md#SSAS.Use.Schedule)
+ [프록시에서 SSAS 액세스 취소](SSAS.Use.md#SSAS.Use.Revoke)
+ [SSAS 데이터베이스 백업](SSAS.Backup.md)
+ [SSAS 데이터베이스 복원](SSAS.Restore.md)
+ [DB 인스턴스를 지정된 시간으로 복원](SSAS.Restore.md#SSAS.PITR)
+ [SSAS 모드 변경](SSAS.ChangeMode.md)
+ [SSAS 해제](SSAS.Disable.md)
+ [SSAS 문제 해결](SSAS.Trouble.md)
## 제한 사항
RDS for SQL Server에서 SSAS를 사용하는 경우 다음과 같은 제한 사항이 적용됩니다.
+ RDS for SQL Server는 테이블 형식 또는 다차원 모드에서 SSAS 실행을 지원합니다. 자세한 내용은 Microsoft 설명서의 [테이블 형식 및 다차원 솔루션 비교](https://docs.microsoft.com/en-us/analysis-services/comparing-tabular-and-multidimensional-solutions-ssas)를 참조하세요.
+ 한 번에 하나의 SSAS 모드만 사용할 수 있습니다. 모드를 변경하기 전에 모든 SSAS 데이터베이스를 삭제해야 합니다.
자세한 내용은 [SSAS 모드 변경](SSAS.ChangeMode.md) 단원을 참조하십시오.
+ 다중 AZ 인스턴스는 지원되지 않습니다.
+ 인스턴스는 SSAS 인증을 위해 자체 관리형 Active Directory 또는 AWS Directory Service for Microsoft Active Directory를 사용해야 합니다. 자세한 내용은 [RDS for SQL Server를 사용하여 Active Directory 작업](User.SQLServer.ActiveDirectoryWindowsAuth.md) 단원을 참조하십시오.
+ 사용자에게는 SSAS 서버 관리자 액세스 권한이 부여되지 않지만 데이터베이스 수준 관리자 액세스 권한을 부여받을 수 있습니다.
+ SSAS에 액세스하기 위해 지원되는 유일한 포트는 2383입니다.
+ 프로젝트를 직접 배포할 수 없습니다. 이를 수행할 RDS 저장 프로시저를 제공합니다. 자세한 내용은 [Amazon RDS에 SSAS 프로젝트 배포](SSAS.Deploy.md) 섹션을 참조하세요.
+ 배포 중 처리는 지원되지 않습니다.
+ .xmla 파일을 배포에 사용하는 것은 지원되지 않습니다.
+ SSAS 프로젝트 입력 파일 및 데이터베이스 백업 출력 파일은 DB 인스턴스의 `D:\S3` 폴더에만 있을 수 있습니다.
# SSAS 설정
다음 프로세스를 사용하여 DB 인스턴스에 SSAS를 설정합니다.
1. 새 옵션 그룹을 생성하거나 기존 옵션 그룹을 선택합니다.
1. [`SSAS`] 옵션을 옵션 그룹에 추가합니다.
1. 옵션 그룹을 DB 인스턴스에 연결합니다.
1. SSAS 리스너 포트의 Virtual Private Cloud(VPC) 보안 그룹에 대한 인바운드 액세스를 허용합니다.
1. Amazon S3 통합을 설정합니다.
## SSAS용 옵션 그룹 생성
AWS Management Console 또는 AWS CLI를 사용하여 SQL Server 엔진과 사용하려는 DB 인스턴스 버전에 해당하는 옵션 그룹을 생성합니다.
**참고**
올바른 SQL Server 엔진 및 버전인 경우 기존 옵션 그룹을 사용할 수도 있습니다.
### 콘솔
다음 콘솔 프로시저는 SQL Server Standard 에디션 2017에 대한 옵션 그룹을 생성합니다.
**옵션 그룹을 생성하려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **옵션 그룹**을 선택합니다.
1. **그룹 생성**을 선택합니다.
1. **보안 그룹 생성** 창에서 다음을 수행합니다.
1. [**이름(Name)**]에 AWS 계정 내에서 쉽게 식별할 수 있는 옵션 그룹 이름을 입력합니다(예: **ssas-se-2017**). 이름은 글자, 숫자 및 하이픈만 사용 가능합니다.
1. **설명**에 옵션 그룹에 대한 간단한 설명을 입력합니다(예: **SSAS option group for SQL Server SE 2017**). 이 설명은 표시 용도로만 사용됩니다.
1. **엔진**에 대해 **sqlserver-se**를 선택합니다.
1. **메이저 엔진 버전**에 대해 **14.00**을 선택합니다.
1. **생성(Create)**을 선택합니다.
### CLI
다음 CLI 예제는 SQL Server Standard 에디션 2017에 대한 옵션 그룹을 생성합니다.
**옵션 그룹을 생성하려면**
+ 다음 명령 중 하나를 사용합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds create-option-group \
--option-group-name ssas-se-2017 \
--engine-name sqlserver-se \
--major-engine-version 14.00 \
--option-group-description "SSAS option group for SQL Server SE 2017"
```
Windows의 경우:
```
aws rds create-option-group ^
--option-group-name ssas-se-2017 ^
--engine-name sqlserver-se ^
--major-engine-version 14.00 ^
--option-group-description "SSAS option group for SQL Server SE 2017"
```
## 옵션 그룹에 SSAS 옵션 추가
그런 다음 AWS Management Console 또는 AWS CLI를 사용하여 `SSAS` 옵션을 옵션 그룹에 추가합니다.
### 콘솔
**SSAS 옵션을 추가하려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **옵션 그룹**을 선택합니다.
1. 방금 생성한 옵션 그룹을 선택합니다.
1. **옵션 추가**를 선택합니다.
1. **옵션 세부 정보**에서 **옵션 이름**으로 **SSAS**를 선택합니다.
1. **옵션 설정**에서 다음을 수행합니다.
1. **최대 메모리(Max memory)**에 10\$180 범위의 값을 입력합니다.
**최대 메모리**는 SSAS가 실행 중인 요청과 우선 순위가 높은 새 요청에 대한 공간을 확보하기 위해 메모리를 보다 적극적으로 해제하기 시작하는 상한 임계값을 지정합니다. 숫자는 DB 인스턴스에 대한 총 메모리 비율입니다. 허용 값은 10–80이고, 기본값은 45입니다.
1. **모드(Mode)**에서 SSAS 서버 모드인 **테이블 형식(Tabular)** 또는 **다차원(Multidimensional)**을 선택합니다.
**모드(Mode)** 옵션 설정이 표시되지 않으면 해당 AWS 리전에서 다차원 모드가 지원되지 않는 것입니다. 자세한 내용은 [제한 사항](Appendix.SQLServer.Options.SSAS.md#SSAS.Limitations) 단원을 참조하십시오.
**테이블 형식(Tabular)**이 기본값입니다.
1. **보안 그룹**의 경우 옵션과 연결할 VPC 보안 그룹을 선택합니다.
**참고**
SSAS, 2383에 액세스하기 위한 포트가 미리 채워져 있습니다.
1. **예약**에서 옵션을 즉시 추가할지 또는 다음 유지 관리 기간에 추가할지를 선택합니다.
1. **옵션 추가**를 선택합니다.
### CLI
**SSAS 옵션을 추가하려면**
1. 다음 파라미터를 사용하여 JSON 파일(예: `ssas-option.json`)을 생성합니다.
+ `OptionGroupName` – 이전에 생성했거나 선택한 옵션 그룹의 이름입니다(다음 예의 경우 `ssas-se-2017`).
+ `Port` – SSAS에 액세스하는 데 사용하는 포트입니다. 지원되는 유일한 포트는 2383입니다.
+ `VpcSecurityGroupMemberships` – RDS DB 인스턴스에 대한 VPC 보안 그룹의 멤버십입니다.
+ `MAX_MEMORY` – SSAS가 실행 중인 요청과 우선 순위가 높은 새 요청에 대한 공간을 확보하기 위해 메모리를 보다 적극적으로 해제하기 시작해야 하는 상한 임계값입니다. 숫자는 DB 인스턴스에 대한 총 메모리 비율입니다. 허용 값은 10–80이고, 기본값은 45입니다.
+ `MODE` - SSAS 서버 모드(`Tabular` 또는 `Multidimensional`)입니다. `Tabular`가 기본값입니다.
`MODE` 옵션 설정이 유효하지 않다는 오류가 나타나면 해당 AWS 리전에서 다차원 모드가 지원되지 않는 것입니다. 자세한 내용은 [제한 사항](Appendix.SQLServer.Options.SSAS.md#SSAS.Limitations) 단원을 참조하십시오.
다음은 SSAS 옵션 설정이 있는 JSON 파일의 예입니다.
```
{
"OptionGroupName": "ssas-se-2017",
"OptionsToInclude": [
{
"OptionName": "SSAS",
"Port": 2383,
"VpcSecurityGroupMemberships": ["sg-0abcdef123"],
"OptionSettings": [{"Name":"MAX_MEMORY","Value":"60"},{"Name":"MODE","Value":"Multidimensional"}]
}],
"ApplyImmediately": true
}
```
1. [`SSAS`] 옵션을 옵션 그룹에 추가합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds add-option-to-option-group \
--cli-input-json file://ssas-option.json \
--apply-immediately
```
Windows의 경우:
```
aws rds add-option-to-option-group ^
--cli-input-json file://ssas-option.json ^
--apply-immediately
```
## 옵션 그룹을 DB 인스턴스와 연결
콘솔 또는 CLI를 사용하여 옵션 그룹을 DB 인스턴스와 연결할 수 있습니다.
### 콘솔
옵션 그룹을 새 DB 인스턴스 또는 기존 DB 인스턴스와 연결합니다.
+ 새 DB 인스턴스의 경우 인스턴스를 시작할 때 옵션 그룹을 DB 인스턴스와 연결합니다. 자세한 내용은 [Amazon RDS DB 인스턴스 생성](USER_CreateDBInstance.md) 섹션을 참조하세요.
+ 기존 DB 인스턴스의 경우 인스턴스를 수정하고 새 옵션 그룹을 인스턴스와 연결합니다. 자세한 내용은 [Amazon RDS DB 인스턴스 수정](Overview.DBInstance.Modifying.md) 단원을 참조하십시오.
**참고**
기존 인스턴스를 사용하는 경우 이미 Active Directory 도메인과 AWS Identity and Access Management(IAM) 역할이 연결되어 있어야 합니다. 새 인스턴스를 생성하는 경우 기존 Active Directory 도메인 및 IAM 역할을 지정합니다. 자세한 내용은 [RDS for SQL Server를 사용하여 Active Directory 작업](User.SQLServer.ActiveDirectoryWindowsAuth.md) 단원을 참조하십시오.
### CLI
옵션 그룹을 새 DB 인스턴스 또는 기존 DB 인스턴스와 연결할 수 있습니다.
**참고**
기존 인스턴스를 사용하는 경우 이미 Active Directory 도메인과 IAM 역할이 연결되어 있어야 합니다. 새 인스턴스를 생성하는 경우 기존 Active Directory 도메인 및 IAM 역할을 지정합니다. 자세한 내용은 [RDS for SQL Server를 사용하여 Active Directory 작업](User.SQLServer.ActiveDirectoryWindowsAuth.md) 단원을 참조하십시오.
**옵션 그룹을 사용하는 DB 인스턴스를 생성하려면**
+ 옵션 그룹을 생성할 때 사용한 것과 동일한 DB 엔진 유형과 메이저 버전을 지정합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds create-db-instance \
--db-instance-identifier myssasinstance \
--db-instance-class db.m5.2xlarge \
--engine sqlserver-se \
--engine-version 14.00.3223.3.v1 \
--allocated-storage 100 \
--manage-master-user-password \
--master-username admin \
--storage-type gp2 \
--license-model li \
--domain-iam-role-name my-directory-iam-role \
--domain my-domain-id \
--option-group-name ssas-se-2017
```
Windows의 경우:
```
aws rds create-db-instance ^
--db-instance-identifier myssasinstance ^
--db-instance-class db.m5.2xlarge ^
--engine sqlserver-se ^
--engine-version 14.00.3223.3.v1 ^
--allocated-storage 100 ^
--manage-master-user-password ^
--master-username admin ^
--storage-type gp2 ^
--license-model li ^
--domain-iam-role-name my-directory-iam-role ^
--domain my-domain-id ^
--option-group-name ssas-se-2017
```
**DB 인스턴스를 수정하여 옵션 그룹을 연결하려면**
+ 다음 명령 중 하나를 사용합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds modify-db-instance \
--db-instance-identifier myssasinstance \
--option-group-name ssas-se-2017 \
--apply-immediately
```
Windows의 경우:
```
aws rds modify-db-instance ^
--db-instance-identifier myssasinstance ^
--option-group-name ssas-se-2017 ^
--apply-immediately
```
## VPC 보안 그룹에 대한 인바운드 액세스 허용
DB 인스턴스와 연결된 VPC 보안 그룹에서 지정된 SSAS 리스너 포트에 대한 인바운드 규칙을 생성합니다. 보안 그룹 설정에 대한 자세한 내용은 [보안 그룹을 생성하여 VPC 내부의 DB 인스턴스에 대한 액세스를 제공](CHAP_SettingUp.md#CHAP_SettingUp.SecurityGroup) 단원을 참조하십시오.
## Amazon S3 통합 사용 설정
배포를 위해 호스트에 모델 구성 파일을 다운로드하려면 Amazon S3 통합을 사용합니다. 자세한 내용은 [Amazon RDS for SQL Server DB 인스턴스와 Amazon S3 통합](User.SQLServer.Options.S3-integration.md) 단원을 참조하십시오.
# Amazon RDS에 SSAS 프로젝트 배포
RDS에서는 SQL Server Management Studio(SSMS)를 사용하여 SSAS 프로젝트를 직접 배포할 수 없습니다. 프로젝트를 배포하려면 RDS 저장 프로시저를 사용합니다.
**참고**
.xmla 파일을 배포에 사용하는 것은 지원되지 않습니다.
프로젝트를 배포하기 전에 다음 사항을 확인하십시오.
+ Amazon S3 통합이 설정됩니다. 자세한 내용은 [Amazon RDS for SQL Server DB 인스턴스와 Amazon S3 통합](User.SQLServer.Options.S3-integration.md) 단원을 참조하십시오.
+ `Processing Option` 구성 설정이 `Do Not Process`로 설정됩니다. 이 설정은 배포 후 처리가 진행되지 않음을 의미합니다.
+ `myssasproject.asdatabase` 파일과 `myssasproject.deploymentoptions` 파일이 모두 있습니다. SSAS 프로젝트를 빌드할 때 자동으로 생성됩니다.
**RDS에 SSAS 프로젝트를 배포하려면**
1. 다음 예제와 같이 S3 버킷에서 DB 인스턴스로 `.asdatabase`(SSAS 모델) 파일을 다운로드합니다. 다운로드 파라미터에 대한 자세한 내용은 [Amazon S3 버킷의 파일을 SQL Server DB 인스턴스로 다운로드](Appendix.SQLServer.Options.S3-integration.using.md#Appendix.SQLServer.Options.S3-integration.using.download) 단원을 참조하십시오.
```
exec msdb.dbo.rds_download_from_s3
@s3_arn_of_file='arn:aws:s3:::bucket_name/myssasproject.asdatabase',
[@rds_file_path='D:\S3\myssasproject.asdatabase'],
[@overwrite_file=1];
```
1. S3 버킷에서 DB 인스턴스로 `.deploymentoptions` 파일을 다운로드합니다.
```
exec msdb.dbo.rds_download_from_s3
@s3_arn_of_file='arn:aws:s3:::bucket_name/myssasproject.deploymentoptions',
[@rds_file_path='D:\S3\myssasproject.deploymentoptions'],
[@overwrite_file=1];
```
1. 프로젝트를 배포합니다.
```
exec msdb.dbo.rds_msbi_task
@task_type='SSAS_DEPLOY_PROJECT',
@file_path='D:\S3\myssasproject.asdatabase';
```
# 배포 작업의 상태 모니터링
배포(또는 다운로드) 작업의 상태를 추적하려면 `rds_fn_task_status` 함수를 호출합니다. 두 가지 파라미터가 필요합니다. 첫 번째 파라미터는 SSAS에 적용되지 않기 때문에 항상 `NULL`이어야 합니다. 두 번째 파라미터는 작업 ID를 수락합니다.
모든 작업 목록을 보려면 다음 예와 같이 첫 번째 파라미터를 `NULL`로, 두 번째 파라미터를 `0`으로 설정하십시오.
```
SELECT * FROM msdb.dbo.rds_fn_task_status(NULL,0);
```
특정 작업을 수행하려면 다음 예와 같이 첫 번째 파라미터를 `NULL`로, 두 번째 파라미터를 작업 ID로 설정하십시오.
```
SELECT * FROM msdb.dbo.rds_fn_task_status(NULL,42);
```
`rds_fn_task_status` 함수는 다음 정보를 반환합니다.
| 출력 파라미터 | 설명 |
| --- | --- |
| `task_id` | 작업의 ID입니다. |
| `task_type` | SSAS의 경우 작업 유형은 다음과 같을 수 있습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/SSAS.Monitor.html) |
| `database_name` | SSAS 작업에는 적용되지 않습니다. |
| `% complete` | 백분율로 나타낸 작업의 진행률입니다. |
| `duration (mins)` | 작업에 소요된 시간입니다(분). |
| `lifecycle` | 작업의 상태입니다. 가능한 상태는 다음과 같습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/SSAS.Monitor.html) |
| `task_info` | 작업에 대한 추가 정보입니다. 처리 중에 오류가 발생하면 이 열에 오류 정보가 포함됩니다. 자세한 내용은 [SSAS 문제 해결](SSAS.Trouble.md) 단원을 참조하십시오. |
| `last_updated` | 작업 상태를 마지막으로 업데이트한 날짜와 시간입니다. |
| `created_at` | 작업을 생성한 날짜와 시간입니다. |
| `S3_object_arn` | SSAS 작업에는 적용되지 않습니다. |
| `overwrite_S3_backup_file` | SSAS 작업에는 적용되지 않습니다. |
| `KMS_master_key_arn` | SSAS 작업에는 적용되지 않습니다. |
| `filepath` | SSAS 작업에는 적용되지 않습니다. |
| `overwrite_file` | SSAS 작업에는 적용되지 않습니다. |
| `task_metadata` | SSAS 작업과 관련된 메타데이터입니다. |
# Amazon RDS에서 SSAS 사용
SSAS 프로젝트를 배포한 후 SSMS에서 OLAP 데이터베이스를 직접 처리할 수 있습니다.
**RDS에서 SSAS를 사용하려면**
1. SSMS에서 Active Directory 도메인의 사용자 이름과 암호를 사용하여 SSAS에 연결합니다.
1. **데이터베이스**를 확장합니다. 새로 배포된 SSAS 데이터베이스가 나타납니다.
1. 연결 문자열을 찾고 사용자 이름과 암호를 업데이트하여 원본 SQL 데이터베이스에 대한 액세스 권한을 부여합니다. 이 작업은 SSAS 객체를 처리하는 데 필요합니다.
1. 테이블형 모드의 경우 다음을 수행합니다.
1. **연결(Connections)** 탭을 확장합니다.
1. 연결 객체의 컨텍스트 메뉴(마우스 오른쪽 버튼 클릭)를 연 다음 **속성(Properties)**을 선택합니다.
1. 연결 문자열에서 사용자 이름과 암호를 업데이트합니다.
1. 다차원 모드의 경우 다음을 수행합니다.
1. **데이터 원본(Data Sources)** 탭을 확장합니다.
1. 데이터 원본 객체의 컨텍스트 메뉴(마우스 오른쪽 버튼 클릭)를 연 다음 **속성(Properties)**을 선택합니다.
1. 연결 문자열에서 사용자 이름과 암호를 업데이트합니다.
1. 생성한 SSAS 데이터베이스에 대한 컨텍스트 메뉴(마우스 오른쪽 버튼 클릭)를 열고 **데이터베이스 처리**를 선택합니다.
입력 데이터의 크기에 따라 처리 작업을 완료하는 데 몇 분 정도 걸릴 수 있습니다.
**Topics**
+ [SSAS용 Windows 인증 사용자 설정](#SSAS.Use.Auth)
+ [도메인 사용자를 데이터베이스 관리자로 추가](#SSAS.Admin)
+ [SSAS 프록시 생성](#SSAS.Use.Proxy)
+ [SQL Server 에이전트를 사용하여 SSAS 데이터베이스 처리 예약](#SSAS.Use.Schedule)
+ [프록시에서 SSAS 액세스 취소](#SSAS.Use.Revoke)
## SSAS용 Windows 인증 사용자 설정
기본 관리자 사용자(마스터 사용자라고도 함)는 다음 코드 예제를 사용하여 Windows 인증 로그인을 설정하고 필요한 절차 권한을 부여할 수 있습니다. 이렇게 하면 도메인 사용자에게 SSAS 고객 태스크를 실행하고, S3 파일 전송 절차를 사용하고, 자격 증명을 만들고, SQL Server 에이전트 프록시로 작업할 수 있는 권한이 부여됩니다. 자세한 내용은 Microsoft 설명서의 [자격 증명(데이터베이스 엔진)](https://docs.microsoft.com/en-us/sql/relational-databases/security/authentication-access/credentials-database-engine?view=sql-server-ver15) 및 [SQL Server 에이전트 프록시 생성](https://docs.microsoft.com/en-us/sql/ssms/agent/create-a-sql-server-agent-proxy?view=sql-server-ver15)을 참조하십시오.
필요에 따라 Windows 인증 사용자에게 다음 사용 권한 중 일부 또는 모두를 부여할 수 있습니다.
**Example**
```
-- Create a server-level domain user login, if it doesn't already exist
USE [master]
GO
CREATE LOGIN [mydomain\user_name] FROM WINDOWS
GO
-- Create domain user, if it doesn't already exist
USE [msdb]
GO
CREATE USER [mydomain\user_name] FOR LOGIN [mydomain\user_name]
GO
-- Grant necessary privileges to the domain user
USE [master]
GO
GRANT ALTER ANY CREDENTIAL TO [mydomain\user_name]
GO
USE [msdb]
GO
GRANT EXEC ON msdb.dbo.rds_msbi_task TO [mydomain\user_name] with grant option
GRANT SELECT ON msdb.dbo.rds_fn_task_status TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.rds_task_status TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.rds_cancel_task TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.rds_download_from_s3 TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.rds_upload_to_s3 TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.rds_delete_from_filesystem TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.rds_gather_file_details TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.sp_add_proxy TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.sp_update_proxy TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.sp_grant_login_to_proxy TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.sp_revoke_login_from_proxy TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.sp_delete_proxy TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.sp_enum_login_for_proxy to [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.sp_enum_proxy_for_subsystem TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.rds_sqlagent_proxy TO [mydomain\user_name] with grant option
ALTER ROLE [SQLAgentUserRole] ADD MEMBER [mydomain\user_name]
GO
```
## 도메인 사용자를 데이터베이스 관리자로 추가
다음과 같은 방법으로 도메인 사용자를 SSAS 데이터베이스 관리자로 추가할 수 있습니다.
+ 데이터베이스 관리자는 SSMS를 사용하여 `admin` 권한이 있는 역할을 생성한 다음 해당 역할에 사용자를 추가할 수 있습니다.
+ 다음 저장 프로시저를 사용할 수 있습니다.
```
exec msdb.dbo.rds_msbi_task
@task_type='SSAS_ADD_DB_ADMIN_MEMBER',
@database_name='myssasdb',
@ssas_role_name='exampleRole',
@ssas_role_member='domain_name\domain_user_name';
```
다음 파라미터는 필수 파라미터입니다.
+ `@task_type` – MSBI 작업의 유형입니다(이 경우 `SSAS_ADD_DB_ADMIN_MEMBER`).
+ `@database_name` – 관리자 권한을 부여할 SSAS 데이터베이스의 이름입니다.
+ `@ssas_role_name` – SSAS 데이터베이스 관리자 역할 이름입니다. 역할이 아직 존재하지 않으면 역할이 생성됩니다.
+ `@ssas_role_member` – 관리자 역할에 추가할 SSAS 데이터베이스 사용자입니다.
## SSAS 프록시 생성
SQL Server 에이전트를 사용하여 SSAS 데이터베이스 처리를 예약하려면 SSAS 자격 증명과 SSAS 프록시를 생성합니다. Windows 인증 사용자로 다음 절차를 실행합니다.
**SSAS 자격 증명 생성**
+ 프록시에 대한 자격 증명을 생성합니다. 이렇게 하려면 SSMS 또는 다음 SQL 문을 사용하면 됩니다.
```
USE [master]
GO
CREATE CREDENTIAL [SSAS_Credential] WITH IDENTITY = N'mydomain\user_name', SECRET = N'mysecret'
GO
```
**참고**
`IDENTITY`는 도메인 인증 로그인이어야 합니다. `mysecret`를 도메인 인증 로그인에 대한 암호로 바꿉니다.
**SSAS 프록시 생성**
1. 다음 SQL 문을 사용하여 프록시를 생성합니다.
```
USE [msdb]
GO
EXEC msdb.dbo.sp_add_proxy @proxy_name=N'SSAS_Proxy',@credential_name=N'SSAS_Credential',@description=N''
GO
```
1. 다음 SQL 문을 사용하여 프록시에 대한 액세스 권한을 다른 사용자에게 부여합니다.
```
USE [msdb]
GO
EXEC msdb.dbo.sp_grant_login_to_proxy @proxy_name=N'SSAS_Proxy',@login_name=N'mydomain\user_name'
GO
```
1. 다음 SQL 문을 사용하여 SSAS 하위 시스템에 프록시에 대한 액세스 권한을 부여합니다.
```
USE [msdb]
GO
EXEC msdb.dbo.rds_sqlagent_proxy @task_type='GRANT_SUBSYSTEM_ACCESS',@proxy_name='SSAS_Proxy',@proxy_subsystem='SSAS'
GO
```
**프록시 및 프록시의 부여를 보려면**
1. 다음 SQL 문을 사용하여 프록시의 피부여자를 확인합니다.
```
USE [msdb]
GO
EXEC sp_help_proxy
GO
```
1. 다음 SQL 문을 사용하여 하위 시스템 부여를 확인합니다.
```
USE [msdb]
GO
EXEC msdb.dbo.sp_enum_proxy_for_subsystem
GO
```
## SQL Server 에이전트를 사용하여 SSAS 데이터베이스 처리 예약
자격 증명 및 프록시를 생성하고 SSAS에 프록시에 대한 액세스 권한을 부여한 후 SSAS 데이터베이스 처리를 예약하는 SQL Server 에이전트 작업을 생성할 수 있습니다.
**SSAS 데이터베이스 처리 예약**
+ SSMS 또는 T-SQL을 사용하여 SQL Server 에이전트 작업을 생성합니다. 다음 예제에서는 T-SQL을 사용합니다. SSMS 또는 T-SQL을 통해 작업 일정을 추가로 구성할 수 있습니다.
+ `@command` 파라미터는 SQL Server 에이전트 작업에서 실행할 XMLA(XML for Analysis) 명령을 간략하게 설명합니다. 이 예에서는 SSAS 다차원 데이터베이스 처리를 구성합니다.
+ `@server` 파라미터는 SQL Server 에이전트 작업의 대상 SSAS 서버 이름을 간략하게 설명합니다.
SQL Server 에이전트 작업이 있는 동일한 RDS DB 인스턴스 내에서 SSAS 서비스를 호출하려면 `localhost:2383`을 호출합니다.
RDS DB 인스턴스 외부에서 SSAS 서비스를 호출하려면 RDS 엔드포인트를 사용합니다. RDS DB 인스턴스가 동일한 도메인에 가입되어 있는 경우 Kerberos Active Directory(AD) 엔드포인트(`your-DB-instance-name.your-AD-domain-name`)를 사용할 수도 있습니다. 외부 DB 인스턴스의 경우 보안 연결을 위해 RDS DB 인스턴스와 연결된 VPC 보안 그룹을 올바르게 구성해야 합니다.
다양한 XMLA 작업을 지원하도록 쿼리를 추가로 편집할 수 있습니다. T-SQL 쿼리를 직접 수정하거나 SQL Server 에이전트 작업 생성 후 SSMS UI를 사용하여 편집합니다.
```
USE [msdb]
GO
DECLARE @jobId BINARY(16)
EXEC msdb.dbo.sp_add_job @job_name=N'SSAS_Job',
@enabled=1,
@notify_level_eventlog=0,
@notify_level_email=0,
@notify_level_netsend=0,
@notify_level_page=0,
@delete_level=0,
@category_name=N'[Uncategorized (Local)]',
@job_id = @jobId OUTPUT
GO
EXEC msdb.dbo.sp_add_jobserver
@job_name=N'SSAS_Job',
@server_name = N'(local)'
GO
EXEC msdb.dbo.sp_add_jobstep @job_name=N'SSAS_Job', @step_name=N'Process_SSAS_Object',
@step_id=1,
@cmdexec_success_code=0,
@on_success_action=1,
@on_success_step_id=0,
@on_fail_action=2,
@on_fail_step_id=0,
@retry_attempts=0,
@retry_interval=0,
@os_run_priority=0, @subsystem=N'ANALYSISCOMMAND',
@command=N'ProcessFullUseExisting',
@server=N'localhost:2383',
@database_name=N'master',
@flags=0,
@proxy_name=N'SSAS_Proxy'
GO
```
## 프록시에서 SSAS 액세스 취소
다음 저장 프로시저를 사용하여 SSAS 하위 시스템에 대한 액세스를 취소하고 SSAS 프록시를 삭제할 수 있습니다.
**액세스를 취소하고 프록시를 삭제하려면**
1. 하위 시스템 액세스를 취소합니다.
```
USE [msdb]
GO
EXEC msdb.dbo.rds_sqlagent_proxy @task_type='REVOKE_SUBSYSTEM_ACCESS',@proxy_name='SSAS_Proxy',@proxy_subsystem='SSAS'
GO
```
1. 프록시에 대한 부여를 취소합니다.
```
USE [msdb]
GO
EXEC msdb.dbo.sp_revoke_login_from_proxy @proxy_name=N'SSAS_Proxy',@name=N'mydomain\user_name'
GO
```
1. 프록시를 삭제합니다.
```
USE [msdb]
GO
EXEC dbo.sp_delete_proxy @proxy_name = N'SSAS_Proxy'
GO
```
# SSAS 데이터베이스 백업
SSAS 데이터베이스 백업 파일은 DB 인스턴스의 `D:\S3` 폴더에만 생성할 수 있습니다. 백업 파일을 S3 버킷으로 이동하려면 Amazon S3를 사용합니다.
다음과 같이 SSAS 데이터베이스를 백업할 수 있습니다.
+ 특정 데이터베이스에 대한 `admin` 역할이 있는 도메인 사용자는 SSMS를 사용하여 데이터베이스를 `D:\S3` 폴더에 백업할 수 있습니다.
자세한 내용은 [도메인 사용자를 데이터베이스 관리자로 추가](SSAS.Use.md#SSAS.Admin) 섹션을 참조하세요.
+ 다음 저장 프로시저를 사용할 수 있습니다. 이 저장 프로시저는 암호화를 지원하지 않습니다.
```
exec msdb.dbo.rds_msbi_task
@task_type='SSAS_BACKUP_DB',
@database_name='myssasdb',
@file_path='D:\S3\ssas_db_backup.abf',
[@ssas_apply_compression=1],
[@ssas_overwrite_file=1];
```
다음 파라미터는 필수 파라미터입니다.
+ `@task_type` – MSBI 작업의 유형입니다(이 경우 `SSAS_BACKUP_DB`).
+ `@database_name` – 백업 대상 SSAS 데이터베이스의 이름입니다.
+ `@file_path` – SSAS 백업 파일의 경로입니다. `.abf` 확장이 필요합니다.
다음 파라미터는 선택적입니다.
+ `@ssas_apply_compression` – SSAS 백업 압축을 적용할지 여부입니다. 유효한 값은 1(예) 및 0(아니오)입니다.
+ `@ssas_overwrite_file` – SSAS 백업 파일을 덮어쓸지 여부입니다. 유효한 값은 1(예) 및 0(아니오)입니다.
# SSAS 데이터베이스 복원
다음 저장 프로시저를 사용하여 백업에서 SSAS 데이터베이스를 복원합니다.
이름이 같은 기존 SSAS 데이터베이스가 있으면 데이터베이스를 복원할 수 없습니다. 복원을 위한 저장 프로시저는 암호화된 백업 파일을 지원하지 않습니다.
```
exec msdb.dbo.rds_msbi_task
@task_type='SSAS_RESTORE_DB',
@database_name='mynewssasdb',
@file_path='D:\S3\ssas_db_backup.abf';
```
다음 파라미터는 필수 파라미터입니다.
+ `@task_type` – MSBI 작업의 유형입니다(이 경우 `SSAS_RESTORE_DB`).
+ `@database_name` – 복원 대상 새 SSAS 데이터베이스의 이름입니다.
+ `@file_path` – SSAS 백업 파일의 경로입니다.
## DB 인스턴스를 지정된 시간으로 복원
PITR(특정 시점으로 복구)은 SSAS 데이터베이스에 적용되지 않습니다. PITR을 수행하는 경우 요청된 시간 이전의 마지막 스냅샷에 있는 SSAS 데이터만 복원된 인스턴스에서 사용할 수 있습니다.
**복원된 DB 인스턴스에서 SSAS 데이터베이스를 최신 상태로 유지하려면**
1. SSAS 데이터베이스를 원본 인스턴스의 `D:\S3` 폴더에 백업합니다.
1. 백업 파일을 S3 버킷으로 전송합니다.
1. S3 버킷에서 복원된 인스턴스의 `D:\S3` 폴더로 백업 파일을 전송합니다.
1. 저장 프로시저를 실행하여 SSAS 데이터베이스를 복원된 인스턴스로 복원합니다.
SSAS 프로젝트를 다시 처리하여 데이터베이스를 복원할 수도 있습니다.
# SSAS 모드 변경
SSAS가 실행되는 모드를 테이블 형식 또는 다차원으로 변경할 수 있습니다. 모드를 변경하려면 AWS Management Console 또는 AWS CLI를 사용하여 SSAS 옵션의 옵션 설정을 수정합니다.
**중요**
한 번에 하나의 SSAS 모드만 사용할 수 있습니다. 모드를 변경하기 전에 모든 SSAS 데이터베이스를 삭제해야 합니다. 그렇지 않으면 오류가 발생합니다.
## 콘솔
다음 Amazon RDS 콘솔 절차는 SSAS 모드를 테이블 형식으로 변경하고 `MAX_MEMORY` 파라미터를 70%로 설정합니다.
**SSAS 옵션 수정**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **옵션 그룹**을 선택합니다.
1. 수정하려는 `SSAS` 옵션이 있는 옵션 그룹을 선택합니다(이전 예의 `ssas-se-2017`).
1. **옵션 수정(Modify option)**을 선택합니다.
1. 옵션 설정을 변경합니다.
1. **최대 메모리(Max memory)**에서 **70**을 입력합니다.
1. **모드(Mode)**에서 **테이블 형식(Tabular)**을 선택합니다.
1. **옵션 수정(Modify option)**을 선택합니다.
## AWS CLI
다음 AWS CLI 예에서는 SSAS 모드를 테이블 형식으로 변경하고 `MAX_MEMORY` 파라미터를 70%로 설정합니다.
CLI 명령이 작동하려면 수정하지 않는 경우에도 필수 파라미터를 모두 포함해야 합니다.
**SSAS 옵션 수정**
+ 다음 명령 중 하나를 사용합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds add-option-to-option-group \
--option-group-name ssas-se-2017 \
--options "OptionName=SSAS,VpcSecurityGroupMemberships=sg-12345e67,OptionSettings=[{Name=MAX_MEMORY,Value=70},{Name=MODE,Value=Tabular}]" \
--apply-immediately
```
Windows의 경우:
```
aws rds add-option-to-option-group ^
--option-group-name ssas-se-2017 ^
--options OptionName=SSAS,VpcSecurityGroupMemberships=sg-12345e67,OptionSettings=[{Name=MAX_MEMORY,Value=70},{Name=MODE,Value=Tabular}] ^
--apply-immediately
```
# SSAS 해제
SSAS를 해제하려면 해당 옵션 그룹에서 `SSAS` 옵션을 제거합니다.
**중요**
`SSAS` 옵션을 제거하기 전에 SSAS 데이터베이스를 삭제하십시오.
SSAS 데이터베이스를 삭제하고 `SSAS` 옵션을 제거하기 전에 SSAS 데이터베이스를 백업하는 것이 좋습니다.
## 콘솔
**옵션 그룹에서 SSAS 옵션을 제거하려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **옵션 그룹**을 선택합니다.
1. 제거하려는 `SSAS` 옵션이 있는 옵션 그룹을 선택합니다(이전 예의 `ssas-se-2017`).
1. **옵션 삭제**를 선택합니다.
1. **옵션 삭제**에서 **SSAS** 또는 **삭제할 옵션**을 선택합니다.
1. **즉시 적용**에서 옵션을 즉시 삭제하려면 **예**를 선택하고 다음 유지 관리 기간에 삭제하려면 **아니오**를 선택합니다.
1. **Delete**(삭제)를 선택합니다.
## AWS CLI
**옵션 그룹에서 SSAS 옵션을 제거하려면**
+ 다음 명령 중 하나를 사용합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds remove-option-from-option-group \
--option-group-name ssas-se-2017 \
--options SSAS \
--apply-immediately
```
Windows의 경우:
```
aws rds remove-option-from-option-group ^
--option-group-name ssas-se-2017 ^
--options SSAS ^
--apply-immediately
```
# SSAS 문제 해결
SSAS 사용 시 다음과 같은 문제가 발생할 수 있습니다.
| 문제 | 유형 | 문제 해결 제안 |
| --- | --- | --- |
| SSAS 옵션을 구성할 수 없습니다. 요청한 SSAS 모드는 new\$1mode지만 현재 DB 인스턴스에는 number개의 current\$1mode 데이터베이스가 있습니다. new\$1mode 모드로 전환하기 전에 기존 데이터베이스를 삭제하세요. 데이터베이스 삭제를 위해 current\$1mode 모드에 다시 액세스하려면 현재 DB 옵션 그룹을 업데이트하거나 SSAS 옵션에 대한 MODE 옵션 설정 값으로 %s를 사용하여 새 옵션 그룹을 연결합니다. | RDS 이벤트 | 현재 모드를 사용하는 SSAS 데이터베이스가 여전히 있는 경우 SSAS 모드를 변경할 수 없습니다. SSAS 데이터베이스를 삭제한 다음 다시 시도하세요. |
| number개의 기존 mode 데이터베이스가 있어 SSAS 옵션을 제거할 수 없습니다. 모든 SSAS 데이터베이스가 삭제될 때까지 SSAS 옵션을 제거할 수 없습니다. SSAS 옵션을 다시 추가하고 모든 SSAS 데이터베이스를 삭제한 다음 다시 시도하세요. | RDS 이벤트 | 아직 SSAS 데이터베이스가 있는 경우 SSAS를 해제할 수 없습니다. SSAS 데이터베이스를 삭제한 다음 다시 시도하세요. |
| SSSAS 옵션이 사용 설정되지 않았거나 사용 설정되는 중입니다. 나중에 다시 시도해 주세요. | RDS 저장 프로시저 | 옵션이 해제되어 있거나 설정되고 있을 때는 SSAS 저장 프로시저를 실행할 수 없습니다. |
| SSAS 옵션이 잘못 구성되었습니다. 옵션 그룹 구성원 자격 상태가 "동기화 중"인지 확인하고 RDS 이벤트 로그에서 관련 SSAS 구성 오류 메시지를 검토하세요. 이러한 조사 후 다시 시도하세요. 오류가 계속 발생하면 AWS Support에 문의하세요. | RDS 저장 프로시저 | 옵션 그룹 멤버십이 `in-sync` 상태가 아니면 SSAS 저장 프로시저를 실행할 수 없습니다. 이렇게 하면 SSAS 옵션이 잘못된 구성 상태가 됩니다. SSAS 옵션 수정으로 인해 옵션 그룹 멤버십 상태가 `failed`로 변경되는 경우 두 가지 이유가 있을 수 있습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/SSAS.Trouble.html) RDS는 한 번에 하나의 SSAS 모드만 허용하고 SSAS 데이터베이스가 있는 SSAS 옵션 제거를 지원하지 않으므로 SSAS 옵션을 다시 구성합니다. RDS 이벤트 로그에서 SSAS 인스턴스의 구성 오류를 확인하고 그에 따라 문제를 해결하세요. |
| 배포에 실패했습니다. 변경 사항은 deployment\$1file\$1mode 모드에서 실행 중인 서버에만 배포할 수 있습니다. 현재 서버 모드는 current\$1mode입니다. | RDS 저장 프로시저 | 다차원 서버에 테이블 형식 데이터베이스를 배포하거나 테이블 형식 서버에 다차원 데이터베이스를 배포할 수 없습니다. 올바른 모드의 파일을 사용하고 있는지 확인하고 `MODE` 옵션 설정이 적절한 값으로 설정되어 있는지 확인합니다. |
| 복원에 실패했습니다. 백업 파일은 restore\$1file\$1mode 모드로 실행 중인 서버에서만 복원할 수 있습니다. 현재 서버 모드는 current\$1mode입니다. | RDS 저장 프로시저 | 테이블 형식 데이터베이스를 다차원 서버로 복원하거나 다차원 데이터베이스를 테이블 형식 서버로 복원할 수 없습니다. 올바른 모드의 파일을 사용하고 있는지 확인하고 `MODE` 옵션 설정이 적절한 값으로 설정되어 있는지 확인합니다. |
| 복원에 실패했습니다. 백업 파일과 RDS DB 인스턴스 버전이 호환되지 않습니다. | RDS 저장 프로시저 | SQL Server 인스턴스 버전과 호환되지 않는 버전으로 SSAS 데이터베이스를 복원할 수 없습니다. 자세한 내용은 Microsoft 설명서의 [테이블 형식 모델에 대한 호환성 수준](https://docs.microsoft.com/en-us/analysis-services/tabular-models/compatibility-level-for-tabular-models-in-analysis-services)과[다차원 데이터베이스의 호환성 수준](https://docs.microsoft.com/en-us/analysis-services/multidimensional-models/compatibility-level-of-a-multidimensional-database-analysis-services)을 참조하세요. |
| 복원에 실패했습니다. 복원 작업에 지정된 백업 파일이 손상되었거나 SSAS 백업 파일이 아닙니다. @rds\$1file\$1path 형식이 올바른지 확인하세요. | RDS 저장 프로시저 | 손상된 파일을 사용하여 SSAS 데이터베이스를 복원할 수 없습니다. 파일이 손상되지 않았는지 확인합니다. 이 오류는 `@rds_file_path`의 형식이 올바르지 않은 경우에도 발생할 수 있습니다(예: `D:\S3\\incorrect_format.abf`에서와 같이 이중 백슬래시가 있는 경우). |
| 복원에 실패했습니다. 복원된 데이터베이스 이름은 예약어 또는 유효하지 않은 문자(. , ; ' ` : / \$1\$1 \$1 \$1 ? \$1" & % \$1 \$1 \$1 = ( ) [ ] \$1 \$1 < >)를 포함하거나 100자를 초과할 수 없습니다. | RDS 저장 프로시저 | 복원된 데이터베이스 이름은 예약어 또는 유효하지 않은 문자를 포함하거나 100자를 초과할 수 없습니다. SSAS 객체 이름 지정 규칙은 Microsoft 설명서의 [객체 명명 규칙](https://docs.microsoft.com/en-us/analysis-services/multidimensional-models/olap-physical/object-naming-rules-analysis-services)을 참조하세요. |
| 잘못된 역할 이름이 제공되었습니다. 역할 이름은 예약된 문자열을 포함할 수 없습니다. | RDS 저장 프로시저 | 역할 이름은 예약된 문자열을 포함할 수 없습니다. SSAS 객체 이름 지정 규칙은 Microsoft 설명서의 [객체 명명 규칙](https://docs.microsoft.com/en-us/analysis-services/multidimensional-models/olap-physical/object-naming-rules-analysis-services)을 참조하세요. |
| 잘못된 역할 이름이 제공되었습니다. 역할 이름은 예약된 문자(. , ; ' ` : / \$1\$1 \$1 \$1 ? \$1" & % \$1 \$1 \$1 = ( ) [ ] \$1 \$1 < >)를 포함할 수 없습니다. | RDS 저장 프로시저 | 역할 이름은 예약된 문자를 포함할 수 없습니다. SSAS 객체 이름 지정 규칙은 Microsoft 설명서의 [객체 명명 규칙](https://docs.microsoft.com/en-us/analysis-services/multidimensional-models/olap-physical/object-naming-rules-analysis-services)을 참조하세요. |
# Amazon RDS for SQL Server에서 SQL Server Integration Services 지원
Microsoft SQL Server Integration Services(SSIS)는 광범위한 데이터 마이그레이션 작업을 수행하는 데 사용할 수 있는 구성 요소입니다. SSIS는 데이터 통합 및 워크플로우 애플리케이션용 플랫폼입니다. 이는 데이터 추출, 변환 및 로드(ETL)에 사용되는 데이터 웨어하우징 도구를 특징으로 합니다. 이 도구를 사용하여 SQL Server 데이터베이스의 유지 관리 및 다차원 큐브 데이터 업데이트를 자동화할 수도 있습니다.
SSIS 프로젝트는 XML 기반 .dtsx 파일로 저장된 패키지로 구성됩니다. 패키지에는 제어 흐름 및 데이터 흐름이 포함될 수 있습니다. 데이터 흐름을 사용하여 ETL 작업을 나타냅니다. 배포 후 패키지는 SSISDB 데이터베이스의 SQL Server에 저장됩니다. SSISDB는 전체 복구 모드의 OLTP(온라인 트랜잭션 처리) 데이터베이스입니다.
Amazon RDS for SQL Server는 RDS DB 인스턴스에서 SSRS를 직접 실행할 수 있도록 지원합니다. 기존 DB 인스턴스 또는 새 DB 인스턴스에서 SSRS를 활성화할 수 있습니다. SSIS는 데이터베이스 엔진과 동일한 DB 인스턴스에 설치됩니다.
RDS는 다음 버전에서 SQL Server Standard 및 Enterprise Edition용 SSIS를 지원합니다.
+ SQL Server 2022, 모든 버전
+ SQL Server 2019, 버전 15.00.4043.16.v1 이상
+ SQL Server 2017, 버전 14.00.3223.3.v1 이상
+ SQL Server 2016, 버전 13.00.5426.0.v1 이상
**Contents**
+ [제한 및 권장 사항](#SSIS.Limitations)
+ [SSIS 활성화](#SSIS.Enabling)
+ [SSIS용 옵션 그룹 생성](#SSIS.OptionGroup)
+ [옵션 그룹에 SSIS 옵션 추가](#SSIS.Add)
+ [SSIS용 파라미터 그룹 생성](#SSIS.CreateParamGroup)
+ [SSIS용 파라미터 수정](#SSIS.ModifyParam)
+ [옵션 그룹 및 파라미터 그룹을 DB 인스턴스와 연결](#SSIS.Apply)
+ [S3 통합 활성화](#SSIS.EnableS3)
+ [SSISDB에 대한 관리 권한](SSIS.Permissions.md)
+ [SSIS용 Windows 인증 사용자 설정](SSIS.Permissions.md#SSIS.Use.Auth)
+ [SSIS 프로젝트 배포](SSIS.Deploy.md)
+ [배포 작업의 상태 모니터링](SSIS.Monitor.md)
+ [SSIS 사용](SSIS.Use.md)
+ [SSIS 프로젝트에 대한 데이터베이스 연결 관리자 설정](SSIS.Use.md#SSIS.Use.ConnMgrs)
+ [SSIS 프록시 생성](SSIS.Use.md#SSIS.Use.Proxy)
+ [SQL Server 에이전트를 사용하여 SSIS 패키지 예약](SSIS.Use.md#SSIS.Use.Schedule)
+ [프록시에서 SSIS 액세스 취소](SSIS.Use.md#SSIS.Use.Revoke)
+ [SSIS 데이터베이스 비활성화 및 삭제](SSIS.DisableDrop.md)
+ [SSIS 비활성화](SSIS.DisableDrop.md#SSIS.Disable)
+ [SSISDB 데이터베이스 삭제](SSIS.DisableDrop.md#SSIS.Drop)
## 제한 및 권장 사항
RDS for SQL Server에서 SSRS를 실행하는 경우 다음과 같은 제한 및 권장 사항이 적용됩니다.
+ DB 인스턴스에는 `clr enabled` 파라미터가 1로 설정된 연결된 파라미터 그룹이 있어야 합니다. 자세한 내용은 [SSIS용 파라미터 수정](#SSIS.ModifyParam) 섹션을 참조하세요.
**참고**
SQL Server 2017 또는 2019에서 `clr enabled` 파라미터를 활성화하면 DB 인스턴스에서 CLR(공통 언어 런타임)을 사용할 수 없습니다. 자세한 내용은 [지원되지 않는 기능과 지원이 제한된 기능](SQLServer.Concepts.General.FeatureNonSupport.md) 섹션을 참조하세요.
+ 다음 제어 흐름 작업이 지원됩니다.
+ 분석 서비스 DDL 실행 작업
+ 분석 서비스 처리 작업
+ 대량 삽입 작업
+ 데이터베이스 무결성 검사 작업
+ 데이터 흐름 작업
+ 데이터 마이닝 쿼리 작업
+ 데이터 프로파일링 작업
+ 패키지 실행 작업
+ SQL Server 에이전트 작업 실행 작업
+ SQL 실행 작업
+ T-SQL 문 실행 작업
+ 운영자에게 알림 작업
+ 인덱스 재구축 작업
+ 인덱스 재구성 작업
+ 데이터베이스 축소 작업
+ 데이터베이스 전송 작업
+ 작업 전송 작업
+ 로그인 전송 작업
+ SQL Server 개체 전송 작업
+ 통계 업데이트 작업
+ 프로젝트 배포만 지원됩니다.
+ SQL Server 에이전트를 사용하여 SSIS 패키지를 실행할 수 있습니다.
+ SSIS 로그 레코드는 사용자가 만든 데이터베이스에만 삽입할 수 있습니다.
+ 파일 작업에는 `D:\S3` 폴더만 사용합니다. 다른 디렉터리에 있는 파일은 삭제됩니다. 다른 파일 위치 세부 정보를 숙지하십시오.
+ SSIS 프로젝트 입력 및 출력 파일을 `D:\S3` 폴더에 배치합니다.
+ 데이터 흐름 작업의 경우 `BLOBTempStoragePath` 및 `BufferTempStoragePath`의 위치를 `D:\S3` 폴더 내의 파일로 변경합니다. 파일 경로는 `D:\S3\`로 시작되어야 합니다.
+ 파일 연결에 사용되는 모든 파라미터, 변수 및 표현식이 `D:\S3` 폴더를 가리키는지 확인합니다.
+ 다중 AZ 인스턴스에서 장애 조치 후 `D:\S3` 폴더에 SSIS에서 생성한 파일이 삭제됩니다. 자세한 내용은 [S3 통합에 대한 다중 AZ 제한 사항](User.SQLServer.Options.S3-integration.md#S3-MAZ) 섹션을 참조하세요.
+ `D:\S3` 폴더에 SSIS에서 생성한 파일을 Amazon S3 버킷에 업로드하여 내구성을 높입니다.
+ 열 가져오기 및 열 내보내기 변환과 데이터 흐름 작업의 스크립트 구성 요소는 지원되지 않습니다.
+ SSIS 패키지 실행 시 덤프를 활성화할 수 없으며 SSIS 패키지에 데이터 탭을 추가할 수 없습니다.
+ SSIS 확장 기능은 지원되지 않습니다.
+ 프로젝트를 직접 배포할 수 없습니다. 이를 수행할 RDS 저장 프로시저를 제공합니다. 자세한 내용은 [SSIS 프로젝트 배포](SSIS.Deploy.md) 섹션을 참조하세요.
+ RDS에 배포하기 위한 `DoNotSavePasswords` 보호 모드를 사용하여 SSIS 프로젝트(.ispac) 파일을 빌드합니다.
+ 읽기 전용 복제본이 있는 Always On 인스턴스에서는 SSIS가 지원되지 않습니다.
+ `SSIS` 옵션과 연결된 SSISDB 데이터베이스는 백업할 수 없습니다.
+ SSIS의 다른 인스턴스에서 SSISDB 데이터베이스를 가져오고 복원하는 것은 지원되지 않습니다.
+ 다른 SQL Server DB 인스턴스나 Oracle 데이터 소스에 연결할 수 있습니다. MySQL이나 PostgreSQL 같은 다른 데이터베이스 엔진에 연결하는 것은 RDS for SQL Server의 SSIS에서 지원되지 않습니다. Oracle 데이터 소스 연결에 대한 자세한 내용은 [Oracle OLEDB 포함 연결된 서버](Appendix.SQLServer.Options.LinkedServers_Oracle_OLEDB.md) 단원을 참조하세요.
+ SSIS는 온프레미스 도메인에 대한 발신 신뢰가 있는 도메인 조인 인스턴스를 지원하지 않습니다. 발신 신뢰를 사용하는 경우 로컬 AWS 도메인의 계정에서 SSIS 작업을 실행합니다.
+ 파일 시스템 기반 패키지 실행은 지원되지 않습니다.
## SSIS 활성화
SSIS 옵션을 DB 인스턴스에 추가하여 SSIS를 활성화합니다. 다음 프로세스를 사용합니다.
1. 새 옵션 그룹을 생성하거나 기존 옵션 그룹을 선택합니다.
1. [`SSIS`] 옵션을 옵션 그룹에 추가합니다.
1. 새 파라미터 그룹을 생성하거나 기존 파라미터 그룹을 선택합니다.
1. 파라미터 그룹을 수정하여 `clr enabled` 파라미터를 1로 설정합니다.
1. 옵션 그룹 및 파라미터 그룹을 DB 인스턴스와 연결합니다.
1. Amazon S3 통합을 활성화합니다.
**참고**
이름이 SSISDB이거나 예약된 SSIS 로그인이 있는 데이터베이스가 DB 인스턴스에 이미 있는 경우 인스턴스에서 SSIS를 활성화할 수 없습니다.
### SSIS용 옵션 그룹 생성
SSIS를 사용하려면 사용할 DB 인스턴스의 SQL Server 에디션 및 버전에 해당하는 옵션 그룹을 생성하거나 수정합니다. 이렇게 하려면 AWS Management Console 또는 AWS CLI를 사용합니다.
#### 콘솔
다음 절차에서는 SQL Server Standard Edition 2016에 대한 옵션 그룹을 생성합니다.
**옵션 그룹을 생성하려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **옵션 그룹**을 선택합니다.
1. **그룹 생성**을 선택합니다.
1. **보안 그룹 생성** 창에서 다음과 같이 합니다.
1. [**이름(Name)**]에 AWS 계정 내에서 쉽게 식별할 수 있는 옵션 그룹 이름을 입력합니다(예: **ssis-se-2016**). 이름은 글자, 숫자 및 하이픈만 사용 가능합니다.
1. **설명**에 옵션 그룹에 대한 간단한 설명을 입력합니다(예: **SSIS option group for SQL Server SE 2016**). 이 설명은 표시 용도로만 사용됩니다.
1. **엔진**에 대해 **sqlserver-se**를 선택합니다.
1. **메이저 엔진 버전**에 **13.00**을 선택합니다.
1. **생성(Create)**을 선택합니다.
#### CLI
다음 절차에서는 SQL Server Standard Edition 2016에 대한 옵션 그룹을 생성합니다.
**옵션 그룹을 생성하려면**
+ 다음 명령 중 하나를 실행합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds create-option-group \
--option-group-name ssis-se-2016 \
--engine-name sqlserver-se \
--major-engine-version 13.00 \
--option-group-description "SSIS option group for SQL Server SE 2016"
```
Windows의 경우:
```
aws rds create-option-group ^
--option-group-name ssis-se-2016 ^
--engine-name sqlserver-se ^
--major-engine-version 13.00 ^
--option-group-description "SSIS option group for SQL Server SE 2016"
```
### 옵션 그룹에 SSIS 옵션 추가
그런 다음 AWS Management Console 또는 AWS CLI를 사용하여 `SSIS` 옵션을 옵션 그룹에 추가합니다.
#### 콘솔
**SSIS 옵션을 추가하려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **옵션 그룹**을 선택합니다.
1. 이 예제에서는 방금 생성한 옵션 그룹인 **ssis-se-2016**을 선택합니다.
1. **옵션 추가**를 선택합니다.
1. **옵션 세부 정보**에서 **옵션 이름**으로 **SSIS**를 선택합니다.
1. **예약**에서 옵션을 즉시 추가할지 또는 다음 유지 관리 기간에 추가할지를 선택합니다.
1. **옵션 추가**를 선택합니다.
#### CLI
**SSIS 옵션을 추가하려면**
+ [`SSIS`] 옵션을 옵션 그룹에 추가합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds add-option-to-option-group \
--option-group-name ssis-se-2016 \
--options OptionName=SSIS \
--apply-immediately
```
Windows의 경우:
```
aws rds add-option-to-option-group ^
--option-group-name ssis-se-2016 ^
--options OptionName=SSIS ^
--apply-immediately
```
### SSIS용 파라미터 그룹 생성
SSIS를 사용할 DB 인스턴스의 SQL Server 에디션 및 버전에 해당하는 `clr enabled` 파라미터의 파라미터 그룹을 생성하거나 수정합니다.
#### 콘솔
다음 절차에서는 SQL Server Standard Edition 2016에 대한 파라미터 그룹을 생성합니다.
**파라미터 그룹을 생성하려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **파라미터 그룹**을 선택합니다.
1. [**Create parameter group**]을 선택합니다.
1. **서브넷 그룹 생성** 창에서 다음을 수행합니다.
1. **파라미터 그룹 패밀리**에서 **sqlserver-se-13.0**을 선택합니다.
1. **그룹 이름**에 파라미터 그룹의 식별자(예: **ssis-sqlserver-se-13**)를 입력합니다.
1. **설명**에 **clr enabled parameter group**를 입력합니다.
1. **생성(Create)**을 선택합니다.
#### CLI
다음 절차에서는 SQL Server Standard Edition 2016에 대한 파라미터 그룹을 생성합니다.
**파라미터 그룹을 생성하려면**
+ 다음 명령 중 하나를 실행합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds create-db-parameter-group \
--db-parameter-group-name ssis-sqlserver-se-13 \
--db-parameter-group-family "sqlserver-se-13.0" \
--description "clr enabled parameter group"
```
Windows의 경우:
```
aws rds create-db-parameter-group ^
--db-parameter-group-name ssis-sqlserver-se-13 ^
--db-parameter-group-family "sqlserver-se-13.0" ^
--description "clr enabled parameter group"
```
### SSIS용 파라미터 수정
SQL Server 에디션 및 DB 인스턴스의 버전에 해당하는 파라미터 그룹의 `clr enabled` 파라미터를 수정합니다. SSIS의 경우 `clr enabled` 파라미터를 1로 설정합니다.
#### 콘솔
다음 절차에서는 SQL Server Standard Edition 2016에 대해 생성한 파라미터 그룹을 수정합니다.
**파라미터 그룹을 수정하려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **파라미터 그룹**을 선택합니다.
1. 파라미터 그룹(예: **ssis-sqlserver-se-13**)을 선택합니다.
1. **파라미터**에서 파라미터 목록을 **clr**로 필터링합니다.
1. **clr 활성**을 선택합니다.
1. **파라미터 편집**을 선택합니다.
1. **값**에서 **1**을 선택합니다.
1. **변경 사항 저장**을 선택합니다.
#### CLI
다음 절차에서는 SQL Server Standard Edition 2016에 대해 생성한 파라미터 그룹을 수정합니다.
**파라미터 그룹을 수정하려면**
+ 다음 명령 중 하나를 실행합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds modify-db-parameter-group \
--db-parameter-group-name ssis-sqlserver-se-13 \
--parameters "ParameterName='clr enabled',ParameterValue=1,ApplyMethod=immediate"
```
Windows의 경우:
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name ssis-sqlserver-se-13 ^
--parameters "ParameterName='clr enabled',ParameterValue=1,ApplyMethod=immediate"
```
### 옵션 그룹 및 파라미터 그룹을 DB 인스턴스와 연결
SSIS 옵션 그룹 및 파라미터 그룹을 DB 인스턴스와 연결하려면 AWS Management Console 또는 AWS CLI를 사용합니다.
**참고**
기존 인스턴스를 사용하는 경우 이미 Active Directory 도메인과 AWS Identity and Access Management(IAM) 역할이 연결되어 있어야 합니다. 새 인스턴스를 생성하는 경우 기존 Active Directory 도메인 및 IAM 역할을 지정합니다. 자세한 내용은 [RDS for SQL Server를 사용하여 Active Directory 작업](User.SQLServer.ActiveDirectoryWindowsAuth.md) 섹션을 참조하세요.
#### 콘솔
SSIS 활성화를 완료하려면 SSIS 옵션 그룹 및 파라미터 그룹을 새 DB 인스턴스 또는 기존 DB 인스턴스와 연결합니다.
+ 새 DB 인스턴스의 경우 인스턴스를 시작할 때 이러한 그룹을 연결합니다. 자세한 내용은 [Amazon RDS DB 인스턴스 생성](USER_CreateDBInstance.md) 섹션을 참조하세요.
+ 기존 DB 인스턴스의 경우 인스턴스를 수정하여 그룹을 연결합니다. 자세한 내용은 [Amazon RDS DB 인스턴스 수정](Overview.DBInstance.Modifying.md) 섹션을 참조하세요.
#### CLI
SSIS 옵션 그룹 및 파라미터 그룹을 새 DB 인스턴스 또는 기존 DB 인스턴스와 연결할 수 있습니다.
**SSIS 옵션 그룹 및 파라미터 그룹을 사용하여 인스턴스를 생성하려면**
+ 옵션 그룹을 생성할 때 사용한 것과 동일한 DB 엔진 유형과 메이저 버전을 지정합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds create-db-instance \
--db-instance-identifier myssisinstance \
--db-instance-class db.m5.2xlarge \
--engine sqlserver-se \
--engine-version 13.00.5426.0.v1 \
--allocated-storage 100 \
--manage-master-user-password \
--master-username admin \
--storage-type gp2 \
--license-model li \
--domain-iam-role-name my-directory-iam-role \
--domain my-domain-id \
--option-group-name ssis-se-2016 \
--db-parameter-group-name ssis-sqlserver-se-13
```
Windows의 경우:
```
aws rds create-db-instance ^
--db-instance-identifier myssisinstance ^
--db-instance-class db.m5.2xlarge ^
--engine sqlserver-se ^
--engine-version 13.00.5426.0.v1 ^
--allocated-storage 100 ^
--manage-master-user-password ^
--master-username admin ^
--storage-type gp2 ^
--license-model li ^
--domain-iam-role-name my-directory-iam-role ^
--domain my-domain-id ^
--option-group-name ssis-se-2016 ^
--db-parameter-group-name ssis-sqlserver-se-13
```
**인스턴스를 수정하고 SSIS 옵션 그룹 및 파라미터 그룹을 연결하려면**
+ 다음 명령 중 하나를 실행합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds modify-db-instance \
--db-instance-identifier myssisinstance \
--option-group-name ssis-se-2016 \
--db-parameter-group-name ssis-sqlserver-se-13 \
--apply-immediately
```
Windows의 경우:
```
aws rds modify-db-instance ^
--db-instance-identifier myssisinstance ^
--option-group-name ssis-se-2016 ^
--db-parameter-group-name ssis-sqlserver-se-13 ^
--apply-immediately
```
### S3 통합 활성화
배포를 위해 SSIS 프로젝트(.ispac) 파일을 호스트에 다운로드하려면 S3 파일 통합을 사용합니다. 자세한 내용은 [Amazon RDS for SQL Server DB 인스턴스와 Amazon S3 통합](User.SQLServer.Options.S3-integration.md) 섹션을 참조하세요.
# SSISDB에 대한 관리 권한
SSIS 옵션을 사용하여 인스턴스를 생성하거나 수정하면 마스터 사용자에게 ssis\$1admin 및 ssis\$1logreader 역할이 부여된 SSISDB 데이터베이스가 생성됩니다. 마스터 사용자는 SSISDB에 대해 다음 권한을 가집니다.
+ ssis\$1admin 역할 변경
+ ssis\$1logreader 역할 변경
+ 모든 사용자 변경
마스터 사용자는 SQL 인증 사용자이므로 마스터 사용자를 사용하여 SSIS 패키지를 실행할 수 없습니다. 마스터 사용자는 이러한 권한을 사용하여 새 SSISDB 사용자를 생성하고 이를 ssis\$1admin 및 ssis\$1logreader 역할에 추가할 수 있습니다. 이렇게 하면 SSIS 사용을 위해 도메인 사용자에게 액세스 권한을 부여하는 데 유용합니다.
## SSIS용 Windows 인증 사용자 설정
마스터 사용자가 다음 코드 예제를 사용하여 SSISDB에서 Windows 인증 로그인을 설정하고 필요한 절차에 대한 권한을 부여할 수 있습니다. 이렇게 하면 도메인 사용자에게 SSIS 패키지를 배포 및 실행하고, S3 파일 전송 프로시저를 사용하고, 자격 증명을 만들고, SQL Server 에이전트 프록시를 사용할 수 있는 권한이 부여됩니다. 자세한 내용은 Microsoft 설명서의 [자격 증명(데이터베이스 엔진)](https://docs.microsoft.com/en-us/sql/relational-databases/security/authentication-access/credentials-database-engine?view=sql-server-ver15) 및 [SQL Server 에이전트 프록시 생성](https://docs.microsoft.com/en-us/sql/ssms/agent/create-a-sql-server-agent-proxy?view=sql-server-ver15)을 참조하십시오.
**참고**
필요에 따라 Windows 인증 사용자에게 다음 사용 권한 중 일부 또는 모두를 부여할 수 있습니다.
**Example**
```
-- Create a server-level SQL login for the domain user, if it doesn't already exist
USE [master]
GO
CREATE LOGIN [mydomain\user_name] FROM WINDOWS
GO
-- Create a database-level account for the domain user, if it doesn't already exist
USE [SSISDB]
GO
CREATE USER [mydomain\user_name] FOR LOGIN [mydomain\user_name]
-- Add SSIS role membership to the domain user
ALTER ROLE [ssis_admin] ADD MEMBER [mydomain\user_name]
ALTER ROLE [ssis_logreader] ADD MEMBER [mydomain\user_name]
GO
-- Add MSDB role membership to the domain user
USE [msdb]
GO
CREATE USER [mydomain\user_name] FOR LOGIN [mydomain\user_name]
-- Grant MSDB stored procedure privileges to the domain user
GRANT EXEC ON msdb.dbo.rds_msbi_task TO [mydomain\user_name] with grant option
GRANT SELECT ON msdb.dbo.rds_fn_task_status TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.rds_task_status TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.rds_cancel_task TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.rds_download_from_s3 TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.rds_upload_to_s3 TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.rds_delete_from_filesystem TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.rds_gather_file_details TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.sp_add_proxy TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.sp_update_proxy TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.sp_grant_login_to_proxy TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.sp_revoke_login_from_proxy TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.sp_delete_proxy TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.sp_enum_login_for_proxy to [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.sp_enum_proxy_for_subsystem TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.rds_sqlagent_proxy TO [mydomain\user_name] WITH GRANT OPTION
-- Add the SQLAgentUserRole privilege to the domain user
USE [msdb]
GO
ALTER ROLE [SQLAgentUserRole] ADD MEMBER [mydomain\user_name]
GO
-- Grant the ALTER ANY CREDENTIAL privilege to the domain user
USE [master]
GO
GRANT ALTER ANY CREDENTIAL TO [mydomain\user_name]
GO
```
# SSIS 프로젝트 배포
RDS에서는 SQL Server Management Studio(SSMS) 또는 SSIS 프로시저를 사용하여 SSIS 프로젝트를 직접 배포할 수 없습니다. Amazon S3에서 프로젝트 파일을 다운로드한 다음 배포하려면 RDS 저장 프로시저를 사용합니다.
저장 프로시저를 실행하려면 저장 프로시저를 실행할 권한을 부여한 사용자로 로그인합니다. 자세한 내용은 [SSIS용 Windows 인증 사용자 설정](SSIS.Permissions.md#SSIS.Use.Auth) 섹션을 참조하세요.
**SSIS 프로젝트를 배포하려면**
1. 프로젝트(.ispac) 파일을 다운로드합니다.
```
exec msdb.dbo.rds_download_from_s3
@s3_arn_of_file='arn:aws:s3:::bucket_name/ssisproject.ispac',
@rds_file_path='D:\S3\ssisproject.ispac',
@overwrite_file=1;
```
1. 다음 사항을 확인하여 배포 작업을 제출합니다.
+ 폴더는 SSIS 카탈로그에 있습니다.
+ 프로젝트 이름은 SSIS 프로젝트를 개발하는 동안 사용한 프로젝트 이름과 일치합니다.
```
exec msdb.dbo.rds_msbi_task
@task_type='SSIS_DEPLOY_PROJECT',
@folder_name='DEMO',
@project_name='ssisproject',
@file_path='D:\S3\ssisproject.ispac';
```
# 배포 작업의 상태 모니터링
배포 작업의 상태를 추적하려면 `rds_fn_task_status` 함수를 호출합니다. 두 가지 파라미터가 필요합니다. 첫 번째 파라미터는 SSIS에 적용되지 않기 때문에 항상 `NULL`이어야 합니다. 두 번째 파라미터는 작업 ID를 수락합니다.
모든 작업 목록을 보려면 다음 예와 같이 첫 번째 파라미터를 `NULL`로, 두 번째 파라미터를 `0`으로 설정하십시오.
```
SELECT * FROM msdb.dbo.rds_fn_task_status(NULL,0);
```
특정 작업을 수행하려면 다음 예와 같이 첫 번째 파라미터를 `NULL`로, 두 번째 파라미터를 작업 ID로 설정하십시오.
```
SELECT * FROM msdb.dbo.rds_fn_task_status(NULL,42);
```
`rds_fn_task_status` 함수는 다음 정보를 반환합니다.
| 출력 파라미터 | 설명 |
| --- | --- |
| `task_id` | 작업의 ID입니다. |
| `task_type` | `SSIS_DEPLOY_PROJECT` |
| `database_name` | SSIS 작업에는 적용되지 않습니다. |
| `% complete` | 백분율로 나타낸 작업의 진행률입니다. |
| `duration (mins)` | 작업에 소요된 시간입니다(분). |
| `lifecycle` | 작업의 상태입니다. 가능한 상태는 다음과 같습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/SSIS.Monitor.html) |
| `task_info` | 작업에 대한 추가 정보입니다. 처리 중에 오류가 발생하면 이 열에 오류 정보가 포함됩니다. |
| `last_updated` | 작업 상태를 마지막으로 업데이트한 날짜와 시간입니다. |
| `created_at` | 작업을 생성한 날짜와 시간입니다. |
| `S3_object_arn` | SSIS 작업에는 적용되지 않습니다. |
| `overwrite_S3_backup_file` | SSIS 작업에는 적용되지 않습니다. |
| `KMS_master_key_arn` | SSIS 작업에는 적용되지 않습니다. |
| `filepath` | SSIS 작업에는 적용되지 않습니다. |
| `overwrite_file` | SSIS 작업에는 적용되지 않습니다. |
| `task_metadata` | SSIS 작업과 관련된 메타데이터입니다. |
# SSIS 사용
SSIS 프로젝트를 SSIS 카탈로그에 배포한 후 SSMS에서 직접 패키지를 실행하거나 SQL Server 에이전트를 사용하여 예약할 수 있습니다. SSIS 패키지를 실행하려면 Windows 인증 로그인을 사용해야 합니다. 자세한 내용은 [SSIS용 Windows 인증 사용자 설정](SSIS.Permissions.md#SSIS.Use.Auth) 섹션을 참조하세요.
**Topics**
+ [SSIS 프로젝트에 대한 데이터베이스 연결 관리자 설정](#SSIS.Use.ConnMgrs)
+ [SSIS 프록시 생성](#SSIS.Use.Proxy)
+ [SQL Server 에이전트를 사용하여 SSIS 패키지 예약](#SSIS.Use.Schedule)
+ [프록시에서 SSIS 액세스 취소](#SSIS.Use.Revoke)
## SSIS 프로젝트에 대한 데이터베이스 연결 관리자 설정
연결 관리자를 사용하는 경우 다음과 같은 유형의 인증을 사용할 수 있습니다.
+ AWS 관리형 Active Directory를 사용하는 로컬 데이터베이스 연결의 경우 SQL 인증 또는 Windows 인증을 사용할 수 있습니다. Windows 인증의 경우 연결 문자열의 서버 이름으로 `DB_instance_name.fully_qualified_domain_name`을 사용합니다.
예를 들어 `myssisinstance.corp-ad.example.com`입니다. 여기서 `myssisinstance`는 DB 인스턴스 이름이고 `corp-ad.example.com`은 정규화된 도메인 이름입니다.
+ 원격 연결의 경우 항상 SQL 인증을 사용합니다.
+ 자체 관리형 Active Directory를 사용하는 로컬 데이터베이스 연결의 경우 SQL 인증 또는 Windows 인증을 사용할 수 있습니다. Windows 인증의 경우 연결 문자열의 서버 이름으로 `.` 또는 `LocalHost`를 사용합니다.
## SSIS 프록시 생성
SQL Server 에이전트를 사용하여 SSIS 패키지를 예약하려면 SSIS 자격 증명과 SSIS 프록시를 생성합니다. Windows 인증 사용자로 다음 절차를 실행합니다.
**SSIS 자격 증명을 생성하려면**
+ 프록시에 대한 자격 증명을 생성합니다. 이렇게 하려면 SSMS 또는 다음 SQL 문을 사용하면 됩니다.
```
USE [master]
GO
CREATE CREDENTIAL [SSIS_Credential] WITH IDENTITY = N'mydomain\user_name', SECRET = N'mysecret'
GO
```
**참고**
`IDENTITY`는 도메인 인증 로그인이어야 합니다. `mysecret`를 도메인 인증 로그인에 대한 암호로 바꿉니다.
SSISDB 기본 호스트가 변경될 때마다 새 호스트가 액세스할 수 있도록 SSIS 프록시 자격 증명을 변경합니다.
**SSIS 프록시를 생성하려면**
1. 다음 SQL 문을 사용하여 프록시를 생성합니다.
```
USE [msdb]
GO
EXEC msdb.dbo.sp_add_proxy @proxy_name=N'SSIS_Proxy',@credential_name=N'SSIS_Credential',@description=N''
GO
```
1. 다음 SQL 문을 사용하여 프록시에 대한 액세스 권한을 다른 사용자에게 부여합니다.
```
USE [msdb]
GO
EXEC msdb.dbo.sp_grant_login_to_proxy @proxy_name=N'SSIS_Proxy',@login_name=N'mydomain\user_name'
GO
```
1. 다음 SQL 문을 사용하여 SSIS 하위 시스템에 프록시에 대한 액세스 권한을 부여합니다.
```
USE [msdb]
GO
EXEC msdb.dbo.rds_sqlagent_proxy @task_type='GRANT_SUBSYSTEM_ACCESS',@proxy_name='SSIS_Proxy',@proxy_subsystem='SSIS'
GO
```
**프록시 및 프록시의 부여를 보려면**
1. 다음 SQL 문을 사용하여 프록시의 피부여자를 확인합니다.
```
USE [msdb]
GO
EXEC sp_help_proxy
GO
```
1. 다음 SQL 문을 사용하여 하위 시스템 부여를 확인합니다.
```
USE [msdb]
GO
EXEC msdb.dbo.sp_enum_proxy_for_subsystem
GO
```
## SQL Server 에이전트를 사용하여 SSIS 패키지 예약
자격 증명 및 프록시를 생성하고 SSIS에 프록시에 대한 액세스 권한을 부여한 후 SSIS 패키지를 예약하는 SQL Server 에이전트 작업을 생성할 수 있습니다.
**SSIS 패키지를 예약하려면**
+ SSMS 또는 T-SQL을 사용하여 SQL Server 에이전트 작업을 생성할 수 있습니다. 다음 예제에서는 T-SQL을 사용합니다.
```
USE [msdb]
GO
DECLARE @jobId BINARY(16)
EXEC msdb.dbo.sp_add_job @job_name=N'MYSSISJob',
@enabled=1,
@notify_level_eventlog=0,
@notify_level_email=2,
@notify_level_page=2,
@delete_level=0,
@category_name=N'[Uncategorized (Local)]',
@job_id = @jobId OUTPUT
GO
EXEC msdb.dbo.sp_add_jobserver @job_name=N'MYSSISJob',@server_name=N'(local)'
GO
EXEC msdb.dbo.sp_add_jobstep @job_name=N'MYSSISJob',@step_name=N'ExecuteSSISPackage',
@step_id=1,
@cmdexec_success_code=0,
@on_success_action=1,
@on_fail_action=2,
@retry_attempts=0,
@retry_interval=0,
@os_run_priority=0,
@subsystem=N'SSIS',
@command=N'/ISSERVER "\"\SSISDB\MySSISFolder\MySSISProject\MySSISPackage.dtsx\"" /SERVER "\"my-rds-ssis-instance.corp-ad.company.com/\""
/Par "\"$ServerOption::LOGGING_LEVEL(Int16)\"";1 /Par "\"$ServerOption::SYNCHRONIZED(Boolean)\"";True /CALLERINFO SQLAGENT /REPORTING E',
@database_name=N'master',
@flags=0,
@proxy_name=N'SSIS_Proxy'
GO
```
## 프록시에서 SSIS 액세스 취소
다음 저장 프로시저를 사용하여 SSIS 하위 시스템에 대한 액세스를 취소하고 SSIS 프록시를 삭제할 수 있습니다.
**액세스를 취소하고 프록시를 삭제하려면**
1. 하위 시스템 액세스를 취소합니다.
```
USE [msdb]
GO
EXEC msdb.dbo.rds_sqlagent_proxy @task_type='REVOKE_SUBSYSTEM_ACCESS',@proxy_name='SSIS_Proxy',@proxy_subsystem='SSIS'
GO
```
1. 프록시에 대한 부여를 취소합니다.
```
USE [msdb]
GO
EXEC msdb.dbo.sp_revoke_login_from_proxy @proxy_name=N'SSIS_Proxy',@name=N'mydomain\user_name'
GO
```
1. 프록시를 삭제합니다.
```
USE [msdb]
GO
EXEC dbo.sp_delete_proxy @proxy_name = N'SSIS_Proxy'
GO
```
# SSIS 데이터베이스 비활성화 및 삭제
다음 단계를 사용하여 SSIS 데이터베이스를 비활성화하거나 삭제합니다.
**Topics**
+ [SSIS 비활성화](#SSIS.Disable)
+ [SSISDB 데이터베이스 삭제](#SSIS.Drop)
## SSIS 비활성화
SSIS를 비활성화하려면 해당 옵션 그룹에서 `SSIS` 옵션을 제거합니다.
**중요**
이 옵션을 제거해도 SSISDB 데이터베이스가 삭제되지 않으므로 SSIS 프로젝트 손실 없이 해당 옵션을 안전하게 제거할 수 있습니다.
제거 후 `SSIS` 옵션을 다시 활성화하여 이전에 SSIS 카탈로그에 배포된 SSIS 프로젝트를 다시 사용할 수 있습니다.
### 콘솔
다음 절차에서는 `SSIS` 옵션을 제거합니다.
**옵션 그룹에서 SSIS 옵션을 제거하려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **옵션 그룹**을 선택합니다.
1. `SSIS` 옵션이 있는 옵션 그룹을 선택합니다(이전 예제의 경우 `ssis-se-2016`).
1. **옵션 삭제**를 선택합니다.
1. **옵션 삭제**에서 **삭제할 옵션**에 **SSIS**를 선택합니다.
1. **즉시 적용**에서 옵션을 즉시 삭제하려면 **예**를 선택하고 다음 유지 관리 기간에 삭제하려면 **아니오**를 선택합니다.
1. **Delete**(삭제)를 선택합니다.
### CLI
다음 절차에서는 `SSIS` 옵션을 제거합니다.
**옵션 그룹에서 SSIS 옵션을 제거하려면**
+ 다음 명령 중 하나를 실행합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds remove-option-from-option-group \
--option-group-name ssis-se-2016 \
--options SSIS \
--apply-immediately
```
Windows의 경우:
```
aws rds remove-option-from-option-group ^
--option-group-name ssis-se-2016 ^
--options SSIS ^
--apply-immediately
```
## SSISDB 데이터베이스 삭제
SSIS 옵션을 제거한 후 SSISDB 데이터베이스는 삭제되지 않습니다. SSISDB 데이터베이스를 삭제하려면 SSIS 옵션을 제거한 후 `rds_drop_ssis_database` 저장 프로시저를 사용합니다.
**SSIS 데이터베이스를 삭제하려면**
+ 다음 저장 프로시저를 사용합니다.
```
USE [msdb]
GO
EXEC dbo.rds_drop_ssis_database
GO
```
SSISDB 데이터베이스를 삭제한 후 SSIS 옵션을 다시 활성화하면 새 SSISDB 카탈로그를 얻을 수 있습니다.
# Amazon RDS for SQL Server에서 SQL Server Reporting Services 지원
Microsoft SQL Server Reporting Services(SSRS)는 보고서 생성 및 배포에 사용되는 서버 기반 애플리케이션으로, SQL Server Analysis Services(SSAS) 및 SQL Server Integration Services(SSIS)를 포함하는 SQL Server 서비스 제품군의 일부입니다. SQL Server를 기반으로 하는 서비스인 SSRS를 사용하여 다양한 데이터 원본에서 데이터를 수집하고 쉽게 이해 및 분석 가능한 방식으로 제공할 수 있습니다.
Amazon RDS for SQL Server는 RDS DB 인스턴스에서 SSRS를 직접 실행할 수 있도록 지원합니다. 기존 DB 인스턴스 또는 새 DB 인스턴스에서 SSRS를 사용할 수 있습니다.
RDS는 다음 버전에서 SQL Server Standard 및 Enterprise Edition용 SSRS를 지원합니다.
+ SQL Server 2022, 모든 버전
+ SQL Server 2019, 버전 15.00.4043.16.v1 이상
+ SQL Server 2017, 버전 14.00.3223.3.v1 이상
+ SQL Server 2016, 13.00.5820.21.v1 이상 버전
**Contents**
+ [제한 및 권장 사항](#SSRS.Limitations)
+ [SSRS 설정](SSRS.Enabling.md)
+ [SSRS용 옵션 그룹 생성](SSRS.Enabling.md#SSRS.OptionGroup)
+ [옵션 그룹에 SSRS 옵션 추가](SSRS.Enabling.md#SSRS.Add)
+ [옵션 그룹을 DB 인스턴스와 연결](SSRS.Enabling.md#SSRS.Apply)
+ [VPC 보안 그룹에 대한 인바운드 액세스 허용](SSRS.Enabling.md#SSRS.Inbound)
+ [보고서 서버 데이터베이스](#SSRS.DBs)
+ [SSRS 로그 파일](#SSRS.Logs)
+ [SSRS 웹 포털 액세스](SSRS.Access.md)
+ [RDS에서 SSL 사용](SSRS.Access.md#SSRS.Access.SSL)
+ [도메인 사용자에게 액세스 권한 부여](SSRS.Access.md#SSRS.Access.Grant)
+ [웹 포털 액세스](SSRS.Access.md#SSRS.Access)
+ [보고서 배포 및 보고서 데이터 소스 구성](SSRS.DeployConfig.md)
+ [SSRS에 보고서 배포](SSRS.DeployConfig.md#SSRS.Deploy)
+ [보고서 데이터 소스 구성](SSRS.DeployConfig.md#SSRS.ConfigureDataSource)
+ [SSRS 이메일을 사용하여 보고서 보내기](SSRS.Email.md)
+ [시스템 수준 권한 취소](SSRS.Access.Revoke.md)
+ [작업의 상태 모니터링](SSRS.Monitor.md)
+ [SSRS 데이터베이스 비활성화 및 삭제](SSRS.DisableDelete.md)
+ [SSRS 해제](SSRS.DisableDelete.md#SSRS.Disable)
+ [SSRS 데이터베이스 삭제](SSRS.DisableDelete.md#SSRS.Drop)
## 제한 및 권장 사항
RDS for SQL Server에서 SSRS를 실행하는 경우 다음과 같은 제한 및 권장 사항이 적용됩니다.
+ 읽기 전용 복제본이 있는 DB 인스턴스에서는 SSRS를 사용할 수 없습니다.
+ 인스턴스에서 자체 관리형 Active Directory 또는 SSRS용 AWS Directory Service for Microsoft Active Directory 웹 포털 및 웹 서버 인증을 사용해야 합니다. 자세한 내용은 [RDS for SQL Server를 사용하여 Active Directory 작업](User.SQLServer.ActiveDirectoryWindowsAuth.md) 단원을 참조하십시오.
+ SSRS 옵션으로 만든 보고 서버 데이터베이스는 백업할 수 없습니다.
+ 다른 SSRS 인스턴스에서 보고서 서버 데이터베이스를 가져오고 복원하는 것은 지원되지 않습니다. 자세한 내용은 [보고서 서버 데이터베이스](#SSRS.DBs) 단원을 참조하십시오.
+ 기본 SSL 포트(443)에서 수신하도록 SSRS를 구성할 수 없습니다. 허용되는 값은 1150–49511(1234, 1434, 3260, 3343, 3389, 47001 제외)입니다.
+ Windows 파일 공유를 통한 구독은 지원되지 않습니다.
+ 보고 서비스 구성 관리자를 사용하는 것은 지원되지 않습니다.
+ 역할을 생성 및 수정하는 것은 지원되지 않습니다.
+ 보고서 서버 속성을 수정하는 것은 지원되지 않습니다.
+ 시스템 관리자 및 시스템 사용자 역할은 부여되지 않습니다.
+ 웹 포털을 통해 시스템 수준의 역할 할당을 편집할 수 없습니다.
# SSRS 설정
다음 프로세스를 사용하여 DB 인스턴스에 대해 SSRS를 켭니다.
1. 새 옵션 그룹을 생성하거나 기존 옵션 그룹을 선택합니다.
1. [`SSRS`] 옵션을 옵션 그룹에 추가합니다.
1. 옵션 그룹을 DB 인스턴스에 연동시킵니다.
1. SSRS 리스너 포트의 Virtual Private Cloud(VPC) 보안 그룹에 대한 인바운드 액세스를 허용합니다.
## SSRS용 옵션 그룹 생성
SSRS를 사용하려면 SQL Server 엔진과 사용할 DB 인스턴스 버전에 해당하는 옵션 그룹을 생성합니다. 이렇게 하려면 AWS Management Console 또는 AWS CLI를 사용합니다.
**참고**
올바른 SQL Server 엔진 및 버전인 경우 기존 옵션 그룹을 사용할 수도 있습니다.
### 콘솔
다음 절차에서는 SQL Server Standard Edition 2017에 대한 옵션 그룹을 생성합니다.
**옵션 그룹을 생성하려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **옵션 그룹**을 선택합니다.
1. **그룹 생성**을 선택합니다.
1. **보안 그룹 생성** 창에서 다음을 수행합니다.
1. **이름**에 AWS 계정 계정 내에서 쉽게 식별할 수 있는 옵션 그룹 이름을 입력합니다(예: **ssrs-se-2017**). 이름은 글자, 숫자 및 하이픈만 사용 가능합니다.
1. **설명**에 옵션 그룹에 대한 간단한 설명을 입력합니다(예: **SSRS option group for SQL Server SE 2017**). 이 설명은 표시 용도로만 사용됩니다.
1. **엔진**에 대해 **sqlserver-se**를 선택합니다.
1. **메이저 엔진 버전**에 대해 **14.00**을 선택합니다.
1. **생성(Create)**을 선택합니다.
### CLI
다음 절차에서는 SQL Server Standard Edition 2017에 대한 옵션 그룹을 생성합니다.
**옵션 그룹을 생성하려면**
+ 다음 명령 중 하나를 실행합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds create-option-group \
--option-group-name ssrs-se-2017 \
--engine-name sqlserver-se \
--major-engine-version 14.00 \
--option-group-description "SSRS option group for SQL Server SE 2017"
```
Windows의 경우:
```
aws rds create-option-group ^
--option-group-name ssrs-se-2017 ^
--engine-name sqlserver-se ^
--major-engine-version 14.00 ^
--option-group-description "SSRS option group for SQL Server SE 2017"
```
## 옵션 그룹에 SSRS 옵션 추가
그런 다음 AWS Management Console 또는 AWS CLI를 사용하여 `SSRS` 옵션을 옵션 그룹에 추가합니다.
### 콘솔
**SSRS 옵션을 추가하려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **옵션 그룹**을 선택합니다.
1. 방금 생성한 옵션 그룹을 선택한 다음 **옵션 추가**를 선택합니다.
1. **옵션 세부 정보**에서 **옵션 이름**으로 **SSRS**를 선택합니다.
1. **옵션 설정**에서 다음을 수행합니다.
1. SSRS 서비스가 수신할 포트를 입력합니다. 기본값은 8443입니다. 허용되는 값 목록은 [제한 및 권장 사항](Appendix.SQLServer.Options.SSRS.md#SSRS.Limitations) 단원을 참조하십시오.
1. **최대 메모리**에 값을 입력합니다.
**최대 메모리**는 상한 임계값을 지정합니다. 이 임계값을 넘으면 보고서 서버 애플리케이션에 새 메모리 할당 요청이 수락되지 않습니다. 숫자는 DB 인스턴스에 대한 총 메모리 비율입니다. 허용되는 값은 10–80입니다.
1. **보안 그룹**의 경우 옵션과 연결할 VPC 보안 그룹을 선택합니다. DB 인스턴스와 연결된 보안 그룹을 사용합니다.
1. SSRS 이메일을 사용하여 보고서를 보내려면 **보고 서비스의 이메일 배달** 아래에서 **이메일 배달 옵션 구성** 확인란을 선택한 후 다음을 수행합니다.
1. **발신자 이메일 주소**에 대해 SSRS 이메일에서 보낸 메시지의 **보낸 사람** 필드에 사용할 이메일 주소를 입력합니다.
SMTP 서버에서 메일을 보낼 수 있는 권한이 있는 사용자 계정을 지정합니다.
1. 에 대한**SMTP 서버**, 사용할 SMTP 서버 또는 게이트웨이를 지정합니다.
IP 주소, 회사 인트라넷에 있는 컴퓨터의 NetBIOS 이름 또는 정규화된 도메인 이름이 될 수 있습니다.
1. **SMTP 포트**에 메일 서버에 연결할 때 사용할 포트를 입력합니다. 기본값은 25입니다.
1. 인증을 사용하려면:
1. **인증 사용**확인란을 선택합니다.
1. **Secret Amazon 리소스 이름(ARN**)에 사용자 자격 증명에 대한 AWS Secrets Manager ARN을 입력합니다.
다음 형식을 사용합니다.
**arn:aws:secretsmanager:*Region*:*AccountId*:secret:*SecretName*-*6RandomCharacters***
예:
**arn:aws:secretsmanager:*us-west-2*:*123456789012*:secret:*MySecret-a1b2c3***
새 SFTP 비밀 생성에 대한 자세한 정보는 [SSRS 이메일을 사용하여 보고서 보내기](SSRS.Email.md) 단원을 참조하십시오.
1. SSL을 사용하여 이메일 메시지를 암호화하려면 **SSL(Secure Sockets Layer) 사용** 확인란을 선택합니다.
1. **예약**에서 옵션을 즉시 추가할지 또는 다음 유지 관리 기간에 추가할지를 선택합니다.
1. **옵션 추가**를 선택합니다.
### CLI
**SSRS 옵션을 추가하려면**
1. JSON 파일 (예: `ssrs-option.json`)을 새 제품으로 합니다.
1. 다음 필수 파라미터를 설정합니다.
+ `OptionGroupName` – 이전에 생성했거나 선택한 옵션 그룹의 이름입니다(다음 예의 경우 `ssrs-se-2017`).
+ `Port` – SSRS 서비스가 수신할 포트입니다. 기본값은 8443입니다. 허용되는 값 목록은 [제한 및 권장 사항](Appendix.SQLServer.Options.SSRS.md#SSRS.Limitations) 단원을 참조하십시오.
+ `VpcSecurityGroupMemberships` – RDS DB 인스턴스에 대한 VPC 보안 그룹 멤버십입니다.
+ `MAX_MEMORY` – 상한 임계값을 지정합니다. 이 임계값을 넘으면 보고서 서버 애플리케이션에 새 메모리 할당 요청이 수락되지 않습니다. 숫자는 DB 인스턴스에 대한 총 메모리 비율입니다. 허용되는 값은 10–80입니다.
1. (선택 사항) SSRS 이메일을 사용하려면 다음 파라미터를 설정합니다.
+ `SMTP_ENABLE_EMAIL` — `true`로 설정하여 SSRS 이메일을 사용합니다. 기본값은 `false`입니다.
+ `SMTP_SENDER_EMAIL_ADDRESS` — SSRS 이메일에서 보낸 메시지의 **보낸 사람** 필드에 사용할 전자 메일 주소입니다. SMTP 서버에서 메일을 보낼 수 있는 권한이 있는 사용자 계정을 지정합니다.
+ `SMTP_SERVER` — 사용할 SMTP 서버 또는 게이트웨이입니다. IP 주소, 회사 인트라넷에 있는 컴퓨터의 NetBIOS 이름 또는 정규화된 도메인 이름이 될 수 있습니다.
+ `SMTP_PORT` — 메일 서버에 연결하는 데 사용할 포트입니다. 기본값은 25입니다.
+ `SMTP_USE_SSL` — `true`를 설정하여 SSL을 사용하는 이메일 메시지를 암호화합니다. 기본값은 `true`입니다.
+ `SMTP_EMAIL_CREDENTIALS_SECRET_ARN` — 사용자 자격 증명을 보관하는 Secrets Manager ARN. 다음 형식을 사용합니다.
**arn:aws:secretsmanager:*Region*:*AccountId*:secret:*SecretName*-*6RandomCharacters***
비밀 생성에 대한 자세한 내용은 [SSRS 이메일을 사용하여 보고서 보내기](SSRS.Email.md) 단원을 참조하세요.
+ `SMTP_USE_ANONYMOUS_AUTHENTICATION` — 인증을 사용하지 않으려면 `true`로 설정하고 `SMTP_EMAIL_CREDENTIALS_SECRET_ARN`을 포함하지 마세요.
기본값은 `SMTP_ENABLE_EMAIL`이 `true`일 때 `false`입니다.
다음 예에는 암호 ARN을 사용하는 SSRS 이메일 파라미터가 포함되어 있습니다.
```
{
"OptionGroupName": "ssrs-se-2017",
"OptionsToInclude": [
{
"OptionName": "SSRS",
"Port": 8443,
"VpcSecurityGroupMemberships": ["sg-0abcdef123"],
"OptionSettings": [
{"Name": "MAX_MEMORY","Value": "60"},
{"Name": "SMTP_ENABLE_EMAIL","Value": "true"}
{"Name": "SMTP_SENDER_EMAIL_ADDRESS","Value": "nobody@example.com"},
{"Name": "SMTP_SERVER","Value": "email-smtp.us-west-2.amazonaws.com"},
{"Name": "SMTP_PORT","Value": "25"},
{"Name": "SMTP_USE_SSL","Value": "true"},
{"Name": "SMTP_EMAIL_CREDENTIALS_SECRET_ARN","Value": "arn:aws:secretsmanager:us-west-2:123456789012:secret:MySecret-a1b2c3"}
]
}],
"ApplyImmediately": true
}
```
1. [`SSRS`] 옵션을 옵션 그룹에 추가합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds add-option-to-option-group \
--cli-input-json file://ssrs-option.json \
--apply-immediately
```
Windows의 경우:
```
aws rds add-option-to-option-group ^
--cli-input-json file://ssrs-option.json ^
--apply-immediately
```
## 옵션 그룹을 DB 인스턴스와 연결
AWS Management Console 또는 AWS CLI를 사용하여 옵션 그룹을 DB 인스턴스와 연결할 수 있습니다.
기존 DB 인스턴스를 사용하는 경우 이미 Active Directory 도메인과 AWS Identity and Access Management(IAM) 역할이 연결되어 있어야 합니다. 새 인스턴스를 생성하는 경우 기존 Active Directory 도메인 및 IAM 역할을 지정합니다. 자세한 내용은 [RDS for SQL Server를 사용하여 Active Directory 작업](User.SQLServer.ActiveDirectoryWindowsAuth.md) 섹션을 참조하세요.
### 콘솔
옵션 그룹을 새 DB 인스턴스 또는 기존 DB 인스턴스와 연결할 수 있습니다.
+ 새 DB 인스턴스의 경우, 인스턴스를 시작할 때 옵션 그룹을 연결하십시오. 자세한 내용은 [Amazon RDS DB 인스턴스 생성](USER_CreateDBInstance.md) 섹션을 참조하세요.
+ 기존 DB 인스턴스의 경우 인스턴스를 수정하고 새 옵션 그룹을 연결합니다. 자세한 내용은 [Amazon RDS DB 인스턴스 수정](Overview.DBInstance.Modifying.md)을 참조하세요.
### CLI
옵션 그룹을 새 DB 인스턴스 또는 기존 DB 인스턴스와 연결할 수 있습니다.
**옵션 그룹을 사용하는 DB 인스턴스를 생성하려면**
+ 옵션 그룹을 생성할 때 사용한 것과 동일한 DB 엔진 유형과 메이저 버전을 지정합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds create-db-instance \
--db-instance-identifier myssrsinstance \
--db-instance-class db.m5.2xlarge \
--engine sqlserver-se \
--engine-version 14.00.3223.3.v1 \
--allocated-storage 100 \
--manage-master-user-password \
--master-username admin \
--storage-type gp2 \
--license-model li \
--domain-iam-role-name my-directory-iam-role \
--domain my-domain-id \
--option-group-name ssrs-se-2017
```
Windows의 경우:
```
aws rds create-db-instance ^
--db-instance-identifier myssrsinstance ^
--db-instance-class db.m5.2xlarge ^
--engine sqlserver-se ^
--engine-version 14.00.3223.3.v1 ^
--allocated-storage 100 ^
--manage-master-user-password ^
--master-username admin ^
--storage-type gp2 ^
--license-model li ^
--domain-iam-role-name my-directory-iam-role ^
--domain my-domain-id ^
--option-group-name ssrs-se-2017
```
**옵션 그룹을 사용하도록 DB 인스턴스를 수정하려면**
+ 다음 명령 중 하나를 실행합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds modify-db-instance \
--db-instance-identifier myssrsinstance \
--option-group-name ssrs-se-2017 \
--apply-immediately
```
Windows의 경우:
```
aws rds modify-db-instance ^
--db-instance-identifier myssrsinstance ^
--option-group-name ssrs-se-2017 ^
--apply-immediately
```
## VPC 보안 그룹에 대한 인바운드 액세스 허용
DB 인스턴스와 연결된 VPC 보안 그룹에 대한 인바운드 액세스를 허용하려면 지정된 SSRS 리스너 포트에 대한 인바운드 규칙을 생성합니다. 보안 그룹 설정에 대한 자세한 내용은 [보안 그룹을 생성하여 VPC 내부의 DB 인스턴스에 대한 액세스를 제공](CHAP_SettingUp.md#CHAP_SettingUp.SecurityGroup) 단원을 참조하십시오.
## 보고서 서버 데이터베이스
DB 인스턴스가 SSRS 옵션과 연결되면 DB 인스턴스에 두 개의 새 데이터베이스가 생성됩니다.
+ `rdsadmin_ReportServer`
+ `rdsadmin_ReportServerTempDB`
이러한 데이터베이스는 ReportServer 및 ReportServerTempDB 데이터베이스로 작동합니다. SSRS는 ReportServer 데이터베이스에 데이터를 저장하고 ReportServerTempDB 데이터베이스에 데이터를 캐시합니다. 자세한 정보는 Microsoft 문서의 [보고서 서버 데이터베이스](https://learn.microsoft.com/en-us/sql/reporting-services/report-server/report-server-database-ssrs-native-mode?view=sql-server-ver15)를 참조하세요.
RDS는 이러한 데이터베이스를 소유하고 관리하므로 ALTER 및 DROP 등의 데이터베이스 작업은 허용되지 않습니다. `rdsadmin_ReportServerTempDB` 데이터베이스에서는 액세스가 허용되지 않습니다. 그러나 `rdsadmin_ReportServer` 데이터베이스에서 읽기 작업을 수행할 수 있습니다.
## SSRS 로그 파일
SSRS 로그 파일을 나열하고 보고 다운로드할 수 있습니다. SSRS 로그 파일은 ReportServerService\$1*timestamp*.log의 명명 규칙을 따릅니다. 이러한 보고서 서버 로그는 `D:\rdsdbdata\Log\SSRS` 디렉터리에 있습니다. (`D:\rdsdbdata\Log` 디렉터리는 오류 로그 및 SQL Server 에이전트 로그의 상위 디렉터리이기도 합니다.) 자세한 내용은 [데이터베이스 로그 파일 보기 및 나열](USER_LogAccess.Procedural.Viewing.md) 단원을 참조하십시오.
기존 SSRS 인스턴스의 경우 보고서 서버 로그에 액세스하려면 SSRS 서비스를 다시 시작해야 할 수 있습니다. `SSRS` 옵션을 업데이트하여 서비스를 재시작하면 됩니다.
자세한 내용은 [Amazon RDS for Microsoft SQL Server 로그 작업](Appendix.SQLServer.CommonDBATasks.Logs.md)을 참조하세요.
# SSRS 웹 포털 액세스
SSRS 웹 포털에 액세스하려면 다음 프로세스를 사용합니다.
1. Secure Sockets Layer(SSL) 설정
1. 도메인 사용자에게 액세스 권한을 부여합니다.
1. 브라우저 및 도메인 사용자 자격 증명을 사용하여 웹 포털에 액세스합니다.
## RDS에서 SSL 사용
SSRS는 연결에 HTTPS SSL 프로토콜을 사용합니다. 이 프로토콜을 사용할 수 있도록 클라이언트 컴퓨터의 Microsoft Windows 운영 체제로 SSL 인증서를 가져옵니다.
SSL 인증서에 대한 자세한 내용은 [SSL/TLS를 사용하여 DB 인스턴스 또는 클러스터 에 대한 연결 암호화](UsingWithRDS.SSL.md) 단원을 참조하십시오. SQL Server에서 SSL을 사용하는 방법에 대한 자세한 내용은 [Microsoft SQL Server DB 인스턴스와 함께 SSL 사용](SQLServer.Concepts.General.SSL.Using.md) 단원을 참조하십시오.
## 도메인 사용자에게 액세스 권한 부여
새 SSRS 활성화 시 SSRS에 역할이 할당되어 있지 않습니다. 도메인 사용자 또는 사용자 그룹에 웹 포털에 대한 액세스 권한을 부여하기 위해 RDS는 저장 프로시저를 제공합니다.
**웹 포털에서 도메인 사용자에게 액세스 권한을 부여하려면**
+ 다음 저장 프로시저를 사용합니다.
```
exec msdb.dbo.rds_msbi_task
@task_type='SSRS_GRANT_PORTAL_PERMISSION',
@ssrs_group_or_username=N'AD_domain\user';
```
도메인 사용자 또는 사용자 그룹에는 `RDS_SSRS_ROLE` 시스템 역할이 부여됩니다. 이 역할은 다음과 같은 시스템 수준의 작업을 수행할 수 있습니다.
+ 보고서 실행
+ 작업 관리
+ 공유 일정 관리
+ 공유 일정 보기
루트 폴더에서 항목 수준의 `Content Manager` 역할도 부여됩니다.
## 웹 포털 액세스
`SSRS_GRANT_PORTAL_PERMISSION` 작업이 성공적으로 완료되면 웹 브라우저를 사용하여 포털에 액세스할 수 있습니다. 웹 포털 URL의 형식은 다음과 같습니다.
```
https://rds_endpoint:port/Reports
```
위의 형식에서 각 요소는 다음과 같습니다.
+ *`rds_endpoint`* – SSRS와 함께 사용 중인 RDS DB 인스턴스의 엔드포인트입니다.
이 엔드포인트는 DB 인스턴스의 **연결 및 보안** 탭에서 찾을 수 있습니다. 자세한 내용은 [Microsoft SQL Server DB 인스턴스에 연결](USER_ConnectToMicrosoftSQLServerInstance.md) 섹션을 참조하세요.
+ `port` – `SSRS` 옵션에서 설정한 SSRS의 리스너 포트입니다.
**웹 포털에 액세스하려면**
1. 브라우저에 웹 포털 URL을 입력합니다.
```
https://myssrsinstance.cg034itsfake.us-east-1.rds.amazonaws.com:8443/Reports
```
1. `SSRS_GRANT_PORTAL_PERMISSION` 작업을 통해 액세스 권한을 부여한 도메인 사용자의 자격 증명으로 로그인합니다.
# 보고서 배포 및 보고서 데이터 소스 구성
다음 절차에 따라 보고서를 SSRS에 배포하고 보고 데이터 소스를 구성합니다.
**Topics**
+ [SSRS에 보고서 배포](#SSRS.Deploy)
+ [보고서 데이터 소스 구성](#SSRS.ConfigureDataSource)
## SSRS에 보고서 배포
웹 포털에 대한 액세스 권한이 있으면 웹 포털에 보고서를 배포할 수 있습니다. 웹 포털의 업로드 도구를 사용하여 보고서를 업로드하거나 [SQL Server 데이터 도구(SSDT)](https://docs.microsoft.com/en-us/sql/ssdt/download-sql-server-data-tools-ssdt)에서 직접 배포할 수 있습니다. SSDT에서 배포하는 경우 다음을 확인하세요.
+ SSDT를 시작한 사용자가 SSRS 웹 포털에 액세스할 수 있습니다.
+ SSRS 프로젝트 속성의 `TargetServerURL` 값이 다음과 같이 `ReportServer` 접미사가 붙은 RDS DB 인스턴스의 HTTPS 엔드포인트로 설정됩니다.
```
https://myssrsinstance.cg034itsfake.us-east-1.rds.amazonaws.com:8443/ReportServer
```
## 보고서 데이터 소스 구성
보고서를 SSRS에 배포한 후에는 보고서 데이터 소스를 구성해야 합니다. 보고서 데이터 소스를 구성할 때 다음 요구 사항을 충족해야 합니다.
+ AWS Directory Service for Microsoft Active Directory에 연결된 RDS for SQL Server DB 인스턴스의 경우 정규화된 도메인 이름(FQDN)을 연결 문자열의 데이터 소스 이름으로 사용합니다. 예를 들어 `myssrsinstance.corp-ad.example.com`입니다. 여기서 `myssrsinstance`는 DB 인스턴스 이름이고 `corp-ad.example.com`은 정규화된 도메인 이름입니다.
+ 자체 관리형 Active Directory에 연결된 RDS for SQL Server DB 인스턴스의 경우 `.` 또는 `LocalHost`를 연결 문자열의 데이터 소스 이름으로 사용합니다.
# SSRS 이메일을 사용하여 보고서 보내기
SSRS에는 사용자에게 보고서를 보내는 데 사용할 수 있는 SSRS 전자 메일 확장이 포함되어 있습니다.
SSRS 이메일을 구성하려면 `SSRS` 옵션 설정을 사용합니다. 자세한 내용은 [옵션 그룹에 SSRS 옵션 추가](SSRS.Enabling.md#SSRS.Add)을 참조하세요.
SSRS 이메일을 구성한 후 보고서 서버에서 보고서를 구독할 수 있습니다. 자세한 내용은 [보고 서비스를 통한 이메일 전달](https://docs.microsoft.com/en-us/sql/reporting-services/subscriptions/e-mail-delivery-in-reporting-services)을 알아보려면 다음 섹션을 참조하세요.마이크로소프트 설명서에서
SSRS 이메일이 RDS에서 작동하려면 AWS Secrets Manager와의 통합이 필요합니다. Secrets Manager와 통합하려면 보안 암호를 생성합니다.
**참고**
나중에 암호를 변경하는 경우 옵션 그룹의 `SSRS` 옵션도 업데이트해야 합니다.
**SSRS 이메일에 보안 암호를 만들려면**
1. *AWS Secrets Manager 사용 설명서*의 [암호 생성](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) 단계를 따릅니다.
1. **암호 유형 선택**에서 **다른 유형의 암호**를 선택합니다.
1. **키/값 쌍**의 경우 다음을 입력합니다.
+ **SMTP\$1USERNAME** - SMTP 서버에서 메일을 보낼 권한이 있는 사용자를 입력합니다.
+ **SMTP\$1PASSWORD** - SMTP 사용자의 암호를 입력합니다.
1. **암호화 키**의 경우 기본 AWS KMS key을 사용하지 않습니다. 기존의 키를 사용하거나 새 키를 생성합니다.
KMS 키 정책은 다음과 같은 `kms:Decrypt` 작업을 허용해야 합니다.
```
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"Service": [
"rds.amazonaws.com"
]
},
"Action": [
"kms:Decrypt"
],
"Resource": "*"
}
```
1. *AWS Secrets Manager 사용 설명서*의 [암호에 권한 정책 연결](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_resource-policies.html)의 단계를 따르세요. 권한 정책은 `rds.amazonaws.com` 서비스 주체에게 `secretsmanager:GetSecretValue` 작업을 제공합니다.
*혼란스러운 대리인* 문제를 피하기 위해 정책의 `aws:sourceAccount` 및 `aws:sourceArn` 조건을 사용하는 것이 좋습니다. `aws:sourceAccount`에 대해 AWS 계정 및 `aws:sourceArn`의 옵션 그룹 ARN을 사용합니다. 자세한 내용은 [교차 서비스 혼동된 대리자 문제 방지](cross-service-confused-deputy-prevention.md) 단원을 감사하세요.
다음 예는 권한 정책을 보여 줍니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement" : [ {
"Effect" : "Allow",
"Principal" : {
"Service" : "rds.amazonaws.com"
},
"Action" : "secretsmanager:GetSecretValue",
"Resource" : "*",
"Condition" : {
"StringEquals" : {
"aws:sourceAccount" : "123456789012"
},
"ArnLike" : {
"aws:sourceArn" : "arn:aws:rds:us-west-2:123456789012:og:ssrs-se-2017"
}
}
} ]
}
```
------
더 많은 예제는 **AWS Secrets Manager 사용 설명서의 [AWS Secrets Manager에 대한 권한 정책 예](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_examples.html)를 참조하세요.
# 시스템 수준 권한 취소
`RDS_SSRS_ROLE` 시스템 역할에는 시스템 수준 역할 할당을 삭제할 수 있는 권한이 없습니다. `RDS_SSRS_ROLE`에서 사용자 또는 사용자 그룹을 제거하려면 역할을 부여하는 데 사용한 것과 동일한 저장 프로시저를 사용하되 `SSRS_REVOKE_PORTAL_PERMISSION` 작업 유형을 사용합니다.
**웹 포털에 대한 도메인 사용자의 액세스 권한을 취소하려면**
+ 다음 저장 프로시저를 사용합니다.
```
exec msdb.dbo.rds_msbi_task
@task_type='SSRS_REVOKE_PORTAL_PERMISSION',
@ssrs_group_or_username=N'AD_domain\user';
```
이렇게 하면 `RDS_SSRS_ROLE` 시스템 역할에서 사용자가 삭제됩니다. 또한 사용자가 `Content Manager` 항목 수준 역할(역할을 가진 경우)에서 삭제됩니다.
# 작업의 상태 모니터링
권한 부여 또는 취소 작업의 상태를 추적하려면 `rds_fn_task_status` 함수를 호출합니다. 두 가지 파라미터가 필요합니다. 첫 번째 파라미터는 SSRS에 적용되지 않기 때문에 항상 `NULL`이어야 합니다. 두 번째 파라미터는 작업 ID를 수락합니다.
모든 작업 목록을 보려면 다음 예와 같이 첫 번째 파라미터를 `NULL`로, 두 번째 파라미터를 `0`으로 설정하십시오.
```
SELECT * FROM msdb.dbo.rds_fn_task_status(NULL,0);
```
특정 작업을 수행하려면 다음 예와 같이 첫 번째 파라미터를 `NULL`로, 두 번째 파라미터를 작업 ID로 설정하십시오.
```
SELECT * FROM msdb.dbo.rds_fn_task_status(NULL,42);
```
`rds_fn_task_status` 함수는 다음 정보를 반환합니다.
| 출력 파라미터 | 설명 |
| --- | --- |
| `task_id` | 작업의 ID입니다. |
| `task_type` | SSRS의 경우 작업 유형은 다음과 같을 수 있습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/SSRS.Monitor.html) |
| `database_name` | SSRS 작업에는 적용되지 않습니다. |
| `% complete` | 백분율로 나타낸 작업의 진행률입니다. |
| `duration (mins)` | 작업에 소요된 시간입니다(분). |
| `lifecycle` | 작업의 상태입니다. 가능한 상태는 다음과 같습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/SSRS.Monitor.html) |
| `task_info` | 작업에 대한 추가 정보입니다. 처리 중에 오류가 발생하면 이 열에 오류 정보가 포함됩니다. |
| `last_updated` | 작업 상태를 마지막으로 업데이트한 날짜와 시간입니다. |
| `created_at` | 작업을 생성한 날짜와 시간입니다. |
| `S3_object_arn` | SSRS 작업에는 적용되지 않습니다. |
| `overwrite_S3_backup_file` | SSRS 작업에는 적용되지 않습니다. |
| `KMS_master_key_arn` | SSRS 작업에는 적용되지 않습니다. |
| `filepath` | SSRS 작업에는 적용되지 않습니다. |
| `overwrite_file` | SSRS 작업에는 적용되지 않습니다. |
| `task_metadata` | SSRS 작업과 관련된 메타데이터입니다. |
# SSRS 데이터베이스 비활성화 및 삭제
다음 절차에 따라 SSRS를 비활성화하고 SSRS 데이터베이스를 삭제합니다.
**Topics**
+ [SSRS 해제](#SSRS.Disable)
+ [SSRS 데이터베이스 삭제](#SSRS.Drop)
## SSRS 해제
SSRS를 해제하려면 해당 옵션 그룹에서 `SSRS` 옵션을 제거합니다. 이 옵션을 제거해도 SSRS 데이터베이스는 삭제되지 않습니다. 자세한 내용은 [SSRS 데이터베이스 삭제](#SSRS.Drop)을 참조하세요.
`SSRS` 옵션을 다시 추가하여 SSRS를 다시 켤 수 있어야 합니다. SSRS 데이터베이스도 삭제한 경우 동일한 DB 인스턴스에서 옵션을 읽으면 새 보고서 서버 데이터베이스가 생성됩니다.
### 콘솔
**옵션 그룹에서 SSRS 옵션을 제거하려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **옵션 그룹**을 선택합니다.
1. `SSRS` 옵션이 있는 옵션 그룹을 선택합니다(이전 예제의 경우 `ssrs-se-2017`).
1. **옵션 삭제**를 선택합니다.
1. **옵션 삭제**에서 **SSRS** 또는 **삭제할 옵션**을 선택합니다.
1. **즉시 적용**에서 옵션을 즉시 삭제하려면 **예**를 선택하고 다음 유지 관리 기간에 삭제하려면 **아니오**를 선택합니다.
1. **Delete**(삭제)를 선택합니다.
### CLI
**옵션 그룹에서 SSRS 옵션을 제거하려면**
+ 다음 명령 중 하나를 실행합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds remove-option-from-option-group \
--option-group-name ssrs-se-2017 \
--options SSRS \
--apply-immediately
```
Windows의 경우:
```
aws rds remove-option-from-option-group ^
--option-group-name ssrs-se-2017 ^
--options SSRS ^
--apply-immediately
```
## SSRS 데이터베이스 삭제
`SSRS` 옵션을 제거해도 보고서 서버 데이터베이스는 삭제되지 않습니다. 삭제하려면 다음 저장 프로시저를 사용합니다.
보고서 서버 데이터베이스를 삭제하려면 먼저 `SSRS` 옵션을 제거해야 합니다.
**SSRS 데이터베이스를 삭제하려면**
+ 다음 저장 프로시저를 사용합니다.
```
exec msdb.dbo.rds_drop_ssrs_databases
```
# RDS for SQL Server에서 Microsoft Distributed Transaction Coordinator 지원
*분산 트랜잭션*은 두 개 이상의 네트워크 호스트가 관련된 데이터베이스 트랜잭션입니다. RDS for SQL Server는 호스트 간의 분산 트랜잭션을 지원하며 여기서 단일 호스트는 다음 중 하나일 수 있습니다.
+ RDS for SQL Server DB 인스턴스
+ 온프레미스 SQL Server 호스트
+ SQL Server가 설치된 Amazon EC2 호스트
+ 분산 트랜잭션을 지원하는 데이터베이스 엔진이 있는 기타 EC2 호스트 또는 RDS DB 인스턴스
RDS에서는 SQL Server 2012(버전 11.00.5058.0.v1 이상)부터 모든 에디션의 RDS for SQL Server에서 분산 트랜잭션을 지원합니다. Microsoft Distributed Transaction Coordinator(MSDTC)를 사용하여 지원이 제공됩니다. MSDTC에 대한 자세한 내용은 Microsoft 설명서에서 [Distributed Transaction Coordinator](https://docs.microsoft.com/en-us/previous-versions/windows/desktop/ms684146(v=vs.85))를 참조하세요.
**Contents**
+ [제한 사항](#Appendix.SQLServer.Options.MSDTC.Limitations)
+ [MSDTC 활성화](Appendix.SQLServer.Options.MSDTC.Enabling.md)
+ [MSDTC용 옵션 그룹 생성](Appendix.SQLServer.Options.MSDTC.Enabling.md#Appendix.SQLServer.Options.MSDTC.OptionGroup)
+ [옵션 그룹에 MSDTC 옵션 추가](Appendix.SQLServer.Options.MSDTC.Enabling.md#Appendix.SQLServer.Options.MSDTC.Add)
+ [MSDTC용 파라미터 그룹 생성](Appendix.SQLServer.Options.MSDTC.Enabling.md#MSDTC.CreateParamGroup)
+ [MSDTC에 대한 파라미터 수정](Appendix.SQLServer.Options.MSDTC.Enabling.md#ModifyParam.MSDTC)
+ [옵션 그룹 및 파라미터 그룹을 DB 인스턴스와 연결](Appendix.SQLServer.Options.MSDTC.Enabling.md#MSDTC.Apply)
+ [MSDTC 옵션 수정](Appendix.SQLServer.Options.MSDTC.Enabling.md#Appendix.SQLServer.Options.MSDTC.Modify)
+ [트랜잭션 사용](#Appendix.SQLServer.Options.MSDTC.Using)
+ [분산 트랜잭션 사용](#Appendix.SQLServer.Options.MSDTC.UsingXA)
+ [XA 트랜잭션 사용](#MSDTC.XA)
+ [트랜잭션 추적 사용](#MSDTC.Tracing)
+ [MSDTC 비활성화](Appendix.SQLServer.Options.MSDTC.Disable.md)
+ [RDS for SQL Server에 대한 MSDTC 문제 해결](Appendix.SQLServer.Options.MSDTC.Troubleshooting.md)
## 제한 사항
RDS for SQL Server에서 MSDTC를 사용하는 경우 다음과 같은 제한 사항이 적용됩니다.
+ SQL Server 데이터베이스 미러링을 사용하는 인스턴스에서는 MSDTC가 지원되지 않습니다. 자세한 내용은 [트랜잭션 - 가용성 그룹 및 데이터베이스 미러링](https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/transactions-always-on-availability-and-database-mirroring?view=sql-server-ver15#non-support-for-distributed-transactions)을 참조하십시오.
+ `in-doubt xact resolution` 파라미터를 1 또는 2로 설정해야 합니다. 자세한 내용은 [MSDTC에 대한 파라미터 수정](Appendix.SQLServer.Options.MSDTC.Enabling.md#ModifyParam.MSDTC) 단원을 참조하세요.
+ MSDTC에서는 분산 트랜잭션에 참여하는 모든 호스트를 호스트 이름을 사용하여 확인할 수 있어야 합니다. RDS는 도메인에 가입된 인스턴스에 대해 이 기능을 자동으로 유지 관리합니다. 그러나 독립 실행형 인스턴스의 경우 DNS 서버를 수동으로 구성해야 합니다.
+ Java Database Connectivity(JDBC) XA 트랜잭션은 SQL Server 2017 버전 14.00.3223.3 이상 및 SQL Server 2019에서 지원됩니다.
+ RDS 인스턴스의 클라이언트 동적 연결 라이브러리(DLL)를 사용하는 분산 트랜잭션은 지원되지 않습니다.
+ 사용자 지정 XA 동적 연결 라이브러리 사용은 지원되지 않습니다.
# MSDTC 활성화
DB 인스턴스에 MSDTC를 활성화하려면 다음 프로세스를 사용합니다.
1. 새 옵션 그룹을 생성하거나 기존 옵션 그룹을 선택합니다.
1. [`MSDTC`] 옵션을 옵션 그룹에 추가합니다.
1. 새 파라미터 그룹을 생성하거나 기존 파라미터 그룹을 선택합니다.
1. 파라미터 그룹을 수정하여 `in-doubt xact resolution` 파라미터를 1 또는 2로 설정합니다.
1. 옵션 그룹 및 파라미터 그룹을 DB 인스턴스와 연결합니다.
## MSDTC용 옵션 그룹 생성
AWS Management Console 또는 AWS CLI를 사용하여 SQL Server 엔진과 DB 인스턴스 버전에 해당하는 옵션 그룹을 생성합니다.
**참고**
올바른 SQL Server 엔진 및 버전인 경우 기존 옵션 그룹을 사용할 수도 있습니다.
### 콘솔
다음 절차에서는 SQL Server Standard Edition 2016에 대한 옵션 그룹을 생성합니다.
**옵션 그룹을 생성하려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **옵션 그룹**을 선택합니다.
1. **그룹 생성**을 선택합니다.
1. **보안 그룹 생성** 창에서 다음을 수행합니다.
1. [**이름(Name)**]에 AWS 계정 내에서 쉽게 식별할 수 있는 옵션 그룹 이름을 입력합니다(예: **msdtc-se-2016**). 이름은 글자, 숫자 및 하이픈만 사용 가능합니다.
1. **설명**에 옵션 그룹에 대한 간단한 설명을 입력합니다(예: **MSDTC option group for SQL Server SE 2016**). 이 설명은 표시 용도로만 사용됩니다.
1. **엔진**에 대해 **sqlserver-se**를 선택합니다.
1. **메이저 엔진 버전**에 **13.00**을 선택합니다.
1. **생성(Create)**을 선택합니다.
### CLI
다음 예에서는 SQL Server Standard Edition 2016에 대한 옵션 그룹을 생성합니다.
**옵션 그룹을 생성하려면**
+ 다음 명령 중 하나를 사용합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds create-option-group \
--option-group-name msdtc-se-2016 \
--engine-name sqlserver-se \
--major-engine-version 13.00 \
--option-group-description "MSDTC option group for SQL Server SE 2016"
```
Windows의 경우:
```
aws rds create-option-group ^
--option-group-name msdtc-se-2016 ^
--engine-name sqlserver-se ^
--major-engine-version 13.00 ^
--option-group-description "MSDTC option group for SQL Server SE 2016"
```
## 옵션 그룹에 MSDTC 옵션 추가
그런 다음 AWS Management Console 또는 AWS CLI를 사용하여 `MSDTC` 옵션을 옵션 그룹에 추가합니다.
다음 옵션 설정이 필요합니다.
+ **포트** – MSDTC에 액세스하는 데 사용하는 포트입니다. 허용되는 값은 1150–49151(1234, 1434, 3260, 3343, 3389, 47001 제외)입니다. 기본값은 5000입니다.
사용하려는 포트가 방화벽 규칙에서 활성화되어 있는지 확인합니다. 또한 필요에 따라 DB 인스턴스와 연결된 보안 그룹의 인바운드 및 아웃바운드 규칙에서 이 포트를 활성화해야 합니다. 자세한 내용은 [Amazon RDS DB 인스턴스에 연결할 수 없음](CHAP_Troubleshooting.md#CHAP_Troubleshooting.Connecting) 단원을 참조하세요.
+ **보안 그룹** – RDS DB 인스턴스에 대한 VPC 보안 그룹 멤버십입니다.
+ **인증 유형** – 호스트 간의 인증 모드입니다. 지원되는 인증 유형은 다음과 같습니다.
+ 상호 – RDS 인스턴스가 통합 인증을 사용하여 상호 인증됩니다. 이 옵션을 선택하는 경우 이 옵션 그룹과 연결된 모든 인스턴스가 도메인에 가입되어 있어야 합니다.
+ 없음 – 호스트 간에 인증이 수행되지 않습니다. 프로덕션 환경에서는 이 모드를 사용하지 않는 것이 좋습니다.
+ **트랜잭션 로그 크기** – MSDTC 트랜잭션 로그의 크기입니다. 허용되는 값은 4–1024MB입니다. 기본 크기는 4MB입니다.
다음 옵션 설정은 선택 사항입니다.
+ **인바운드 연결 활성화** – 이 옵션 그룹과 연결된 인스턴스로의 인바운드 MSDTC 연결을 허용할지 여부를 지정합니다.
+ **아웃바운드 연결 활성화** – 이 옵션 그룹과 연결된 인스턴스로부터의 아웃바운드 MSDTC 연결을 허용할지 여부를 지정합니다.
+ **XA 활성화** – XA 트랜잭션을 허용할지 여부를 지정합니다 . XA 프로토콜에 대한 자세한 내용은 [XA 사양](https://publications.opengroup.org/c193)을 참조하세요.
+ **SNA LU 활성화** – 분산 트랜잭션에 SNA LU 프로토콜을 사용하도록 허용할지 여부를 지정합니다. SNA LU 프로토콜 지원에 대한 자세한 내용은 Microsoft 설명서의 [IBM CICS LU 6.2 트랜잭션 관리](https://docs.microsoft.com/en-us/previous-versions/windows/desktop/ms685136(v=vs.85))를 참조하세요.
### 콘솔
**MSDTC 옵션을 추가하려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **옵션 그룹**을 선택합니다.
1. 방금 생성한 옵션 그룹을 선택합니다.
1. **옵션 추가**를 선택합니다.
1. **옵션 세부 정보**에서 **옵션 이름**으로 **MSDTC**를 선택합니다.
1. **옵션 설정**에서 다음을 수행합니다.
1. **포트**에 MSDTC에 액세스하는 데 사용할 포트 번호를 입력합니다. 기본값은 **5000**입니다.
1. **보안 그룹**의 경우 옵션과 연결할 VPC 보안 그룹을 선택합니다.
1. **인증 유형**에서 **상호** 또는 **없음**을 선택합니다.
1. **트랜잭션 로그 크기**에 4–1024 사이의 값을 입력합니다. 기본값은 **4**입니다.
1. **추가 구성**에서 다음을 수행합니다.
1. **연결**에서 필요에 따라 **인바운드 연결 활성화** 및 **아웃바운드 연결 활성화**를 선택합니다.
1. **허용된 프로토콜**에서 필요에 따라 **XA 활성화** 및 **SNA LU 활성화**를 선택합니다.
1. **예약**에서 옵션을 즉시 추가할지 또는 다음 유지 관리 기간에 추가할지를 선택합니다.
1. **옵션 추가**를 선택합니다.
이 옵션을 추가하는 데 재부팅은 필요하지 않습니다.
### CLI
**MSDTC 옵션을 추가하려면**
1. 다음 필수 파라미터를 사용하여 JSON 파일(예: `msdtc-option.json`)을 생성합니다.
```
{
"OptionGroupName":"msdtc-se-2016",
"OptionsToInclude": [
{
"OptionName":"MSDTC",
"Port":5000,
"VpcSecurityGroupMemberships":["sg-0abcdef123"],
"OptionSettings":[{"Name":"AUTHENTICATION","Value":"MUTUAL"},{"Name":"TRANSACTION_LOG_SIZE","Value":"4"}]
}],
"ApplyImmediately": true
}
```
1. [`MSDTC`] 옵션을 옵션 그룹에 추가합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds add-option-to-option-group \
--cli-input-json file://msdtc-option.json \
--apply-immediately
```
Windows의 경우:
```
aws rds add-option-to-option-group ^
--cli-input-json file://msdtc-option.json ^
--apply-immediately
```
재부팅이 필요하지 않습니다.
## MSDTC용 파라미터 그룹 생성
DB 인스턴스의 SQL Server 에디션 및 버전에 해당하는 `in-doubt xact resolution` 파라미터의 파라미터 그룹을 생성하거나 수정합니다.
### 콘솔
다음 예에서는 SQL Server Standard Edition 2016에 대한 파라미터 그룹을 생성합니다.
**파라미터 그룹을 생성하려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **파라미터 그룹**을 선택합니다.
1. [**Create parameter group**]을 선택합니다.
1. **서브넷 그룹 생성** 창에서 다음을 수행합니다.
1. **파라미터 그룹 패밀리**에서 **sqlserver-se-13.0**을 선택합니다.
1. **그룹 이름**에 파라미터 그룹의 식별자(예: **msdtc-sqlserver-se-13**)를 입력합니다.
1. **설명**에 **in-doubt xact resolution**를 입력합니다.
1. **생성(Create)**을 선택합니다.
### CLI
다음 예에서는 SQL Server Standard Edition 2016에 대한 파라미터 그룹을 생성합니다.
**파라미터 그룹을 생성하려면**
+ 다음 명령 중 하나를 사용합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds create-db-parameter-group \
--db-parameter-group-name msdtc-sqlserver-se-13 \
--db-parameter-group-family "sqlserver-se-13.0" \
--description "in-doubt xact resolution"
```
Windows의 경우:
```
aws rds create-db-parameter-group ^
--db-parameter-group-name msdtc-sqlserver-se-13 ^
--db-parameter-group-family "sqlserver-se-13.0" ^
--description "in-doubt xact resolution"
```
## MSDTC에 대한 파라미터 수정
SQL Server 에디션 및 DB 인스턴스의 버전에 해당하는 파라미터 그룹의 `in-doubt xact resolution` 파라미터를 수정합니다.
MSDTC에 대해 `in-doubt xact resolution` 파라미터를 다음 중 하나로 설정합니다.
+ `1` - `Presume commit` 모든 MSDTC 미결 트랜잭션을 커밋된 것으로 가정합니다.
+ `2` - `Presume abort` 모든 MSDTC 미결 트랜잭션을 중지된 것으로 가정합니다.
자세한 내용은 Microsoft 설명서의 [in-doubt xact resolution 서버 구성 옵션](https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/in-doubt-xact-resolution-server-configuration-option)을 참조하세요.
### 콘솔
다음 예에서는 SQL Server Standard Edition 2016에 대해 생성한 파라미터 그룹을 수정합니다.
**파라미터 그룹을 수정하려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **파라미터 그룹**을 선택합니다.
1. 파라미터 그룹(예: **msdtc-sqlserver-se-13**)을 선택합니다.
1. **파라미터**에서 파라미터 목록을 **xact**로 필터링합니다.
1. **in-doubt xact resolution**을 선택합니다.
1. **파라미터 편집**을 선택합니다.
1. **1** 또는 **2**를 입력합니다.
1. **Save changes**(변경 사항 저장)를 선택합니다.
### CLI
다음 예에서는 SQL Server Standard Edition 2016에 대해 생성한 파라미터 그룹을 수정합니다.
**파라미터 그룹을 수정하려면**
+ 다음 명령 중 하나를 사용합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds modify-db-parameter-group \
--db-parameter-group-name msdtc-sqlserver-se-13 \
--parameters "ParameterName='in-doubt xact resolution',ParameterValue=1,ApplyMethod=immediate"
```
Windows의 경우:
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name msdtc-sqlserver-se-13 ^
--parameters "ParameterName='in-doubt xact resolution',ParameterValue=1,ApplyMethod=immediate"
```
## 옵션 그룹 및 파라미터 그룹을 DB 인스턴스와 연결
AWS Management Console 또는 AWS CLI를 사용하여 MSDTC 옵션 그룹 및 파라미터 그룹을 DB 인스턴스와 연결할 수 있습니다.
### 콘솔
MSDTC 옵션 그룹 및 파라미터 그룹을 새 DB 인스턴스 또는 기존 DB 인스턴스와 연결할 수 있습니다.
+ 새 DB 인스턴스의 경우 인스턴스를 시작할 때 이러한 그룹을 연결합니다. 자세한 내용은 [Amazon RDS DB 인스턴스 생성](USER_CreateDBInstance.md) 섹션을 참조하세요.
+ 기존 DB 인스턴스의 경우 인스턴스를 수정하여 그룹을 연결합니다. 자세한 내용은 [Amazon RDS DB 인스턴스 수정](Overview.DBInstance.Modifying.md) 섹션을 참조하세요.
**참고**
도메인에 가입된 기존 DB 인스턴스를 사용하는 경우 이미 Active Directory 도메인과 AWS Identity and Access Management(IAM) 역할이 연결되어 있어야 합니다. 도메인에 가입된 새 인스턴스를 생성하는 경우 기존 Active Directory 도메인 및 IAM 역할을 지정합니다. 자세한 내용은 [RDS for SQL Server를 사용하여 AWS 관리형 Active Directory 작업](USER_SQLServerWinAuth.md) 단원을 참조하세요.
### CLI
MSDTC 옵션 그룹 및 파라미터 그룹을 새 DB 인스턴스 또는 기존 DB 인스턴스와 연결할 수 있습니다.
**참고**
도메인에 가입된 기존 DB 인스턴스를 사용하는 경우 이미 Active Directory 도메인과 IAM 역할이 연결되어 있어야 합니다. 도메인에 가입된 새 인스턴스를 생성하는 경우 기존 Active Directory 도메인 및 IAM 역할을 지정합니다. 자세한 내용은 [RDS for SQL Server를 사용하여 AWS 관리형 Active Directory 작업](USER_SQLServerWinAuth.md) 섹션을 참조하세요.
**MSDTC 옵션 그룹 및 파라미터 그룹과 함께 DB 인스턴스를 생성하려면**
+ 옵션 그룹을 생성할 때 사용한 것과 동일한 DB 엔진 유형과 메이저 버전을 지정합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds create-db-instance \
--db-instance-identifier mydbinstance \
--db-instance-class db.m5.2xlarge \
--engine sqlserver-se \
--engine-version 13.00.5426.0.v1 \
--allocated-storage 100 \
--manage-master-user-password \
--master-username admin \
--storage-type gp2 \
--license-model li \
--domain-iam-role-name my-directory-iam-role \
--domain my-domain-id \
--option-group-name msdtc-se-2016 \
--db-parameter-group-name msdtc-sqlserver-se-13
```
Windows의 경우:
```
aws rds create-db-instance ^
--db-instance-identifier mydbinstance ^
--db-instance-class db.m5.2xlarge ^
--engine sqlserver-se ^
--engine-version 13.00.5426.0.v1 ^
--allocated-storage 100 ^
--manage-master-user-password ^
--master-username admin ^
--storage-type gp2 ^
--license-model li ^
--domain-iam-role-name my-directory-iam-role ^
--domain my-domain-id ^
--option-group-name msdtc-se-2016 ^
--db-parameter-group-name msdtc-sqlserver-se-13
```
**DB 인스턴스를 수정하고 MSDTC 옵션 그룹 및 파라미터 그룹을 연결하려면**
+ 다음 명령 중 하나를 사용합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds modify-db-instance \
--db-instance-identifier mydbinstance \
--option-group-name msdtc-se-2016 \
--db-parameter-group-name msdtc-sqlserver-se-13 \
--apply-immediately
```
Windows의 경우:
```
aws rds modify-db-instance ^
--db-instance-identifier mydbinstance ^
--option-group-name msdtc-se-2016 ^
--db-parameter-group-name msdtc-sqlserver-se-13 ^
--apply-immediately
```
## MSDTC 옵션 수정
`MSDTC` 옵션을 활성화한 후 해당 설정을 수정할 수 있습니다. 옵션 설정을 변경하는 방법에 대한 자세한 내용은 [옵션 설정 수정](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.ModifyOption) 단원을 참조하십시오.
**참고**
MSDTC 옵션 설정을 일부 변경하려면 MSDTC 서비스를 다시 시작해야 합니다. 이 요구 사항은 분산 트랜잭션 실행에 영향을 줄 수 있습니다.
## 트랜잭션 사용
### 분산 트랜잭션 사용
Amazon RDS for SQL Server에서는 온프레미스에서 실행되는 분산 트랜잭션과 동일한 방식으로 분산 트랜잭션을 실행합니다.
+ .NET Framework `System.Transactions` 승격 가능한 트랜잭션 사용. 이를 통해 필요할 때까지 생성을 연기함으로써 분산 트랜잭션을 최적화합니다.
이 경우 승격이 자동으로 수행되므로 사용자가 개입할 필요가 없습니다. 트랜잭션 내에 하나의 리소스 관리자만 있는 경우 승격이 수행되지 않습니다. 암시적 트랜잭션 범위에 대한 자세한 내용은 Microsoft 설명서의 [트랜잭션 범위를 사용하여 암시적 트랜잭션 구현](https://docs.microsoft.com/en-us/dotnet/framework/data/transactions/implementing-an-implicit-transaction-using-transaction-scope)을 참조하십시오.
승격 가능 트랜잭션은 다음 .NET 구현에서 지원됩니다.
+ ADO.NET 2.0부터 `System.Data.SqlClient`는 SQL Server를 사용하여 승격 가능한 트랜잭션을 지원합니다. 자세한 내용은 Microsoft 설명서에서 [SQL Server와의 System.Transactions 통합](https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/system-transactions-integration-with-sql-server)을 참조하십시오.
+ ODP.NET은 `System.Transactions`를 지원합니다. Oracle Database 11g 릴리스 1(버전 11.1) 이상에서 `TransactionsScope` 범위에서 열린 첫 번째 연결에 대해 로컬 트랜잭션이 생성됩니다. 두 번째 연결이 열리면 이 트랜잭션이 분산 트랜잭션으로 자동 승격됩니다. ODP.NET에서 분산 트랜잭션 지원에 대한 자세한 내용은 Microsoft 설명서의 [Microsoft Distributed Transaction Coordinator 통합](https://docs.oracle.com/en/database/oracle/oracle-data-access-components/18.3/ntmts/using-mts-with-oracledb.html)을 참조하십시오.
+ `BEGIN DISTRIBUTED TRANSACTION` 문 사용. 자세한 내용은 Microsoft 설명서의 [BEGIN DISTRIBUTED TRANSACTION(Transact-SQL)](https://docs.microsoft.com/en-us/sql/t-sql/language-elements/begin-distributed-transaction-transact-sql)을 참조하세요.
### XA 트랜잭션 사용
RDS for SQL Server 2017 버전 14.00.3223.3부터 JDBC를 사용하여 분산 트랜잭션을 제어할 수 있습니다. `Enable XA` 옵션 설정을 `true` 옵션의 `MSDTC`(으)로 설정하면 RDS가 자동으로 JDBC 트랜잭션을 활성화하고 `SqlJDBCXAUser` 역할을 `guest` 사용자에게 부여합니다. 이를 통해 JDBC를 통해 분산 트랜잭션을 실행할 수 있습니다. 코드 예제를 포함한 자세한 정보는 Microsoft 설명서의 [XA 트랜잭션 이해](https://docs.microsoft.com/en-us/sql/connect/jdbc/understanding-xa-transactions)를 참조하세요.
### 트랜잭션 추적 사용
RDS는 문제 해결을 위해 MSDTC 트랜잭션 추적을 제어하고 RDS DB 인스턴스에서 해당 추적을 다운로드할 수 있도록 지원합니다. 다음 RDS 저장 프로시저를 실행하여 트랜잭션 추적 세션을 제어할 수 있습니다.
```
exec msdb.dbo.rds_msdtc_transaction_tracing 'trace_action',
[@traceall='0|1'],
[@traceaborted='0|1'],
[@tracelong='0|1'];
```
다음 파라미터는 필수입니다.
+ `trace_action` – 추적 작업입니다. `START`, `STOP` 또는 `STATUS`일 수 있습니다.
다음 파라미터는 선택적입니다.
+ `@traceall` – 모든 분산 트랜잭션을 추적하려면 1로 설정합니다. 기본값은 0입니다.
+ `@traceaborted` – 취소된 분산 트랜잭션을 추적하려면 1로 설정합니다. 기본값은 0입니다.
+ `@tracelong` – 장기 실행 분산 트랜잭션을 추적하려면 1로 설정합니다. 기본값은 0입니다.
**Example START 추적 작업**
새 트랜잭션 추적 세션을 시작하려면 다음 예에 나온 문을 실행합니다.
```
exec msdb.dbo.rds_msdtc_transaction_tracing 'START',
@traceall='0',
@traceaborted='1',
@tracelong='1';
```
한 번에 하나의 트랜잭션 추적 세션만 활성화할 수 있습니다. 추적 세션이 활성 상태일 때 새 추적 세션 `START` 명령이 실행되면 오류가 반환되고 활성 추적 세션이 변경되지 않습니다.
**Example STOP 추적 작업**
트랜잭션 추적 세션을 중지하려면 다음 문을 실행합니다.
```
exec msdb.dbo.rds_msdtc_transaction_tracing 'STOP'
```
이 문은 활성 트랜잭션 추적 세션을 중지하고 트랜잭션 추적 데이터를 RDS DB 인스턴스의 로그 디렉터리에 저장합니다. 출력의 첫 번째 행에는 전체 결과가 포함되며 다음 줄은 작업의 세부 정보를 나타냅니다.
다음은 성공적인 추적 세션 중지의 예입니다.
```
OK: Trace session has been successfully stopped.
Setting log file to: D:\rdsdbdata\MSDTC\Trace\dtctrace.log
Examining D:\rdsdbdata\MSDTC\Trace\msdtctr.mof for message formats, 8 found.
Searching for TMF files on path: (null)
Logfile D:\rdsdbdata\MSDTC\Trace\dtctrace.log:
OS version 10.0.14393 (Currently running on 6.2.9200)
Start Time
End Time
Timezone is @tzres.dll,-932 (Bias is 0mins)
BufferSize 16384 B
Maximum File Size 10 MB
Buffers Written Not set (Logger may not have been stopped).
Logger Mode Settings (11000002) ( circular paged
ProcessorCount 1
Processing completed Buffers: 1, Events: 3, EventsLost: 0 :: Format Errors: 0, Unknowns: 3
Event traces dumped to d:\rdsdbdata\Log\msdtc_.log
```
세부 정보를 사용하여 생성된 로그 파일의 이름을 쿼리할 수 있습니다. RDS DB 인스턴스에서 로그 파일을 다운로드하는 방법에 대한 자세한 내용은 [Amazon RDS 로그 파일 모니터링](USER_LogAccess.md) 단원을 참조하십시오.
추적 세션 로그는 35일 동안 인스턴스에 남아 있습니다. 이전 추적 세션 로그는 자동으로 삭제됩니다.
**Example STATUS 추적 작업**
트랜잭션 추적 세션의 상태를 추적하려면 다음 문을 실행합니다.
```
exec msdb.dbo.rds_msdtc_transaction_tracing 'STATUS'
```
이 문은 결과 집합의 별도 행으로 다음을 출력합니다.
```
OK
SessionStatus:
TraceAll:
TraceAborted:
TraceLongLived:
```
첫 번째 줄은 작업의 전체 결과(`OK` 또는 `ERROR`)와 함께 세부 정보(해당되는 경우)를 나타냅니다. 그 다음 줄에는 추적 세션 상태에 대한 세부 정보가 표시됩니다.
+ `SessionStatus`의 값은 다음 중 하나일 수 있습니다.
+ `Started` - 추적 세션이 실행 중인 경우.
+ `Stopped` - 실행 중인 추적 세션이 없는 경우.
+ 추적 세션 플래그는 `True` 명령에서 설정된 방법에 따라 `False` 또는 `START`일 수 있습니다.
# MSDTC 비활성화
MSDTC를 비활성화하려면 해당 옵션 그룹에서 `MSDTC` 옵션을 제거합니다.
## 콘솔
**옵션 그룹에서 MSDTC 옵션을 제거하려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **옵션 그룹**을 선택합니다.
1. `MSDTC` 옵션이 있는 옵션 그룹을 선택합니다(이전 예제의 경우 `msdtc-se-2016`).
1. **옵션 삭제**를 선택합니다.
1. **옵션 삭제**에서 **MSDTC** 또는 **삭제할 옵션**을 선택합니다.
1. **즉시 적용**에서 옵션을 즉시 삭제하려면 **예**를 선택하고 다음 유지 관리 기간에 삭제하려면 **아니오**를 선택합니다.
1. **Delete**(삭제)를 선택합니다.
## CLI
**옵션 그룹에서 MSDTC 옵션을 제거하려면**
+ 다음 명령 중 하나를 사용합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds remove-option-from-option-group \
--option-group-name msdtc-se-2016 \
--options MSDTC \
--apply-immediately
```
Windows의 경우:
```
aws rds remove-option-from-option-group ^
--option-group-name msdtc-se-2016 ^
--options MSDTC ^
--apply-immediately
```
# RDS for SQL Server에 대한 MSDTC 문제 해결
경우에 따라 클라이언트 컴퓨터에서 실행되는 MSDTC와 RDS for SQL Server DB 인스턴스에서 실행되는 MSDTC 서비스 간에 연결을 설정하는 데 문제가 있을 수 있습니다. 그 경우 다음을 확인하십시오.
+ DB 인스턴스와 연결된 보안 그룹의 인바운드 규칙이 올바르게 구성되어 있는지. 자세한 내용은 [Amazon RDS DB 인스턴스에 연결할 수 없음](CHAP_Troubleshooting.md#CHAP_Troubleshooting.Connecting) 섹션을 참조하세요.
+ 클라이언트 컴퓨터가 올바르게 구성되어 있는지.
+ 클라이언트 컴퓨터에서 MSDTC 방화벽 규칙이 활성화되어 있는지.
**클라이언트 컴퓨터를 구성하려면**
1. **구성 요소 서비스**를 엽니다.
또는 **서버 관리자**에서 **도구**를 선택한 다음 **구성 요소 서비스**를 선택합니다.
1. **구성 요소 서비스**, **컴퓨터**, **내 컴퓨터**, **Distributed Transaction Coordinator**를 차례로 확장합니다.
1. **로컬 DTC**에 대한 컨텍스트 메뉴를 열고(마우스 오른쪽 버튼 클릭) **속성**을 선택합니다.
1. **보안** 탭을 선택합니다.
1. 다음을 모두 선택합니다.
+ **네트워크 DTC 액세스**
+ **인바운드 허용**
+ **아웃바운드 허용**
1. 올바른 인증 모드가 선택되어 있는지 확인합니다.
+ **상호 인증 필요** – 클라이언트 시스템이 분산 트랜잭션에 참여하는 다른 노드와 동일한 도메인에 가입되었거나 도메인 간에 신뢰 관계가 구성되어 있습니다.
+ **인증 필요 없음** – 다른 모든 경우.
1. **확인**을 선택하여 변경 사항을 저장합니다.
1. 서비스를 다시 시작하라는 메시지가 표시되면 **예**를 선택합니다.
**MSDTC 방화벽 규칙을 활성화하려면**
1. Windows 방화벽을 연 다음 **고급 설정**을 선택합니다.
**서버 관리자**를 열고 **도구**, **Windows Firewall with Advanced Security**를 차례로 선택합니다.
**참고**
운영 체제에 따라 Windows 방화벽을 Windows Defender 방화벽이라고 할 수도 있습니다.
1. 왼쪽 창에서 **인바운드 규칙**을 선택합니다.
1. 다음 방화벽 규칙을 활성화합니다(아직 활성화되지 않은 경우).
+ **DTC(Distributed Transaction Coordinator)(RPC)**
+ **DTC(Distributed Transaction Coordinator)(RPC)-EPMAP**
+ **DTC(Distributed Transaction Coordinator)(TCP-In)**
1. Windows 방화벽을 닫습니다.
# RDS for SQL Server를 사용한 Microsoft SQL Server 리소스 관리
리소스 거버너는 인스턴스 리소스를 정확하게 제어할 수 있는 SQL Server Enterprise Edition 기능입니다. 이를 통해 워크로드가 CPU, 메모리 및 물리적 I/O 리소스를 사용하는 방식에 대한 특정 제한을 설정할 수 있습니다. 리소스 거버너를 사용하면 다음을 수행할 수 있습니다.
+ 다양한 워크로드가 인스턴스 리소스를 공유하는 방식을 관리하여 다중 테넌트 환경에서 리소스 독점 방지
+ 다양한 사용자 및 애플리케이션에 대한 특정 리소스 제한 및 우선 순위를 설정하여 예측 가능한 성능 제공
기존 또는 새 RDS for SQL Server DB 인스턴스에서 리소스 거버너를 활성화할 수 있습니다.
리소스 거버너는 세 가지 기본 개념을 사용합니다.
+ **리소스 풀** - 인스턴스 물리적 리소스(CPU, 메모리 및 I/O)를 관리하는 컨테이너입니다. 두 개의 기본 제공 풀(내부 및 기본)을 가져오고 추가 사용자 지정 풀을 생성할 수 있습니다.
+ **워크로드 그룹** - 특성이 유사한 데이터베이스 세션용 컨테이너입니다. 모든 워크로드 그룹은 리소스 풀에 속합니다. 두 개의 기본 제공 워크로드 그룹(내부 및 기본)을 가져오고 추가 사용자 지정 워크로드 그룹을 생성할 수 있습니다.
+ **분류** - 사용자 이름, 애플리케이션 이름, 데이터베이스 이름 또는 호스트 이름을 기반으로 수신 세션을 처리하는 워크로드 그룹을 결정하는 프로세스입니다.
SQL Server의 리소스 거버너에 대한 자세한 내용은 Microsoft 설명서의 [리소스 거버너](https://learn.microsoft.com/en-us/sql/relational-databases/resource-governor/resource-governor?view=sql-server-ver16)를 참조하세요.
**Contents**
+ [지원되는 버전 및 리전](#ResourceGovernor.SupportedVersions)
+ [제한 및 권장 사항](#ResourceGovernor.Limitations)
+ [RDS for SQL Server 인스턴스에 대한 Microsoft SQL Server 리소스 거버너 활성화](ResourceGovernor.Enabling.md)
+ [`RESOURCE_GOVERNOR`용 옵션 그룹 만들기](ResourceGovernor.Enabling.md#ResourceGovernor.OptionGroup)
+ [옵션 그룹에 `RESOURCE_GOVERNOR` 옵션 추가](ResourceGovernor.Enabling.md#ResourceGovernor.Add)
+ [옵션 그룹을 DB 인스턴스와 연결](ResourceGovernor.Enabling.md#ResourceGovernor.Apply)
+ [RDS for SQL Server 인스턴스에 Microsoft SQL Server 리소스 거버너 사용](ResourceGovernor.Using.md)
+ [리소스 풀 관리](ResourceGovernor.Using.md#ResourceGovernor.ManageResourcePool)
+ [리소스 풀 생성](ResourceGovernor.Using.md#ResourceGovernor.CreateResourcePool)
+ [리소스 풀 변경](ResourceGovernor.Using.md#ResourceGovernor.AlterResourcePool)
+ [리소스 풀 삭제](ResourceGovernor.Using.md#ResourceGovernor.DropResourcePool)
+ [워크로드 그룹 관리](ResourceGovernor.Using.md#ResourceGovernor.ManageWorkloadGroups)
+ [워크로드 그룹 생성](ResourceGovernor.Using.md#ResourceGovernor.CreateWorkloadGroup)
+ [워크로드 그룹 변경](ResourceGovernor.Using.md#ResourceGovernor.AlterWorkloadGroup)
+ [워크로드 그룹 삭제](ResourceGovernor.Using.md#ResourceGovernor.DropWorkloadGroup)
+ [분류기 함수 생성 및 등록](ResourceGovernor.Using.md#ResourceGovernor.ClassifierFunction)
+ [분류자 함수 삭제](ResourceGovernor.Using.md#ResourceGovernor.DropClassifier)
+ [분류자 함수 등록 취소](ResourceGovernor.Using.md#ResourceGovernor.DeregisterClassifier)
+ [통계 재설정](ResourceGovernor.Using.md#ResourceGovernor.ResetStats)
+ [리소스 거버너 구성 변경 사항](ResourceGovernor.Using.md#ResourceGovernor.ConfigChanges)
+ [TempDB를 리소스 풀에 바인딩](ResourceGovernor.Using.md#ResourceGovernor.BindTempDB)
+ [리소스 풀에서 TempDB 바인딩 해제](ResourceGovernor.Using.md#ResourceGovernor.UnbindTempDB)
+ [리소스 거버너 정리](ResourceGovernor.Using.md#ResourceGovernor.Cleanup)
+ [다중 AZ 배포에 대한 고려 사항](#ResourceGovernor.Considerations)
+ [읽기 전용 복제본에 대한 고려 사항](#ResourceGovernor.ReadReplica)
+ [RDS for SQL Server 인스턴스의 시스템 뷰를 사용하여 Microsoft SQL Server 리소스 거버너 모니터링](ResourceGovernor.Monitoring.md)
+ [리소스 풀 런타임 통계](ResourceGovernor.Monitoring.md#ResourceGovernor.ResourcePoolStats)
+ [RDS for SQL Server 인스턴스에 대한 Microsoft SQL Server 리소스 거버너 비활성화](ResourceGovernor.Disabling.md)
+ [RDS for SQL Server에서 리소스 거버너를 구성하는 모범 사례](ResourceGovernor.BestPractices.md)
## 지원되는 버전 및 리전
Amazon RDS는 RDS for SQL Server를 사용할 수 있는 모든 AWS 리전에서 다음 SQL Server 버전 및 에디션에 대한 리소스 조절을 지원합니다.
+ SQL Server 2022 Developer Edition 및 Enterprise Edition
+ SQL Server 2019 Enterprise Edition
+ SQL Server 2017 Enterprise Edition
+ SQL Server 2016 Enterprise Edition
## 제한 및 권장 사항
리소스 거버너에는 다음과 같은 제한 사항 및 권장 사항이 적용됩니다.
+ 에디션 및 서비스 제한:
+ SQL Server Enterprise Edition에서만 사용할 수 있습니다.
+ 리소스 관리는 SQL Server 데이터베이스 엔진으로 제한됩니다. 분석 서비스, 통합 서비스 및 보고 서비스에 대한 리소스 거버너는 지원되지 않습니다.
+ 구성 제한:
+ 모든 구성에 Amazon RDS 저장 프로시저를 사용해야 합니다.
+ 기본 DDL 문 및 SQL Server Management Studio GUI 구성은 지원되지 않습니다.
+ 리소스 풀 파라미터:
+ `rds_`로 시작하는 풀 이름은 지원되지 않습니다.
+ 내부 및 기본 리소스 풀 수정은 허용되지 않습니다.
+ 사용자 정의 리소스 풀의 경우 다음 리소스 풀 파라미터는 지원되지 않습니다.
+ `MIN_MEMORY_PERCENT`
+ `MIN_CPU_PERCENT`
+ `MIN_IOPS_PER_VOLUME`
+ `AFFINITY`
+ 워크로드 그룹 파라미터:
+ `rds_`로 시작하는 워크로드 그룹 이름은 지원되지 않습니다.
+ 내부 워크로드 그룹 수정은 허용되지 않습니다.
+ 기본 워크로드 그룹의 경우:
+ `REQUEST_MAX_MEMORY_GRANT_PERCENT` 파라미터만 수정할 수 있습니다.
+ 기본 워크로드 그룹의 경우 `REQUEST_MAX_MEMORY_GRANT_PERCENT`는 1에서 70 사이여야 합니다.
+ 다른 모든 파라미터는 잠겨 있으며 변경할 수 없습니다.
+ 사용자 정의 워크로드 그룹을 사용하면 모든 파라미터를 수정할 수 있습니다.
+ 분류자 함수 제한 사항:
+ 분류자 함수는 지정된 기준(사용자 이름, 데이터베이스, 호스트 또는 애플리케이션 이름)에 따라 사용자 지정 워크로드 그룹에 연결을 라우팅합니다.
+ 각 라우팅 조건에서 최대 2개의 사용자 정의 워크로드 그룹을 지원합니다.
+ 기준을 각 그룹 내의 `AND` 조건과 결합합니다.
+ 워크로드 그룹당 하나 이상의 라우팅 기준이 필요합니다.
+ 위에 나열된 분류 방법만 지원됩니다.
+ 함수 이름은 `rg_classifier_`로 시작해야 합니다.
+ 일치하는 조건이 없는 경우 기본 그룹 할당입니다.
# RDS for SQL Server 인스턴스에 대한 Microsoft SQL Server 리소스 거버너 활성화
RDS for SQL Server DB 인스턴스에 `RESOURCE_GOVERNOR` 옵션을 추가하여 리소스 거버너를 활성화합니다. 다음 프로세스를 사용합니다.
1. 새 옵션 그룹을 생성하거나 기존 옵션 그룹을 선택합니다.
1. [`RESOURCE_GOVERNOR`] 옵션을 옵션 그룹에 추가합니다.
1. 옵션 그룹을 DB 인스턴스에 연결합니다.
**참고**
옵션 그룹을 통해 리소스 거버너를 활성화하면 재부팅할 필요가 없습니다.
## `RESOURCE_GOVERNOR`용 옵션 그룹 만들기
리소스 거버너를 활성화하려면 사용할 DB 인스턴스의 SQL Server 에디션 및 버전에 해당하는 옵션 그룹을 생성하거나 수정합니다. 이 절차를 완료하려면 AWS Management Console 또는 AWS CLI를 사용합니다.
### 콘솔
다음 절차를 사용하여 SQL Server Enterprise Edition 2022에 대한 옵션 그룹을 생성합니다.
**옵션 그룹을 생성하려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **옵션 그룹**을 선택합니다.
1. **그룹 생성**을 선택합니다.
1. **보안 그룹 생성** 창에서 다음과 같이 합니다.
1. [**이름(Name)**]에 AWS 계정 내에서 쉽게 식별할 수 있는 옵션 그룹 이름을 입력합니다(예: **resource-governor-ee-2022**). 이름은 글자, 숫자 및 하이픈만 사용 가능합니다.
1. **설명**에 옵션 그룹에 대한 간단한 설명을 입력합니다(예: **RESOURCE\$1GOVERNOR option group for SQL Server EE 2022**). 이 설명은 표시 용도로만 사용됩니다.
1. **엔진**에 대해 **sqlserver-ee**를 선택합니다.
1. **메이저 엔진 버전**에 대해 **16.00**을 선택합니다.
1. **생성(Create)**을 선택합니다.
### CLI
다음 절차에서는 SQL Server Enterprise Edition 2022에 대한 옵션 그룹을 생성합니다.
**옵션 그룹을 생성하려면**
+ 다음 명령 중 하나를 실행합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds create-option-group \
--option-group-name resource-governor-ee-2022 \
--engine-name sqlserver-ee \
--major-engine-version 16.00 \
--option-group-description "RESOURCE_GOVERNOR option group for SQL Server EE 2022"
```
Windows의 경우:
```
aws rds create-option-group ^
--option-group-name resource-governor-ee-2022 ^
--engine-name sqlserver-ee ^
--major-engine-version 16.00 ^
--option-group-description "RESOURCE_GOVERNOR option group for SQL Server EE 2022"
```
## 옵션 그룹에 `RESOURCE_GOVERNOR` 옵션 추가
그런 다음 AWS Management Console 또는 AWS CLI를 사용하여 `RESOURCE_GOVERNOR` 옵션을 옵션 그룹에 추가합니다.
### 콘솔
**RESOURCE\$1GOVERNOR 옵션 추가**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **옵션 그룹**을 선택합니다.
1. 이 예제에서는 방금 생성한 옵션 그룹인 **resource-governor-ee-2022**를 선택합니다.
1. **옵션 추가**를 선택합니다.
1. **옵션 세부 정보**에서 **옵션 이름**으로 **RESOURCE\$1GOVERNOR**를 선택합니다.
1. **예약**에서 옵션을 즉시 추가할지 또는 다음 유지 관리 기간에 추가할지를 선택합니다.
1. **옵션 추가**를 선택합니다.
### CLI
**`RESOURCE_GOVERNOR` 옵션을 추가하려면**
+ [`RESOURCE_GOVERNOR`] 옵션을 옵션 그룹에 추가합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds add-option-to-option-group \
--option-group-name resource-governor-ee-2022 \
--options "OptionName=RESOURCE_GOVERNOR" \
--apply-immediately
```
Windows의 경우:
```
aws rds add-option-to-option-group ^
--option-group-name resource-governor-ee-2022 ^
--options "OptionName=RESOURCE_GOVERNOR" ^
--apply-immediately
```
## 옵션 그룹을 DB 인스턴스와 연결
AWS Management Console 또는 AWS CLI를 사용하여 `RESOURCE_GOVERNOR` 옵션 그룹을 DB 인스턴스와 연결할 수 있습니다.
### 콘솔
리소스 거버너 활성화를 완료하려면 `RESOURCE_GOVERNOR` 옵션 그룹을 새 DB 인스턴스 또는 기존 DB 인스턴스와 연결합니다.
+ 새 DB 인스턴스의 경우 인스턴스를 시작할 때 이러한 그룹을 연결합니다. 자세한 내용은 [Amazon RDS DB 인스턴스 생성](USER_CreateDBInstance.md) 섹션을 참조하세요.
+ 기존 DB 인스턴스의 경우 인스턴스를 수정하여 그룹을 연결합니다. 자세한 내용은 [Amazon RDS DB 인스턴스 수정](Overview.DBInstance.Modifying.md) 섹션을 참조하세요.
### CLI
`RESOURCE_GOVERNOR` 옵션 그룹을 새 DB 인스턴스 또는 기존 DB 인스턴스와 연결할 수 있습니다.
**`RESOURCE_GOVERNOR` 옵션 그룹을 사용하여 인스턴스 생성**
+ 옵션 그룹을 생성할 때 사용한 것과 동일한 DB 엔진 유형과 메이저 버전을 지정합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds create-db-instance \
--db-instance-identifier mytestsqlserverresourcegovernorinstance \
--db-instance-class db.m5.2xlarge \
--engine sqlserver-ee \
--engine-version 16.00 \
--license-model license-included \
--allocated-storage 100 \
--master-username admin \
--master-user-password password \
--storage-type gp2 \
--option-group-name resource-governor-ee-2022
```
Windows의 경우:
```
aws rds create-db-instance ^
--db-instance-identifier mytestsqlserverresourcegovernorinstance ^
--db-instance-class db.m5.2xlarge ^
--engine sqlserver-ee ^
--engine-version 16.00 ^
--license-model license-included ^
--allocated-storage 100 ^
--master-username admin ^
--master-user-password password ^
--storage-type gp2 ^
--option-group-name resource-governor-ee-2022
```
**인스턴스를 수정하여 `RESOURCE_GOVERNOR` 옵션 그룹을 연결하려면**
+ 다음 명령 중 하나를 실행합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds modify-db-instance \
--db-instance-identifier mytestinstance \
--option-group-name resource-governor-ee-2022 \
--apply-immediately
```
Windows의 경우:
```
aws rds modify-db-instance ^
--db-instance-identifier mytestinstance ^
--option-group-name resource-governor-ee-2022 ^
--apply-immediately
```
# RDS for SQL Server 인스턴스에 Microsoft SQL Server 리소스 거버너 사용
리소스 거버너 옵션을 옵션 그룹에 추가한 후에는 데이터베이스 엔진 수준에서 리소스 거버너 옵션이 아직 활성화되지 않습니다. 리소스 권한 부여를 완전히 활성화하려면 RDS for SQL Server 저장 프로시저를 사용하여 이를 활성화하고 필요한 리소스 권한 부여 객체를 생성해야 합니다. 자세한 내용은 [Microsoft SQL Server DB 인스턴스에 연결](USER_ConnectToMicrosoftSQLServerInstance.md) 섹션을 참조하세요.
먼저 SQL Server 데이터베이스에 연결한 다음 적절한 RDS for SQL Server 저장 프로시저를 직접적으로 호출하여 구성을 완료합니다. 데이터베이스 연결 방법에 대한 자세한 내용은 [Microsoft SQL Server DB 인스턴스에 연결](USER_ConnectToMicrosoftSQLServerInstance.md) 섹션을 참조하십시오.
각각의 저장 프로시저를 호출하는 방법에 대한 지침은 다음 주제를 참조하십시오.
**Topics**
+ [리소스 풀 관리](#ResourceGovernor.ManageResourcePool)
+ [워크로드 그룹 관리](#ResourceGovernor.ManageWorkloadGroups)
+ [분류기 함수 생성 및 등록](#ResourceGovernor.ClassifierFunction)
+ [분류자 함수 삭제](#ResourceGovernor.DropClassifier)
+ [분류자 함수 등록 취소](#ResourceGovernor.DeregisterClassifier)
+ [통계 재설정](#ResourceGovernor.ResetStats)
+ [리소스 거버너 구성 변경 사항](#ResourceGovernor.ConfigChanges)
+ [TempDB를 리소스 풀에 바인딩](#ResourceGovernor.BindTempDB)
+ [리소스 풀에서 TempDB 바인딩 해제](#ResourceGovernor.UnbindTempDB)
+ [리소스 거버너 정리](#ResourceGovernor.Cleanup)
## 리소스 풀 관리
### 리소스 풀 생성
옵션 그룹에서 리소스 거버너가 활성화되면 `rds_create_resource_pool`을 사용하여 사용자 지정 리소스 풀을 생성할 수 있습니다. 이러한 풀을 사용하면 CPU, 메모리 및 IOPS의 특정 비율을 다양한 워크로드에 할당할 수 있습니다.
**사용법**
```
USE [msdb]
EXEC dbo.rds_create_resource_pool
@pool_name=value,
@MAX_CPU_PERCENT=value,
@CAP_CPU_PERCENT=value,
@MAX_MEMORY_PERCENT=value,
@MAX_IOPS_PER_VOLUME=value
```
다음 파라미터는 필수 파라미터입니다.
+ `@group_name` - 기존 사용자 정의 워크로드 그룹의 이름입니다.
+ `@pool_name` - 리소스 풀의 사용자 정의 이름입니다. *pool\$1name*은 영숫자이며 최대 128자이고, 데이터베이스 엔진 인스턴스 내에서 고유해야 하며, 데이터베이스 식별자 규칙을 준수해야 합니다.
다음 파라미터는 선택적입니다.
+ `@MAX_CPU_PERCENT` - CPU 경합이 있을 때 리소스 풀의 모든 요청이 수신하는 최대 평균 CPU 대역폭을 지정합니다. *값*은 기본 설정이 100인 정수입니다. *값*에 허용되는 범위는 1\$1100입니다.
+ `@CAP_CPU_PERCENT` - 리소스 풀의 모든 요청이 수신하는 CPU 대역폭에 대한 하드 캡을 지정합니다. 최대 CPU 대역폭 수준을 지정된 값과 동일하게 제한합니다. *값*은 기본 설정이 100인 정수입니다. *값*에 허용되는 범위는 1\$1100입니다.
+ `@MAX_MEMORY_PERCENT` - 이 리소스 풀의 요청이 사용할 수 있는 쿼리 워크스페이스 메모리의 최대 양을 지정합니다. *값*은 기본 설정이 100인 정수입니다. *값*에 허용되는 범위는 1\$1100입니다.
+ `@MAX_IOPS_PER_VOLUME` - 리소스 풀을 허용할 디스크 볼륨당 최대 초당 I/O 작업 수(IOPS)를 지정합니다. *값*에 허용되는 범위는 0\$12^31-1(2,147,483,647)입니다. 풀에 대한 IOPS 제한을 제거하려면 0을 지정합니다. 기본값은 0입니다.
**예제**
모든 기본값으로 리소스 풀을 생성하는 예:
```
--This creates resource pool 'SalesPool' with all default values
USE [msdb]
EXEC rds_create_resource_pool @pool_name = 'SalesPool';
--Apply changes
USE [msdb]
EXEC msdb.dbo.rds_alter_resource_governor_configuration;
--Validate configuration
select * from sys.resource_governor_resource_pools
```
다른 파라미터가 지정된 리소스 풀을 생성하는 예:
```
--creates resource pool
USE [msdb]
EXEC dbo.rds_create_resource_pool
@pool_name='analytics',
@MAX_CPU_PERCENT = 30,
@CAP_CPU_PERCENT = 40,
@MAX_MEMORY_PERCENT = 20;
--Apply changes
EXEC msdb.dbo.rds_alter_resource_governor_configuration;
--Validate configuration
select * from sys.resource_governor_resource_pools
```
### 리소스 풀 변경
**사용법**
```
USE [msdb]
EXEC dbo.rds_alter_resource_pool
@pool_name=value,
@MAX_CPU_PERCENT=value,
@CAP_CPU_PERCENT=value,
@MAX_MEMORY_PERCENT=value,
@MAX_IOPS_PER_VOLUME=value;
```
다음 파라미터는 필수 파라미터입니다.
+ `@pool_name` - 기존 사용자 정의 리소스 풀의 이름입니다. Amazon RDS SQL Server에서는 기본 리소스 풀을 변경할 수 없습니다.
선택적 파라미터 중 하나 이상을 지정해야 합니다.
+ `@MAX_CPU_PERCENT` - CPU 경합이 있을 때 리소스 풀의 모든 요청이 수신하는 최대 평균 CPU 대역폭을 지정합니다. *값*은 기본 설정이 100인 정수입니다. *값*에 허용되는 범위는 1\$1100입니다.
+ `@CAP_CPU_PERCENT` - 리소스 풀의 모든 요청이 수신하는 CPU 대역폭에 대한 하드 캡을 지정합니다. 최대 CPU 대역폭 수준을 지정된 값과 동일하게 제한합니다. *값*은 기본 설정이 100인 정수입니다. *값*에 허용되는 범위는 1\$1100입니다.
+ `@MAX_MEMORY_PERCENT` - 이 리소스 풀의 요청이 사용할 수 있는 쿼리 워크스페이스 메모리의 최대 양을 지정합니다. *값*은 기본 설정이 100인 정수입니다. *값*에 허용되는 범위는 1\$1100입니다.
+ `@MAX_IOPS_PER_VOLUME` - 리소스 풀을 허용할 디스크 볼륨당 최대 초당 I/O 작업 수(IOPS)를 지정합니다. *값*에 허용되는 범위는 0\$12^31-1(2,147,483,647)입니다. 풀에 대한 IOPS 제한을 제거하려면 0을 지정합니다. 기본값은 0입니다.
**예제**
```
--This alters resource pool
USE [msdb]
EXEC dbo.rds_alter_resource_pool
@pool_name='analytics',
@MAX_CPU_PERCENT = 10,
@CAP_CPU_PERCENT = 20,
@MAX_MEMORY_PERCENT = 50;
--Apply changes
EXEC msdb.dbo.rds_alter_resource_governor_configuration;
--Validate configuration.
select * from sys.resource_governor_resource_pools
```
### 리소스 풀 삭제
**사용법**
```
USE [msdb]
EXEC dbo.rds_drop_resource_pool
@pool_name=value;
```
다음 파라미터는 필수입니다.
+ `@pool_name` - 기존 사용자 정의 리소스 풀의 이름입니다.
**참고**
SQL Server에서는 내부 또는 기본 리소스 풀을 삭제할 수 없습니다.
**예제**
```
--This drops resource pool
USE [msdb]
EXEC dbo.rds_drop_resource_pool
@pool_name='analytics'
--Apply changes
EXEC msdb.dbo.rds_alter_resource_governor_configuration;
--Validate configuration
select * from sys.resource_governor_resource_pools
```
## 워크로드 그룹 관리
`rds_create_workload_group` 및 `rds_alter_workload_group`으로 생성 및 관리되는 워크로드 그룹을 사용하면 쿼리 그룹에 대한 중요도 수준, 메모리 권한 부여 및 기타 파라미터를 설정할 수 있습니다.
### 워크로드 그룹 생성
**사용법**
```
USE [msdb]
EXEC dbo.rds_create_workload_group
@group_name = value,
@IMPORTANCE ={ LOW | MEDIUM | HIGH },
@REQUEST_MAX_MEMORY_GRANT_PERCENT =value,
@REQUEST_MAX_CPU_TIME_SEC = value ,
@REQUEST_MEMORY_GRANT_TIMEOUT_SEC = value,
@MAX_DOP = value,
@GROUP_MAX_REQUESTS = value,
@pool_name = value
```
다음 파라미터는 필수 파라미터입니다.
+ `@pool_name` - 기존 사용자 정의 리소스 풀의 이름입니다.
+ `@group_name` - 기존 사용자 정의 워크로드 그룹의 이름입니다.
다음 파라미터는 선택적입니다.
+ `@IMPORTANCE` - 워크로드 그룹에서 요청의 상대적 중요도를 지정합니다. 기본값은 `MEDIUM`입니다.
+ `@REQUEST_MAX_MEMORY_GRANT_PERCENT` - 단일 요청이 풀에서 가져올 수 있는 쿼리 워크스페이스 메모리의 최대 양을 지정합니다. *값*은 `MAX_MEMORY_PERCENT`에서 정의한 리소스 풀 크기의 백분율입니다. 기본값은 25입니다.
+ `@REQUEST_MAX_CPU_TIME_SEC` - 배치 요청이 사용할 수 있는 최대 CPU 시간을 초 단위로 지정합니다. *값*은 0 또는 양의 정수여야 합니다. *값*의 기본 설정은 0이며 이는 무제한을 의미합니다.
+ `@REQUEST_MEMORY_GRANT_TIMEOUT_SEC` - 쿼리가 쿼리 작업 영역 메모리의 메모리 부여를 사용할 수 있을 때까지 기다릴 수 있는 최대 시간을 초 단위로 지정합니다. *값*은 0 또는 양의 정수여야 합니다. *값*의 기본 설정인 0은 쿼리 비용을 기반으로 한 내부 계산을 사용하여 최대 시간을 결정합니다.
+ `@MAX_DOP` - 병렬 쿼리 실행을 위한 최대 병렬 처리 정도(`MAXDOP`)를 지정합니다. *값*에 허용되는 범위는 0\$164입니다. *값*의 기본 설정인 0은 전역 설정을 사용합니다.
+ `@GROUP_MAX_REQUESTS` = 워크로드 그룹에서 실행할 수 있는 최대 동시 요청 수를 지정합니다. *값*은 0 또는 양의 정수여야 합니다. *값*의 기본 설정은 0이며 무제한 요청을 허용합니다.
+ `@pool_name` = 워크로드 그룹을 *pool\$1name*으로 식별되는 사용자 정의 리소스 풀 또는 `default` 리소스 풀과 연결합니다. *pool\$1name*이 제공되지 않으면 워크로드 그룹이 기본 제공 `default` 풀과 연결됩니다.
**예시**
```
--This creates workload group named 'analytics'
USE msdb;
EXEC dbo.rds_create_workload_group
@group_name = 'analytics',
@IMPORTANCE = 'HIGH',
@REQUEST_MAX_MEMORY_GRANT_PERCENT = 25,
@REQUEST_MAX_CPU_TIME_SEC = 0,
@REQUEST_MEMORY_GRANT_TIMEOUT_SEC = 0,
@MAX_DOP = 0,
@GROUP_MAX_REQUESTS = 0,
@pool_name = 'analytics';
--Apply changes
EXEC msdb.dbo.rds_alter_resource_governor_configuration;
--Validate configuration
select * from sys.resource_governor_workload_groups
```
### 워크로드 그룹 변경
**사용법**
```
EXEC msdb.dbo.rds_alter_workload_group
@group_name = value,
@IMPORTANCE = 'LOW|MEDIUM|HIGH',
@REQUEST_MAX_MEMORY_GRANT_PERCENT = value,
@REQUEST_MAX_CPU_TIME_SEC = value,
@REQUEST_MEMORY_GRANT_TIMEOUT_SEC = value,
@MAX_DOP = value,
@GROUP_MAX_REQUESTS = value,
@pool_name = value
```
다음 파라미터는 필수 파라미터입니다.
+ `@group_name` - 기본 또는 기존 사용자 정의 워크로드 그룹의 이름입니다.
**참고**
기본 워크로드 그룹의 `REQUEST_MAX_MEMORY_GRANT_PERCENT` 파라미터 변경만 지원됩니다. 기본 워크로드 그룹의 경우 `REQUEST_MAX_MEMORY_GRANT_PERCENT`는 1에서 70 사이여야 합니다. 기본 워크로드 그룹에서는 다른 파라미터를 수정할 수 없습니다. 모든 파라미터는 사용자 정의 워크로드 그룹에서 수정할 수 있습니다.
다음 파라미터는 선택적입니다.
+ `@IMPORTANCE` - 워크로드 그룹에서 요청의 상대적 중요도를 지정합니다. 기본값은 MEDIUM입니다.
+ `@REQUEST_MAX_MEMORY_GRANT_PERCENT` - 단일 요청이 풀에서 가져올 수 있는 쿼리 워크스페이스 메모리의 최대 양을 지정합니다. *값*은 `MAX_MEMORY_PERCENT`에서 정의한 리소스 풀 크기의 백분율입니다. 기본값은 25입니다. Amazon RDS에서 `REQUEST_MAX_MEMORY_GRANT_PERCENT`는 1에서 70 사이여야 합니다.
+ `@REQUEST_MAX_CPU_TIME_SEC` - 배치 요청이 사용할 수 있는 최대 CPU 시간을 초 단위로 지정합니다. *값*은 0 또는 양의 정수여야 합니다. *값*의 기본 설정은 0이며 이는 무제한을 의미합니다.
+ `@REQUEST_MEMORY_GRANT_TIMEOUT_SEC` - 쿼리가 쿼리 작업 영역 메모리의 메모리 부여를 사용할 수 있을 때까지 기다릴 수 있는 최대 시간을 초 단위로 지정합니다. *값*은 0 또는 양의 정수여야 합니다. *값*의 기본 설정인 0은 쿼리 비용을 기반으로 한 내부 계산을 사용하여 최대 시간을 결정합니다.
+ `@MAX_DOP` - 병렬 쿼리 실행을 위한 최대 병렬 처리 정도(MAXDOP)를 지정합니다. *값*에 허용되는 범위는 0\$164입니다. *값*의 기본 설정인 0은 전역 설정을 사용합니다.
+ `@GROUP_MAX_REQUESTS` - 워크로드 그룹에서 실행할 수 있는 최대 동시 요청 수를 지정합니다. *값*은 0 또는 양의 정수여야 합니다. *값*의 기본 설정은 0이며 무제한 요청을 허용합니다.
+ `@pool_name` - 워크로드 그룹을 *pool\$1name*으로 식별되는 사용자 정의 리소스 풀과 연결합니다.
**예제**
기본 워크로드 그룹을 수정하는 예제 REQUEST\$1MAX\$1MEMORY\$1GRANT\$1PERCENT 변경:
```
--Modify default workload group (set memory grant cap to 10%)
USE msdb
EXEC dbo.rds_alter_workload_group
@group_name = 'default',
@REQUEST_MAX_MEMORY_GRANT_PERCENT=10;
--Apply changes
EXEC msdb.dbo.rds_alter_resource_governor_configuration;
--Validate configuration
SELECT * FROM sys.resource_governor_workload_groups WHERE name='default';
```
기본이 아닌 워크로드 그룹을 수정하는 예:
```
EXEC msdb.dbo.rds_alter_workload_group
@group_name = 'analytics',
@IMPORTANCE = 'HIGH',
@REQUEST_MAX_MEMORY_GRANT_PERCENT = 30,
@REQUEST_MAX_CPU_TIME_SEC = 3600,
@REQUEST_MEMORY_GRANT_TIMEOUT_SEC = 60,
@MAX_DOP = 4,
@GROUP_MAX_REQUESTS = 100;
--Apply changes
EXEC msdb.dbo.rds_alter_resource_governor_configuration;
```
기본값이 아닌 워크로드 그룹을 다른 리소스 풀로 이동하는 예:
```
EXEC msdb.dbo.rds_alter_workload_group
@group_name = 'analytics',
@pool_name='abc'
--Apply changes
EXEC msdb.dbo.rds_alter_resource_governor_configuration;
--Validate configuration
select * from sys.resource_governor_workload_groups
```
### 워크로드 그룹 삭제
**사용법**
```
EXEC msdb.dbo.rds_drop_workload_group
@group_name = value
```
다음 파라미터는 필수 파라미터입니다.
+ `@group_name` - 기존 사용자 정의 워크로드 그룹의 이름입니다.
**예제**
```
--Drops a Workload Group:
EXEC msdb.dbo.rds_drop_workload_group
@group_name = 'analytics';
--Apply changes
EXEC msdb.dbo.rds_alter_resource_governor_configuration;
--Validate configuration
select * from sys.resource_governor_workload_groups
```
## 분류기 함수 생성 및 등록
이 절차에서는 지정된 기준(사용자 이름, 데이터베이스, 호스트 또는 애플리케이션 이름)을 기반으로 사용자 지정 워크로드 그룹으로 연결을 라우팅하는 마스터 데이터베이스에 리소스 어드바이저 분류자 함수를 생성합니다. 리소스 거버너가 활성화되고 리소스 거버너 구성에 분류자 함수가 지정된 경우 함수 출력에 따라 새 세션에 사용되는 워크로드 그룹이 결정됩니다. 분류자 함수가 없는 경우 모든 세션이 `default` 그룹으로 분류됩니다.
**기능:**
+ 각 라우팅 조건에서 최대 2개의 워크로드 그룹을 지원합니다.
+ 기준을 각 그룹 내의 `AND` 조건과 결합합니다.
+ 워크로드 그룹당 하나 이상의 라우팅 기준이 필요합니다.
+ 함수 이름은 `rg_classifier_`로 시작해야 합니다.
+ 일치하는 조건이 없는 경우 기본 그룹 할당입니다.
분류자 함수의 특징과 동작은 다음과 같습니다.
+ 함수는 서버 범위(마스터 데이터베이스)에 정의됩니다.
+ 함수는 스키마 바인딩으로 정의됩니다.
+ 연결 풀링이 활성화된 경우에도 함수는 모든 새 세션에 대해 평가됩니다.
+ 함수는 세션에 대한 워크로드 그룹 컨텍스트를 반환합니다. 세션은 세션 수명 동안 분류자가 반환한 워크로드 그룹에 할당됩니다.
+ 함수가 NULL, 기본값 또는 존재하지 않는 워크로드 그룹의 이름을 반환하면 세션에 기본 워크로드 그룹 컨텍스트가 지정됩니다. 어떤 이유로든 함수가 실패하면 세션에도 기본 컨텍스트가 제공됩니다.
+ 여러 분류자 함수를 생성할 수 있습니다. 그러나 SQL Server에서는 한 번에 하나의 분류자 함수만 등록할 수 있습니다.
+ 함수 이름을 NULL로 설정하는 등록 취소 절차(`EXEC dbo.msdb.rds_alter_resource_governor_configuration @deregister_function = 1;`)를 사용하여 분류자 상태를 제거하거나 (`EXEC dbo.msdb.rds_alter_resource_governor_configuration @classifier_function = ;`)을 사용하여 다른 분류자 함수를 등록하지 않는 한 분류자 함수를 삭제할 수 없습니다.
+ 분류자 함수가 없는 경우 모든 세션이 기본 그룹으로 분류됩니다.
+ 분류자 함수는 리소스 관리자 구성에서 참조되는 동안에는 수정할 수 없습니다. 그러나 다른 분류자 함수를 사용하도록 구성을 수정할 수 있습니다. 분류자를 변경하려면 분류자 함수 쌍을 생성하는 것이 좋습니다. 예를 들어 `rg_classifier_a`와 `rg_classifier_b`를 만들 수 있습니다.
**사용법**
```
EXEC msdb.dbo.rds_create_classifier_function
@function_name = value,
@workload_group1 = value,
@user_name1 = value,
@db_name1 = value,
@host_name1 = value,
@app_name1 = value,
@workload_group2 = value,
@user_name2 = value,
@db_name2 = value,
@host_name2 = value,
@app_name2 = value
```
다음 파라미터는 필수 파라미터입니다.
+ `@function_name` - 분류자 함수의 이름입니다. `rg_classifier_`로 시작해야 함
+ `@workload_group1` - 첫 번째 워크로드 그룹의 이름
다음 파라미터는 선택적입니다.
(그룹 1에 이러한 기준 중 하나 이상을 지정해야 함)
+ `@user_name1` - 그룹 1의 로그인 이름
+ `@db_name1` - 그룹 1의 데이터베이스 이름
+ `@host_name1` - 그룹 1의 호스트 이름
+ `@app_name1` - 그룹 1의 애플리케이션 이름
(그룹 2가 지정된 경우 하나 이상의 기준을 제공해야 합니다.)
+ `@workload_group2` - 두 번째 워크로드 그룹의 이름
+ `@user_name2` - 그룹 2의 로그인 이름
+ `@db_name2` - 그룹 2의 데이터베이스 이름
+ `@host_name2` - 그룹 2의 호스트 이름
+ `@app_name2` - 그룹 2의 애플리케이션 이름
**참고**
시스템 계정, 데이터베이스, 애플리케이션 및 호스트는 제한됩니다.
**예제**
하나의 워크로드 그룹이 있는 기본 예제:
```
/*Create a classifier to route all requests from 'PowerBI' app to workload group
'reporting_group'*/
EXEC msdb.dbo.rds_create_classifier_function
@function_name = 'rg_classifier_a',
@workload_group1 = 'reporting_group',
@app_name1 = 'PowerBI';
--Register the classifier
EXEC msdb.dbo.rds_alter_resource_governor_configuration
@classifier_function = 'rg_classifier_a';
-- Apply changes
EXEC msdb.dbo.rds_alter_resource_governor_configuration
/*Query sys.resource_governor_configuration to validate that resource governor is enabled and is using the classifier function we created and registered*/
use master
go
SELECT OBJECT_SCHEMA_NAME(classifier_function_id) AS classifier_schema_name,
OBJECT_NAME(classifier_function_id) AS classifier_object_name,
is_enabled
FROM sys.resource_governor_configuration;
```
## 분류자 함수 삭제
**사용법**
```
USE [msdb]
EXEC dbo.rds_drop_classifier_function
@function_name = value;
```
다음 파라미터는 필수입니다.
+ `@function_name` - 기존 사용자 정의 분류자 함수의 이름입니다.
**예제**
```
EXEC msdb.dbo.rds_drop_classifier_function
@function_name = 'rg_classifier_b';
```
## 분류자 함수 등록 취소
분류자 함수의 등록을 취소하려면 이 절차를 사용합니다. 함수가 등록 취소되면 새 세션이 기본 워크로드 그룹에 자동으로 할당됩니다.
**사용법**
```
USE [msdb]
EXEC dbo.rds_alter_resource_governor_configuration
@deregister_function = 1;
```
등록 취소하려면 다음 파라미터가 필요합니다.
+ `@deregister_function`이 1이어야 함
**예제**
```
EXEC msdb.dbo.rds_alter_resource_governor_configuration
@deregister_function = 1;
GO
-- Apply changes
EXEC msdb.dbo.rds_alter_resource_governor_configuration;
```
## 통계 재설정
리소스 거버너 통계는 마지막 서버 재시작 이후 누적됩니다. 특정 시간부터 통계를 수집해야 하는 경우 다음 Amazon RDS 저장 프로시저를 사용하여 통계를 재설정할 수 있습니다.
**사용법**
```
USE [msdb]
EXEC dbo.rds_alter_resource_governor_configuration
@reset_statistics = 1;
```
통계를 재설정하려면 다음 파라미터가 필요합니다.
+ `@reset_statistics`이 1이어야 함
## 리소스 거버너 구성 변경 사항
리소스 거버너가 활성화되지 않은 경우 `rds_alter_resource_governor_configuration`은 리소스 거버너를 활성화합니다. 리소스 거버너 활성화의 결과는 다음과 같습니다.
+ 분류자 함수가 있는 경우 새 세션에 대해 실행되어 워크로드 그룹에 할당됩니다.
+ 리소스 조정자 구성에 지정된 리소스 제한이 적용되고 적용됩니다.
+ 리소스 조정자 구성에 지정된 리소스 제한이 적용되고 적용됩니다.
+ 리소스 권한 부여를 활성화하기 전에 존재했던 요청은 리소스 권한 부여가 활성화될 때 이루어진 구성 변경의 영향을 받을 수 있습니다.
+ 리소스 거버너를 활성화하기 전에 기존 요청은 리소스 거버너가 활성화될 때 이루어진 구성 변경의 영향을 받을 수 있습니다.
+ RDS for SQL Server에서 리소스 지연 구성 변경 사항을 적용하려면 `EXEC msdb.dbo.rds_alter_resource_governor_configuration`을 실행해야 합니다.
**사용법**
```
USE [msdb]
EXEC dbo.rds_alter_resource_governor_configuration
```
## TempDB를 리소스 풀에 바인딩
Amazon RDS SQL Server 버전 2019 이상에서 `rds_bind_tempdb_metadata_to_resource_pool`을 사용하여 tempdb 메모리 최적화 메타데이터를 특정 리소스 풀에 바인딩할 수 있습니다.
**참고**
tempdb 메타데이터를 리소스 풀에 바인딩하기 전에 메모리 최적화 tempdb 메타데이터 기능을 활성화해야 합니다. Amazon RDS에서 이 기능을 활성화하려면 정적 파라미터 `tempdb metadata memory-optimized`를 사용합니다.
Amazon RDS에서 정적 파라미터를 활성화하고 장애 조치 없이 재부팅을 수행하여 파라미터를 적용합니다.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name test-sqlserver-ee-2022 \
--parameters "ParameterName='tempdb metadata memory-optimized',ParameterValue=True,ApplyMethod=pending-reboot"
```
**사용법**
```
USE [msdb]
EXEC dbo.rds_bind_tempdb_metadata_to_resource_pool
@pool_name=value;
```
다음 파라미터는 필수입니다.
+ `@pool_name` - 기존 사용자 정의 리소스 풀의 이름입니다.
**참고**
또한 메모리 최적화 TempDB 메타데이터 기능이 이미 활성화된 경우에도 이 변경 사항을 적용하려면 장애 조치 없이 SQL 서비스 재부팅이 필요합니다.
## 리소스 풀에서 TempDB 바인딩 해제
리소스 풀에서 tempdb 메모리 최적화 메타데이터의 바인딩을 해제합니다.
**참고**
또한이 변경 사항을 적용하려면 장애 조치 없이 SQL 서비스 재부팅이 필요합니다.
**사용법**
```
USE [msdb]
EXEC dbo.rds_unbind_tempdb_metadata_from_resource_pool
```
## 리소스 거버너 정리
이 절차는 옵션 그룹에서 리소스 관리자 옵션을 제거한 후 연결된 모든 객체를 정리하는 것입니다. 이렇게 하면 리소스 거버너가 비활성화되고, 기본 워크로드 그룹이 기본 설정으로 되돌리고, 사용자 지정 워크로드 그룹, 리소스 풀 및 분류자 함수가 제거됩니다.
**주요 기능**:
+ 기본 워크로드 그룹을 기본 설정으로 되돌립니다.
+ 리소스 거버너를 비활성화합니다.
+ 사용자 지정 워크로드 그룹을 제거합니다.
+ 사용자 지정 리소스 풀을 제거합니다.
+ 분류자 함수를 삭제합니다.
+ 활성화된 경우 tempdb 리소스 풀 바인딩을 제거합니다.
**중요**
워크로드 그룹에 활성 세션이 있는 경우 이 정리에 오류가 발생할 수 있습니다. 비즈니스 요구 사항에 따라 활성 세션이 완료될 때까지 기다리거나 활성 세션을 종료합니다. 유지 관리 기간 동안 이를 실행하는 것이 좋습니다.
리소스 풀이 tempdb에 바인딩되고 장애 조치 없이 재부팅되지 않은 경우 이 정리에 오류가 발생할 수 있습니다. 리소스 풀을 tempdb에 바인딩하거나 이전에 리소스 풀을 tempdb에서 바인딩하지 않은 경우 장애 조치 없이 재부팅을 수행하여 변경 사항을 적용합니다. 유지 관리 기간 동안 이를 실행하는 것이 좋습니다.
**사용법**
```
USE [msdb]
EXEC dbo.rds_cleanup_resource_governor
```
## 다중 AZ 배포에 대한 고려 사항
RDS for SQL Server는 다중 AZ 배포에서 리소스 거버너를 보조 인스턴스에 복제합니다. 수정된 시기와 보조 인스턴스와 마지막으로 동기화된 새 리소스 거버너를 확인할 수 있습니다.
다음 쿼리를 사용하여 복제의 `last_sync_time`을 확인합니다.
```
SELECT * from msdb.dbo.rds_fn_server_object_last_sync_time();
```
쿼리 결과에서 동기화 시간이 리소스 조정자 업데이트 또는 생성 시간을 초과하면 리소스 조정자는 보조와 동기화됩니다.
수동 DB 장애 조치를 수행하여 리소스 준수 복제를 확인하려면 `last_sync_time`이 먼저 업데이트될 때까지 기다립니다. 그런 다음 다중 AZ 장애 조치를 진행합니다.
## 읽기 전용 복제본에 대한 고려 사항
+ 소스 DB 인스턴스와 동일한 리전에 있는 SQL Server 복제본의 경우 소스와 동일한 옵션 그룹을 사용합니다. 옵션 그룹에 대한 변경 사항은 유지 관리 기간에 관계없이 즉시 복제본으로 전파됩니다.
+ SQL Server 리전 간 복제본을 생성하면 RDS가 전용 옵션 그룹을 생성합니다.
+ 전용 옵션 그룹에서 SQL Server 리전 간 복제본을 제거할 수 없습니다. 다른 DB 인스턴스는 SQL Server 리전 간 복제본에 전용 옵션 그룹을 사용할 수 없습니다.
+ 리소스 거버너 옵션은 복제되지 않은 옵션입니다. 전용 옵션 그룹에 복제되지 않은 옵션을 추가하거나 제거할 수 있습니다.
+ SQL Server 리전 간 읽기 전용 복제본을 승격하면 승격된 복제본은 옵션 관리를 포함해 다른 SQL Server DB 인스턴스와 동일하게 작동합니다.
**참고**
읽기 전용 복제본에서 리소스 거버너를 사용하는 경우 옵션을 옵션 그룹에 추가한 후 Amazon RDS 저장 프로시저를 사용하여 읽기 전용 복제본에 리소스 거버너가 구성되었는지 수동으로 확인해야 합니다. 리소스 거버너 구성은 읽기 전용 복제본에 자동으로 복제되지 않습니다. 또한 읽기 전용 복제본의 워크로드는 일반적으로 기본 인스턴스와 다릅니다. 따라서 워크로드 및 인스턴스 유형에 따라 복제본에 리소스 구성을 적용하는 것이 좋습니다. 읽기 전용 복제본에서 이러한 Amazon RDS 저장 프로시저를 독립적으로 실행하여 읽기 전용 복제본에서 리소스 거버너를 구성할 수 있습니다.
# RDS for SQL Server 인스턴스의 시스템 뷰를 사용하여 Microsoft SQL Server 리소스 거버너 모니터링
리소스 거버너 통계는 마지막 서버 재시작 이후 누적됩니다. 특정 시간부터 통계를 수집해야 하는 경우 다음 Amazon RDS 저장 프로시저를 사용하여 통계를 재설정할 수 있습니다.
```
EXEC msdb.dbo.rds_alter_resource_governor_configuration
@reset_statistics = 1;
```
## 리소스 풀 런타임 통계
각 리소스 풀에 대해 리소스 거버너는 CPU 및 메모리 사용률, 메모리 부족 이벤트, 메모리 부여, I/O 및 기타 통계를 추적합니다. 자세한 내용은 [ sys.dm\$1resource\$1governor\$1resource\$1pools](https://learn.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/sys-dm-resource-governor-resource-pools-transact-sql?view=sql-server-ver17)를 참조하세요.
다음 쿼리는 모든 리소스 풀에 대해 사용 가능한 통계의 하위 집합을 반환합니다.
```
SELECT rp.pool_id,
rp.name AS resource_pool_name,
wg.workload_group_count,
rp.statistics_start_time,
rp.total_cpu_usage_ms,
rp.target_memory_kb,
rp.used_memory_kb,
rp.out_of_memory_count,
rp.active_memgrant_count,
rp.total_memgrant_count,
rp.total_memgrant_timeout_count,
rp.read_io_completed_total,
rp.write_io_completed_total,
rp.read_bytes_total,
rp.write_bytes_total,
rp.read_io_stall_total_ms,
rp.write_io_stall_total_ms
FROM sys.dm_resource_governor_resource_pools AS rp
OUTER APPLY (
SELECT COUNT(1) AS workload_group_count
FROM sys.dm_resource_governor_workload_groups AS wg
WHERE wg.pool_id = rp.pool_id
) AS wg;
```
# RDS for SQL Server 인스턴스에 대한 Microsoft SQL Server 리소스 거버너 비활성화
RDS for SQL Server에서 리소스 거버너를 비활성화하면 서비스가 워크로드 리소스 관리를 중지합니다. 리소스 거버너를 비활성화하기 전에 이것이 데이터베이스 연결 및 구성에 미치는 영향을 검토하세요.
리소스 거버너를 비활성화하면 다음과 같은 결과가 나타납니다.
+ 분류자 함수는 새 연결이 열릴 때 실행되지 않습니다.
+ 새 연결은 자동으로 기본 워크로드 그룹으로 분류됩니다.
+ 기존 워크로드 그룹 및 리소스 풀 설정은 모두 기본값으로 재설정됩니다.
+ 제한에 도달하면 이벤트가 실행되지 않습니다.
+ 리소스 거버너 구성은 변경할 수 있지만 리소스 거버너가 활성화될 때까지는 변경 사항이 적용되지 않습니다.
리소스 관리자 기능을 비활성화하려면 해당 옵션 그룹에서 `RESOURCE_GOVERNOR` 옵션을 제거합니다.
## 콘솔
다음 절차에서는 `RESOURCE_GOVERNOR` 옵션을 제거합니다.
**옵션 그룹에서 RESOURCE\$1GOVERNOR 옵션 제거**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **옵션 그룹**을 선택합니다.
1. `RESOURCE_GOVERNOR` 옵션이 있는 옵션 그룹을 선택합니다(이전 예제의 경우 `resource-governor-ee-2022`).
1. **옵션 삭제**를 선택합니다.
1. **삭제 옵션**에서 **삭제할 옵션**으로 **RESOURCE\$1GOVERNOR**를 선택합니다.
1. **Apply immediately**(즉시 적용)에서 **Yes**(예)를 선택하여 옵션을 즉시 삭제하거나 **No**(아니오)를 선택하여 다음 유지 관리 기간에 삭제합니다.
1. **삭제**를 선택합니다.
## CLI
다음 절차에서는 `RESOURCE_GOVERNOR` 옵션을 제거합니다.
**옵션 그룹에서 RESOURCE\$1GOVERNOR 옵션 제거**
+ 다음 명령 중 하나를 실행합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds remove-option-from-option-group \
--option-group-name resource-governor-ee-2022 \
--options RESOURCE_GOVERNOR \
--apply-immediately
```
Windows의 경우:
```
aws rds remove-option-from-option-group ^
--option-group-name resource-governor-ee-2022 ^
--options RESOURCE_GOVERNOR ^
--apply-immediately
```
# RDS for SQL Server에서 리소스 거버너를 구성하는 모범 사례
리소스 소비를 제어하기 위해 RDS for SQL Server는 Microsoft SQL Server 리소스 거버너를 지원합니다. 다음 모범 사례는 일반적인 구성 문제를 방지하고 데이터베이스 성능을 최적화하는 데 도움이 됩니다.
1. 리소스 거버너 구성은 `master` 데이터베이스에 저장됩니다. 리소스 관리자 구성 스크립트의 사본을 항상 별도로 저장하는 것이 좋습니다.
1. 분류기 함수는 로그인 처리 시간을 연장하므로 분류기에서 복잡한 로직을 피하는 것이 좋습니다. 지나치게 복잡한 함수는 Amazon RDS 자동화 세션을 포함하여 로그인 지연 또는 연결 제한 시간을 유발할 수 있습니다. 이는 인스턴스 상태를 모니터링하는 Amazon RDS 자동화 기능에 영향을 미칠 수 있습니다. 따라서 프로덕션 환경에서 구현하기 전에 항상 사전 프로덕션 환경에서 분류기 함수를 테스트하는 것이 좋습니다.
1. 워크로드 그룹에서 `REQUEST_MAX_MEMORY_GRANT_PERCENT`에 대한 높은 값(70 이상)을 설정하지 마세요. 이렇게 하면 데이터베이스 인스턴스가 다른 동시 쿼리에 충분한 메모리를 할당하지 못하여 메모리 권한 제한 시간 오류(오류 8645)가 발생할 수 있습니다. 반대로이 값을 너무 낮거나(1 미만) 0으로 설정하면 메모리 워크스페이스가 필요한 쿼리(정렬 또는 해시 작업과 관련된 쿼리 등)가 사용자 정의 워크로드 그룹에서 제대로 실행되지 않을 수 있습니다. RDS는 기본 워크로드 그룹에서 값을 1\$170으로 제한하여 이러한 제한을 적용합니다.
1. tempdb를 리소스 풀에 바인딩하는 경우 메모리 최적화 tempdb 메타데이터를 풀에 바인딩한 후 풀이 최대 설정에 도달할 수 있으며 `tempdb`를 사용하는 쿼리는 out-of-memory 오류로 인해 실패할 수 있습니다. 경우에 따라 메모리 부족 오류가 발생할 경우 SQL Server가 중지될 수 있습니다. 이러한 일이 발생할 가능성을 줄이려면 메모리 풀의 `MAX_MEMORY_PERCENT`를 높은 값으로 설정합니다.
# Amazon RDS for Microsoft SQL Server에 대한 일반 DBA 작업
이 단원에서는 Microsoft SQL Server 데이터베이스 엔진을 실행하는 DB 인스턴스의 몇 가지 일반적인 DBA 작업을 Amazon RDS에 따라 구현하는 방법에 대해 살펴봅니다. 관리되는 서비스 환경을 제공하기 위해 Amazon RDS는 DB 인스턴스에 대해 셸 액세스를 제공하지 않으며, 고급 권한을 필요로 하는 특정 시스템 절차와 테이블에 대한 액세스를 제한합니다.
**참고**
SQL Server DB 인스턴스를 이용한 작업에서는 스크립트를 실행하여 새롭게 생성한 데이터베이스를 수정할 수는 있지만 새로운 데이터베이스 모델로 사용되는 데이터베이스인 [모델] 데이터베이스는 수정할 수 없습니다.
**Topics**
+ [Amazon RDS에서 실행되는 Microsoft SQL Server DB 인스턴스의 tempdb 데이터베이스에 액세스](SQLServer.TempDB.md)
+ [데이터베이스 엔진 튜닝 관리자를 사용하여 Amazon RDS for SQL Server DB 인스턴스의 데이터베이스 워크로드 분석](Appendix.SQLServer.CommonDBATasks.Workload.md)
+ [Amazon RDS for SQL Server 데이터베이스 `db_owner`를 `rdsa` 계정으로 변경](Appendix.SQLServer.CommonDBATasks.ChangeDBowner.md)
+ [Amazon RDS for Microsoft SQL Server의 데이터 정렬 및 문자 세트 관리](Appendix.SQLServer.CommonDBATasks.Collation.md)
+ [Amazon RDS for SQL Server용 데이터베이스 사용자 생성](Appendix.SQLServer.CommonDBATasks.CreateUser.md)
+ [Amazon RDS for SQL Server 데이터베이스에 적용할 복구 모델 결정](Appendix.SQLServer.CommonDBATasks.DatabaseRecovery.md)
+ [Amazon RDS for SQL Server의 마지막 장애 조치 시간 결정](Appendix.SQLServer.CommonDBATasks.LastFailover.md)
+ [로그 시퀀스 번호 차이로 인한 시점 복구 실패 문제 해결](Appendix.SQLServer.CommonDBATasks.PITR-LSN-Gaps.md)
+ [Amazon RDS for SQL Server의 데이터베이스 이름 보기 거부 또는 허용](Appendix.SQLServer.CommonDBATasks.ManageView.md)
+ [Amazon RDS for SQL Server에 대한 대량 로드 중 빠른 삽입 비활성화](Appendix.SQLServer.CommonDBATasks.DisableFastInserts.md)
+ [Amazon RDS for Microsoft SQL Server DB 인스턴스 데이터베이스 삭제](Appendix.SQLServer.CommonDBATasks.DropMirrorDB.md)
+ [다중 AZ 배포의 Amazon RDS for Microsoft SQL Server 데이터베이스 이름 변경](Appendix.SQLServer.CommonDBATasks.RenamingDB.md)
+ [Amazon RDS for SQL Server 마스터 사용자의 db\$1owner 역할 멤버십 재설정](Appendix.SQLServer.CommonDBATasks.ResetPassword.md)
+ [Amazon RDS for SQL Server에 대한 라이선스 종료 DB 인스턴스 복원](Appendix.SQLServer.CommonDBATasks.RestoreLTI.md)
+ [오프라인에서 온라인으로 Amazon RDS for SQL Server 데이터베이스 전환](Appendix.SQLServer.CommonDBATasks.TransitionOnline.md)
+ [Amazon RDS for SQL Server에 변경 데이터 캡처 사용](Appendix.SQLServer.CommonDBATasks.CDC.md)
+ [Amazon RDS에 SQL Server Agent 사용](Appendix.SQLServer.CommonDBATasks.Agent.md)
+ [Amazon RDS for Microsoft SQL Server 로그 작업](Appendix.SQLServer.CommonDBATasks.Logs.md)
+ [Amazon RDS for SQL Server에 대한 추적 및 덤프 파일 작업](Appendix.SQLServer.CommonDBATasks.TraceFiles.md)
# Amazon RDS에서 실행되는 Microsoft SQL Server DB 인스턴스의 tempdb 데이터베이스에 액세스
Amazon RDS에서 실행되는 Microsoft SQL Server DB 인스턴스의 `tempdb` 데이터베이스에 액세스할 수 있습니다. Microsoft SQL Server Management Studio(SSMS)를 통한 Transact-SQL 또는 기타 표준 SQL 클라이언트 애플리케이션을 사용하여 `tempdb`에서 코드를 실행할 수 있습니다. DB 인스턴스 연결에 대한 자세한 내용은 [Microsoft SQL Server DB 인스턴스에 연결](USER_ConnectToMicrosoftSQLServerInstance.md) 단원을 참조하십시오.
DB 인스턴스의 마스터 사용자는 `CONTROL` 데이터베이스 옵션을 수정할 수 있도록 `tempdb`에 대한 `tempdb` 액세스 권한을 부여받습니다. 마스터 사용자는 `tempdb` 데이터베이스의 데이터베이스 소유자가 아닙니다. 필요한 경우 마스터 사용자는 다른 사용자가 `CONTROL` 데이터베이스 옵션을 수정할 수 있도록 이들에게 `tempdb` 액세스 권한을 부여할 수 있습니다.
**참고**
`tempdb` 데이터베이스에서 Database Console Commands(DBCC)를 실행할 수 없습니다.
# tempdb 데이터베이스 옵션 수정
Amazon RDS DB 인스턴스에 있는 `tempdb` 데이터베이스의 데이터베이스 옵션을 수정할 수 있습니다. 수정할 수 있는 옵션에 대한 자세한 내용은 Microsoft 설명서의 [tempdb 데이터베이스](https://msdn.microsoft.com/en-us/library/ms190768%28v=sql.120%29.aspx)를 참조하십시오.
최대 파일 크기 옵션과 같은 데이터베이스 옵션은 DB 인스턴스를 다시 시작한 후에도 유지됩니다. 데이터를 가져올 때 성능을 최적화하고 스토리지 부족을 방지하도록 데이터베이스 옵션을 수정할 수 있습니다.
## 데이터를 가져올 때 성능 최적화
대량의 데이터를 DB 인스턴스로 가져올 때 성능을 최적화하려면 tempdb 데이터베이스의 `SIZE` 및 `FILEGROWTH` 속성을 큰 수로 설정합니다. `tempdb`를 최적화하는 방법에 대한 자세한 내용은 Microsoft 설명서의 [tempdb 성능 최적화](https://technet.microsoft.com/en-us/library/ms175527%28v=sql.120%29.aspx)를 참조하십시오.
다음은 크기를 100GB로, 파일 증가를 10%로 설정한 예입니다.
```
1. alter database[tempdb] modify file (NAME = N'templog', SIZE=100GB, FILEGROWTH = 10%)
```
## 스토리지 문제 방지
`tempdb` 데이터베이스에서 사용 가능한 모든 디스크 공간을 사용하는 것을 방지하려면 `MAXSIZE` 속성을 설정합니다. 다음은 속성을 2048MB로 설정한 예입니다.
```
1. alter database [tempdb] modify file (NAME = N'templog', MAXSIZE = 2048MB)
```
# tempdb 데이터베이스 축소
Amazon RDS DB 인스턴스의 `tempdb` 데이터베이스는 두 가지 방법으로 축소할 수 있습니다. `rds_shrink_tempdbfile` 프로시저를 사용하거나, `SIZE` 속성을 설정하면 됩니다.
## rds\$1shrink\$1tempdbfile 프로시저 사용
Amazon RDS 프로시저 `msdb.dbo.rds_shrink_tempdbfile`를 사용하여 `tempdb` 데이터베이스를 축소할 수 있습니다. `rds_shrink_tempdbfile`에 대한 `CONTROL` 액세스 권한이 있는 경우에만 `tempdb`을 호출할 수 있습니다. `rds_shrink_tempdbfile`을 호출해도 DB 인스턴스에 가동 중지가 발생하지 않습니다.
`rds_shrink_tempdbfile` 프로시저에는 다음과 같은 파라미터가 있습니다.
****
| 파라미터 이름 | 데이터 형식 | 기본값 | 필수 | 설명 |
| --- | --- | --- | --- | --- |
| `@temp_filename` | SYSNAME | — | 필수 | 축소할 파일의 논리적 이름입니다. |
| `@target_size` | int | null | 선택 사항 | 파일의 새로운 크기(MB)입니다. |
다음 예제에서는 `tempdb` 데이터베이스의 파일 이름을 가져옵니다.
```
1. use tempdb;
2. GO
3.
4. select name, * from sys.sysfiles;
5. GO
```
다음 예제에서는 `tempdb`이라는 `test_file` 데이터베이스 파일을 축소하고 새로운 `10`MB 크기를 요청합니다.
```
1. exec msdb.dbo.rds_shrink_tempdbfile @temp_filename = N'test_file', @target_size = 10;
```
## SIZE 속성 설정
`tempdb` 속성을 설정한 다음 DB 인스턴스를 다시 시작하여 `SIZE` 데이터베이스를 축소할 수도 있습니다. DB 인스턴스를 다시 시작하는 방법에 대한 자세한 내용은 [ DB 인스턴스 재부팅](USER_RebootInstance.md) 단원을 참조하십시오.
다음은 `SIZE` 속성을 1024MB로 설정한 예입니다.
```
1. alter database [tempdb] modify file (NAME = N'templog', SIZE = 1024MB)
```
# 다중 AZ 배포에 대한 TempDB 구성
RDS for SQL Server DB 인스턴스가 데이터베이스 미러링(DBM) 또는 상시 작동 가용성 그룹(AG)을 사용하는 다중 AZ 배포에 있는 경우, `tempdb` 데이터베이스 사용에 대한 다음 고려 사항을 유념하세요.
기본 DB 인스턴스에서 보조 DB 인스턴스로 `tempdb` 데이터를 복제할 수 없습니다. 보조 DB 인스턴스로 장애 조치하면 보조 DB 인스턴스에 있는 `tempdb`는 비어 있게 됩니다.
파일 크기 조정 및 자동 증가 설정을 비롯한 `tempdb` 데이터베이스 옵션의 구성을 기본 DB 인스턴스에서 보조 DB 인스턴스로 동기화할 수 있습니다. `tempDB` 구성 동기화는 모든 RDS for SQL Server 버전에서 지원됩니다. 다음 저장 프로시저를 사용하여 `tempdb` 구성의 자동 동기화를 켤 수 있습니다.
```
EXECUTE msdb.dbo.rds_set_system_database_sync_objects @object_types = 'TempDbFile';
```
**중요**
`rds_set_system_database_sync_objects` 저장 프로시저를 사용하기 전에 보조 DB 인스턴스가 아닌 기본 DB 인스턴스에서 기본 `tempdb` 구성을 설정했는지 확인하세요. 보조 DB 인스턴스에서 구성을 변경한 경우 자동 동기화를 켜면 기본 `tempdb` 구성이 삭제될 수 있습니다.
다음 기능을 사용하면 `tempdb` 구성 자동 동기화가 켜져 있는지 확인할 수 있습니다.
```
SELECT * from msdb.dbo.rds_fn_get_system_database_sync_objects();
```
`tempdb` 구성 자동 동기화가 켜져 있는 경우 `object_class` 필드에 반환 값이 표시됩니다. 끄면 값이 반환되지 않습니다.
다음 함수를 사용하여 객체가 마지막으로 동기화된 시간(UTC 시간)을 찾을 수 있습니다.
```
SELECT * from msdb.dbo.rds_fn_server_object_last_sync_time();
```
예를 들어, 01:00에 `tempdb` 구성을 수정한 다음 `rds_fn_server_object_last_sync_time` 함수를 실행하는 경우 에서 반환되는 값은 01:00 `last_sync_time` 이후여야 하며, 이는 자동 동기화가 발생했음을 나타냅니다.
SQL Server 에이전트 작업 복제를 함께 사용하는 경우 `@object_type` 파라미터에 SQL 에이전트 작업과 `tempdb` 구성을 제공하여 둘 모두에 대해 복제를 활성화할 수 있습니다.
```
EXECUTE msdb.dbo.rds_set_system_database_sync_objects @object_types = 'SQLAgentJob,TempDbFile';
```
SQL Server 에이전트 작업 복제에 대한 자세한 내용은 [SQL Server 에이전트 작업 복제 켜기](Appendix.SQLServer.CommonDBATasks.Agent.md#SQLServerAgent.Replicate) 섹션을 참조하세요.
`tempdb` 구성 변경 내용이 자동으로 동기화되도록 `rds_set_system_database_sync_objects` 저장 프로시저를 사용하는 대신 다음과 같은 수동 방법 중 하나를 사용할 수 있습니다.
**참고**
`rds_set_system_database_sync_objects` 저장 프로시저를 사용하여 `tempdb` 구성의 자동 동기화를 켤 수 있습니다. 자동 동기화를 사용하면 `tempdb` 구성을 변경할 때마다 이러한 수동 작업을 수행할 필요가 없습니다.
+ 먼저 DB 인스턴스를 수정하고 다중 AZ를 비활성화한 다음 tempdb를 수정하고 마지막으로 다중 AZ를 다시 활성화합니다. 이 방법을 사용하는 경우 가동 중지가 없습니다.
자세한 내용은 [Amazon RDS DB 인스턴스 수정](Overview.DBInstance.Modifying.md) 섹션을 참조하세요.
+ 먼저 원래의 기본 인스턴스에서 `tempdb`를 수정한 다음, 수동으로 장애 조치를 수행하고, 마지막으로 새 기본 인스턴스에서 `tempdb`를 수정합니다. 이 방법을 사용하는 경우 가동 중지가 있습니다.
자세한 내용은 [ DB 인스턴스 재부팅](USER_RebootInstance.md) 단원을 참조하십시오.
# 데이터베이스 엔진 튜닝 관리자를 사용하여 Amazon RDS for SQL Server DB 인스턴스의 데이터베이스 워크로드 분석
데이터베이스 엔진 튜닝 관리자는 Microsoft에서 제공하는 클라이언트 애플리케이션으로, 데이터베이스 워크로드를 분석하고 실행하는 쿼리 종류에 따라 Microsoft SQL Server 데이터베이스에 대한 최적의 인덱스 집합을 권장합니다. SQL Server Management Studio와 마찬가지로 튜닝 어드바이저 역시 SQL Server 기반 Amazon RDS DB 인스턴스에 연결되어 있는 클라이언트 컴퓨터에서 실행됩니다. 여기서 클라이언트 컴퓨터는 기업 네트워크 내 온프레미스에서 실행되는 로컬 컴퓨터가 될 수도 있고, 혹은 Amazon RDS DB 인스턴스와 동일한 리전에서 실행되는 Amazon EC2 Windows 인스턴스가 될 수도 있습니다.
이 섹션에서는 튜닝 어드바이저의 분석 워크로드를 캡처하는 방법에 대해 살펴보겠습니다. Amazon RDS는 SQL Server 인스턴스에 대한 호스트 액세스를 제한하기 때문에 이 방법은 워크로드 캡처에 우선적으로 사용되는 프로세스입니다. 자세한 내용은 Microsoft 설명서의 [데이터베이스 엔진 튜닝 관리자](https://docs.microsoft.com/en-us/sql/relational-databases/performance/database-engine-tuning-advisor)를 참조하세요.
튜닝 어드바이저를 사용하려면 먼저 워크로드를 어드바이저에게 제공해야 합니다. 여기서 워크로드란 튜닝하려는 데이터베이스에 실행하는 Transact-SQL 문의 집합을 말합니다. 데이터베이스 엔진 튜닝 어드바이저는 데이터베이스를 튜닝할 때 트레이스 파일, 트레이스 테이블, Transact-SQL 스크립트 또는 XML 파일을 워크로드 입력 수단으로 사용합니다. Amazon RDS에서는 클라이언트 컴퓨터의 파일이나 클라이언트 컴퓨터에 액세스할 수 있는 Amazon RDS for SQL Server DB의 데이터베이스 테이블을 워크로드로 사용할 수도 있습니다. 하지만 파일이든, 테이블이든 상관없이 튜닝하려는 데이터베이스에 대한 쿼리는 재실행에 적합한 형식에 따라 저장되어야 합니다.
튜닝 어드바이저의 효과를 극대화하려면 워크로드가 최대한 사실적이어야 합니다. 워크로드 파일이나 테이블은 DB 인스턴스에 대한 트레이스를 수행하여 생성할 수 있습니다. 트레이스가 실행 중일 때도 DB 인스턴스에 가해지는 부하를 시뮬레이션하거나 정상적인 부하로 애플리케이션을 실행할 수 있습니다.
트레이스는 클라이언트 측과 서버 측, 두 가지 유형이 있습니다. 클라이언트 측 트레이스는 설치가 더욱 쉬울 뿐만 아니라 트레이스 이벤트가 캡처되는 것을 SQL Server 프로파일러에서 실시간으로 볼 수 있습니다. 반면 서버 측 트레이스는 설치가 더욱 복잡할 뿐만 아니라 몇 가지 Transact-SQL 스크립트를 작성해야 합니다. 그뿐만 아니라 트레이스가 Amazon RDS DB 인스턴스의 파일에 기록되기 때문에 스토리지 공간을 차지하게 됩니다. DB 인스턴스는 스토리지가 가득 찬 상태가 되어 스토리지 공간이 부족할 경우 더 이상 사용할 수 없기 때문에 실행 중인 서버 측 트레이스가 사용하는 스토리지 공간을 계속해서 추적해야 합니다.
클라이언트 측 트레이스의 경우, SQL Server 프로파일러에 트레이스 데이터가 충분히 캡처되면 트레이스를 로컬 컴퓨터의 파일이나 클라이언트 컴퓨터에 액세스할 수 있는 DB 인스턴스의 데이터베이스 테이블에 저장하여 워크로드 파일을 생성할 수 있습니다. 하지만 클라이언트 측 트레이스를 사용할 때는 과도한 부하 시 트레이스가 쿼리를 모두 캡처하지 못한다는 커다란 단점이 있습니다. 이로 인해 데이터베이스 엔진 튜닝 어드바이저의 분석 효과가 약해질 수 있습니다. 따라서 과도한 부하에서 트레이스를 실행하면서 트레이스 세션 중 모든 쿼리를 캡처해야 하는 경우에는 서버 측 트레이스를 사용하는 것이 바람직합니다.
서버 측 트레이스에서는 DB 인스턴스의 트레이스 파일을 적합한 워크로드 파일로 가져오거나, 완료된 트레이스를 DB 인스턴스의 테이블에 저장할 수 있습니다. 또한 SQL Server 프로파일러를 사용해 트레이스를 로컬 컴퓨터의 파일에 저장하거나 튜닝 어드바이저를 사용해 DB 인스턴스의 트레이스 테이블을 읽을 수 있습니다.
# SQL Server DB 인스턴스의 클라이언트 측 트레이스 실행
**SQL Server DB 인스턴스의 클라이언트 측 트레이스를 실행하는 방법**
1. SQL Server 프로파일러를 시작합니다. 이 프로파일러는 SQL Server 인스턴스 폴더 내 Performance Tools 폴더에 설치되어 있습니다. 클라이언트 측 트레이스를 시작하려면 트레이스 정의 템플릿을 로드하거나 정의해야 합니다.
1. SQL Server 프로파일러 파일 메뉴에서 **New Trace(새 트레이스)**를 선택합니다. [**Connect to Server**] 대화 상자에 DB 인스턴스 엔드포인트, 포트, 마스터 사용자 이름 그리고 트레이스를 실행할 데이터베이스의 암호를 입력합니다.
1. [**Trace Properties**] 대화 상자에 트레이스 이름을 입력한 다음 트레이스 정의 템플릿을 선택합니다. 기본 템플릿인 TSQL\$1Replay는 애플리케이션으로 제공됩니다. 이 템플릿을 편집하여 트레이스를 정의할 수 있습니다. [**Trace Properties**] 대화 상자의 [**Events Selection**] 탭 아래 있는 이벤트와 이벤트 정보를 편집합니다.
추적 정의 템플릿 및 SQL Server 프로파일러를 사용하여 클라이언트 측 추적을 지정하는 방법에 대한 자세한 내용은 Microsoft 설명서의 [데이터베이스 엔진 튜닝 관리자](https://docs.microsoft.com/en-us/sql/relational-databases/performance/database-engine-tuning-advisor)를 참조하세요.
1. 클라이언트 측 트레이스를 시작하여 DB 인스턴스에 대한 SQL 쿼리 실행을 실시간으로 모니터링합니다.
1. 트레이스가 완료되면 **파일** 메뉴에서 **Stop Trace(트레이스 중지)**를 선택합니다. 결과를 파일이나 DB 인스턴스의 트레이스 테이블로 저장합니다.
# SQL Server DB 인스턴스의 서버 측 트레이스 실행
스크립트를 작성하여 서버 측 트레이스를 생성하는 것은 복잡할 뿐만 아니라 이 문서의 범위에서 벗어납니다. 따라서 여기서는 예제로 사용할 수 있는 샘플 스크립트만 다룹니다. 클라이언트 측 트레이스와 마찬가지로 이 트레이스의 목적 역시 데이터베이스 엔진 튜닝 어드바이저를 사용해 열 수 있도록 워크로드 파일 또는 트레이스를 생성하는 데 있습니다.
다음은 서버 측 트레이스를 시작하여 세부 정보를 워크 로드에 캡처하기 위해 요약된 예제 스크립트입니다. 트레이스가 처음에는 D:\$1RDSDBDATA\$1Log 디렉터리의 RDSTrace.trc 파일에 저장되지만 100MB마다 롤오버되어 이후부터는 RDSTrace\$11.trc, RDSTrace\$12.trc 등의 이름으로 트레이스 파일이 저장됩니다.
```
DECLARE @file_name NVARCHAR(245) = 'D:\RDSDBDATA\Log\RDSTrace';
DECLARE @max_file_size BIGINT = 100;
DECLARE @on BIT = 1
DECLARE @rc INT
DECLARE @traceid INT
EXEC @rc = sp_trace_create @traceid OUTPUT, 2, @file_name, @max_file_size
IF (@rc = 0) BEGIN
EXEC sp_trace_setevent @traceid, 10, 1, @on
EXEC sp_trace_setevent @traceid, 10, 2, @on
EXEC sp_trace_setevent @traceid, 10, 3, @on
. . .
EXEC sp_trace_setfilter @traceid, 10, 0, 7, N'SQL Profiler'
EXEC sp_trace_setstatus @traceid, 1
END
```
다음은 트레이스를 중단하는 스크립트 예제입니다. 단, 이전 스크립트에서 생성된 트레이스는 명시적으로 트레이스가 중단되거나, 프로세스의 디스크 공간이 부족해질 때까지 계속 실행됩니다.
```
DECLARE @traceid INT
SELECT @traceid = traceid FROM ::fn_trace_getinfo(default)
WHERE property = 5 AND value = 1 AND traceid <> 1
IF @traceid IS NOT NULL BEGIN
EXEC sp_trace_setstatus @traceid, 0
EXEC sp_trace_setstatus @traceid, 2
END
```
서버 측 트레이스 결과는 데이터베이스 테이블로 저장한 후 fn\$1trace\$1gettable 함수를 이용하면 튜닝 어드바이저의 워크로드로 사용할 수 있습니다. 다음 명령은 RDSTrace\$11.trc 등의 모든 롤오버 파일을 포함해 D:\$1rdsdbdata\$1Log 디렉터리에서 RDSTrace.trc라는 이름의 모든 파일 결과를 현재 데이터베이스에서 RDSTrace라는 이름의 테이블로 로드합니다.
```
SELECT * INTO RDSTrace
FROM fn_trace_gettable('D:\rdsdbdata\Log\RDSTrace.trc', default);
```
예를 들어 RDSTrace\$11.trc 같이 특정 롤오버 파일을 테이블에 저장하려면 롤오버 파일의 이름을 지정한 다음 fn\$1trace\$1gettable의 마지막 파라미터를 default가 아닌 1로 변경합니다.
```
SELECT * INTO RDSTrace_1
FROM fn_trace_gettable('D:\rdsdbdata\Log\RDSTrace_1.trc', 1);
```
# 트레이스를 이용한 튜닝 어드바이저 실행
로컬 파일이든 데이터베이스 테이블이든 상관없이 트레이스가 생성되면 이제 DB 인스턴스에 대해 튜닝 어드바이저를 실행할 수 있습니다. Amazon RDS와 함께 튜닝 어드바이저를 사용하는 방법은 독립된 원격 SQL Server 인스턴스를 사용할 때와 프로세스가 동일합니다. 그 밖에 클라이언트 컴퓨터에서 튜닝 어드바이저 UI를 사용하거나 명령줄에서 dta.exe 유틸리티를 사용할 수도 있습니다. 하지만 두 가지 경우 모두 DB 인스턴스 엔드포인트를 사용하여 Amazon RDS DB 인스턴스에 연결한 후 마스터 사용자 이름과 마스터 사용자 암호를 입력해야만 튜닝 어드바이저를 사용할 수 있습니다.
다음 코드 예제는 **dta.cnazcmklsdei.us-east-1.rds.amazonaws.com** 엔드포인트에서 Amazon RDS DB 인스턴스에 대해 dta.exe 명령줄 유틸리티를 사용하는 방법을 나타냅니다. 이 예에는 마스터 사용자 이름 **admin** 및 마스터 사용자 암호 **test**가 포함되며 튜닝할 예제 데이터베이스의 이름은 **C:\$1RDSTrace.trc**라는 머신 이름으로 지정됩니다. 또한 예제 명령줄 코드를 보면 트레이스 세션 이름을 **RDSTrace1**로 지정하였으며, 로컬 컴퓨터에 출력되는 파일 이름을 SQL 출력 스크립트의 경우 **RDSTrace.sql**로, 결과 파일의 경우 **RDSTrace.txt**로, 그리고 분석한 XML 파일의 경우 **RDSTrace.xml**로 지정하였습니다. 마지막으로 RDSDTA 데이터베이스 이름을 **RDSTraceErrors**로 지정한 오류 테이블도 있습니다.
```
dta -S dta.cnazcmklsdei.us-east-1.rds.amazonaws.com -U admin -P test -D RDSDTA -if C:\RDSTrace.trc -s RDSTrace1 -of C:\ RDSTrace.sql -or C:\ RDSTrace.txt -ox C:\ RDSTrace.xml -e RDSDTA.dbo.RDSTraceErrors
```
다음 예제 명령줄 코드는 입력 워크로드가 **RDSTrace** 데이터베이스에서 **RDSDTA**라는 이름의 원격 Amazon RDS 인스턴스에 저장된 테이블이라는 점을 제외하고 모두 동일합니다.
```
dta -S dta.cnazcmklsdei.us-east-1.rds.amazonaws.com -U admin -P test -D RDSDTA -it RDSDTA.dbo.RDSTrace -s RDSTrace1 -of C:\ RDSTrace.sql -or C:\ RDSTrace.txt -ox C:\ RDSTrace.xml -e RDSDTA.dbo.RDSTraceErrors
```
dta 유틸리티 명령줄 파라미터의 전체 목록은 Microsoft 설명서의 [dta 유틸리티](https://docs.microsoft.com/en-us/sql/tools/dta/dta-utility)를 참조하세요.
# Amazon RDS for SQL Server 데이터베이스 `db_owner`를 `rdsa` 계정으로 변경
RDS for SQL Server DB 인스턴스에서 데이터베이스를 생성하거나 복원하는 경우 Amazon RDS가 데이터베이스 소유자를 `rdsa`로 설정합니다. SQL Server 데이터베이스 미러링(DBM) 또는 상시 가동 가용성 그룹(AG)을 사용하는 다중 AZ 배포의 경우 Amazon RDS는 보조 DB 인스턴스의 데이터베이스 소유자를 `NT AUTHORITY\SYSTEM`으로 설정합니다. 보조 DB 인스턴스가 기본 역할로 승격되기 전까지는 보조 데이터베이스의 소유자를 변경할 수 없습니다. 대부분의 경우 쿼리를 실행할 때 데이터베이스 소유자를 `NT AUTHORITY\SYSTEM`으로 설정하는 것은 문제가 되지 않지만, 실행을 위해 승격된 권한이 필요한 `sys.sp_updatestats`와 같은 시스템 저장 프로시저를 실행할 때는 오류가 발생할 수 있습니다.
다음 쿼리를 사용하여 `NT AUTHORITY\SYSTEM`에서 소유한 데이터베이스의 소유자를 식별할 수 있습니다.
```
SELECT name FROM sys.databases WHERE SUSER_SNAME(owner_sid) = 'NT AUTHORITY\SYSTEM';
```
Amazon RDS 저장 프로시저 `rds_changedbowner_to_rdsa`를 사용하여 데이터베이스 소유자를 `rdsa`로 변경할 수 있습니다. 다음 데이터베이스는 `rds_changedbowner_to_rdsa`와 함께 사용할 수 없습니다. `master, model, msdb, rdsadmin, rdsadmin_ReportServer, rdsadmin_ReportServerTempDB, SSISDB`
데이터베이스 소유자를 `rdsa`로 변경하려면 `rds_changedbowner_to_rdsa` 저장 프로시저를 호출하고 데이터베이스 이름을 입력합니다.
**Example 사용법:**
```
exec msdb.dbo.rds_changedbowner_to_rdsa 'TestDB1';
```
다음 파라미터는 필수입니다.
+ `@db_name` - 데이터베이스 소유자를 `rdsa`로 변경할 데이터베이스의 이름입니다.
**중요**
`rds_changedbowner_to_rdsa`를 사용하여 데이터베이스의 소유권을 `rdsa` 이외의 로그인으로 변경할 수 없습니다. 예를 들어 데이터베이스를 만들 때 사용한 로그인의 소유권을 변경할 수 없습니다. 다른 데이터베이스 사용자를 사용하여 멤버십을 부여할 수 없을 때 마스터 사용자의 `db_owner` 역할에서 손실된 멤버십을 복원하려면 마스터 사용자 암호를 재설정하여 `db_owner` 역할의 멤버십을 확보합니다. 자세한 내용은 [Amazon RDS for SQL Server 마스터 사용자의 db\$1owner 역할 멤버십 재설정](Appendix.SQLServer.CommonDBATasks.ResetPassword.md) 섹션을 참조하세요.
# Amazon RDS for Microsoft SQL Server의 데이터 정렬 및 문자 세트 관리
이 주제에서는 Amazon RDS에서 Microsoft SQL Server의 데이터 정렬 및 문자 세트를 관리하는 방법에 대한 지침을 제공합니다. 데이터베이스 생성 중에 데이터 정렬을 구성하고 나중에 수정하여 언어 및 로캘 요구 사항에 따라 텍스트 데이터를 적절하게 처리하는 방법을 설명합니다. 또한 Amazon RDS의 SQL Server 환경에서 호환성 및 성능을 유지하기 위한 모범 사례를 다룹니다.
SQL Server는 여러 수준에서 콜레이션을 지원합니다. DB 인스턴스를 생성할 때 기본 서버 콜레이션을 설정합니다. 데이터베이스, 테이블 또는 열 수준에서 콜레이션을 재정의할 수 있습니다.
**Topics**
+ [Microsoft SQL Server의 서버 수준 콜레이션](#Appendix.SQLServer.CommonDBATasks.Collation.Server)
+ [Microsoft SQL Server의 데이터베이스 수준 콜레이션](#Appendix.SQLServer.CommonDBATasks.Collation.Database-Table-Column)
## Microsoft SQL Server의 서버 수준 콜레이션
Microsoft SQL Server DB 인스턴스를 생성할 때 사용하려는 서버 콜레이션을 설정할 수 있습니다. 다른 콜레이션을 선택하지 않으면 서버 수준 콜레이션이 SQL\$1Latin1\$1General\$1CP1\$1CI\$1AS으로 기본 설정됩니다. 모든 데이터베이스 및 데이터베이스 객체에 서버 콜레이션이 기본적으로 적용됩니다.
**참고**
DB 스냅샷에서 복원할 때 데이터 정렬을 변경할 수 없습니다.
현재 Amazon RDS에서는 다음과 같은 서버 콜레이션을 지원합니다.
| 콜레이션 | 설명 |
| --- | --- |
| Arabic\$1CI\$1AS | 아랍어, 대소문자 비구분, 액센트 구분, 일본어 가나 비구분, 전자/반자 비구분 |
| Chinese\$1PRC\$1BIN2 | 중국어-중화인민공화국어, 이진 코드 포인트 비교 정렬 |
| Chinese\$1PRC\$1CI\$1AS | 중국어-중화인민공화국어, 대소문자 비구분, 액센트 구분, 일본어 가나 비구분, 전자/반자 비구분 |
| Chinese\$1Taiwan\$1Stroke\$1CI\$1AS | 중국어-대만어-스트로크, 소문자 비구분, 액센트 구분, 일본어 가나 비구분, 전자/반자 비구분 |
| Danish\$1Norwegian\$1CI\$1AS | 덴마크어, 대소문자 비구분, 액센트 구분, 일본어 가나 비구분, 전자/반자 비구분 |
| Danish\$1Norwegian\$1CI\$1AS\$1KS | 덴마크-노르웨이어, 대소문자 비구분, 액센트 구분, 일본어 가나 비구분, 전자/반자 비구분 |
| Danish\$1Norwegian\$1CI\$1AS\$1KS\$1WS | 덴마크-노르웨이어, 대소문자 비구분, 액센트 구분, 일본어 가나 구분, 전자/반자 구분 |
| Danish\$1Norwegian\$1CI\$1AS\$1WS | 덴마크-노르웨이어, 대소문자 비구분, 액센트 구분, 일본어 가나 비구분, 전자/반자 구분 |
| Danish\$1Norwegian\$1CS\$1AI | 덴마크-노르웨이어, 대소문자 구분, 액센트 비구분, 일본어 가나 비구분, 전자/반자 비구분 |
| Danish\$1Norwegian\$1CS\$1AI\$1KS | 덴마크-노르웨이어, 대소문자 구분, 액센트 비구분, 일본어 가나 구분, 전자/반자 비구분 |
| Finnish\$1Swedish\$1100\$1BIN | Finnish-Swedish-100, 이진 정렬 |
| Finnish\$1Swedish\$1100\$1BIN2 | Finnish-Swedish-100, 이진 코드 포인트 비교 정렬 |
| Finnish\$1Swedish\$1100\$1CI\$1AI | Finnish-Swedish-100, 대소문자 비구분, 액센트 비구분, 일본어 가나 비구분, 전자/반자 비구분 |
| Finnish\$1Swedish\$1100\$1CI\$1AS | Finnish-Swedish-100, 대소문자 비구분, 액센트 구분, 일본어 가나 비구분, 전자/반자 비구분 |
| Finnish\$1Swedish\$1CI\$1AS | 핀란드어, 스웨덴어, 스웨덴어(핀란드), 대소문자 비구분, 액센트 구분, 일본어 가나 비구분, 전자/반자 비구분 |
| French\$1CI\$1AS | 프랑스어, 대소문자 비구분, 액센트 구분, 일본어 가나 비구분, 전자/반자 비구분 |
| Greek\$1CI\$1AS | 그리스어, 대소문자 비구분, 액센트 구분, 일본어 가나 비구분, 전자/반자 비구분 |
| Greek\$1CS\$1AS | 그리스어, 대소문자 구분, 액센트 구분, 일본어 가나 비구분, 전자/반자 비구분 |
| Hebrew\$1BIN | 히브리어, 이진 정렬 |
| Hebrew\$1CI\$1AS | 히브리어, 대소문자 비구분, 액센트 구분, 일본어 가나 비구분, 전자/반자 비구분 |
| Japanese\$1BIN | 일본어, 이진 정렬 |
| Japanese\$1CI\$1AS | 일본어, 대소문자 비구분, 액센트 구분, 일본어 가나 비구분, 전자/반자 비구분 |
| Japanese\$1CS\$1AS | 일본어, 대소문자 구분, 액센트 구분, 일본어 가나 비구분, 전자/반자 비구분 |
| Japanese\$1XJIS\$1140\$1CI\$1AS | 일본어, 대소문자 비구분, 액센트 비구분, 일본어 가나 비구분, 전자/반자 비구분, 보조 문자, 변형 선택기 비구분 |
| Japanese\$1XJIS\$1140\$1CI\$1AS\$1KS\$1VSS | 일본어, 대소문자 비구분, 액센트 구분, 일본어 가나 구분, 전자/반자 비구분, 보조 문자, 변형 선택기 구분 |
| Japanese\$1XJIS\$1140\$1CI\$1AS\$1VSS | 일본어, 대소문자 비구분, 액센트 구분, 일본어 가나 비구분, 전자/반자 비구분, 보조 문자, 변형 선택기 구분 |
| 일본어\$1XJIS\$1140\$1CS\$1AS\$1KS\$1WS | 일본어, 대소문자 구분, 액센트 구분, 일본어 가나 구분, 전자/반자 구분, 보조 문자, 변형 선택기 비구분 |
| Korean\$1Wansung\$1CI\$1AS | 한국어-완성형, 대소문자 비구분, 액센트 구분, 일본어 가나 비구분, 전자/반자 비구분 |
| Latin1\$1General\$1100\$1BIN | 라틴어1-일반-100, 이진 정렬 |
| Latin1\$1General\$1100\$1BIN2 | 라틴어1-일반-100, 이진 코드 포인트 비교 정렬 |
| Latin1\$1General\$1100\$1BIN2\$1UTF8 | Latin1-General-100, 이진 코드 포인트 비교 정렬, UTF-8 인코딩 |
| Latin1\$1General\$1100\$1CI\$1AS | 라틴어1-일반-100, 대소문자 비구분, 액센트 구분, 일본어 가나 비구분, 전자/반자 비구분 |
| Latin1\$1General\$1100\$1CI\$1AS\$1SC\$1UTF8 | Latin1-General-100, 대소문자 비구분, 액센트 구분, 보조 문자, UTF-8 인코딩 |
| Latin1\$1General\$1BIN | 라틴어1-일반, 이진 정렬 |
| Latin1\$1General\$1BIN2 | 라틴어1-일반, 이진 코드 포인트 비교 정렬 |
| Latin1\$1General\$1CI\$1AI | 라틴어1-일반, 대소문자 비구분, 액센트 비구분, 일본어 가나 비구분, 전자/반자 비구분 |
| Latin1\$1General\$1CI\$1AS | 라틴어1-일반, 대소문자 비구분, 액센트 구분, 일본어 가나 비구분, 전자/반자 비구분 |
| Latin1\$1General\$1CI\$1AS\$1KS | 라틴어1-일반, 대소문자 비구분, 액센트 구분, 일본어 가나 구분, 전자/반자 비구분 |
| Latin1\$1General\$1CS\$1AS | 라틴어1-일반, 대소문자 구분, 액센트 구분, 일본어 가나 비구분, 전자/반자 비구분 |
| Modern\$1Spanish\$1CI\$1AS | 현대-스페인어, 대소문자 비구분, 액센트 구분, 일본어 가나 비구분, 전자/반자 비구분 |
| Polish\$1CI\$1AS | 폴란드어, 대소문자 비구분, 액센트 구분, 일본어 가나 비구분, 전자/반자 비구분 |
| SQL\$11xCompat\$1CP850\$1CI\$1AS | 라틴어1-일반, 유니코드 데이터의 경우 대소문자 비구분, 액센트 구분, 일본어 가나 비구분, 전자/반자 비구분, 비 유니코드 데이터의 경우 코드 페이지 850의 SQL Server 정렬 순서 49 |
| SQL\$1Latin1\$1General\$1CP1\$1CI\$1AI | 라틴어1-일반, 유니코드 데이터의 경우 대소문자 비구분, 액센트 비구분, 일본어 가나 비구분, 전자/반자 비구분, 비 유니코드 데이터의 경우 코드 페이지 1252의 SQL Server 정렬 순서 54 |
| **SQL\$1Latin1\$1General\$1CP1\$1CI\$1AS(기본값)** | 라틴어1-일반, 유니코드 데이터의 경우 대소문자 비구분, 액센트 구분, 일본어 가나 비구분, 전자/반자 비구분, 비 유니코드 데이터의 경우 코드 페이지 1252의 SQL Server 정렬 순서 52 |
| SQL\$1Latin1\$1General\$1CP1\$1CS\$1AS | 라틴어1-일반, 유니코드 데이터의 경우 대소문자 구분, 액센트 구분, 일본어 가나 비구분, 전자/반자 비구분, 비 유니코드 데이터의 경우 코드 페이지 1252의 SQL Server 정렬 순서 51 |
| SQL\$1Latin1\$1General\$1CP437\$1CI\$1AI | 라틴어1-일반, 유니코드 데이터의 경우 대소문자 비구분, 액센트 비구분, 일본어 가나 비구분, 전자/반자 비구분, 비 유니코드 데이터의 경우 코드 페이지 437의 SQL Server 정렬 순서 34 |
| SQL\$1Latin1\$1General\$1CP850\$1BIN | 라틴어1-일반, 유니코드 데이터의 경우 이진 정렬 순서, 비유니코드 데이터의 경우 코드 페이지 850의 SQL Server 정렬 순서 40 |
| SQL\$1Latin1\$1General\$1CP850\$1BIN2 | 라틴어1-일반, 유니코드 데이터의 경우 이진 코드 포인트 비교, 비 유니코드 데이터의 경우 코드 페이지 850의 SQL Server 정렬 순서 40 |
| SQL\$1Latin1\$1General\$1CP850\$1CI\$1AI | 라틴어1-일반, 유니코드 데이터의 경우 대소문자 비구분, 액센트 비구분, 일본어 가나 비구분, 전자/반자 비구분, 비유니코드 데이터의 경우 코드 페이지 850의 SQL Server 정렬 순서 44 |
| SQL\$1Latin1\$1General\$1CP850\$1CI\$1AS | 라틴어1-일반, 유니코드 데이터의 경우 대소문자 비구분, 액센트 구분, 일본어 가나 비구분, 전자/반자 비구분, 비 유니코드 데이터의 경우 코드 페이지 850의 SQL Server 정렬 순서 42 |
| SQL\$1Latin1\$1General\$1Pref\$1CP850\$1CI\$1AS | Latin1-General-Pref, 유니코드 데이터의 경우 대소문자 비구분, 액센트 구분, 일본어 가나 비구분, 전자/반자 비구분, 비유니코드 데이터의 경우 코드 페이지 850의 SQL Server 정렬 순서 183 |
| SQL\$1Latin1\$1General\$1CP1256\$1CI\$1AS | 라틴어1-일반, 유니코드 데이터의 경우 대소문자 비구분, 액센트 구분, 일본어 가나 비구분, 전자/반자 비구분, 비 유니코드 데이터의 경우 코드 페이지 1256의 SQL Server 정렬 순서 146 |
| SQL\$1Latin1\$1General\$1CP1255\$1CS\$1AS | Latin1-General, 유니코드 데이터의 경우 대소문자 구분, 액센트 구분, 일본어 가나 비구분, 전자/반자 비구분, 비유니코드 데이터의 경우 코드 페이지 1255의 SQL Server 정렬 순서 137 |
| Thai\$1CI\$1AS | 프랑스어, 대소문자 비구분, 액센트 구분, 일본어 가나 비구분, 전자/반자 비구분 |
| Turkish\$1CI\$1AS | 터키어, 대소문자 비구분, 액센트 구분, 일본어 가나 비구분, 전자/반자 비구분 |
AWS CLI를 사용하여 프로그래밍 방식으로 지원되는 데이터 정렬 목록을 검색할 수도 있습니다.
```
aws rds describe-db-engine-versions --engine sqlserver-ee --list-supported-character-sets --query 'DBEngineVersions[].SupportedCharacterSets[].CharacterSetName' | sort -u
```
콜레이션을 선택하려면 다음을 수행하세요.
+ Amazon RDS 콘솔을 사용하는 경우 새 DB 인스턴스를 생성할 때 **Additional configuration**(추가 구성)을 선택한 다음 **Collation**(데이터 정렬) 필드에 데이터 정렬을 입력합니다. 자세한 내용은 [Amazon RDS DB 인스턴스 생성](USER_CreateDBInstance.md) 섹션을 참조하세요.
+ AWS CLI를 사용하는 경우 `--character-set-name` 명령과 함께 `create-db-instance` 옵션을 사용합니다. 자세한 내용은 [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)를 참조하세요.
+ Amazon RDS API를 사용하는 경우 `CharacterSetName` 작업과 함께 `CreateDBInstance` 파라미터를 사용합니다. 자세한 내용은 [CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html)를 참조하세요.
## Microsoft SQL Server의 데이터베이스 수준 콜레이션
새로운 데이터베이스 또는 데이터베이스 객체를 생성하면서 데이터 정렬을 무시하면 데이터베이스, 테이블 또는 열을 기준으로 기본 데이터 정렬을 변경할 수도 있습니다. 예를 들어 기본 서버 콜레이션이 SQL\$1Latin1\$1General\$1CP1\$1CI\$1AS인 경우, Mohawk 콜레이션 지원을 위해 이를 Mohawk\$1100\$1CI\$1AS로 변경할 수 있습니다. 모든 쿼리 인수는 필요에 따라 타입캐스트를 통해 다른 데이터 정렬을 사용할 수 있습니다.
예를 들어 다음 쿼리는 AccountName 열의 기본 콜레이션을 Japanese\$1CI\$1AS로 변경합니다.
```
CREATE TABLE [dbo].[Account]
(
[AccountID] [nvarchar](10) NOT NULL,
[AccountName] [nvarchar](100) COLLATE Mohawk_100_CI_AS NOT NULL
) ON [PRIMARY];
```
Microsoft SQL Server DB 엔진은 기본적인 NCHAR, NVARCHAR 및 NTEXT 데이터 유형에 따라 Unicode를 지원합니다. 이를 테면 CJK 지원이 필요할 경우 문자 스토리지에 이 세 가지 Unicode 데이터 유형을 사용하면 데이터베이스 및 테이블 생성 시 기본 서버 데이터 정렬을 무시할 수 있습니다. SQL Server에 대한 데이터 정렬 및 Unicode 지원을 설명한 Microsoft 링크를 몇 가지 소개합니다.
+ [Working with Collations](http://msdn.microsoft.com/en-us/library/ms187582%28v=sql.105%29.aspx)
+ [Collation and International Terminology](http://msdn.microsoft.com/en-us/library/ms143726%28v=sql.105%29)
+ [Using SQL Server Collations](http://msdn.microsoft.com/en-us/library/ms144260%28v=sql.105%29.aspx)
+ [International Considerations for Databases and Database Engine Applications](http://msdn.microsoft.com/en-us/library/ms190245%28v=sql.105%29.aspx)
# Amazon RDS for SQL Server용 데이터베이스 사용자 생성
다음 예와 같이 T-SQL 스크립트를 실행하여 Amazon RDS for Microsoft SQL Server DB 인스턴스의 데이터베이스 사용자를 생성할 수 있습니다. SQL 서버 관리 제품군(SSMS)과 같은 애플리케이션을 사용합니다. DB 인스턴스를 생성할 때 생성된 마스터 사용자로 DB 인스턴스에 로그인합니다.
```
--Initially set context to master database
USE [master];
GO
--Create a server-level login named theirname with password theirpassword
CREATE LOGIN [theirname] WITH PASSWORD = 'theirpassword';
GO
--Set context to msdb database
USE [msdb];
GO
--Create a database user named theirname and link it to server-level login theirname
CREATE USER [theirname] FOR LOGIN [theirname];
GO
```
데이터베이스 사용자를 역할에 추가하는 예는 [SQLAgentUser 역할에 사용자 추가](SQLServerAgent.AddUser.md) 섹션을 참조하세요.
**참고**
사용자를 추가할 때 권한 오류가 발생할 경우, DB 인스턴스 마스터 사용자 암호를 수정하여 복원할 수 있습니다. 자세한 내용은 [Amazon RDS for SQL Server 마스터 사용자의 db\$1owner 역할 멤버십 재설정](Appendix.SQLServer.CommonDBATasks.ResetPassword.md) 섹션을 참조하세요.
애플리케이션에서 마스터 사용자 권한을 복제하는 것은 모범 사례가 아닙니다. 자세한 내용은 [How to clone master user permissions in Amazon RDS for SQL Server](https://aws.amazon.com/blogs/database/how-to-clone-master-user-permissions-in-amazon-rds-for-sql-server/)를 참조하세요.
# Amazon RDS for SQL Server 데이터베이스에 적용할 복구 모델 결정
Amazon RDS에서 복구 모델, 보존 기간 및 데이터베이스 상태는 서로 연결되어 있습니다.
이러한 설정 중 하나를 변경하기 전에 결과를 이해하는 것이 중요합니다. 각 설정은 다른 설정에 영향을 줄 수 있습니다. 예:
+ 백업 보존이 활성화되어 있는 상태에서 데이터베이스의 복구 모델을 SIMPLE 또는 BULK\$1LOGGED로 변경하면 Amazon RDS는 5분 이내에 복구 모델을 FULL로 재설정합니다. 또한 RDS가 DB 인스턴스의 스냅샷을 캡처합니다.
+ 백업 보존을 `0`일로 설정하면 RDS가 복구 모드를 SIMPLE로 설정합니다.
+ 백업 보존이 `0`일로 설정되어 있는 상태에서 데이터베이스의 복구 모델을 SIMPLE에서 다른 옵션으로 변경하면 RDS가 복구 모델을 SIMPLE로 재설정합니다.
**중요**
ALTER DATABASE 등을 사용하여—수행할 수 있을 것처럼 보이더라도 다중 AZ 인스턴스에서 복구 모델을 절대로 변경하지 마십시오. 백업 보존, 따라서 전체 복구 모드는 다중 AZ에 필요합니다. 복구 모델을 변경하면 RDS가 즉시 다시 이를 FULL로 변경합니다.
이 자동 재설정을 수행하면 RDS가 미러를 완전히 재구축합니다. 이 재구축 중에 미러가 장애 조치에 대비할 때까지 약 30-90분 동안 데이터베이스의 가용성이 저하됩니다. 또한 DB 인스턴스는 단일 AZ에서 다중 AZ로 변환하는 경우와 같은 방식으로 성능 저하를 경험합니다. 성능이 저하되는 기간은 데이터베이스 스토리지 크기에 따라 달라지는데—저장된 데이터베이스가 클수록 성능 저하가 길어집니다.
SQL Server 복구 모델에 대한 자세한 내용은 Microsoft 설명서의 [복구 모델(SQL Server)](https://docs.microsoft.com/en-us/sql/relational-databases/backup-restore/recovery-models-sql-server)을 참조하세요.
# Amazon RDS for SQL Server의 마지막 장애 조치 시간 결정
마지막 장애 조치 시간을 확인하려면 다음 저장 프로시저를 사용합니다.
```
execute msdb.dbo.rds_failover_time;
```
이 프로시저는 다음 정보를 반환합니다.
****
| 출력 파라미터 | 설명 |
| --- | --- |
| errorlog\$1available\$1from | 로그 디렉터리에서 오류 로그를 사용할 수 있게 된 시간을 표시합니다. |
| recent\$1failover\$1time | 오류 로그에 장애 조치가 있는 경우 마지막 장애 조치 시간을 표시합니다. 그렇지 않은 경우 `null`입니다. |
**참고**
저장 프로시저는 로그 디렉터리에서 사용 가능한 모든 SQL Server 오류 로그를 검색하여 최근의 장애 조치 시간을 확인합니다. SQL Server에서 장애 조치 메시지를 덮어쓴 경우 프로시저는 장애 조치 시간을 확인하지 않습니다.
**Example 최근 장애 조치 없음**
이 예에서는 오류 로그에 최근 장애 조치가 없는 경우의 출력을 보여 줍니다. 2020-04-29 23:59:00.01 이후로 장애 조치가 발생하지 않았습니다.
| errorlog\$1available\$1from | recent\$1failover\$1time |
| --- | --- |
| 2020-04-29 23:59:00.0100000 | null |
**Example 최근 장애 조치**
이 예에서는 오류 로그에 장애 조치가 있는 경우의 출력을 보여 줍니다. 가장 최근의 장애 조치는 2020-05-05 18:57:51.89에 있었습니다.
| errorlog\$1available\$1from | recent\$1failover\$1time |
| --- | --- |
| 2020-04-29 23:59:00.0100000 | 2020-05-05 18:57:51.8900000 |
# 로그 시퀀스 번호 차이로 인한 시점 복구 실패 문제 해결
RDS for SQL Server에서 시점 복구(PITR)를 시도할 때 로그 시퀀스 번호(LSN) 차이로 인해 실패가 발생할 수 있습니다. 이러한 차이로 인해 RDS가 데이터베이스를 요청된 시간으로 복원할 수 없으며 RDS는 복원 인스턴스를 `incompatible-restore` 상태로 전환합니다.
이러한 문제가 발생하는 일반적인 원인은 다음과 같습니다.
+ 데이터베이스 복구 모델에 대한 수동 변경
+ 트랜잭션 로그 백업을 완료하기 위한 리소스가 부족하여 발생하는 RDS의 자동 복구 모델 변경
데이터베이스에서 LSN 차이를 식별하려면 다음 쿼리를 실행합니다.
```
SELECT * FROM msdb.dbo.rds_fn_list_tlog_backup_metadata(database_name)
ORDER BY backup_file_time_utc desc;
```
LSN 차이가 발견되면 다음을 수행할 수 있습니다.
+ LSN 차이 이전의 복원 지점을 선택합니다.
+ 기다렸다가 다음 인스턴스 백업이 완료된 후 특정 시점으로 복원합니다.
이 문제를 방지하려면 RDS for SQL Server 데이터베이스의 복구 모델을 수동으로 변경하지 않는 것이 좋습니다. 이렇게 하면 인스턴스 내구성이 저하되기 때문입니다. 또한 정기적인 트랜잭션 로그 백업을 보장하기 위해 워크로드에 충분한 리소스가 있는 인스턴스 유형을 선택하는 것이 좋습니다.
트랜잭션 로그 관리에 대한 자세한 내용은 Microsoft SQL Server 설명서의 [SQL Server transaction log architecture and management guide](https://learn.microsoft.com/en-us/sql/relational-databases/sql-server-transaction-log-architecture-and-management-guide?view=sql-server-ver16)를 참조하세요.
# Amazon RDS for SQL Server의 데이터베이스 이름 보기 거부 또는 허용
마스터 사용자는 `DENY VIEW ANY DATABASE TO LOGIN`을 설정하여 사용자에게 데이터베이스를 숨길 수 없습니다. 이 권한을 변경하려면 다음 저장 프로시저를 대신 사용합니다.
+ *LOGIN*에 대한 데이터베이스 보기 액세스 거부:
```
EXEC msdb.dbo.rds_manage_view_db_permission @permission=‘DENY’, @server_principal=‘LOGIN’
go
```
+ *LOGIN*에 대한 데이터베이스 보기 액세스 허용:
```
EXEC msdb.dbo.rds_manage_view_db_permission @permission='GRANT', @server_principal='LOGIN'
go
```
이 저장 프로시저를 사용할 때는 다음 사항을 고려해야 합니다.
+ 데이터베이스 이름은 SSMS 및 내부 동적 관리 보기(DMV)에서 숨겨집니다. 하지만 데이터베이스 이름은 감사, 로그 및 메타데이터 테이블에서 계속 볼 수 있습니다. 이는 보안이 적용되는 `VIEW ANY DATABASE` 서버 권한입니다. 자세한 내용은 [DENY 서버 권한](https://learn.microsoft.com/en-us/sql/t-sql/statements/deny-server-permissions-transact-sql?view=sql-server-ver16#permissions)을 참조하세요.
+ 권한이 `GRANT`(허용)로 되돌려지면 *LOGIN*은 모든 데이터베이스를 볼 수 있습니다.
+ *LOGIN*을 삭제하고 다시 만들면 LOGIN과 관련된 보기 권한이 `ALLOW`로 재설정됩니다.
+ 다중 AZ 인스턴스의 경우 기본 호스트의 *LOGIN*에만 `DENY` 또는 `GRANT` 권한을 설정합니다. 변경 사항은 보조 호스트에 자동으로 전파됩니다.
+ 이 권한은 로그인이 데이터베이스 이름을 볼 수 있는지만 변경합니다. 그러나 데이터베이스와 내부 객체에 대한 액세스는 별도로 관리됩니다.
# Amazon RDS for SQL Server에 대한 대량 로드 중 빠른 삽입 비활성화
SQL Server 2016부터는 빠른 삽입이 기본적으로 사용됩니다. 빠른 삽입은 데이터베이스가 삽입 성능을 최적화하기 위해 단순 또는 대량 로그 복구 모델에 있는 동안 발생하는 최소 로깅을 활용합니다. 빠른 삽입을 통해 각 일괄 로드 배치가 새 범위를 획득하여 삽입 성능을 최적화하기 위해 사용 가능한 공간이 있는 기존 범위에 대한 할당 조회를 건너뜁니다.
그러나 배치 크기가 작은 일괄 로드를 빠르게 삽입하면 객체에서 사용되지 않는 공간이 늘어날 수 있습니다. 배치 크기를 늘릴 수 없는 경우 추적 플래그 692를 활성화하면 사용되지 않는 예약된 공간을 줄일 수 있지만 성능이 저하됩니다. 이 추적 플래그를 활성화하면 데이터를 힙 또는 클러스터된 인덱스로 일괄 로드하는 동안 빠른 삽입이 비활성화됩니다.
DB 파라미터 그룹을 사용하여 추적 플래그 692를 시작 파라미터로 활성화합니다. 자세한 내용은 [Amazon RDS의 파라미터 그룹](USER_WorkingWithParamGroups.md) 섹션을 참조하세요.
추적 플래그 692는 SQL Server 2016 이상에서 Amazon RDS에 대해 지원됩니다. 추적 플래그에 대한 자세한 내용은 Microsoft 설명서의 [DBCC TRACEON - 추적 플래그](https://docs.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-traceon-trace-flags-transact-sql)를 참조하세요.
# Amazon RDS for Microsoft SQL Server DB 인스턴스 데이터베이스 삭제
단일 AZ 또는 다중 AZ 배포에서 Microsoft SQL Server를 실행하는 Amazon RDS DB 인스턴스의 데이터베이스를 삭제할 수 있습니다. 데이터베이스를 삭제하려면 다음 명령을 사용합니다.
```
--replace your-database-name with the name of the database you want to drop
EXECUTE msdb.dbo.rds_drop_database N'your-database-name'
```
**참고**
이 명령에서는 직선형 홑따옴표를 사용하세요. 스마트 따옴표를 사용하면 오류가 발생할 수 있습니다.
이 절차를 사용하여 데이터베이스를 삭제하면, Amazon RDS가 데이터베이스와의 기존 연결을 모두 삭제하고 데이터베이스의 백업 기록을 제거합니다.
다른 사용자에게 백업 및 복원 허용량을 부여하려면 다음 프로시저를 따릅니다.
```
USE master
GO
CREATE LOGIN user1 WITH PASSWORD=N'changeThis', DEFAULT_DATABASE=master, CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF
GO
USE msdb
GO
CREATE USER user1 FOR LOGIN user1
GO
use msdb
GO
GRANT EXECUTE ON msdb.dbo.rds_backup_database TO user1
GO
GRANT EXECUTE ON msdb.dbo.rds_restore_database TO user1
GO
```
# 다중 AZ 배포의 Amazon RDS for Microsoft SQL Server 데이터베이스 이름 변경
다중 AZ를 사용하는 Microsoft SQL Server 데이터베이스 인스턴스의 이름을 변경하려면 다음 절차에 따릅니다.
1. 먼저 해당 DB 인스턴스에 대해 다중 AZ를 해제합니다.
1. `rdsadmin.dbo.rds_modify_db_name`을 실행하여 데이터베이스의 이름을 변경합니다.
1. 그 다음에 해당 DB 인스턴스에 대해 다중 AZ 미러링 또는 상시 작동 가용성 그룹을 활성화하여 원래 상태로 되돌립니다.
자세한 내용은 [다중 AZ를 Microsoft SQL Server DB 인스턴스에 추가](USER_SQLServerMultiAZ.md#USER_SQLServerMultiAZ.Adding) 섹션을 참조하세요.
**참고**
해당 인스턴스에서 다중 AZ를 사용하지 않는 경우 `rdsadmin.dbo.rds_modify_db_name`을 실행하기 전 또는 후에 설정 값을 수정할 필요가 없습니다.
읽기 전용 복제본 소스 인스턴스의 데이터베이스 이름은 변경할 수 없습니다.
**예시: **다음 예시에서 `rdsadmin.dbo.rds_modify_db_name` 저장 프로시저는 데이터베이스 이름을 **MOO**에서 **ZAR**로 바꿉니다. 이는 `DDL ALTER DATABASE [MOO] MODIFY NAME = [ZAR]` 문을 실행하는 것과 유사합니다.
```
EXEC rdsadmin.dbo.rds_modify_db_name N'MOO', N'ZAR'
GO
```
# Amazon RDS for SQL Server 마스터 사용자의 db\$1owner 역할 멤버십 재설정
마스터 사용자를 RDS for SQL Server 데이터베이스의 `db_owner` 역할 멤버십에서 제외하고 다른 데이터베이스 사용자가 멤버십을 부여할 수 없는 경우, DB 인스턴스 마스터 사용자 암호를 수정하여 손실된 멤버십을 복원할 수 있습니다.
RDS는 DB 인스턴스 마스터 사용자 암호를 변경하여 실수로 취소되었을 수 있는 DB 인스턴스의 데이터베이스에 대한 `db_owner` 멤버십을 부여합니다. Amazon RDS 콘솔, AWS CLI 명령 [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) 또는 [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) API 작업을 사용하여 DB 인스턴스 암호를 변경할 수 있습니다. DB 인스턴스 변경에 대한 자세한 내용은 [Amazon RDS DB 인스턴스 수정](Overview.DBInstance.Modifying.md) 단원을 참조하십시오.
# Amazon RDS for SQL Server에 대한 라이선스 종료 DB 인스턴스 복원
Microsoft는 Microsoft License Mobility 정보를 보고하지 않은 일부 Amazon RDS 고객에게 DB 인스턴스를 종료할 것을 요청했습니다 Amazon RDS는 이러한 DB 인스턴스의 스냅샷을 생성하며, 스냅샷에서 라이선스 포함 모델이 있는 새 DB 인스턴스로 복원할 수 있습니다.
Standard Edition의 스냅샷에서 Standard Edition 또는 Enterprise Edition으로 복원할 수 있습니다.
Enterprise Edition의 스냅샷에서 Standard Edition 또는 Enterprise Edition으로 복원할 수 있습니다.
**Amazon RDS가 인스턴스의 최종 스냅샷을 생성한 후 SQL Server 스냅샷에서 복원하려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 [**Snapshots**]를 선택합니다.
1. SQL Server DB 인스턴스의 스냅샷을 선택합니다. Amazon RDS가 DB 인스턴스의 최종 스냅샷을 생성합니다. 종료된 인스턴스 스냅샷의 이름은 `instance_name-final-snapshot` 형식입니다. 예를 들어 DB 인스턴스 이름이 **mytest.cdxgahslksma.us-east-1.rds.com**일 경우, 최종 스냅샷은 ** mytest-final-snapshot**이라는 이름으로 원본 DB 인스턴스와 동일한 AWS 리전에 있습니다.
1. **작업**에서 **스냅샷 복원**을 선택합니다.
[**Restore DB Instance**] 창이 나타납니다.
1. **라이선스 모델**에서 **라이선스 포함**을 선택합니다.
1. 사용할 SQL Server DB 엔진을 선택합니다.
1. **DB 인스턴스 식별자**에 복원된 DB 인스턴스의 이름을 입력합니다.
1. [**Restore DB Instance**]를 선택합니다.
스냅샷에서 복원하는 자세한 방법은 [DB 인스턴스 복원](USER_RestoreFromSnapshot.md) 단원을 참조하세요.
# 오프라인에서 온라인으로 Amazon RDS for SQL Server 데이터베이스 전환
`OFFLINE`에서 `ONLINE`으로 Amazon RDS DB 인스턴스의 Microsoft SQL Server 데이터베이스를 전환할 수 있습니다.
****
| SQL Server 메소드 | Amazon RDS 메서드 |
| --- | --- |
| ALTER DATABASE *db\$1name* SET ONLINE; | EXEC rdsadmin.dbo.rds\$1set\$1database\$1online *db\$1name* |
# Amazon RDS for SQL Server에 변경 데이터 캡처 사용
Amazon RDS는 Microsoft SQL Server를 실행하는 DB 인스턴스에 대해 CDC(변경 데이터 캡처)를 지원합니다. 테이블의 데이터에 대한 CDC 캡처 변경입니다. 각 변경 사항에 대한 메타데이터를 저장하고, 이후에 액세스할 수 있습니다. CDC 작동 방식에 대한 자세한 내용은 Microsoft 설명서의 [변경 데이터 캡처](https://docs.microsoft.com/en-us/sql/relational-databases/track-changes/track-data-changes-sql-server#Capture)를 참조하세요. Amazon RDS DB 인스턴스에 CDC를 사용하기 전에 `msdb.dbo.rds_cdc_enable_db`를 실행하여 데이터베이스에서 이를 활성화합니다. CDC가 활성화된 이후 데이터베이스의 `db_owner`인 모든 사용자는 데이터베이스의 테이블에서 CDC를 활성화 또는 비활성화할 수 있습니다.
**중요**
복원 도중 CDC가 비활성화됩니다. 모든 관련 메타데이터가 데이터베이스에서 자동으로 제거됩니다. 이는 스냅샷 복원과 특정 시점으로 복원에 적용됩니다. 이러한 유형의 복원 중 하나를 수행한 이후 CDC를 다시 활성화하고 추적할 테이블을 다시 지정할 수 있습니다.
DB 인스턴스에 대해 CDC를 활성화하려면 `msdb.dbo.rds_cdc_enable_db` 저장 프로시저를 실행합니다.
```
1. exec msdb.dbo.rds_cdc_enable_db 'database_name'
```
DB 인스턴스에 대해 CDC를 비활성화하려면 `msdb.dbo.rds_cdc_disable_db` 저장 프로시저를 실행합니다.
```
1. exec msdb.dbo.rds_cdc_disable_db 'database_name'
```
사용자에게 CDC 권한을 부여하려면 다음 프로시저를 사용합니다.
```
1. go
2. GRANT EXECUTE ON msdb.dbo.rds_cdc_enable_db TO User1
3. GRANT EXECUTE ON msdb.dbo.rds_cdc_disable_db TO User1
```
**Topics**
+ [변경 데이터 캡처로 테이블 추적](#Appendix.SQLServer.CommonDBATasks.CDC.tables)
+ [변경 데이터 캡처 작업](#Appendix.SQLServer.CommonDBATasks.CDC.jobs)
+ [다중 AZ 인스턴스에 대한 변경 데이터 캡처](#Appendix.SQLServer.CommonDBATasks.CDC.Multi-AZ)
## 변경 데이터 캡처로 테이블 추적
데이터베이스에서 CDC가 활성화된 이후 특정 테이블 추적을 시작할 수 있습니다. [sys.sp\$1cdc\$1enable\$1table](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sys-sp-cdc-enable-table-transact-sql)을 실행하여 추적할 테이블을 선택할 수 있습니다.
```
1. --Begin tracking a table
2. exec sys.sp_cdc_enable_table
3. @source_schema = N'source_schema'
4. , @source_name = N'source_name'
5. , @role_name = N'role_name'
6.
7. --The following parameters are optional:
8.
9. --, @capture_instance = 'capture_instance'
10. --, @supports_net_changes = supports_net_changes
11. --, @index_name = 'index_name'
12. --, @captured_column_list = 'captured_column_list'
13. --, @filegroup_name = 'filegroup_name'
14. --, @allow_partition_switch = 'allow_partition_switch'
15. ;
```
테이블에 대한 CDC 구성을 보려면 [sys.sp\$1cdc\$1help\$1change\$1data\$1capture](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sys-sp-cdc-help-change-data-capture-transact-sql)를 실행합니다.
```
1. --View CDC configuration
2. exec sys.sp_cdc_help_change_data_capture
3.
4. --The following parameters are optional and must be used together.
5. -- 'schema_name', 'table_name'
6. ;
```
SQL Server 설명서의 CDC 테이블, 함수 및 저장된 절차에 대한 자세한 내용은 다음을 참조하세요.
+ [변경 데이터 캡처 저장 프로시저(Transact-SQL)](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/change-data-capture-stored-procedures-transact-sql)
+ [변경 데이터 캡처 함수(Transact-SQL)](https://docs.microsoft.com/en-us/sql/relational-databases/system-functions/change-data-capture-functions-transact-sql)
+ [변경 데이터 캡처 테이블(Transact-SQL)](https://docs.microsoft.com/en-us/sql/relational-databases/system-tables/change-data-capture-tables-transact-sql)
## 변경 데이터 캡처 작업
CDC를 활성화할 때 SQL Server가 CDC 작업을 생성합니다. 데이터베이스 소유자(`db_owner`)는 CDC 작업의 보기, 생성, 수정 및 삭제가 가능합니다. 하지만 RDS 시스템 계정은 이들을 소유합니다. 따라서 기본 보기, 절차 또는 SQL Server Management Studio에서 작업이 보이지 않습니다.
데이터베이스의 CDC 동작을 제어하려면 [sp\$1cdc\$1enable\$1table](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sys-sp-cdc-enable-table-transact-sql) 및 [sp\$1cdc\$1start\$1job](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sys-sp-cdc-start-job-transact-sql)과 같은 기본 SQL Server 절차를 사용합니다. `maxtrans` 및 `maxscans`와 같은 CDC 작업 파라미터를 변경하려면 [sp\$1cdc\$1change\$1job](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sys-sp-cdc-change-job-transact-sql)을 사용할 수 있습니다.
CDC 작업에 관한 추가 정보를 얻으려면 다음 동적 관리 보기를 쿼리할 수 있습니다.
+ sys.dm\$1cdc\$1errors
+ sys.dm\$1cdc\$1log\$1scan\$1sessions
+ sysjobs
+ sysjobhistory
## 다중 AZ 인스턴스에 대한 변경 데이터 캡처
다중 AZ 인스턴스에서 CDC를 사용하는 경우 미러의 CDC 작업 구성이 보안 주체에 있는 것과 일치해야 합니다. CDC 작업은 `database_id`로 매핑됩니다. 보조의 데이터베이스 ID가 보안 주체의 ID와 다른 경우 작업이 올바른 데이터베이스와 연결되지 않습니다. 장애 조치 이후 오류를 방지하기 위해 RDS는 작업을 취소하고 새 보안 주체에 작업을 다시 생성합니다. 다시 생성된 작업은 장애 조치 이전에 보안 주체가 기록한 파라미터를 사용합니다.
이 프로세스가 빠르게 실행되기는 하지만 CDC 작업은 RDS가 이를 수정하기 전에 실행될 수 있습니다. 기본 복제본과 보조 복제본 사이의 파라미터를 강제로 일관되게 하는 3가지 방법이 있습니다.
+ CDC를 활성화한 모든 데이터베이스에 대해 동일한 작업 파라미터를 사용합니다.
+ CDC 작업 구성을 변경하기 전에 다중 AZ 인스턴스를 단일 AZ로 변환합니다.
+ 보안 주체에서 파라미터를 변경할 때마다 수동으로 전송합니다.
장애 조치 이후 CDC 작업을 다시 생성하는 데 사용되는 CDC 파라미터를 보고 정의하려면 `rds_show_configuration` 및 `rds_set_configuration`을 사용합니다.
다음은 `cdc_capture_maxtrans`의 값을 반환하는 예입니다. `RDS_DEFAULT`로 설정된 모든 파라미터의 경우 RDS가 자동으로 값을 구성합니다.
```
-- Show configuration for each parameter on either primary and secondary replicas.
exec rdsadmin.dbo.rds_show_configuration 'cdc_capture_maxtrans';
```
보조에서 구성을 설정하려면 `rdsadmin.dbo.rds_set_configuration`을 실행합니다. 이 절차는 부 서버의 모든 데이터베이스에 대한 파라미터 값을 설정합니다. 이러한 설정은 장애 조치 이후에만 사용됩니다. 다음 예제는 모든 CDC 캡처 작업에 대한 `maxtrans`를 *1000*으로 설정합니다.
```
--To set values on secondary. These are used after failover.
exec rdsadmin.dbo.rds_set_configuration 'cdc_capture_maxtrans', 1000;
```
보안 주체에서 CDC 작업 파라미터를 설정하려면 [sys.sp\$1cdc\$1change\$1job](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sys-sp-cdc-change-job-transact-sql)을 대신 사용합니다.
# Amazon RDS에 SQL Server Agent 사용
Amazon RDS에서는 Microsoft SQL Server Enterprise Edition, Standard Edition 또는 Web Edition을 실행하는 DB 인스턴스에서 SQL Server 에이전트를 사용할 수 있습니다. SQL Server 에이전트는 예약된 관리 작업을 실행하는 Microsoft Windows 서비스입니다. SQL Server 에이전트를 사용하면 T-SQL 작업을 통해 인덱스를 리빌드하고, 손상 검사를 실행하고, SQL Server DB 인스턴스의 데이터를 집계할 수 있습니다.
SQL Server DB 인스턴스를 생성하면 마스터 사용자가 `SQLAgentUserRole` 역할에 등록됩니다.
SQL Server 에이전트는 특정 이벤트 발생 시, 혹은 필요에 따라 예약 작업을 실행할 수 있습니다. 자세한 내용은 Microsoft 설명서에서 [SQL Server 에이전트](http://msdn.microsoft.com/en-us/library/ms189237)를 참조하세요.
**참고**
DB 인스턴스의 유지 관리 및 백업 기간 중에는 작업 실행을 예약하지 마세요. AWS를 통해 시작되는 유지 관리 및 백업 프로세스에 의해 작업이 중단되거나 취소될 수 있습니다.
다중 AZ 배포에서 SQL Server 에이전트 작업은 작업 복제 기능이 켜져 있을 때 기본 호스트에서 보조 호스트로 복제됩니다. 자세한 내용은 [SQL Server 에이전트 작업 복제 켜기](#SQLServerAgent.Replicate) 섹션을 참조하세요.
다중 AZ 배포에서는 SQL Server 에이전트 작업이 10,000개로 제한됩니다. 한도를 늘려야 할 경우 지원에 문의하여 할당량 증대를 요청하세요. [[지원 센터(AWS Support Center)](https://console.aws.amazon.com/support/home#/)] 페이지를 열고 필요한 경우, 로그인한 다음 [**사례 생성(Create Case)**]을 선택합니다. **Service Limit increase(서비스 한도 증가)**를 선택합니다. 양식을 작성하고 제출합니다.
SQL Server Management Studio(SSMS)에서 SQL Server 에이전트의 개별 작업 기록을 보려면 Object Explorer를 열고 작업을 마우스 오른쪽 버튼으로 클릭한 다음 [**기록 보기(View History)**]를 선택합니다.
SQL Server 에이전트는 DB 인스턴스의 관리형 호스트에서 실행되므로 일부 작업이 지원되지 않습니다.
+ 예를 들어 ActiveX, Windows cmdshell 또는 Windows PowerShell을 사용하여 복제 작업이나 명령줄 스크립트를 실행하는 것은 지원되지 않습니다.
+ SQL Server 에이전트를 수동으로 시작, 중지 또는 다시 시작할 수 없습니다.
+ SQL Server 에이전트를 통한 이메일 알림은 DB 인스턴스에서 사용할 수 없습니다.
+ SQL Server 에이전트 알림 및 연산자는 지원되지 않습니다.
+ SQL Server 에이전트를 사용한 백업 생성은 지원되지 않습니다. DB 인스턴스를 백업하려면 Amazon RDS를 사용합니다.
+ 현재 RDS for SQL Server는 SQL Server 에이전트 토큰 사용을 지원하지 않습니다.
## SQL Server 에이전트 작업 복제 켜기
다음 저장 프로시저를 사용하여 SQL Server 에이전트 작업 복제를 켤 수 있습니다.
```
EXECUTE msdb.dbo.rds_set_system_database_sync_objects @object_types = 'SQLAgentJob';
```
Amazon RDS for SQL Server에서 지원하는 모든 SQL Server 버전에서 저장 프로시저를 실행할 수 있습니다. 다음 범주의 작업이 복제됩니다.
+ [분류되지 않음(로컬)]
+ [분류되지 않음(멀티 서버)]
+ [분류되지 않음]
+ 데이터 수집기
+ 데이터베이스 엔진 튜닝 관리자
+ 데이터베이스 유지 관리
+ 전체 텍스트
T-SQL 작업 단계를 사용하는 작업만 복제됩니다. SSIS(SQL Server Integration Services), SSRS(SQL Server Reporting Service), 복제 및 PowerShell과 같은 단계 유형이 있는 작업은 복제되지 않습니다. 데이터베이스 메일 및 서버 수준 객체를 사용하는 작업은 복제되지 않습니다.
**중요**
프라이머리 호스트는 복제를 위한 신뢰할 수 있는 소스입니다. 작업 복제를 설정하기 전에 SQL Server 에이전트 작업이 프라이머리에 있는지 확인합니다. 새 작업이 보조 호스트에 있을 때 이 기능을 설정하면 SQL Server 에이전트 작업이 삭제될 수 있습니다.
다음 기능을 사용하면 복제가 켜져 있는지 확인할 수 있습니다.
```
SELECT * from msdb.dbo.rds_fn_get_system_database_sync_objects();
```
T-SQL 쿼리는 SQL Server 에이전트 작업이 복제되는 경우 다음을 반환합니다. 복제하지 않으면 `object_class`에 대해 아무 것도 반환하지 않습니다.
![\[SQL Server 에이전트 작업이 복제 중입니다.\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/SQLAgentJob.png)
다음 함수를 사용하여 객체가 마지막으로 동기화된 시간(UTC 시간)을 찾을 수 있습니다.
```
SELECT * from msdb.dbo.rds_fn_server_object_last_sync_time();
```
예를 들어 SQL Server 에이전트 작업을 01:00에 수정한다고 가정합니다. 가장 최근에 동기화된 시간은 동기화가 수행되었음을 나타내는 01:00 이후일 것으로 예상합니다.
동기화 후에는 보조 노드에서 반환된 `date_created`와 `date_modified`가 일치할 것으로 예상됩니다.
![\[서버 객체가 마지막으로 동기화된 시간은 01:21:23이었습니다.\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/SQLAgentJob_last_sync_time.png)
`tempdb` 복제를 함께 사용하는 경우 `@object_type` 파라미터에 SQL 에이전트 작업과 `tempdb` 구성을 제공하여 둘 모두에 대해 복제를 활성화할 수 있습니다.
```
EXECUTE msdb.dbo.rds_set_system_database_sync_objects @object_types = 'SQLAgentJob,TempDbFile';
```
`tempdb` 복제에 대한 자세한 내용은 [다중 AZ 배포에 대한 TempDB 구성](SQLServer.TempDB.MAZ.md) 섹션을 참조하세요.
# SQL Server 에이전트 역할
RDS for SQL Server는 작업 관리를 위한 각기 다른 수준의 권한을 가진 다음과 같은 SQL Server 에이전트 역할을 지원합니다.
+ **SQLAgentUserRole**
권한
+ 자체 작업, 일정 및 연산자 생성 및 관리
+ 자체 작업 및 일정의 속성 보기
+ 다른 사용자가 생성한 작업을 보거나 관리할 수 없음
이 역할은 자신의 작업을 생성하고 관리해야 하지만 다른 사용자가 생성한 작업에는 액세스할 필요가 없는 사용자에게 적합합니다.
+ **SQLAgentReaderRole**
권한
+ SQLAgentUserRole의 모든 권한
+ 다른 사용자가 생성한 작업 및 일정을 포함하여 모든 작업 및 일정 목록 보기
+ 모든 작업의 속성 보기
+ 작업 기록 검토
이 역할은 모든 작업의 상태를 모니터링해야 하지만 관리할 필요는 없는 사용자에게 적합합니다.
+ **SQLAgentOperatorRole**
권한
+ SQLAgentUserRole 및 SQLAgentReaderRole의 모든 권한
+ 작업 실행, 중지 또는 시작
+ 작업 기록 관리
+ 작업 및 일정 활성화/비활성화
+ 연산자 및 프록시 보기
이 역할은 가장 포괄적인 권한을 제공하며 모든 작업을 완전히 제어해야 하는 사용자에게 적합합니다.
다음 명령을 사용하여 SQL Server 로그인에 역할을 할당합니다.
```
USE msdb;
EXEC sp_addrolemember 'SQLAgentOperatorRole', 'username';
```
## RDS for SQL Server에서 SQLAgentOperatorRole 관리
현재 작업을 보려면 SQL Server 로그인에 SQLAgentOperatorRole을 추가하고 데이터베이스 연결을 해제하기 전에 제거해야 합니다.
SQL Server Management Studio에서 SQL Server 에이전트 트리를 시각화하려면 다음 지침을 따르세요.
**SQL Server Management Studio(SSMS)에서 SQL Server 에이전트 보기**
1. RDS 마스터 자격 증명을 사용하여 RDS SQL Server 인스턴스에 로그인하고 원하는 사용자에게 SQLAgentUserRole을 부여합니다.
```
USE msdb
GO
IF NOT EXISTS(SELECT name FROM sys.database_principals WHERE name = 'UserName')
BEGIN
CREATE USER UserName FROM LOGIN UserName
END
GO
ALTER ROLE SQLAgentUserRole ADD MEMBER UserName
GO
GRANT ALTER ON ROLE::[SQLAgentOperatorRole] to UserName
GO
```
이러한 명령은 사용자가 존재하지 않는 경우 `msdb` 데이터베이스에 사용자를 생성합니다. 또한 SSMS의 SQL Server 에이전트 트리가 표시되도록 SQLAgentUserRole에 사용자를 추가합니다. 마지막으로, SQLAgentOperatorRole에 대한 변경 권한을 사용자에게 부여합니다. 이렇게 하면 사용자가 해당 역할에 자신을 추가/제거할 수 있습니다.
1. 위에서 언급한 역할에 자신을 추가하려면 작업을 확인해야 하는 사용자와 함께 RDS SQL Server 인스턴스에 연결하고 다음 스크립트를 실행합니다.
```
use msdb
go
ALTER ROLE SQLAgentOperatorRole ADD MEMBER UserName
GO
```
그런 다음, **작업** 폴더를 마우스 오른쪽 버튼으로 클릭하고 **새로 고침**을 선택합니다.
1. 이 작업을 수행하면 **작업** 탭에 **\$1**(더하기) 버튼이 표시됩니다. 이 버튼을 클릭하여 SQL Server 에이전트 작업 목록을 확장합니다.
1.
**중요**
RDS SQL Server 인스턴스에서 연결을 해제하기 전에 SQLAgentOperatorRole에서 자신을 제거해야 합니다.
SQLAgentOperatorRole에서 로그인을 제거하려면 Management Studio를 연결 해제하거나 닫기 전에 다음 쿼리를 실행합니다.
```
USE msdb
GO
ALTER ROLE SQLAgentOperatorRole DROP MEMBER UserName
GO
```
자세한 내용은 [Leveraging SQLAgentOperatorRole in RDS SQL Server](https://aws.amazon.com/blogs/database/leveraging-sqlagentoperatorrole-in-rds-sql-server/)을 참조하세요.
# SQLAgentUser 역할에 사용자 추가
추가 로그인 또는 사용자의 SQL Server 에이전트 사용을 허용하려면 마스터 사용자로 로그인한 후 다음을 수행합니다.
1. `CREATE LOGIN` 명령을 사용하여 다른 서버 수준 로그인을 생성합니다.
1. `msdb` 명령을 사용하여 `CREATE USER` 사용자를 생성한 다음 이전 단계에서 생성한 로그인에 이 사용자를 연결합니다.
1. `SQLAgentUserRole` 시스템 저장 프로시저를 사용하여 `sp_addrolemember`에 사용자를 추가합니다.
예를 들어 마스터 사용자 이름은 **admin**이며, 이름이 **theirname**이고 암호가 **theirpassword**인 사용자에게 SQL Server 에이전트에 대한 액세스 권한을 부여한다고 가정하겠습니다. 이 경우 다음 절차를 사용할 수 있습니다.
**SQLAgentUser 역할에 사용자를 추가하려면**
1. 마스터 사용자로 로그인합니다.
1. 다음 명령을 실행합니다:
```
--Initially set context to master database
USE [master];
GO
--Create a server-level login named theirname with password theirpassword
CREATE LOGIN [theirname] WITH PASSWORD = 'theirpassword';
GO
--Set context to msdb database
USE [msdb];
GO
--Create a database user named theirname and link it to server-level login theirname
CREATE USER [theirname] FOR LOGIN [theirname];
GO
--Added database user theirname in msdb to SQLAgentUserRole in msdb
EXEC sp_addrolemember [SQLAgentUserRole], [theirname];
```
# SQL Server 에이전트 작업 삭제
`sp_delete_job` 저장 프로시저를 사용하여 Amazon RDS for Microsoft SQL Server의 SQL Server 에이전트 작업을 삭제합니다.
SSMS를 사용하여 SQL Server 에이전트 작업을 삭제할 수는 없습니다. 그렇게 하면 다음과 유사한 오류 메시지가 표시됩니다.
```
The EXECUTE permission was denied on the object 'xp_regread', database 'mssqlsystemresource', schema 'sys'.
```
RDS는 관리형 서비스이기 때문에 Windows 레지스트리에 액세스하는 프로시저의 실행을 제한합니다. SSMS를 사용하는 경우 SSMS는 RDS에 의해 권한이 부여되지 않은 프로세스(`xp_regread`)를 실행하려고 시도합니다.
**참고**
RDS for SQL Server에서는 sysadmin 역할의 구성원만 다른 로그인에서 소유한 작업을 업데이트하거나 삭제할 수 있습니다. 자세한 내용은 [Leveraging SQLAgentOperatorRole in RDS SQL Server](https://aws.amazon.com/blogs/database/leveraging-sqlagentoperatorrole-in-rds-sql-server/)을 참조하세요.
**SQL Server 에이전트 작업을 삭제하려면**
+ 다음 T-SQL 문을 실행합니다.
```
EXEC msdb..sp_delete_job @job_name = 'job_name';
```
# Amazon RDS for Microsoft SQL Server 로그 작업
Amazon RDS 콘솔을 사용하여 SQL Server 에이전트 로그, Microsoft SQL Server 오류 로그 및 SQL Server Reporting Services(SSRS) 로그를 확인하고, 보고, 다운로드할 수 있습니다.
## 로그 파일 조사
Amazon RDS 콘솔을 통해 로그를 보면 당시에 존재하는 내용을 확인할 수 있습니다. 콘솔에서 로그를 모니터링하면 로그가 동적 상태로 열리기 때문에 거의 실시간으로 업데이트를 볼 수 있습니다.
따라서 최신 상태의 로그만 모니터링됩니다. 예를 들어 다음과 같은 로그가 표시되어 있다고 가정하겠습니다.
![\[오류 로그가 선택된 Amazon RDS 콘솔의 로그 섹션 이미지.\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/logs_sqlserver.png)
가장 최근 로그인 log/ERROR만 업데이트가 활성화되어 있습니다. 다른 로그도 볼 수는 있지만 정적 상태로 열리기 때문에 업데이트되지 않습니다.
## 로그 파일 보관
Amazon RDS 콘솔은 지난 주부터 당일까지 로그를 표시합니다. 이 로그는 당일 이후 참조를 목적으로 다운로드하여 아카이브(보관)할 수 있습니다. Amazon S3 버킷에 로드하는 것도 로그를 아카이브할 수 있는 한 가지 방법입니다. Amazon S3 버킷 설치 및 파일 업로드 방법에 대한 자세한 내용은 *Amazon Simple Storage Service 시작 안내서*의 [Amazon S3 기본 사항](https://docs.aws.amazon.com/AmazonS3/latest/userguide/AmazonS3Basics.html)에서 **시작하기**를 클릭하면 확인할 수 있습니다.
## 오류 및 에이전트 로그 보기
Microsoft SQL 서버 오류 및 에이전트 로그를 보려면 다음 파라미터와 함께 Amazon RDS 저장 프로시저 `rds_read_error_log`를 사용합니다.
+ **`@index`** – 가져올 로그의 버전. 기본값은 0이며, 현재 오류 로그를 가져옵니다. 이전 로그를 가져오려면 1을 지정하고, 그보다 하나 이전의 로그를 가져오려면 2를 지정하는 식입니다.
+ **`@type`** – 가져올 로그의 유형. 오류 로그를 가져오려면 1을 지정합니다. 에이전트 로그를 가져오려면 2를 지정합니다.
**Example**
다음 예시에서는 현재 오류 로그를 요청합니다.
```
EXEC rdsadmin.dbo.rds_read_error_log @index = 0, @type = 1;
```
SQL Server 오류에 대한 자세한 내용은 Microsoft 설명서의 [데이터베이스 엔진 오류](https://docs.microsoft.com/en-us/sql/relational-databases/errors-events/database-engine-events-and-errors)를 참조하세요.
# Amazon RDS for SQL Server에 대한 추적 및 덤프 파일 작업
이 단원에서는 Microsoft SQL Server를 실행하는 Amazon RDS DB 인스턴스에 대한 추적 파일 및 덤프 파일 작업에 대해 설명합니다.
## 추적 SQL 쿼리 생성
```
1. declare @rc int
2. declare @TraceID int
3. declare @maxfilesize bigint
4.
5. set @maxfilesize = 5
6.
7. exec @rc = sp_trace_create @TraceID output, 0, N'D:\rdsdbdata\log\rdstest', @maxfilesize, NULL
```
## 열린 추적 보기
```
1. select * from ::fn_trace_getinfo(default)
```
## 추적 내용 보기
```
1. select * from ::fn_trace_gettable('D:\rdsdbdata\log\rdstest.trc', default)
```
## 추적 및 덤프 파일의 보존 기간 설정
추적 및 덤프 파일이 누적되면서 디스크 공간을 낭비할 수 있습니다. Amazon RDS는 7일 이상 지난 추적 및 덤프 파일은 제거하도록 기본 설정되어 있습니다.
다음 예시에서처럼 현재 추적 및 덤프 파일 보존 기간을 보려면 `rds_show_configuration` 프로시저를 사용합니다.
```
1. exec rdsadmin..rds_show_configuration;
```
추적 파일의 보존 기간을 수정하려면 `rds_set_configuration` 프로시저를 사용하여 `tracefile retention`을 분 단위로 설정합니다. 다음 예시에서는 추적 파일 보존 기간을 24시간으로 설정합니다.
```
1. exec rdsadmin..rds_set_configuration 'tracefile retention', 1440;
```
덤프 파일의 보존 기간을 수정하려면 `rds_set_configuration` 프로시저를 사용하여 `dumpfile retention`을 분 단위로 설정합니다. 다음 예시에서는 덤프 파일 보존 기간을 3일로 설정합니다.
```
1. exec rdsadmin..rds_set_configuration 'dumpfile retention', 4320;
```
보안상의 이유로 인해 SQL Server DB 인스턴스에서는 특정 추적 또는 덤프 파일을 삭제할 수 없습니다. 사용하지 않는 추적 또는 덤프 파일을 모두 삭제하려면 해당 파일에 대한 보존 기간을 0으로 설정합니다.