일반 권장사항

MySQL | PostgreSQL | SQL Server

이 페이지에서는 Cloud SQL의 성능, 내구성, 가용성을 최적화하기 위한 권장사항을 제공합니다.

Cloud SQL 인스턴스에 문제가 발생하면 문제 해결 중에 다음을 검토하세요.

인스턴스 구성 및 관리

권장사항	추가 정보
운영 가이드라인을 읽고 따라 인스턴스에 Cloud SQL SLA가 적용되는지 확인하세요.
기본 인스턴스의 유지보수 기간을 구성하여 방해가 되는 업데이트가 발생할 수 있는 시간을 제어하세요.	유지보수 기간을 참조하세요.
인스턴스를 정기적으로 삭제하고 다시 만드는 경우 인스턴스 ID의 타임스탬프를 사용하여 새로운 인스턴스 ID의 사용 가능성을 높이세요.
이전 작업이 완료되기 전에 관리 작업을 시작하지 마세요.	Cloud SQL 인스턴스는 이전 작업을 완료할 때까지 새로운 작업 요청을 수락하지 않습니다. 조기에 새로운 작업을 시작하려고 시도하면 작업 요청에 실패합니다. 인스턴스 다시 시작도 여기에 포함됩니다. Google Cloud 콘솔의 인스턴스 상태에는 작업 실행 여부가 반영되지 않습니다. 녹색 체크표시는 인스턴스가 `RUNNABLE` 상태인 것만 나타냅니다. 작업 실행 여부를 확인하려면 작업 탭으로 이동하여 최근 작업 상태를 확인합니다.
중요한 데이터베이스 유지보수를 수용하도록 스토리지를 구성합니다.	스토리지 자동 증가 사용 설정 인스턴스 설정이 중지되었거나 스토리지 자동 증가 한도가 사용 설정된 경우 Cloud SQL이 수행할 수 있는 중요한 데이터베이스 유지보수 작업을 수용할 수 있도록 적어도 20%의 가용 공간이 있어야 합니다. 사용 가능한 디스크 공간이 20% 미만일 때 알림을 받으려면 임곗값 초과 위치와 .8 값을 사용해 디스크 사용률 측정항목에 대한 측정항목 기반 알림 정책을 만듭니다. 자세한 내용은 측정항목 기반 알림 정책 만들기를 참조하세요.
CPU 사용률 초과를 방지하세요.	Google Cloud 콘솔의 인스턴스 세부정보 페이지에서 인스턴스가 사용하고 있는 가용 CPU 비율을 확인할 수 있습니다. 자세한 내용은 측정항목을 참조하세요. 또한 측정항목 임곗값 알림 정책 만들기를 사용하여 CPU 사용량을 모니터링하고 지정된 기준에 도달할 때 알림을 받을 수 있습니다. 사용률이 초과되지 않도록 인스턴스의 CPU 수를 늘릴 수 있습니다. CPU를 변경하려면 인스턴스를 다시 시작해야 합니다. 인스턴스가 이미 최대 CPU 수에 도달한 경우에는 데이터베이스를 여러 인스턴스로 샤딩해야 합니다.
메모리 소진을 방지하세요.	메모리 소진의 징후를 찾을 때는 주로 usage 측정항목을 사용해야 합니다. 메모리 부족 오류를 방지하려면 이 측정항목이 90% 미만으로 유지되는 것이 좋습니다. 또한 total_usage 측정항목을 사용하여 데이터베이스 컨테이너가 사용하는 메모리와 운영체제 캐시에서 할당한 메모리 등 Cloud SQL 인스턴스가 사용하는 가용 메모리 비율을 관찰할 수도 있습니다. 두 측정항목의 차이를 관찰하면 프로세스에서 사용하는 메모리의 양과 운영체제 캐시에서 사용하는 메모리의 양을 식별할 수 있습니다. 이 캐시에서 메모리의 용도를 변경할 수 있습니다. 메모리 부족 문제를 예측하려면 두 측정항목을 모두 확인하고 함께 해석합니다. 측정항목이 높으면 인스턴스의 메모리가 부족할 수 있습니다. 이는 커스텀 구성, 워크로드에 비해 크기가 줄어드는 인스턴스, 이러한 요소의 조합 때문일 수 있습니다. Cloud SQL 인스턴스를 확장하여 메모리 크기를 늘립니다. 인스턴스의 메모리 크기를 변경하려면 인스턴스를 다시 시작해야 합니다. 인스턴스가 이미 최대 메모리 크기에 있으면 데이터베이스를 여러 인스턴스로 샤딩해야 합니다. Google Cloud 콘솔에서 두 측정항목을 모니터링하는 방법에 대한 자세한 내용은 측정항목을 참조하세요.
Cloud SQL에 최적으로 작동하도록 SQL Server를 설정합니다.	SQL Server 설정을 참조하세요.
테스트 실행을 위해 최적의 방식으로 인스턴스를 미세 조정합니다.	다음 표에서는 테스트 실행에 적합한 구성 값을 보여줍니다. vCPU: `40` 메모리: `262144 MB` MAXDOP: `8` 동시 로드 비용 임곗값: `120` tempdb 파일: `8`. 자동 증가를 방지하도록 미리 크기가 지정되었습니다. 사용자 데이터베이스 파일: 자동 증가가 `64-128`MB로 설정됩니다. 자동 증가를 방지하도록 미리 크기가 지정되었습니다. 스토리지: 최적 IOPS를 위한 `>= 4TB`
SQL Server를 배포하기 전 I/O 하위 시스템의 용량을 결정합니다.	다양한 I/O 유형 및 크기를 테스트합니다. SQL Server에서 시작되는 영구 디스크 스토리지에 수행되는 I/O 크기는 IOPS 및 처리량에 영향을 줍니다. IOPS 한도 또는 처리량 한도에 도달하면 SQL Server 워크로드가 조정됩니다. Cloud SQL에서 사용되는 스토리지 유형은 고성능 엔터프라이즈급 워크로드에 적합한 PD SSD입니다. 다음과 같이 성능을 극대화하도록 VM을 맞춤설정합니다. 4TB 이상의 디스크 크기는 더 많은 처리량 및 IOPS를 제공합니다. vCPU가 높을수록 더 많은 IOPS 및 처리량을 제공합니다. 더 높은 vCPU를 사용할 때는 함께 증가할 수 있는 동시 로드를 위한 DB 대기 시간을 모니터링하세요. 최적 성능을 위해 더 높은 I/O 큐 깊이를 얻을 수 있도록 I/O를 병렬로 실행합니다.
색인 조각화 및 색인 누락을 방지합니다.	데이터 변경 빈도에 따라 색인을 다시 빌드하도록 색인을 다시 구성하거나 일정을 설정합니다. 또한 조각화를 줄이기 위해 적절한 채우기 요소를 설정합니다. SQL Server에서 성능이 향상될 수 있는 누락된 색인을 모니터링합니다.
통계를 정기적으로 업데이트합니다.	통계가 오래되었으면 SQL 쿼리 옵티마이저가 최적화되지 않은 쿼리 계획을 생성할 수 있습니다. 특히 대용량 데이터가 변경된 후에는 통계를 업데이트하세요. 쿼리 저장소를 사용하여 최적화되지 않은 쿼리 계획이 있는 SQL Server를 모니터링하고 문제를 해결합니다.
데이터베이스 파일이 불필요하게 커지지 않도록 방지합니다.	요구사항에 적합한 증분 값을 사용해서 백분율 대신 MB로 `autogrow`를 설정합니다. 또한 autogrowth가 적용되기 전 증가를 사전에 관리합니다. 또한 데이터베이스 및 인스턴스에 공간이 부족할 때 Cloud SQL이 저장공간을 추가할 수 있도록 Cloud SQL 스토리지 자동 증가 사용 설정 기능이 사용 설정되었는지 유의합니다.
`DBCC CHECKDB`를 일주일에 한 번 이상 실행하여 데이터베이스 무결성 문제를 감지합니다.	`DBCC CHECKDB`는 데이터베이스에 있는 모든 객체의 무결성을 확인합니다. 매주 `DBCC CHECKDB`를 실행하면 데이터베이스가 손상되지 않았는지 확인할 수 있습니다. `DBCC CHECKDB`는 인스턴스 성능에 영향을 줄 수 있는 리소스 집약적인 작업입니다. 프로덕션 서버에서 `DBCC CHECKDB`를 실행하지 마세요. 프로덕션 서버에서 `DBCC CHECKDB`을 실행하는 대신 다음 옵션 중 하나를 사용하는 것이 좋습니다. 데이터베이스를 클론하고 클론 데이터베이스에서 `DBCC CHECKDB`를 실행합니다. 백업을 다른 인스턴스로 복원한 다음 복원된 인스턴스의 데이터베이스에서 `DBCC CHECKDB`를 실행합니다. 인스턴스 복원에 대한 자세한 내용은 인스턴스 복원을 참조하세요. 다음 코드 스니펫을 사용하여 데이터베이스에서 `DBCC CHECKDB`를 실행합니다. (권장사항) `EXTENDED_LOGICAL_CHECKS`를 사용하여 `DBCC CHECKDB`을 실행합니다. 이는 포괄적이지만 리소스 집약적인 검사입니다. USE `DATABASE_NAME` DBCC CHECKDB WITH EXTENDED_LOGICAL_CHECKS, DATA_PURITY,NO_INFOMSGS, ALL_ERRORMSGS `PHYSICAL_ONLY`로 `DBCC CHECKDB`를 실행합니다. USE `DATABASE_NAME` DBCC CHECKDB WITH PHYSICAL_ONLY, NO_INFOMSGS, ALL_ERRORMSGS

