SSDT Добавление 2 столбцов в конец таблицы приводит к перестроению таблицы - PullRequest
0 голосов
/ 13 марта 2020

Мы используем Azure DevOps для автоматического развертывания изменений в нашей производственной базе данных, которая является базой данных Azure SQL. Это нормально работает для большинства выпусков, так как большую часть времени мы делаем ограниченные изменения. Иногда мы сталкиваемся с проблемами - это перестройка таблиц, которая занимает много времени. Конечный результат хорош, только длительное время работы приводит к простою сайта, который мы можем себе позволить.

Мы используем проект базы данных в Visual Studio для управления этой и некоторыми другими базами данных. Это включает в себя файл xml, который мы включаем в публикацию с SSDT, который содержит параметры процесса развертывания. (Ie игнорировать порядок столбцов и лайки).

Следующее изменение приводит к перестройке таблицы:

CREATE TABLE [dbo].[AccountCompany] (
    [CompanyId]                   INT             IDENTITY (1, 1) NOT NULL,
    [AccountTypeCode]             NVARCHAR (2)    DEFAULT ('00') NOT NULL,
    <Various columns, some with defaults>
    [PONumberMandatoryUpstream] BIT NULL, 
    [PONumberMandatoryDownstream] BIT NULL, 
    CONSTRAINT [PK_AccountCompany] PRIMARY KEY CLUSTERED ([CompanyId] ASC),
    CONSTRAINT [FK_AccountCompany_AccountBranchType] FOREIGN KEY ([BranchTypeCode]) REFERENCES [dbo].[AccountBranchType] ([BranchTypeCode]),
    CONSTRAINT [FK_AccountCompany_AccountCustomerBusinessSegment] FOREIGN KEY ([BusinessSegment]) REFERENCES [dbo].[AccountCustomerBusinessSegment] ([BusinessSegmentCode]),
    CONSTRAINT [FK_AccountCompany_AccountDmsEndpoint] FOREIGN KEY ([DmsEndpointId]) REFERENCES [dbo].[AccountDmsEndpoint] ([DmsEndpointId]),
    CONSTRAINT [FK_AccountCompany_AccountDmsType] FOREIGN KEY ([DmsTypeCode]) REFERENCES [dbo].[AccountDmsType] ([DmsTypeCode]),    
    CONSTRAINT [FK_AccountCompany_AccountType] FOREIGN KEY ([AccountTypeCode]) REFERENCES [dbo].[AccountType] ([AccountTypeCode]),
    CONSTRAINT [FK_AccountCompany_Currency_Purchase] FOREIGN KEY ([PurchaseCurrencyCode]) REFERENCES [dbo].[Currency] ([CurrencyCode]),
    CONSTRAINT [FK_AccountCompany_Currency_Sales] FOREIGN KEY ([SalesCurrencyCode]) REFERENCES [dbo].[Currency] ([CurrencyCode]),
    CONSTRAINT [FK_AccountCompany_MasterLanguage] FOREIGN KEY ([CultureCode]) REFERENCES [dbo].[MasterLanguage] ([CultureCode])
);

GO
CREATE NONCLUSTERED INDEX [IX_AccountCompany_LocationCode_Active]
    ON [dbo].[AccountCompany]([LocationCode] ASC, [Active] ASC)
    INCLUDE([AccountTypeCode], [BranchTypeCode], [DeliveryTimeDealer], [DeliveryTimeDealerGroup], [DeliveryTimeDealerPreferred], [DeliveryTimeFacingPdc], [DeliveryTimeTotalPaccar], [DmsDealerId], [DmsEndpointId], [DmsTypeCode], [FleetCustomerCode], [Guid], [CultureCode], [LogoAssetSequential], [LogoUrl], [Name], [PurchaseCurrencyCode], [RowVersion], [RushOrder], [SalesCurrencyCode]);

GO
CREATE NONCLUSTERED INDEX [IX_AccountCompany_Guid]
    ON [dbo].[AccountCompany]([Guid] ASC);

GO
CREATE NONCLUSTERED INDEX [IX_AccountCompany_DmsTypeCode]
    ON [dbo].[AccountCompany]([DmsTypeCode] ASC);

GO
CREATE NONCLUSTERED INDEX [IX_AccountCompany_AccountTypeCode]
    ON [dbo].[AccountCompany]([AccountTypeCode] ASC);

Последние 2 столбца, PONumberMandatoryUpstream и PONumberMandatoryDownstream, вероятно, ведут к таблице перестроить. Оба столбца являются новыми и добавляются в конец таблицы без внешних ключей / ограничений / индексов. Если я вручную сравниваю со схемой, я вижу только инструкцию ALTER TABLE ADD COLUMN, которая не перестраивает таблицу. По какой-то причине автоматическое развертывание c решает, что таблицу нужно перестроить.

Кто-нибудь с идеей, почему SSDT считает, что таблицу необходимо перестроить?

Мое первое предположение, что может быть чем-то заняться с настройками в файле publi sh xml. Я попытался сравнить эти настройки с теми, что в схеме сравнения, но, похоже, нет никаких различий. При необходимости я могу включить журнал развертывания и файл настроек sh.

1 Ответ

0 голосов
/ 18 марта 2020

Я выяснил, в чем проблема после 2 дней отладки. Оказывается, один из наших администраторов включил обнаружение и классификацию баз данных https://docs.microsoft.com/en-us/azure/sql-database/sql-database-data-discovery-and-classification?tabs=azure-t-sql. Это добавляет несколько дополнительных SQL операторов, касающихся определенных c столбцов и классификации в определении таблицы, которых не было в проекте базы данных. При каждом развертывании эти таблицы перестраивались, что в нашем случае было 44 таблицами.

Эта структура классификации является довольно новой, и развертывание ssdt еще не может обработать это в конвейере. Добавление этих операторов в проект базы данных не сработало, так как это приводило к ошибкам в конвейере, подобно неизвестному утверждению. Нашим единственным вариантом было отключить классификацию, пока это не поддерживается ssdt.

...