웨어하우스 개발을 위한 Git 통합 문제 해결

적용 대상: ✅ Microsoft Fabric의 웨어하우스

이 글에는 Fabric의 내장 Git 통합을 이용한 Fabric Data Warehouse 개발 및 배포에 관한 문제 해결 주제가 포함되어 있습니다.

Important

이 기능은 프리뷰 상태입니다.

창고 자체의 물건에 대한 3부분 이름 사용에 대한 참조

객체는 세 부분 이름인 를 사용하여 같은 창고 내의 다른 객체를 참조할 수 있습니다. [warehouse_name].[schema_name].[object_name]

세 부분 명명은 다른 창고를 참조하기 위한 것입니다. 데이터베이스 부분이 현재 웨어하우스 이름을 지정하면, 빌드는 참조를 외부 참조로 처리하고, 객체는 모델 내에서 두 번 정의됩니다.

데이터베이스 부분을 웨어하우스 자체 객체에 대한 참조에서 제거하세요:

-- Fails: the warehouse is named MyWarehouse and references itself by name
CREATE VIEW [Sales].[CustomerSummary] AS
SELECT c.[CustomerId], c.[OrderDate]
FROM [MyWarehouse].[Sales].[Customers] AS c;

-- Works
CREATE VIEW [Sales].[CustomerSummary] AS
SELECT c.[CustomerId], c.[OrderDate]
FROM [Sales].[Customers] AS c;

창고 자체 객체에 대한 참조만 변경하면 됩니다. 다른 웨어하우스(예: [Other_Warehouse].[Sales].[Orders])에 대한 진정한 데이터베이스 교차 참조가 지원되며 as-is있어야 합니다.

Important

크로스 웨어하우스 또는 크로스 SQL 분석 엔드포인트 참조에만 3단계 명명(database.schema.object)을 사용하며, 같은 웨어하우스 내 객체를 참조하는 데는 사용하지 마세요. 같은 웨어하우스 내 객체를 3부분 명명으로 자가 참조하는 것은 표준 모델링 방식이 아니며, 의도치 않은 외부 참조를 만들 수 있습니다.

가능하다면 같은 창고 내에서도 자기 참조 방식이라도 3부분 명명 대신 2부분 명명(schema.object)을 사용하여 객체를 모델링하세요. 이 관례는 클라이언트 도구 간 일관성을 높이고 3부분 참조가 초래하는 모호함을 방지합니다.

Git 저장소에 있는 오래된 .sqlproj

Git 저장소에는 이전 .sqlproj SDK 버전을 참조하는 파일이 포함될 수 있습니다Microsoft.Build.Sql. 이전 SDK는 열과 같은 최신 Fabric Data Warehouse 문법 IDENTITY 을 인식하지 못합니다.CLUSTER BY

이 문제는 웨어하우스가 현재 정의 형식으로 전환되기 전에 내용이 커밋된 저장소에 영향을 미칩니다. .sqlproj 파일이 오래되는 가장 흔한 상황은 다음과 같습니다:

새로운 작업 공간을 기존 저장소에 연결하는 것. 창고는 그곳에 맡겨진 모든 것들로 만들어집니다.
새로운 작업 공간으로 확장하는 것.
Git에서 삭제된 창고를 복원하는 방법.
창고가 현재 정의 형식으로 옮긴 직후 Git에서 동기화가 이루어지고, 반대 방향으로의 동기화가 완료되기 전입니다.

현재 정의 형식으로 옮겨지지 않은 창고는 영향을 받지 않는데, 이전 프로젝트 파일이 빌드에 사용되지 않기 때문입니다.

.sqlproj SDK 버전 확인 방법

저장소에서 웨어하우스 .sqlproj 파일을 열고 XML 내 SDK 버전을 확인하세요:

<Sdk Name="Microsoft.Build.Sql" Version="2.2.0" />

현재 Microsoft보다 뒤처진 버전입니다. Build.Sql 패키지 버전은 오래된 프로젝트 파일을 나타냅니다. 예를 들어, 당신의 버전이 로 시작 0.1.한다면, 자세한 내용은 Microsoft를 참조하세요. Build.SQL과 템플릿 릴리스.