데이터 아키텍처

권장사항	추가 정보
가능하면 큰 인스턴스를 작은 인스턴스로 분할합니다.	가능한 경우 여러 개의 작은 Cloud SQL 인스턴스를 사용하는 것이 하나의 큰 인스턴스를 사용하는 것보다 더 효과적입니다. 큰 모놀리식 인스턴스를 관리하면 작은 인스턴스들의 그룹을 관리할 때 발생하지 않는 문제가 발생합니다.
너무 많은 데이터베이스 테이블을 사용하지 마세요.	인스턴스의 테이블 수를 10,000개 미만으로 유지합니다. 데이터베이스 테이블이 너무 많으면 데이터베이스 업그레이드 시간에 영향을 줄 수 있습니다.
데이터베이스 콜레이션	새 SQL Server 인스턴스를 설치할 때이든, 데이터베이스 백업을 복원할 때이든, 아니면 서버를 클라이언트 데이터베이스에 연결할 때이든, 작업하는 데이터의 언어 요구사항, 정렬 순서, 대소문자 및 강조 민감도를 이해하는 것이 중요합니다. 서버, 데이터베이스, 열 또는 표현식의 콜레이션을 선택하면 데이터에 특정 특성이 할당됩니다. 이러한 특성은 데이터베이스의 여러 작업 결과에 영향을 줍니다. 예를 들어 `ORDER BY`를 사용하여 쿼리를 생성하는 경우 결과 집합의 정렬 순서는 데이터베이스에 적용되거나 쿼리 표현 수준의 `COLLATE` 절에서 결정되는 콜레이션에 따라 달라집니다. 데이터베이스 콜레이션 및 유니코드 지원에 대해 자세히 알아보세요.
쿼리 설계	최적의 데이터베이스 또는 쿼리 성능을 위해 동일한 쿼리 내에 많은 수의 테이블을 사용하지 않아야 합니다(16개 이상).
쿼리 모니터링	시간이 지남에 따라 쿼리가 저하될 수 있습니다. 애플리케이션 모니터링과 시간 경과에 따른 쿼리 성능이 중요합니다. 이러한 성능 저하의 한 가지 이유는 해시 베일아웃입니다. 재귀 해시 조인 또는 해시 베일아웃으로 인해 서버의 성능이 저하됩니다. trace에 해시 경고 이벤트가 다수 표시되면 조인되는 열의 통계를 업데이트합니다. 해시 베일아웃에 대해 자세히 알아보세요.

