내보내기(0) 인쇄
모두 확장

Azure SQL 데이터베이스 제한(Throttling)

업데이트 날짜: 2015년 2월

이 항목에서는 엔진 제한(throttling) 메커니즘, 연결된 오류 코드 및 발생할 수 있는 오류 해결 방법에 대해 설명합니다.

다음 표에서는 엔진 제한 메커니즘, 반환되는 해당 오류 코드, 오류 해결을 위한 권장 사항에 대한 정보를 제공합니다.

 

엔진 제한 메커니즘 반환된 오류 코드 권장 사항

엔진 제한은 다음 단계에 따라 부하를 줄이고 시스템 상태를 보호합니다.

  1. 시스템을 정상 상태로 되돌리는 데 필요한 부하 감소량을 결정합니다.

  2. 과도한 리소스를 사용하는 구독자 데이터베이스를 제한 후보로 표시합니다. 약간의 초과로 인해 발생하는 엔진 제한인 경우 특정 데이터베이스가 제한 후보 고려 대상에서 면제될 수 있습니다. 많이 초과되어 발생한 엔진 제한인 경우 현재 제한 주기 직전 제한 주기에 부하가 전혀 걸리지 않은 구독자 데이터베이스를 제외하고 모든 구독자 데이터베이스가 제한 후보가 될 수 있습니다.

  3. 후보 데이터베이스의 이전 리소스 사용 패턴을 확인하여 시스템을 정상 상태로 되돌리기 위해 제한되어야 하는 후보 데이터베이스 수를 계산합니다.

  4. 시스템 부하를 원하는 수준으로 되돌릴 때까지 계산된 개수의 후보 데이터베이스를 제한합니다. 제한이 하드 제한인지 소프트 제한인지 여부에 따라 적용되는 제한의 정도 또는 제한 모드가 다를 수 있습니다. 오류 메시지의 인시던트 ID 및 코드 값을 사용하여 적용되는 제한의 정도 및 모드를 확인할 수 있습니다. 제한된 모든 데이터베이스는 최소 1 제한 주기(10초) 동안은 제한된 상태로 유지되지만, 종종 시스템을 정상 상태로 되돌리기 위해 제한 상태가 여러 제한 주기 동안 유지되기도 합니다.

40501: 서비스가 현재 사용 중입니다. 10초 후 요청을 다시 시도하십시오. 인시던트 ID: <ID>. 코드: <코드>.

note참고
인시던트 ID코드 값은 제한되는 요청의 종류와 소프트 제한 또는 하드 제한 여부를 확인하는 데 사용할 수 있습니다. 자세한 내용은 이 항목의 뒷부분에 나오는 "제한 인시던트 ID" 및 "이유 코드 디코딩" 섹션을 참조하십시오.

백오프하고 10초 후에 다시 요청하십시오.

오류 40501의 제한 인시던트 ID는 제한 인시던트를 고유하게 식별하는 GUID 값입니다.

40501: The service is currently busy. Retry the request after 10 seconds. Incident ID: <ID>. Code: <code>.

제한이 발생한 이유나 제한이 지속되는지 여부를 확인할 수 없는 경우 문제를 해결하는 방법을 모르면 Microsoft 지원에 문의하고 오류 메시지의 인시던트 ID(<ID>)를 알려주십시오. Microsoft 지원에서는 이 인시던트 ID를 사용하여 사용자의 제한 인시던트와 관련된 추가 정보를 검색합니다. 인시던트 ID는 다음 정보를 얻는 데 사용할 수 있습니다.

  • 제한 인시던트의 시작 시간

  • 제한 유형(소프트 제한 및 하드 제한)

  • 제한 인시던트 도달로 인한 리소스 유형(예: CPU)

  • 이 제한 인시던트가 발생했을 때 사용자는 무엇을 실행하고 있었습니까?

Microsoft 고객 지원으로부터 근본 원인을 확인한 후 응용 프로그램에서 적절히 변경할 수 있습니다.

다음 섹션에서는 다음 엔진 제한(throttling) 오류 코드에서 반환되는 이유 코드를 디코딩하는 방법에 대해 설명합니다.

40501: The service is currently busy. Retry the request after 10 seconds. Incident ID: <ID>. Code: <code>.

오류 메시지의 이유 코드(<코드>)는 제한 모드 및 초과된 리소스 유형에 대한 정보가 포함된 10진수입니다.

  • 제한 모드는 거부된 문 형식을 열거합니다.

  • 리소스 유형은 초과된 리소스를 지정합니다. CPU 및 IO와 같은 여러 개의 리소스 유형에서 제한 작업을 동시에 수행할 수 있습니다.

예를 들어 이유 코드가 131075인 다음 샘플 오류 메시지를 살펴보세요.

