다음을 통해 공유

SQL Server 2019 빅 데이터 클러스터 플랫폼 알려진 문제

적용 대상: SQL Server 2019(15.x)

중요합니다

Microsoft SQL Server 2019 빅 데이터 클러스터 추가 기능이 사용 중지됩니다. SQL Server 2019 빅 데이터 클러스터에 대한 지원은 2025년 2월 28일에 종료됩니다. Software Assurance를 사용하는 SQL Server 2019의 모든 기존 사용자는 플랫폼에서 완전히 지원되며, 소프트웨어는 지원 종료 시점까지 SQL Server 누적 업데이트를 통해 계속 유지 관리됩니다. 자세한 내용은 공지 블로그 게시물 및 Microsoft SQL Server 플랫폼의 빅 데이터 옵션을 참조하세요.

알려진 문제

임의 실패가 발생할 수 있는 상황에서 azdata를 사용하여 대용량 파일의 HDFS 복사본 만들기

  • 영향을 받는 릴리스: CU14

  • 문제 및 고객 효과: HDFS 경로 간의 명령 중 임의로 오류가 발생하는 버그입니다. 이 버그는 더 큰 파일 복사본에 더 자주 영향을 줍니다.

  • 해결 방법: CU15(누적 업데이트 15)로 업데이트합니다.

Log4j 보안

  • 영향을 받는 릴리스: 없음

  • 문제 및 고객 효과: SQL Server 2019 빅 데이터 클러스터 코드베이스에 대한 철저한 평가 후 12월에 보고된 log4j 취약성과 관련된 위험이 확인되지 않았습니다. CU15에는 빅 데이터 클러스터 컨테이너의 정적 코드 분석에 의해 이미지 검사 경고가 트리거되지 않도록 컨트롤 플레인의 ElasticSearch 인스턴스에 대한 업데이트된 버전의 log4j(2.17)가 포함되어 있습니다.

  • 해결 방법: 항상 빅 데이터 클러스터를 최신 릴리스로 업데이트합니다.

CU8 및 이전 릴리스에서 CU9 이후 릴리스로의 클러스터 업그레이드는 지원되지 않습니다.

  • 영향을 받는 릴리스: CU8 및 이전 릴리스

  • 문제 및 고객 효과: CU8 릴리스 또는 이전 버전의 클러스터를 CU9 위의 모든 릴리스로 직접 업그레이드하는 경우 모니터링 단계에서 업그레이드가 실패합니다.

  • 해결 방법: CU9로 먼저 업그레이드합니다. 그런 다음 CU9에서 최신 릴리스로 업그레이드합니다.

Kubernetes API 버전 1.21 이상인 Kubernetes 플랫폼

  • 영향을 받는 릴리스: 모든 릴리스

  • 문제 및 고객 효과: Kubernetes API 1.21 이상은 CU12를 기준으로 SQL Server 빅 데이터 클러스터의 테스트된 구성이 아닙니다.

SQL Server Machine Learning Services의 MicrosoftML 패키지

  • 영향을 받는 릴리스: CU10, CU11, CU12 및 CU13

  • 문제 및 고객 효과: SQL Server Machine Learning Services의 일부 MicrosoftML R/Python 패키지가 작동하지 않습니다. 모든 SQL Server 마스터 인스턴스에 영향을 줍니다.

SQL Server 2016 이상의 원격 인스턴스에 연결하지 못했습니다.

  • 영향을 받는 릴리스: CU10
  • 문제 및 고객 효과: SQL Server 2019 빅 데이터 클러스터 CU10에서 PolyBase를 사용하여 SHA1 알고리즘을 사용하여 만든 채널 암호화용 인증서를 사용하는 기존 SQL Server 인스턴스에 연결하는 경우 다음 오류가 발생할 수 있습니다.