애플리케이션 구현

권장사항	추가 정보
연결 풀링 및 지수 백오프와 같은 연결 관리 권장사항을 사용하세요.	이러한 방법을 사용하면 애플리케이션의 리소스 사용이 향상되고 Cloud SQL 연결 한도를 유지할 수 있습니다. 자세한 내용과 코드 샘플은 데이터베이스 연결 관리를 참조하세요.
유지보수 기간 중 언제든지 발생할 수 있는 유지보수 업데이트에 대한 애플리케이션의 응답을 테스트하세요.	셀프서비스 유지보수를 통해 유지보수 업데이트를 시뮬레이션하세요. 유지보수 중에 인스턴스를 잠시 사용할 수 없게 되고 기존 연결이 끊어집니다. 유지보수 출시 테스트를 통해 애플리케이션이 예약된 유지보수를 처리하는 방법과 시스템이 복구되는 시간에 대해 보다 잘 이해할 수 있습니다.
언제든지 발생할 수 있는 장애 조치에 대한 애플리케이션의 응답을 테스트하세요.	Google Cloud 콘솔, gcloud CLI 또는 API를 사용하여 장애 조치를 수동으로 시작할 수 있습니다. 장애 조치 시작을 참조하세요.
대규모 트랜잭션은 피하세요.	트랜잭션을 작고 짧게 유지하세요. 대규모 데이터베이스 업데이트가 필요한 경우 하나의 큰 트랜잭션이 아니라 여러 건의 작은 트랜잭션으로 수행하세요.
Cloud SQL 인증 프록시를 사용하는 경우 최신 버전을 사용하세요.	Cloud SQL 인증 프록시를 최신 상태로 유지하기를 참조하세요.