40501: The service is currently busy. Retry the request after 10 seconds. Incident ID: {5DE17AB8-A6E34BE5-A2E95BB5D4CC4155}. Code: 131075.

다음 다이어그램에서는 이유 코드를 디코딩하는 방법을 보여 줍니다.

이유 코드 디코딩

제한 모드를 확인하려면 이유 코드에 모듈로 4를 적용합니다. 모듈로 연산은 한 수를 다른 수로 나눈 나머지를 반환합니다. 제한 유형과 리소스 유형을 확인하려면 1단계에 표시된 대로 이유 코드를 256으로 나눕니다. 그런 다음 2단계와 3단계에 표시된 대로 결과의 몫을 이진 표현으로 변환합니다. 다음 다이어그램에서는 모든 제한 유형과 리소스 유형을 보여 줍니다. 확인된 제한 유형을 다이어그램에 표시된 리소스 유형 비트와 비교하십시오.

다음 표에서는 제한 모드의 목록을 제공합니다.

 

제한 모드 코드 설명 거부된 문 형식 처리 가능한 문

0

제한 없음

없음

모두

1

업데이트/삽입 거부

INSERT, UPDATE, CREATE TABLE | INDEX

DELETE, DROP TABLE | INDEX, TRUNCATE

2

모든 쓰기 거부

INSERT, UPDATE, DELETE, CREATE, DROP

SELECT

3

모두 거부

모두

없음

제한 모드를 확인하려면 이유 코드에 모듈로 4를 적용합니다. 131075 % 4 = 3. 결과 3은 제한 모드가 "모두 거부"임을 의미합니다.

제한 유형 및 리소스 유형을 가져오려면 이유 코드를 256으로 나눕니다. 그런 결과의 몫을 이진 표현으로 변환합니다. 131075/256 = 512(10진수) 및 512(10진수) = 10 00 00 00 00 (이진). 이는 CPU(리소스 유형 4) 및 하드 제한(10)으로 인해 데이터베이스가 제한되었다는 것을 의미합니다.

다음 샘플 코드는 Azure용 Enterprise Library 통합 팩의 임시 오류 처리 응용 프로그램 블록("Topaz"라고도 함)에 있는 ThrottlingCondition 클래스를 사용하여 엔진 제한 오류(40501)의 이유 코드를 디코딩합니다. 임시 오류 처리 응용 프로그램 블록 어셈블리 및 소스 코드를 다운로드하여 ThrottlingCondition 클래스를 사용하려면 Azure용 Enterprise Library 5.0 통합 팩을 참조하십시오.

다음 샘플 코드는 엔진 제한(throttling) 오류(40501)에 제공된 이유 코드를 입력하라는 메시지를 표시한 다음, 지정한 이유 코드에 대한 제한 모드, 제한 유형 및 리소스 유형을 표시합니다.

using System;
using Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling.Data;

namespace ThrottlingDecoder
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.Write("Enter a throttling code to be decoded: ");
            var rawCode = Console.ReadLine();
            int reasonCode;

            if (Int32.TryParse(rawCode, out reasonCode))
            {
                var throttlingCode = ThrottlingCondition.FromReasonCode(reasonCode);

                Console.WriteLine("\nBreakdown for throttling reason code {0}:\n", reasonCode);

                Console.WriteLine("Throttling mode: {0}", throttlingCode.ThrottlingMode);
                Console.WriteLine("Throttled On CPU: {0}", throttlingCode.IsThrottledOnCpu);
                Console.WriteLine("Throttled On DB Size: {0}", throttlingCode.IsThrottledOnDatabaseSize);
                Console.WriteLine("Throttled On DB Reads: {0}", throttlingCode.IsThrottledOnDataRead);
                Console.WriteLine("Throttled On DB Free space: {0}", throttlingCode.IsThrottledOnDataSpace);
                Console.WriteLine("Throttled On Log Free Size: {0}", throttlingCode.IsThrottledOnLogSpace);
                Console.WriteLine("Throttled On Log Writes: {0}", throttlingCode.IsThrottledOnLogWrite);
                Console.WriteLine("Throttled On Worker Threads: {0}", throttlingCode.IsThrottledOnWorkerThreads);
                
                Console.WriteLine("\nThrottled resources:");

                foreach (var res in throttlingCode.ThrottledResources)
                {
                   if (res.Item2 != ThrottlingType.None) Console.ForegroundColor = ConsoleColor.Red;
                    Console.WriteLine("Resource type {0} is throttled on {1}", res.Item1, res.Item2);
                    if (res.Item2 != ThrottlingType.None) Console.ResetColor();
                }
            }
            else
            {
                Console.WriteLine("Sorry, but the input you provided does not seem to be a valid number.");
            }
            Console.Read();
        }
    }
}