Msg 105082, Level 16, State 1, Line 1 105082;Generic ODBC error: [Microsoft][ODBC Driver 17 for SQL Server]SSL Provider: An existing connection was forcibly closed by the remote host. Additional error <2>: ErrorMsg: [Microsoft][ODBC Driver 17 for SQL Server]Client unable to establish connection, SqlState: 08001, NativeError: 10054 Additional error <3>: ErrorMsg: [Microsoft][ODBC Driver 17 for SQL Server] Invalid connection string attribute, SqlState: 01S00, NativeError: 0 .

  • 해결 방법: 이전 기본 이미지 버전보다 Ubuntu 20.04의 보안 요구 사항이 높아져 SHA1 알고리즘을 사용하는 인증서에 대한 원격 연결이 허용되지 않습니다. SQL Server 릴리스 2005-2016의 기본 자체 서명된 인증서는 SHA1 알고리즘을 사용했습니다. 이 변경에 대한 자세한 내용은 SQL Server 2017에서 자체 서명된 인증서에 대한 변경 내용을 참조하세요. 원격 SQL Server 인스턴스에서 112비트 이상의 보안을 사용하는 알고리즘(예: SHA256)을 사용하여 만든 인증서를 사용합니다. 프로덕션 환경의 경우 인증 기관에서 신뢰할 수 있는 인증서를 가져오는 것이 좋습니다. 테스트를 위해 자체 서명된 인증서를 사용할 수도 있습니다. 자체 서명된 인증서를 만들려면 PowerShell Cmdlet New-SelfSignedCertificate 또는 certreq 명령을 참조하세요. 원격 SQL Server 인스턴스에 새 인증서를 설치하는 지침은 데이터베이스 엔진에 암호화된 연결 사용을 참조하세요.

롤백 시 ElasticSearch에서 수집된 로그의 부분 손실

  • 영향을 받는 릴리스: CU9로 업그레이드하지 못한 경우 롤백이 발생하거나 사용자가 이전 릴리스로 다운그레이드를 실행하면 기존 클러스터에 영향을 줍니다.

  • 문제 및 고객 효과: Elastic Search에 사용되는 소프트웨어 버전이 CU9로 업그레이드되었으며 새 버전은 이전 로그 형식/메타데이터와 호환되지 않습니다. ElasticSearch 구성 요소가 성공적으로 업그레이드되었지만 이후 롤백이 트리거되면 ElasticSearch 업그레이드와 롤백 간에 수집된 로그가 영구적으로 손실됩니다. 이전 버전의 SQL Server 2019 빅 데이터 클러스터(권장되지 않음)로 다운그레이드를 실행하면 Elasticsearch에 저장된 로그가 손실됩니다. CU9로 다시 업그레이드하면 데이터가 복원됩니다.

  • 해결 방법: 필요한 경우 명령을 사용하여 azdata bdc debug copy-logs 수집된 로그를 사용하여 문제를 해결할 수 있습니다.

누락된 Pod 및 컨테이너 메트릭

  • 영향을 받는 릴리스: CU9로 업그레이드 시 기존 및 새 클러스터

  • 문제 및 고객 효과: CU9의 구성 요소 모니터링에 사용되는 Telegraf 버전을 업그레이드한 결과 클러스터를 CU9 릴리스로 업그레이드할 때 Pod 및 컨테이너 메트릭이 수집되지 않는 것을 알 수 있습니다. 소프트웨어 업그레이드의 결과로 Telegraf에 사용되는 클러스터 역할 정의에 추가 리소스가 필요하기 때문입니다. 클러스터를 배포하거나 업그레이드를 수행하는 사용자에게 충분한 권한이 없는 경우 배포/업그레이드는 경고로 진행되며 성공하지만 Pod 및 노드 메트릭은 수집되지 않습니다.

  • 해결 방법: 관리자에게 역할 및 해당 서비스 계정(배포/업그레이드 전후)을 만들거나 업데이트하도록 요청할 수 있으며 빅 데이터 클러스터에서 이를 사용합니다. 이 문서에서 는 필요한 아티팩트 만들기 방법을 설명합니다.

azdata bdc copy-logs를 실행해도 로그가 복사되지 않습니다.

  • 영향을 받는 릴리스: Azure Data CLI(azdata) 버전 20.0.0

  • 문제 및 고객 효과: 복사 로그 명령의 구현은 클라이언트 도구 버전 1.15 이상이 명령이 실행된 클라이언트 컴퓨터에 설치되어 있다고 가정 kubectl 합니다. 버전 1.14를 사용하는 kubectl 경우 azdata bdc debug copy-logs 명령은 실패 없이 완료되지만 로그는 복사되지 않습니다. 플래그를 사용하여 --debug 실행하면 출력에서 이 오류를 볼 수 있습니다. 원본 '.'이(가) 잘못되었습니다.

  • 해결 방법: 동일한 클라이언트 컴퓨터에 버전 1.15 이상 도구를 설치 kubectl 하고 명령을 다시 실행 azdata bdc copy-logs 합니다. 설치하는 방법은 kubectl의 지침을 참조하세요.