데이터 가져오기 및 내보내기

권장사항	추가 정보
작은 인스턴스 크기의 가져오기 속도를 높이세요.	작은 인스턴스의 경우 큰 데이터 세트를 가져올 때 성능을 개선하기 위해 임시로 인스턴스의 CPU와 RAM을 증가시킬 수 있습니다.
Cloud SQL로 가져올 데이터를 내보내는 경우 적절한 절차를 사용하세요.	외부 관리 데이터베이스 서버에서 데이터 내보내기를 참조하세요.

백업 및 복구

권장사항	추가 정보
적절한 Cloud SQL 기능을 사용하여 데이터를 보호하세요.	데이터 중복 및 보호 기능을 제공하는 방법은 백업과 내보내기입니다. 이러한 방법들은 각각 다른 시나리오에서 서로 보호하고 강력한 데이터 보호 전략을 통해 상호 보완합니다. 백업은 간편하며 인스턴스의 데이터를 백업을 수행할 당시의 상태로 복원할 수 있습니다. 그러나 백업에는 몇 가지 제한사항이 있습니다. 인스턴스를 삭제하면 백업도 삭제됩니다. 단일 데이터베이스 또는 테이블은 백업할 수 없습니다. 인스턴스가 위치하는 지역을 사용할 수 없는 경우에는 사용 가능한 리전에서도 해당 백업에서 인스턴스를 복원할 수 없습니다. Cloud Storage에 데이터를 다시 만들 때 사용할 수 있는 외부 파일이 만들어지므로 내보내기를 만드는 데 시간이 더 오래 걸립니다. 내보내기는 인스턴스를 삭제해도 영향을 받지 않습니다. 또한 선택한 내보내기 형식에 따라 단일 데이터베이스 또는 테이블만 내보낼 수도 있습니다. Enterprise 또는 Standard SQL Server 인스턴스에서 백업 내보내기 기능을 사용할 때는 SQL Server에서 이미 고유하게 압축된 백업을 압축하려고 시도하므로, GZ 아카이브 파일 만들기를 선택하지 마세요.
인스턴스와 백업이 실수로 삭제되지 않도록 보호하세요.	Google Cloud 콘솔 또는 Terraform을 통해 만든 Cloud SQL 인스턴스는 실수로 인한 삭제 방지를 기본적으로 사용 설정합니다. 추가 보호를 위해 Cloud SQL에서 내보내기 기능을 사용하여 데이터를 내보내세요. Cloud Scheduler를 REST API와 함께 사용하여 내보내기 관리를 자동화하세요. 고급 시나리오의 경우 자동화를 위해 Cloud Functions와 Cloud Functions를 함께 사용합니다.