SQL 데이터베이스 TDS 게이트웨이는 실패를 보고하기 전에 약 30초 동안 연결을 다시 시도합니다. 응용 프로그램 트래픽이 높을 것으로 예상되는 경우 응용 프로그램에 다시 시도 논리를 작성하십시오. 연결이 실패한 경우 다음을 수행합니다.

  • 유휴 상태 및 일시적인 연결 끊김을 처리합니다.

    note참고
    응용 프로그램에 유효하지 않은 연결을 반환하는 SqlClient 문제를 수정하는 .NET Framework 4.0용 안정성 업데이트 1을 설치합니다. 이 업데이트를 설치한 경우 SqlClient는 유효하지 않은 연결을 응용 프로그램에 반환하기 전에 풀의 연결이 유효하지 않은지 여부를 확인합니다. 연결이 유효하지 않은 경우 SqlClient는 응용 프로그램에 유효하지 않은 연결을 반환하기 전에 연결을 다시 시도합니다. 이 문제에 대한 자세한 내용은 SQL 데이터베이스의 연결 풀 오류 최소화를 참조하십시오.

  • 리소스를 사용할 수 있고 연결이 다시 설정될 때까지 10초 간격으로 SQL 데이터베이스에 대한 연결을 다시 시도합니다. 응용 프로그램, 데이터베이스 및 네트워크 작업 부하에 따라 필요한 경우 지연 시간을 늘려야 합니다.

  • 연결이 다시 종료될 경우 작업 부하를 변경합니다. 연결이 다시 종료될 경우 오류 코드를 검토하고 실제로 문제가 되는 부분을 확인한 다음 작업 부하를 변경합니다. 작업 부하를 줄이기 위해 클라이언트 응용 프로그램에 큐 또는 지연 메커니즘을 구현할 수 있습니다.

    리소스 병목 현상이 사라지도록 응용 프로그램과 데이터베이스를 다시 디자인하는 것도 한 가지 방법입니다. 응용 프로그램의 과도한 DDL 또는 DML 작업으로 인해 tempdb가 오버로드되지 않도록 합니다. 또한 트랜잭션으로 인해 리소스가 차단되지 않는지 확인합니다. 적절한 경우 데이터베이스를 여러 개의 작은 데이터베이스로 분할하는 것도 좋습니다.

  • 작성한 코드가 제한에서 복구될 수 있는지 확인합니다. 사용자는 응용 프로그램에서 언제든지 연결이 끊길 수 있다고 가정해야 합니다. 따라서 가능하면 단일 트랜잭션으로 일괄 처리 요청을 만드는 것이 좋습니다. 이 경우 일괄 처리의 일부만 완료되어 데이터베이스가 예기치 않음/테스트되지 않음 상태로 전환되는 경우가 최소화됩니다. 이를 위해 각 임시 일괄 처리 시 및 각 저장 프로시저가 시작하고 끝날 때 BEGIN TRANS/COMMIT TRANS를 수행해야 할 수도 있습니다.

  • 다시 시도 논리가 응용 프로그램의 정확성(멱등성)에 어떤 식으로 영향을 주는지 파악합니다. 업데이트 또는 삽입이 수행될 때 성공이 반환되기 전에 연결이 끊기면 어떤 결과가 발생하는지 이해하는 것이 중요합니다. 트랜잭션이 중단된 경우 올바른 단계는 연결을 다시 시도하는 것입니다. 트랜잭션이 실제로 커밋된 경우에는 트랜잭션을 다시 실행하는 것이 적절하지 않을 수도 있습니다. 사용자가 수행한 변경들이 멱등하지 않은 경우, 연결 끊김을 방지하기 위해 사용되는 다시 시도 논리를 기반으로 반복되는 트랜잭션 커밋을 검색할 수 있도록 해당 논리 데이터베이스 스키마를 수정해야 할 수도 있습니다.

다시 시도 코드로 제한 오류를 기록하여 일시적인 연결, 제한 및 하드 오류 구문, 누락된 저장 프로시저 등을 구분합니다. 이는 특히 SQL 데이터베이스에 연결할 수 없는 경우 문제를 해결하는 데 유용합니다. 이 경우 기록된 정보에 초점을 맞춰 문제를 해결하며 문제를 효과적으로 해결할 수 있는지 여부는 기록된 정보의 정확성에 따라 달라집니다. SQL 데이터베이스 응용 프로그램에 로깅을 구현하는 방법에 대한 자세한 내용은 Azure SQL 데이터베이스 응용 프로그램의 로깅 구현을 참조하십시오.

참고 항목

Microsoft는 MSDN 웹 사이트에 대한 귀하의 의견을 이해하기 위해 온라인 설문 조사를 진행하고 있습니다. 참여하도록 선택하시면 MSDN 웹 사이트에서 나가실 때 온라인 설문 조사가 표시됩니다.

참여하시겠습니까?
표시:
© 2015 Microsoft