SQL Server 마스터 인스턴스에 대해 MSDTC 기능을 사용할 수 없습니다.

  • 영향을 받는 릴리스: 릴리스와 관계없이 모든 빅 데이터 클러스터 배포 구성.

  • 문제 및 고객 효과: 빅 데이터 클러스터 내에 SQL Server 마스터 인스턴스로 배포된 SQL Server에서는 MSDTC 기능을 사용하도록 설정할 수 없습니다. 이 문제에 대한 해결 방법은 없습니다.

HA SQL Server 데이터베이스 암호화 키 암호화기 회전

  • 영향을 받는 릴리스: CU8까지의 모든 버전. CU9에서 해결되었습니다.

  • 문제 및 고객 효과: HA를 사용하여 SQL Server를 배포하면 암호화된 데이터베이스에 대한 인증서 회전이 실패합니다. 마스터 풀에서 다음 명령을 실행하면 오류 메시지가 나타납니다.

    ALTER DATABASE ENCRYPTION KEY
ENCRYPTION BY SERVER
CERTIFICATE <NewCertificateName>;

    효과가 없으며 명령이 실패하고 대상 데이터베이스 암호화가 이전 인증서를 사용하여 유지됩니다.

CU8에서 HDFS 암호화 영역 지원 사용

  • 영향을 받는 릴리스: 이 시나리오는 CU6 또는 이전 버전에서 CU8 릴리스로 특별히 업그레이드할 때 표시됩니다. 이는 CU8+의 새 배포 또는 CU9로 직접 업그레이드할 때 발생하지 않습니다. CU10 이상 릴리스는 영향을 받지 않습니다.

  • 문제 및 고객 효과: HDFS 암호화 영역 지원은 이 시나리오에서 기본적으로 사용하도록 설정되지 않으며 구성 가이드에 제공된 단계를 사용하여 구성해야 합니다.

누적 업데이트를 적용하기 전에 Livy 작업을 비우세요.

  • 영향을 받는 릴리스: CU6까지의 모든 버전. CU8에서 해결되었습니다.

  • 문제 및 고객 효과: 업그레이드 중 sparkhead에서 404 오류를 반환합니다.

  • 해결 방법: 빅 데이터 클러스터를 업그레이드하기 전에 활성 Livy 세션 또는 일괄 처리 작업이 없는지 확인합니다. 이를 방지하려면 지원되는 릴리스에서 업그레이드 의 지침을 따르세요.

    업그레이드 프로세스 중에 Livy가 404 오류를 반환하는 경우 두 노드에서 sparkhead Livy 서버를 다시 시작합니다. 다음은 그 예입니다.

    kubectl -n <clustername> exec -it sparkhead-0/sparkhead-1 -c hadoop-livy-sparkhistory -- exec supervisorctl restart livy

빅 데이터 클러스터 생성 서비스 계정에 대한 암호 만료

  • 영향을 받는 릴리스: 릴리스와 관계없이 Active Directory 통합을 사용하는 모든 빅 데이터 클러스터 배포

  • 문제 및 고객 효과: 빅 데이터 클러스터를 배포하는 동안 워크플로는 서비스 계정 집합을 생성합니다. 도메인 컨트롤러에 설정된 암호 만료 정책에 따라 이러한 계정의 암호가 만료됩니다(기본값은 42일). 현재는 빅 데이터 클러스터의 모든 계정에 대한 자격 증명을 회전하는 메커니즘이 없으므로 만료 기간이 충족되면 클러스터를 작동하지 않습니다.

  • 해결 방법: 빅 데이터 클러스터의 서비스 계정에 대한 만료 정책을 도메인 컨트롤러에서 "암호가 만료되지 않음"으로 업데이트합니다. 이러한 계정의 전체 목록은 자동 생성된 Active Directory 개체를 참조하세요. 이 작업은 만료 시간 전후에 수행할 수 있습니다. 후자의 경우 Active Directory는 만료된 암호를 다시 활성화합니다.