권장사항

추가 정보

적절한 Cloud SQL 기능을 사용하여 데이터를 보호하세요.

데이터 중복 및 보호 기능을 제공하는 방법은 백업과 내보내기입니다. 이러한 방법들은 각각 다른 시나리오에서 서로 보호하고 강력한 데이터 보호 전략을 통해 상호 보완합니다.

백업은 간편하며 인스턴스의 데이터를 백업을 수행할 당시의 상태로 복원할 수 있습니다. 그러나 백업에는 몇 가지 제한사항이 있습니다. 인스턴스를 삭제하면 백업도 삭제됩니다. 단일 데이터베이스 또는 테이블은 백업할 수 없습니다. 인스턴스가 위치하는 지역을 사용할 수 없는 경우에는 사용 가능한 리전에서도 해당 백업에서 인스턴스를 복원할 수 없습니다.

Cloud Storage에 데이터를 다시 만들 때 사용할 수 있는 외부 파일이 만들어지므로 내보내기를 만드는 데 시간이 더 오래 걸립니다. 내보내기는 인스턴스를 삭제해도 영향을 받지 않습니다. 또한 선택한 내보내기 형식에 따라 단일 데이터베이스 또는 테이블만 내보낼 수도 있습니다.

Enterprise 또는 Standard SQL Server 인스턴스에서 백업 내보내기 기능을 사용할 때는 SQL Server에서 이미 고유하게 압축된 백업을 압축하려고 시도하므로, GZ 아카이브 파일 만들기를 선택하지 마세요.

인스턴스와 백업이 실수로 삭제되지 않도록 보호하세요.

Google Cloud 콘솔 또는 Terraform을 통해 만든 Cloud SQL 인스턴스는 실수로 인한 삭제 방지를 기본적으로 사용 설정합니다.

추가 보호를 위해 Cloud SQL에서 내보내기 기능을 사용하여 데이터를 내보내세요. Cloud Scheduler를 REST API와 함께 사용하여 내보내기 관리를 자동화하세요. 고급 시나리오의 경우 자동화를 위해 Cloud Functions와 Cloud Functions를 함께 사용합니다.

SQL Server 설정

일부 SQL Server 설정은 Cloud SQL에 권장됩니다. 다음 주제에서는 몇 가지 권장사항에 대해 설명합니다.

전역 구성 설정

설정	권장사항
`max worker threads`	기본값 0을 유지합니다. 이 설정은 CPU 수에 따라 SQL Server에 제공되는 스레드 수를 정의합니다. 이 값은 시작 시 SQL Server 엔진에서 자동으로 계산됩니다.

수정할 데이터베이스 설정

SQL Server 데이터베이스의 최적 성능을 위해서는 아래 설명에 따라 다음 SQL Server 설정을 지정합니다.