.sqlproj SDK 버전 옵션 업데이트: 먼저 Git에 창고를 동기화하세요

창고가 이미 작업 공간에 존재하고 상태가 좋다면, 작업 공간에서 Git으로 커밋한 후 반대 방향으로 동기화하세요. 이 작업을 통해 프로젝트 파일이 현재 SDK 버전으로 재생성되고, 이후 Git과의 동기화가 정상적으로 작동합니다.

이 옵션은 제공되는 경우 선호되는데, 이는 SDK 속성뿐만 아니라 전체 정의를 최신 상태로 유지하기 때문입니다.

이 옵션이 작동하려면 창고가 이미 현재 정의 형식이어야 합니다. 만약 그렇지 않다면, 먼저 Fabric Git 패널에서 업그레이드한 후 Git으로 전환하세요. 이전 정의 포맷인 웨어하우스에서 커밋하면 이전 포맷을 저장소에 다시 쓰고 SDK 버전을 새로고침하지 않아 다음 동기화도 같은 방식으로 실패합니다. 업그레이드가 안 된다면 옵션 B 를 사용하세요.

.sqlproj SDK 버전 옵션 B: git에서 .sqlproj 파일을 직접 업데이트하세요

목표 작업 공간에 창고가 아직 존재하지 않을 때, 예를 들어 새 작업 공간을 기존 저장소에 연결하거나, 분기하거나, 삭제된 창고를 복원할 때 이 옵션을 사용하세요. 그런 경우에는 동기화할 창고가 없어서 수정 옵션 A가 불가능합니다.

저장소 파일을 최신 Microsoft 버전으로 편집 .sqlproj 하세요. 빌드.SQL 패키지 버전 확인하고 변경 사항을 커밋하세요. 다음은 그 예입니다.

<!-- Before -->
<Sdk Name="Microsoft.Build.Sql" Version="0.1.19-preview" />

<!-- After -->
<Sdk Name="Microsoft.Build.Sql" Version="2.2.0" />

내보내기나 diff 파일을 실행해도 프로젝트 파일이 업데이트되지 않습니다. 이 파일은 작업 공간에서 Git으로 커밋이 완료되거나 수동으로 편집할 때만 다시 작성됩니다.

다른 웨어하우스의 두 개 이상의 테이블을 참조하는 객체 내 자격이 없는 열(unqualified column)

T-SQL 쿼리에서 열을 참조할 때는 항상 테이블 별칭을 제공하고 사용하세요.

T-SQL 쿼리가 다른 웨어하우스의 두 개 이상의 테이블을 참조하면, 빌드는 테이블 별칭 없이 특정 테이블에 대해 작성된 열을 검증할 수 없습니다. 테이블들이 열명을 공유할 필요는 없어도 이 모호함이 존재합니다. 이 모호함은 검증 빌드에 존재합니다.
이 모호성은 동일한 문구 내 다른 웨어하우스의 두 개 이상의 테이블을 참조하는 객체 내 T-SQL 쿼리에 영향을 미칩니다.
이 모호성은 다른 웨어하우스의 한 테이블만 참조하는 객체 내 T-SQL 쿼리에는 영향을 미치지 않습니다. 단일 소스라면 그 사이에 모호함을 가질 필요가 없기 때문입니다.
이 모호성은 한 개의 창고 내에 완전히 머무르는 T-SQL 쿼리에는 영향을 미치지 않습니다.

다음 예 fieldinfo 시에서는 만 가 있으므로 finameSQL은 유효하고 웨어하우스에 대해 올바르게 실행되지만, 검증 빌드에는 모호성이 존재합니다.

-- Fails: two tables from another warehouse, and 'finame' isn't alias-qualified
CREATE PROCEDURE [dbo].[LoadFieldInfo] AS
SELECT finame
FROM   [OtherWarehouse].[halo].[fieldinfo] AS f
INNER JOIN   [OtherWarehouse].[halo].[lookup]    AS l ON f.[id] = l.[id];

영향을 받는 객체의 모든 열 참조에 테이블 별칭을 추가하세요:

-- Works: every column carries its table alias
CREATE PROCEDURE [dbo].[LoadFieldInfo] AS
SELECT f.[finame]
FROM   [OtherWarehouse].[halo].[fieldinfo] AS f
INNER JOIN   [OtherWarehouse].[halo].[lookup]    AS l ON f.[id] = l.[id];