게이트웨이 엔드포인트를 통해 서비스에 액세스하기 위한 자격 증명

  • 영향을 받는 릴리스: CU5부터 배포된 새 클러스터입니다.

  • 문제 및 고객 효과: SQL Server Big Data Clusters CU5를 사용하여 배포된 새 빅 데이터 클러스터의 경우 게이트웨이 사용자 이름이 지정되지 않았습니다. root. 게이트웨이 엔드포인트에 연결하는 데 사용되는 애플리케이션이 잘못된 자격 증명을 사용하는 경우 인증 오류가 표시됩니다. 이 변경은 루트가 아닌 사용자로 빅 데이터 클러스터 내에서 애플리케이션을 실행한 결과입니다(SQL Server 빅 데이터 클러스터 CU5 릴리스로 시작하는 새로운 기본 동작으로, CU5를 사용하여 새 빅 데이터 클러스터를 배포할 때 게이트웨이 엔드포인트의 사용자 이름은 환경 변수를 통해 AZDATA_USERNAME 전달되는 값을 기반으로 합니다. 컨트롤러 및 SQL Server 엔드포인트에 사용되는 것과 동일한 사용자 이름입니다. 이는 새 배포에만 영향을 줍니다. 이전 릴리스와 함께 배포된 기존 빅 데이터 클러스터는 계속 사용합니다 root. 클러스터가 Active Directory 인증을 사용하도록 배포될 때 자격 증명에는 영향을 주지 않습니다.

  • 해결 방법: Azure Data Studio는 개체 탐색기에서 HDFS 검색 환경을 사용하도록 게이트웨이에 대한 연결에 대해 자격 증명 변경을 투명하게 처리합니다. 이 사용 사례를 해결하는 데 필요한 변경 내용을 포함하는 최신 Azure Data Studio 릴리스 를 설치해야 합니다. 게이트웨이를 통해 서비스에 액세스하기 위한 자격 증명을 제공해야 하는 다른 시나리오(예: Azure Data CLI(azdata로그인), Spark용 웹 대시보드 액세스)의 경우 올바른 자격 증명이 사용되는지 확인해야 합니다. CU5 이전에 배포된 기존 클러스터를 대상으로 하는 경우 클러스터를 CU5로 업그레이드한 후에도 사용자 이름을 사용하여 root 게이트웨이에 계속 연결합니다. CU5 빌드를 사용하여 새 클러스터를 배포하는 경우 환경 변수에 해당하는 사용자 이름을 제공하여 로그인합니다 AZDATA_USERNAME .

Pod 및 노드 메트릭이 수집되지 않고 있음

  • 영향을 받는 릴리스: CU5 이미지를 사용하는 신규 및 기존 클러스터

  • 문제 및 고객 효과: 메트릭 Pod 및 호스트 노드 메트릭을 수집하는 데 사용한 API telegraf 와 관련된 보안 수정의 결과로 고객은 메트릭이 수집되지 않는 것을 알 수 있습니다. 이는 CU5로 업그레이드한 후 SQL Server 2019 빅 데이터 클러스터의 신규 및 기존 배포 모두에서 가능합니다. 이 수정의 결과로 Telegraf는 이제 클러스터 전체 역할 권한이 있는 서비스 계정이 필요합니다. 배포는 필요한 서비스 계정 및 클러스터 역할을 만들려고 시도하지만 클러스터를 배포하거나 업그레이드를 수행하는 사용자에게 충분한 권한이 없는 경우 배포/업그레이드가 경고를 진행하여 성공하지만 Pod 및 노드 메트릭은 수집되지 않습니다.

  • 해결 방법: 관리자에게 역할 및 서비스 계정(배포/업그레이드 전후)을 만들도록 요청할 수 있으며 빅 데이터 클러스터에서 이를 사용합니다. 이 문서에서 는 필요한 아티팩트 만들기 방법을 설명합니다.

azdata bdc copy-logs 명령이 실패함

  • 영향을 받는 릴리스: Azure Data CLI(azdata) 버전 20.0.0

  • 문제 및 고객 효과: 복사 로그 명령의 구현은 클라이언트 도구가 명령이 실행된 클라이언트 컴퓨터에 설치되어 있다고 가정 kubectl 합니다. 도구 oc만 설치된 클라이언트에서 OpenShift에 설치된 빅 데이터 클러스터에 대해 명령을 실행할 경우, 오류가 발생하게 됩니다: An error occurred while collecting the logs: [WinError 2] The system cannot find the file specified.

  • 해결 방법: 동일한 클라이언트 컴퓨터에 도구를 설치 kubectl 하고 명령을 다시 실행합니다 azdata bdc copy-logs . 설치하는 방법은 kubectl의 지침을 참조하세요.

프라이빗 리포지토리를 사용하여 배포

  • 영향을 받는 릴리스: GDR1, CU1, CU2. CU3에 대한 문제가 해결되었습니다.

  • 문제 및 고객 효과: 프라이빗 리포지토리에서 업그레이드에는 특정 요구 사항이 있습니다.

  • 해결 방법: 프라이빗 리포지토리를 사용하여 빅 데이터 클러스터를 배포하거나 업그레이드하기 위해 이미지를 미리 끌어오는 경우 현재 빌드 이미지와 대상 빌드 이미지가 프라이빗 리포지토리에 있는지 확인합니다. 이렇게 하면 필요한 경우 성공적인 롤백이 가능합니다. 또한 원래 배포 이후 프라이빗 리포지토리의 자격 증명을 변경한 경우 업그레이드하기 전에 Kubernetes에서 해당 비밀을 업데이트합니다. Azure Data CLI(azdata)는 자격 증명을 통한 AZDATA_PASSWORD 업데이트 및 AZDATA_USERNAME 환경 변수를 지원하지 않습니다. 를 사용하여 kubectl edit secrets비밀을 업데이트합니다.

현재 및 대상 빌드에 다른 리포지토리를 사용하여 업그레이드하는 것은 지원되지 않습니다.

시간 제한으로 인해 업그레이드가 실패할 수 있습니다.

  • 영향을 받는 릴리스: GDR1, CU1, CU2. CU 3에 대해 해결되었습니다.

  • 문제 및 고객 효과: 시간 제한으로 인해 업그레이드가 실패할 수 있습니다.

    다음 코드는 오류의 모양을 보여줍니다.

    > azdata.EXE bdc upgrade --name <mssql-cluster>
Upgrading cluster to version 15.0.4003

NOTE: Cluster upgrade can take a significant amount of time depending on
configuration, network speed, and the number of nodes in the cluster.

Upgrading Control Plane.
Control plane upgrade failed. Failed to upgrade controller.

    이 오류는 AKS(Azure Kubernetes Service)에서 SQL Server 2019 빅 데이터 클러스터를 업그레이드할 때 발생할 가능성이 높습니다.

  • 해결 방법: 업그레이드 시간 제한을 늘입니다.

    업그레이드 시간 제한을 늘리려면 업그레이드 구성 맵을 편집합니다. 업그레이드 구성 맵을 편집하려면 다음을 수행합니다.

    1. 다음 명령을 실행합니다.

      kubectl edit configmap controller-upgrade-configmap

    2. 다음 필드를 편집합니다.

      controllerUpgradeTimeoutInMinutes 컨트롤러 또는 컨트롤러 db가 업그레이드를 완료할 때까지 대기할 시간(분)을 지정합니다. 기본값은 5입니다. 20개 이상으로 업데이트합니다.

      totalUpgradeTimeoutInMinutes: 컨트롤러와 컨트롤러 db가 모두 업그레이드(controller + controllerdb 업그레이드)를 완료하는 데 걸리는 시간을 결합하도록 지정합니다. 기본값은 10입니다. 40 이상으로 업데이트합니다.

      componentUpgradeTimeoutInMinutes: 업그레이드의 각 후속 단계를 완료해야 하는 시간을 지정합니다. 기본값은 30입니다. 45로 업데이트합니다.

    3. 저장한 후 종료합니다.

    다음 Python 스크립트는 시간 제한을 설정하는 또 다른 방법입니다.

    from kubernetes import client, config
import json

def set_upgrade_timeouts(namespace, controller_timeout=20, controller_total_timeout=40, component_timeout=45):
     """ Set the timeouts for upgrades

     The timeout settings are as follows

     controllerUpgradeTimeoutInMinutes: sets the max amount of time for the controller
         or controllerdb to finish upgrading

     totalUpgradeTimeoutInMinutes: sets the max amount of time to wait for both the
         controller and controllerdb to complete their upgrade

     componentUpgradeTimeoutInMinutes: sets the max amount of time allowed for
         subsequent phases of the upgrade to complete
     """
     config.load_kube_config()

     upgrade_config_map = client.CoreV1Api().read_namespaced_config_map("controller-upgrade-configmap", namespace)

     upgrade_config = json.loads(upgrade_config_map.data["controller-upgrade"])

     upgrade_config["controllerUpgradeTimeoutInMinutes"] = controller_timeout

     upgrade_config["totalUpgradeTimeoutInMinutes"] = controller_total_timeout

     upgrade_config["componentUpgradeTimeoutInMinutes"] = component_timeout

     upgrade_config_map.data["controller-upgrade"] = json.dumps(upgrade_config)

     client.CoreV1Api().patch_namespaced_config_map("controller-upgrade-configmap", namespace, upgrade_config_map)

ADS(Azure Data Studio) 또는 curl에서 Livy 작업 제출 실패(500 오류)

  • 문제 및 고객 효과: HA 구성에서 Spark 공유 리소스는 sparkhead 여러 복제본으로 구성됩니다. 이 경우 ADS(Azure Data Studio) 또는 curlLivy 작업 제출에 오류가 발생할 수 있습니다. 확인을 위해 curl를 사용하여 어떤 sparkhead 팟에도 연결할 시 연결이 거부됩니다. 예를 들어 curl https://sparkhead-0:8998/ 또는 curl https://sparkhead-1:8998은 500 오류를 반환합니다.

    이 문제는 다음 시나리오에서 발생합니다.

    • Zookeeper Pod 또는 각 Zookeeper 인스턴스에 대한 프로세스는 몇 번 다시 시작됩니다.
    • pod와 Zookeeper pod 간에 sparkhead 네트워킹 연결이 신뢰할 수 없는 경우

  • 해결 방법: 두 Livy 서버를 다시 시작합니다.

    kubectl -n <clustername> exec sparkhead-0 -c hadoop-livy-sparkhistory supervisorctl restart livy

    kubectl -n <clustername> exec sparkhead-1 -c hadoop-livy-sparkhistory supervisorctl restart livy

가용성 그룹의 마스터 인스턴스일 때 메모리 최적화 테이블 만들기

  • 문제 및 고객 효과: 가용성 그룹 데이터베이스(수신기)에 연결하기 위해 노출된 기본 엔드포인트를 사용하여 메모리 최적화 테이블을 만들 수 없습니다.

  • 해결 방법: SQL Server 마스터 인스턴스가 가용성 그룹 구성인 경우 메모리 최적화 테이블을 만들려면 SQL Server 인스턴스에 연결하고, 엔드포인트를 노출하고, SQL Server 데이터베이스에 연결하고, 새 연결을 사용하여 만든 세션에서 메모리 최적화 테이블을 만듭니다.

외부 테이블에 설치하여 Active Directory 인증 모드를 사용하십시오.

  • 문제 및 고객 효과: SQL Server 마스터 인스턴스가 Active Directory 인증 모드에 있는 경우 외부 테이블 중 하나 이상이 스토리지 풀에 있고 다른 외부 테이블에 삽입되는 외부 테이블에서만 선택하는 쿼리는 다음을 반환합니다.

Msg 7320, Level 16, State 102, Line 1 Cannot execute the query "Remote Query" against OLE DB provider "SQLNCLI11" for linked server "SQLNCLI11". Only ___domain logins can be used to query Kerberized storage pool.

  • 해결 방법: 다음 방법 중 하나로 쿼리를 수정합니다. 스토리지 풀 테이블을 로컬 테이블에 조인하거나 먼저 로컬 테이블에 삽입한 다음 로컬 테이블에서 읽어 데이터 풀에 삽입합니다.

SQL Server 마스터 인스턴스에서 가용성 그룹의 일부인 데이터베이스에는 투명한 데이터 암호화 기능을 사용할 수 없습니다.

  • 문제 및 고객 효과: HA 구성에서는 암호화에 사용되는 마스터 키가 각 복제본에서 다르므로 장애 조치(failover) 후에 암호화를 사용하는 데이터베이스를 사용할 수 없습니다.

  • 해결 방법: 이 문제에 대한 해결 방법은 없습니다. 수정이 있을 때까지 이 구성에서 암호화를 사용하도록 설정하지 않는 것이 좋습니다.

관련 콘텐츠

SQL Server 2019 빅 데이터 클러스터에 대한 자세한 내용은 SQL Server 빅 데이터 클러스터 소개를 참조하세요.