설정	권장사항
`cost threshold for parallelism`	이는 SQL 옵티마이저가 동시 로드를 사용하여 쿼리를 수행할 때 사용되는 임곗값입니다. `5`의 기본값은 너무 많은 쿼리가 병렬로 실행되도록 만들 수 있기 때문에 병렬 스레드에서 데이터베이스 대기 시간이 길어집니다. 이 유형의 경합을 줄이려면 값을 높이세요. `maxdop`이 `1`로 설정된 경우 이 값이 무시됩니다.
`max degree of parallelism (MAXDOP)`	동시 로드로 인한 데이터베이스 대기를 줄이려면 사용 가능한 논리적 프로세서 수와 관련된 특정 권장사항에 따라 이 값을 조정하세요. 이 옵션을 1로 설정할 경우 성능을 신중하게 측정합니다.
`optimize for ad hoc workloads`	계획 캐시에서 많은 수의 단일 사용 계획을 지정하지 않도록 합니다. 많은 수의 단일 사용 임시 배치를 포함하는 워크로드에 대해 계획 캐시 효율을 향상시키려면 이 옵션을 `1`로 설정합니다.
`tempdb`	자동 증가될 필요가 없도록 `tempdb` 크기를 미리 지정합니다. `tempdb`의 모든 파일은 크기가 같아야 하고 파일 증가 설정이 동일해야 합니다. `tempdb` 경합의 데이터베이스 대기 유형은 `PAGELATCH_UP`으로 표시됩니다. 경합을 줄이려면 파일을 더 추가합니다. 프로세서 수가 8이하면 논리적 프로세서와 동일한 개수의 파일을 사용합니다. 프로세서 수가 8보다 크면 8개 데이터 파일을 사용합니다. 경합이 계속되면 더 이상 경합이 없을 때까지 4의 배수로 파일 수를 늘립니다.

워크로드에 따라 다음 설정도 수정해야 할 수 있습니다.

설정	권장사항
`Close Cursor on Commit Enabled`	기본값은 `off`이며, 트랜잭션을 커밋할 때 커서가 자동으로 닫히지 않습니다.
`Default Cursor`	이 옵션은 T-SQL 코드에서 사용되는 커서의 범위를 제어합니다. 이 설정을 변경할 경우 애플리케이션 코드에서 부작용을 평가합니다.
`Page Verify`	이 옵션은 디스크에 기록되기 전 SQL Server가 데이터베이스 페이지에 대해 체크섬을 계산하고 체크섬을 페이지 헤더에 저장할 수 있게 해줍니다. 페이지를 다시 읽으면 체크섬을 다시 계산하여 페이지 무결성을 확인합니다. 권장 값은 `checksum`입니다.
`Parameterization`	기본값은 `simple`입니다. 간단한 매개변수화는 SQL Server가 쿼리의 리터럴 값을 매개변수로 바꿀 수 있게 해줍니다. Microsoft는 이 값을 변경하고 계획 가이드에 따라 사용하는 방법에 대한 가이드를 제공합니다.

보존할 데이터베이스 설정

SQL Server 데이터베이스의 최적 성능을 위해 다음 SQL Server 설정의 기본값을 보존합니다.