스키마 이름의 일관성 없는 대문자 표기

창고는 대소문자 구분 없는 콜레이션을 사용할 수 있어 sales 서, 와 Sales 는 같은 스키마이지만, 스크립트가 서로 다른 곳에서 두 가지 방식을 모두 쓸 수 있습니다. 대문자 구분 없는 데이터베이스는 항상 이를 받아들여왔기 때문에, 이러한 불일치는 보통 오랜 기간 지속되어 온 무해한 문제입니다.

스크립트가 다른 웨어하우스의 같은 스키마 내 두 개 이상의 서로 다른 객체를 참조하고, 각 참조에서 그 스키마를 다르게 철자하면, 빌드는 각 철자에 맞는 문장을 CREATE SCHEMA 생성합니다. 이 문제는 다른 창고를 참조하고 대소문자 구분 없는 콜레이션을 사용하는 창고에만 영향을 미칩니다.

기본적으로 Fabric의 창고는 대소문자 구분된 콜레이션을 사용합니다Latin1_General_100_BIN2_UTF8. 대소문자 구분 창고는 영향을 받지 않습니다. 그 창고들 안에서는, salesSales 의도하든 아니든 서로 다른 두 가지 스키마입니다.
대소문자 구분 없는 데이터베이스는 와 sales를 Sales 모두 포함할 수 없습니다. 중복은 SQL 텍스트의 철자 차이에서만 발생합니다.

창고 집계와 파일에 명시된 ModelCollation 항목을 .sqlproj 확인하세요. (대문자 구분 없음) 또는 CI (대소문자 구분) 같은 단어를 CS 찾아보세요.

<ModelCollation>1033, CI</ModelCollation>   <!-- case-insensitive: affected -->
<ModelCollation>1033, CS</ModelCollation>   <!-- case-sensitive: not affected -->

수정

창고 객체 정의에서 스키마 이름의 대문자 대문자 불일치를 찾으려면, 오류에 명시된 스키마의 대문자 값을 모든 스크립트에서 비교하세요. 같은 스키마에 대한 두 개의 교차 창고 참조가 있는지 찾아보세요. 단, 차이가 있는 경우만 있습니다.

참조된 웨어하우스의 실제 스키마 이름과 일치하는 일관된 대문자 표기를 모든 곳에서 사용하세요. 예를 들어, 온리 Sales 또는 오직 sales를 사용한다.

-- Fails: two objects in the same schema, referenced with different capitalization
CREATE VIEW [dbo].[v_one] AS SELECT * FROM [OtherWarehouse].[sales].[Orders];
GO
CREATE VIEW [dbo].[v_two] AS SELECT * FROM [OtherWarehouse].[Sales].[Customers];

-- Works: same capitalization in both references
CREATE VIEW [dbo].[v_one] AS SELECT * FROM [OtherWarehouse].[Sales].[Orders];
GO
CREATE VIEW [dbo].[v_two] AS SELECT * FROM [OtherWarehouse].[Sales].[Customers];

이 문제는 서로 다른 스키마 대문자 대문자를 가진 두 개의 다른 객체가 있을 때 발생합니다. 같은 객체에 대해 대문자 표기가 다른 두 번의 참조는 올바르게 접혀 실패하지 않습니다.

열 정렬 규칙

만약 어떤 열의 절이 COLLATE창고의 기본 콜레이션과 동일한 콜레이션을 명시적으로 지정한다면, Fabric의 스키마 추출(DacFx 기반)은 명시적 콜레이션을 아예 명시하지 않는 것과 동일하게 취급합니다. 이 경우 다음과 같습니다.

명시적 COLLATE 절은 Git 저장소에 추출된 항목 정의에 나타나지 않습니다.
이 열은 Git 변경, 업데이트, 배포 파이프라인 비교에서 차이로 나타나지 않습니다. 왜냐하면 웨어하우스의 기본 콜레이션과 실질적인 차이가 없기 때문입니다.

웨어하우스의 기본 정렬과 다른 열만 소스 컨트롤에서 명시 COLLATE 적 절을 유지하며, 해당 열의 집합에 대한 변경 사항만 차이로 표시됩니다.

