# 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으로 설정합니다.