설정	보존할 기본값
`Auto Close`	`False`. 이 설정은 활성화된 경우 연결을 열고 닫고 각 연결 이후 프로시져를 플러시합니다. 자주 액세스되는 데이터베이스에서 성능 저하가 발생할 수 있습니다.
`Auto Shrink`	`False`. 활성화하면 데이터베이스 및 색인이 조각화되고 기타 성능 문제가 발생할 수 있습니다. 이에 대한 일부 내용은 이 SQL Server 블로그를 참조하세요.
`Date Correlation Optimization Enabled`	`False`. 이를 사용 설정하면 옵티마이저가 두 관련 테이블 간의 날짜 사이의 관계를 찾고 최적화할 수 있습니다. SQL Server에서 이를 추적하면 일부 성능 오버헤드가 발생합니다.
`Legacy Cardinality Estimation`	`False`. 일부 경우에 SQL Server는 이 설정이 사용 설정되었을 때 카디널리티를 정확하게 계산할 수 없습니다.
`Parameter Sniffing`	`ON`. 데이터베이스 테이블에서 매개변수 스니핑은 다시 사용할 수 있는 실행 계획을 만드는 데 도움을 줄 수 있습니다. 테이블에 데이터가 고르지 않게 분산된 경우 결과 실행 계획이 성능 문제로 이어질 수 있습니다. 이러한 데이터에서는 이 설정을 수정하는 대신 Query Store의 다른 옵션을 사용합니다.
`Query Optimizer Fixes`	`False`. 사용 설정된 경우 SQL Server 카디널리티 에스티메이터의 성능에 영향을 줄 수 있습니다. 이를 사용 설정하도록 선택한 경우 테스트를 통해 쿼리 회귀가 없는지 확인합니다.
`Auto Create Statistics`	`True`.이 옵션은 SQL Server가 쿼리 계획의 카디널리티 예측을 향상시킬 수 있는 단일 열 통계를 만들 수 있게 해줍니다.
`Auto Update Statistics`	`True`. 이 옵션은 SQL Server가 테이블 카디널리티를 기반으로 하는 다시 컴파일 임곗값을 사용해서 오래된 통계를 업데이트할 수 있게 해줍니다.
`Auto Update Statistics Asynchronously`	`False`. 이 옵션은 사용 설정된 경우 SQL 쿼리 옵티마이저가 현재 쿼리 실행에 오래된 쿼리를 사용하도록 지정하고, 이후 워크로드에 도움이 되도록 통계를 비동기적으로 업데이트합니다. 하지만 자주 실행되는 쿼리에 대해 예측 가능한 응답 시간이 예상되거나 통계 업데이트를 기다리는 동안 애플리케이션에서 클라이언트 요청 시간 제한이 자주 발생하는 경우에는 이 옵션을 사용 설정하고 `Auto Update Statistics`를 사용 중지할 수 있습니다.
`Target Recovery Time (Seconds)`	`60`. 이 설정은 더티 페이지를 버퍼 풀에서 디스크로 일정 빈도로 플러시하여 데이터베이스의 복구 시간에 대한 상한 값을 설정합니다. 높은 트랜잭션 워크로드의 경우 최댓값 근처의 스토리지 IOPS와 함께 이 설정에 대해 낮은 값을 사용하면 성능 병목 현상에 영향을 줄 수 있습니다.

Trace 플래그 설정

SQL Server에서 Trace 플래그는 특정 문자를 설정하거나, SQL Server 데이터베이스의 동작을 수정하거나, SQL Server의 문제를 디버깅하기 위해 사용됩니다.

일부 SQL Server Trace 플래그가 Cloud SQL에서 지원되며 데이터베이스 플래그를 사용하여 설정될 수 있습니다. 권장 설정은 다음과 같습니다.

Trace 플래그	권장
`1204`	`Yes`, 많은 교착 상태를 생성하는 워크로드 집중 서버는 예외입니다. 교착 상태에 관여하는 잠금 유형과 리소스를 반환하고 현재 영향을 받은 명령어도 반환합니다.
`1222`	`Yes`, 많은 교착 상태를 생성하는 워크로드 집중 서버는 예외입니다.
`1224`	`No`. 더 많은 메모리 사용으로 이어지고 데이터베이스에서 메모리 압력을 유발할 수 있습니다.
`2528`	`No`. 객체에 대한 병렬 검사가 기본값이고 권장됩니다. 동시 로드 정도는 데이터베이스 엔진에서 자동으로 계산됩니다.
`3205`	`No`. 백업용 테이프 드라이브는 SQL Server용 Cloud SQL의 기능입니다.
`3226`	`No`, TLOG 백업과 같은 자주 수행되는 백업이 필요한 경우는 예외입니다.
`3625`	`No`. 루트 계정에 시스템 관리자 액세스가 없기 때문에 모든 오류 메시지가 표시되지 않을 수 있습니다.
`4199`	`No`. 카디널리티 에스티메이터에 영향을 주고 쿼리 회귀로 이어질 수 있습니다.
`4616`	`No`. 이 제한은 애플리케이션 역할 주변의 보안을 낮춥니다. 애플리케이션 요구사항을 기반으로 검증되어야 합니다.
`7806`	`Yes`. 데이터베이스 서버가 응답하지 않으면 전용 관리자 연결(DAC)만이 진단에 대해 연결을 수행할 수 있는 유일한 방법일 수 있습니다.

다음 단계

데이터베이스 엔진의 일반적인 권장사항에 대한 자세한 내용은 다음을 참조하세요.