예를 들어, 집계가 다음과 같은 Latin1_General_100_CI_AS_KS_WS_SC_UTF8창고를 생각해 보십시오:

CREATE TABLE dbo.MixedCollationExample
(
    CustomerId      INT             NOT NULL,
    FirstName       VARCHAR(100)    NOT NULL,                                               -- inherits warehouse collation
    LastNameBin     VARCHAR(100)    COLLATE Latin1_General_100_BIN2_UTF8 NOT NULL,          -- column override, differs from warehouse collation
    Email           VARCHAR(256)    COLLATE Latin1_General_100_CI_AS_KS_WS_SC_UTF8 NULL     -- explicit collation, matches warehouse collation
);

FirstName 명시적 콜레이션이 없으며, 웨어하우스의 기본 콜레이션을 상속받습니다.
LastNameBin 웨어하우스의 기본 콜레이션과 다른 명시적 콜레이션이 있어, 추출된 정의에 보존되고 변경될 경우 항상 비교 시 나타납니다.
Email 창고의 기본 콜레이션과 일치하는 명시적 콜레이션이 있습니다. 이 절이 COLLATE T-SQL에 존재하지만, Git-extracted 정의나 Git, 배포 파이프라인 비교에는 나타나지 않습니다. 기본값과 동등하기 때문입니다.

중복 후보 객체가 있는 모호한 열 오류

Git에서 커밋하거나 업데이트할 때, 후보 목록에 구분자가 포함된 :: 모호한 열 오류가 발생하면 실패할 수 있습니다. 예를 들어:

SQL71501: View: [dbo].[SchoolSummary] contains an unresolved reference to an object.
Either the object does not exist or the reference is ambiguous because it could refer
to any of the following objects: [dbo].[SchoolSummary].[NCESID] or
[dbo].[SchoolSummary].[ss]::[NCESID].

:: 분리자는 이 오류와 다른 웨어하우스의 두 개 이상의 테이블을 참조하는 객체의 무제한 열에서 발생하는 진정한 모호성과 구별합니다. 테이블 별칭을 추가해도 해결되지 않습니다. 별칭이 후보 목록에 나타나는데도 오류가 계속 발생합니다.

먼저, 이 두 가지 더 흔한 원인을 배제하세요:
- 진짜로 실종되었거나 잘못 이름 붙여진 물건. 같은 커밋이나 업데이트가 특정 누락된 객체(예: SQL71501: View: [dbo].[v_report] has an unresolved reference to object [dbo].[MissingTable])에 대한 해결되지 않은 참조도 보고한다면, 먼저 그 참조를 수정하세요. 후보자들도 :: 보통 그와 함께 통과합니다.
- 진짜 모호한 칼럼이었다. 만약 해당 이름의 열을 노출하는 두 소스의 조인 위에 무제한 열이 선택된다면, 예를 들어 a.[NCESID]해당 열에 테이블 별칭으로 자격을 부여하세요. SQL Server도 이 쿼리를 거부할 테니, Git 통합에만 국한된 문제는 아닙니다.
참조된 모든 객체가 존재하고 어떤 열도 진정으로 모호하다면, 후보들은 :: Git에서 커밋과 업데이트 중에 실행되는 검증에서 알려진 문제이며, 제품 팀이 추적합니다. 다음 우회 방법을 순서대로 시도해 보세요:
1. CTE와 파생 테이블 내부를 명시적인 컬럼 리스트로 대체 SELECT * 하세요.
2. 뷰를 분할하여 각 모호한 소스가 자체 뷰로 정의되도록 하고, 기본 쿼리를 반복하지 않고 그 뷰를 참조하세요.
3. 같은 문장에서 다른 동적으로 형성된 소스와 결합하는 OPENROWSET(BULK ...) 것은 피하세요.

이 중 어느 것도 오류가 해결되지 않으면, 오류에 명시된 객체의 정의를 수집하고 지원 요청을 엽니다. 배포 파이프라인에 대한 구체적인 제한 사항은 제한 사항을 참조하세요.

피드백

이 페이지가 도움이 되었나요?

Last updated on 2026-07-31