Що нового в першій CTP редакції SQL Server 2019

24 вересня була представлена перша редакція CTP випуску SQL Server 2019, і, дозвольте сказати, що він переповнений всілякими поліпшеннями і новими можливостями (багато з яких можна знайти в формі попереднього перегляду в базі даних SQL Azure). У мене була виняткова можливість познайомитися з цим трохи раніше, дозволила мені розширити уявлення про зміни, нехай навіть поверхово. Ви можете також ознайомитися з останніми публікаціями від команди розробників SQL Server і оновленою документацією.

Не вдаючись в подробиці, я збираюся обговорити наступні нові функції ядра: продуктивність, пошук і усунення несправностей у роботі, безпека, доступність і розробка. На даний момент у мене є трохи більше подробиць, ніж у інших, і частина з них уже підготовлено до публікацій. Я повернуся до цього розділу, як і до багатьох інших статей і документації і опублікую їх. Поспішаю повідомити, що це не всеосяжний огляд, а тільки частина функціоналу, яку я встиг «помацати», аж до CTP 2.0. Ще є багато всього, про що варто розповісти.

Продуктивність

 

Табличні змінні: відкладене побудова плану

За табличними змінними закріпилася не дуже хороша репутація, по більшій частині в області оцінки вартості. За замовчуванням, SQL Server припускає, що таблична змінна може містити лише один рядок, що часом призводить до неадекватного вибору плану, коли в змінної буде міститися в рази більше рядків. Як вирішити зазвичай використовується OPTION (RECOMPILE), але це вимагає зміни коду і марнотратно, по відношенню до ресурсів — виконувати перестроювання кожен раз, у той час, як кількість рядків, найчастіше, одне і те ж. Для емуляції перестроювання був введений прапор трасування 2453, але він теж потребує запуск з прапором, і спрацьовує тільки коли відбувається суттєва зміна в рядках.

У рівні сумісності 150 виконується відкладене побудова, якщо присутні табличні змінні, і план запиту не буде побудований до тих пір, поки не буде одноразово заповнена таблична мінлива. Оцінка вартості буде проводитися за результатами першого використання табличної змінної, боз подальших перестроювань. Це компроміс між постійним перестроением, для отримання точної вартості, і повною відсутністю перестроювання з постійною вартістю 1. Якщо кількість рядків залишається відносно постійним, то це хороший показник (і ще більш хороший, якщо число перевищує 1), але може бути менш вигідним, якщо має місце великий розкид в кількості рядків.

Більш глибокий розбір я представив в недавній статті Табличні змінні: Відкладене побудова SQL Server, і Брент Озар теж говорив про це у статті Швидкі табличні змінні (І нові проблеми аналізу параметрів).

Зворотній зв’язок з виділюваної пам’яті в режимі строковому

SQL Server 2017 має зворотний зв’язок з виділюваної пам’яті в пакетному режимі, яка детально описана тут. По суті, для будь-якого виділення пам’яті, пов’язаного з планом запиту, що включає оператори пакетного режиму, SQL Server оцінить пам’ять, використану запитом, і порівнює її з запитаної пам’яттю. Якщо потрібної пам’яті занадто мало або занадто багато, що призведе до сливам в tempdb або порожній витраті пам’яті, то при наступному запуску виділяється пам’ять для відповідного плану запиту буде скорегована. Така поведінка або зменшить виділений обсяг і розширить паралелізм, або збільшить його, для поліпшення продуктивності.

Тепер ми отримуємо таку ж поведінку для запитів у строковому режимі, під рівнем сумісності 150. Якщо запит був змушений злити дані на диск, то для подальших запусків виділяється пам’ять буде збільшена. Якщо по факту виконання запиту потрібно було наполовину менше пам’яті, ніж було виділено, то для подальших запитів вона буде скоригована в нижню сторону. Бретн Озар більш докладно описує це у своїй статті Умовне виділення пам’яті.

Пакетний режим для порядкового зберігання

Починаючи з SQL Server 2012, запити до таблиць з колоночными індексами отримали виграш від підвищення продуктивності пакетного режиму. Поліпшення продуктивності відбуваються з-за оброблювача запитів, що виконує пакетну, а не построчную обробку. Рядки теж обробляються ядром сховища в пакетах, що дозволяє уникнути операторів обміну паралелізму. Пол Уайт (@SQL_Kiwi) нагадав мені, що, якщо використовувати порожню таблицю з колоночным зберіганням, щоб зробити можливими операції пакетного режиму, то оброблені рядки будуть зібрані в пакети невидимим оператором. Однак цей милицю може звести нанівець будь-які поліпшення, отримані від обробки в пакетному режимі. Деяка інформація про це є у відповіді на Stack Exchange.

При рівні сумісності 150, SQL Server 2019 автоматично вибере пакетний режим в певних випадках в якості золотої середини, навіть коли немає колоночных індексів. Можна подумати, що чому б просто не створити колоночный індекс і справа в капелюсі? Або продовжити використовувати згаданий вище милицю? Такий підхід був поширений і на традиційні об’єкти з построчным зберіганням, бо стовпчик індекси, за низкою причин, не завжди можливі, включаючи обмеження функціоналу (наприклад, тригери), витрати при високонавантажених операціях оновлення або видалення, а також відсутності підтримки сторонніх виробників. А від того милиці нічого хорошого очікувати не доводиться.
Я створив дуже просту таблицю з 10 мільйонами рядків і одним кластеризованным індексом на цілочисельному стовпці і запустив цей запит:

SELECT sa5, sa2, SUM(i1), SUM(i2), COUNT(*)
 FROM dbo.FactTable
 WHERE i1 > 100000
 GROUP BY sa5, sa2 
 ORDER BY sa5, sa2;

План виразно показує пошук по кластеризованному індексу та паралелізм, але ні слова про колоночном індексі (що і показує SentryOne Plan Explorer):

Але якщо копнути трохи глибше, то можна побачити, що практично всі оператори виконувалися в пакетному режимі, навіть сортування та скалярні обчислення:

Ви можете вимкнути цю функцію, залишившись на більш низькому рівні сумісності, шляхом зміни конфігурації бази даних або з допомогою підказки DISALLOW_BATCH_MODE у запиті:

SELECT ... OPTION (USE HINT ('DISALLOW_BATCH_MODE'));

У цьому випадку з’являється додатковий оператор обміну, всі оператори виконуються в порядковому режимі, а час виконання запиту збільшується майже в три рази.

До певного рівня можна побачити це в діаграмі, але в дереві подробиць плану можна також побачити вплив умови відбору, нездатного виключити рядки, поки не сталася сортування:

Вибір пакетного режиму – не завжди вдалий крок – евристика, включена в алгоритм прийняття рішення, враховує кількість рядків, типи передбачуваних операторів і очікувану вигоду пакетного режиму.

APPROX_COUNT_DISTINCT

Ця нова агрегатна функція призначена для сценаріїв роботи зі сховищами даних і є еквівалентом COUNT(DISTINCT()). Однак замість того, щоб виконувати дорогі сортування, для визначення фактичної кількості, нова функція покладається на статистику, щоб отримати відносно точні дані. Потрібно розуміти, що похибка лежить в межах 2% від точної кількості, і у 97% випадків, що є нормою для високорівневої аналітики, — це значення, що відображаються на індикаторах або використовуються для швидких оцінок.

Читайте також  Перевірка пунктуації онлайн - Як перевірити пунктуацію онлайн

У своїй системі я створив таблицю з цілочисельними стовпцями, що включають унікальні значення в діапазоні від 100 до 1 000 000, і рядковими стовпцями, з унікальними значеннями в діапазоні від 100 до 100 000. В ній не було ніяких індексів, крім звичайна первинного ключа в першому цілочисельному стовпці. Ось результати виконання COUNT(DISTINCT()) і APPROX_COUNT_DISTINCT() за цим стовпців, з яких можна побачити невеликі розбіжності (але завжди в межах 2%):

Виграш величезний, якщо є обмеження по пам’яті, що відноситься до більшості з нас. Якщо подивитися на плани запитів, в цьому конкретному випадку, то можна побачити величезну різницю у споживанні пам’яті оператором хеш-відповідності (hash match):

Зверніть увагу, що ви, як правило, будете помічати лише значні поліпшення продуктивності, якщо ви вже прив’язані до пам’яті. У моїй системі виконання тривало трохи довше за сильного завантаження ЦП новою функцією:

Можливо, різниця була більш істотною, якщо б у мене були великі таблиці, менше пам’яті, доступної SQL Server, більш високий паралелізм або будь-яка комбінація з вищепереліченого.

Підказки для використання рівня сумісності в межах запиту

У Вас є особливий запит, який працює краще під певним рівнем сумісності, відмінним від поточної бази даних? Тепер це можливо, за рахунок нових підказок запиту, що підтримують шість різних рівнів сумісності і п’ять різних моделей оцінки кількості елементів. Нижче наведені доступні рівні сумісності, приклад синтаксису і модель рівня сумісності, яка використовується в кожному випадку. Подивіться, як це впливає на оцінки, навіть для системних уявлень:

Коротше кажучи: немає більше необхідності запам’ятовувати прапори трасування, або задаватися питанням чи потрібно турбуватися про те, чи поширюється виправлення TF 4199 для оптимізатора запитів, або воно було скасовано якимось іншим пакетом оновлень. Зверніть увагу, що ці додаткові підказки нещодавно також були додані для SQL Server 2017 в накопичувальному оновленні №10 (подробиці дивіться у блозі Педро Лопеса). Ви можете побачити всі підказки доступні за допомогою наступної команди:

SELECT name FROM sys.dm_exec_valid_use_hints;

Але не забувайте, що підказки — це виняткова міра, вони часто підходить для того, щоб вийти зі скрутної ситуації, але не повинні плануватися для використання в довгостроковій перспективі, так як з наступними оновленнями їх поведінка може змінитися.

Пошук і усунення несправностей у роботі

 

Спрощене профілювання за замовчуванням

Для розуміння цього поліпшення потрібно згадати кілька моментів. У SQL Server 2014 з’явилося DMV подання sys.dm_exec_query_profiles, що дозволяє користувачеві, що виконує запит, збирати діагностичну інформацію про всіх операторах на всіх ділянках запиту. Зібрана інформація стає доступною після завершення виконання запиту і дозволяє визначити, які оператори насправді витратили основні ресурси і чому. Будь-який користувач, невыполнявший конкретний запит, міг отримати ці дані для будь-якого сеансу, в якому була включена інструкція STATISTICS XML або STATISTICS PROFILE, або для всіх сеансів, з допомогою розширеного події query_post_execution_showplan, хоча це подія, зокрема, може вплинути на загальну продуктивність.

У Management Studio 2016 доданий функціонал, що дозволяє відображати потоки даних, що проходять через план запиту в режимі реального часу на основі інформації, зібраної від DMV, що робить його ще більш потужним для пошуку і усунення проблем. Plan Explorer також пропонує можливість візуалізації даних, що проходять через запит, як у реальному режимі часу, так і в режимі відтворення.

Починаючи з SQL Server 2016 з пакетом оновлень 1 (SP1), можна також включити полегшену версію збору цих даних по всіх сеансів, з допомогою прапора трасування 7412 або розширеного властивості query_thread_profile, що дозволяє відразу отримати актуальну інформацію про будь-який час, без необхідності що-небудь у ньому включати в явному вигляді (зокрема речі, які негативно впливають на продуктивність). Більш докладно про це розказано в блозі Педро Лопеса.

У SQL Server 2019 ця функція включена за замовчуванням, тому не потрібно запускати ніяких сеансів з розширеними подіями або використовувати якісь прапори трасування та інструкцій STATISTICS ні в якому запиті. Досить просто подивитися на дані від DMV в будь-який час для всіх паралельних сеансів. Але є можливість і відключити даний режим, за допомогою LIGHTWEIGHT_QUERY_PROFILING, однак даний синтаксис не працює в CTP 2.0 і буде виправлений в наступних редакціях.

Статистика звичайна колоночного індексу тепер доступна в клонованих БД

У поточних версіях SQL Server, при клонуванні бази даних, використовується тільки оригінальна статистика об’єкта з кластерних колоночных індексів, без урахування оновлень, вироблених в таблиці після її створення. Якщо Ви використовуєте клон для налаштування запитів та іншого тестування продуктивності, що будуються на оцінках потужності, то ці приклади можуть не підійти. Парикшит Савьяни описав обмеження в цій публікації і надав тимчасове рішення – перед створенням клону потрібно зробити скрипт, який виконує DBCC SHOW_STATISTICS … WITH STATS_STREAM для кожного об’єкта. Це затратно і, безумовно, про це легко забути.

У SQL Server 2019 ця оновлена статистика буде доступна в клоні автоматично, так що можна тестувати різні сценарії запитів та отримувати об’єктивні плани, засновані на реальній статистиці, без ручного запуску STATS_STREAM для всіх таблиць.

Прогноз стиснення для зберігання колоночного

У поточних версіях у процедури sys.sp_estimate_data_compression_savings є наступна перевірка:

if (@data_compression not in ('NONE', 'РЯДОК', 'PAGE'))

Це означає, що вона дозволяє перевіряти стиснення рядка чи сторінки (або бачити результат видалення поточного стиснення). У SQL Server 2019 така перевірка тепер виглядає так:

if (@data_compression not in ('NONE', 'РЯДОК', 'PAGE', 'COLUMNSTORE', 'COLUMNSTORE_ARCHIVE'))

Це чудова новина, тому що дозволяє приблизно передбачати вплив додавання колоночного індексу в таблицю, в якій його немає, або перетворювати таблиці або розділи у ще більш стислий формат колоночного зберігання, без необхідності відновлювати цю таблицю в іншій системі. У мене була таліца з 10 млн рядків, для якої я виконав збережену процедуру з кожним з п’яти параметрів:

EXEC sys.sp_estimate_data_compression_savings
 @schema_name = 'dbo',
 @object_name = 'FactTable',
 @index_id = NULL,
 @partition_number = NULL, 
 @data_compression = 'NONE'; 
 -- repeat for ROW, PAGE, COLUMNSTORE, COLUMNSTORE_ARCHIVE

Результати:

Як і у випадку з іншими типами стиснення, точність повністю залежить від наявних рядків і репрезентативності інших даних. Тим не менш, це досить потужний спосіб отримати приблизні результати без особливої праці.

Читайте також  UHCI, або найперший USB

Нова функція для отримання інформації про сторінку

Довгий час для збору інформації про сторінки, що містять секції, індекс або таблицю, використовувалися команди DBCC PAGE і DBCC IND. Але вони недокументовані і непідтримувані, і буває досить складно автоматизувати вирішення завдань, пов’язаних з кількома індексами або сторінками.

Пізніше з’явилася динамічна адміністративна функція (DMF) sys.dm_db_database_page_allocations, яка повертає набір, який представляє всі сторінки у вказаному об’єкт. Все ще недокументированная і має недоліки, які можуть стати реальною проблемою на великих таблицях: навіть для отримання інформації про одній сторінці, він повинен прочитати всю структуру, що може бути досить затратно.

У SQL Server 2019 з’явилася ще одна DMF — sys.dm_db_page_info. В основному вона повертає всю інформацію про сторінку, без накладних витрат на DMF розподілу. Однак, щоб використовувати функцію в поточних збірках, потрібно заздалегідь знати номер шуканої сраницы. Можливо, такий крок було зроблено навмисно, тому що це єдиний спосіб, що дозволяє забезпечити продуктивність. Так що якщо Ви намагаєтеся визначити всі сторінки в індексі або таблиці, то необхідно використовувати DMF розподілу. В наступній стаття я опишу це питання більш докладно.

Безпека

 

Постійне шифрування з використанням безпечного середовища (анклави)

На даний момент, постійне шифрування захищає конфіденційні дані при передачі і в пам’яті шляхом шифрування/розшифрування на кожному кінці процесу. На жаль, це часто призводить до серйозних обмежень при роботі з даними, таким, як неможливість виконання обчислень і фільтрації, тому доводиться передавати весь набір даних на бік клієнта, щоб виконати, скажімо, пошук по діапазону.

Безпечне середовище (анклав) — це захищена область пам’яті, де такі обчислення і фільтрація можуть бути делеговані (у Windows використовується безпеку на основі віртуалізації) – дані залишаються зашифрованими в ядрі, але можуть бути безпечно розшифровані або зашифровані в безпечному середовищі. Потрібно просто додати параметр ENCLAVE_COMPUTATIONS в первинний ключ, з допомогою SSMS, наприклад, встановивши прапорець «Дозволити обчислення в захищеному середовищі»:

Тепер можна шифрувати дані майже миттєво, порівняно зі старими способом (в якому майстрові, статті командлет Set-SqlColumnEncyption або Вашим додатком, довелося б повністю отримати весь набір з бази даних, зашифрувати його, і відправити назад):

ALTER TABLE dbo.Patients
ALTER COLUMN SSN char(9) -- currently not encrypted! 
ENCRYPTED WITH 
(
 COLUMN_ENCRYPTION_KEY = ColumnEncryptionKeyName, 
 ENCRYPTION_TYPE = Randomized,
 ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256'
) NOT NULL;

Думаю, що для багатьох організацій даний поліпшення буде головною новиною, проте в поточному CTP деякі з цих підсистем все ще удосконалюються, тому за замовчуванням вони виключені, але тут можна подивитися, як їх включити.

Управління сертифікатами диспетчер конфігурації

Управління сертифікатами SSL і TLS завжди було болем, і багато людей були змушені виконувати тяжку роботу, створювати власні скрипти для розгортання та обслуговування сертифікатів свого підприємства. Оновлений диспетчер конфігурації для SQL Server 2019 допоможе швидко переглянути і перевірити сертифікати будь-якого примірника, знайти сертифікати, строк дії яких закінчується найближчим часом, і синхронізувати розгортання сертифікатів у всіх репликациях в групі доступності або всіх вузлах у примірнику відмовостійкого кластера.

Я не пробував всі ці операції, але вони повинні працювати і для попередніх версій SQL Server, якщо управління відбувається диспетчера конфігурацій SQL Server 2019.

Вбудована класифікація даних і аудит

Команда розробників SQL Server додала в SSMS 17.5 можливість класифікувати дані, що дозволяє визначити будь-які стовпці, які можуть містити конфіденційну інформацію або ж суперечити різним стандартам (HIPAA, SOX, PCI, і GDPR, зрозуміло). Майстер використовує алгоритм, що пропонує стовпці, які, імовірно, викличуть проблеми, але як можна скорегувати його пропозицію, видаливши ці стовпці списку, так і додати свої власні. Для зберігання класифікації використовуються розширені властивості; Вбудований в SSMS звіт використовує ту ж інформацію для відображення даних. Поза звіту ці властивості не настільки очевидні.

У SQL Server 2019 з’явилася нова інструкція для цих метаданих, вже доступна в базі даних SQL Azure, і називається як ADD SENSITIVITY CLASSIFICATION. Вона дозволяє виконувати те ж саме, що й майстер в SSMS, але інформація більше не зберігається в розширеному властивості, що і будь-яке звернення до цих даних автоматично відображається в аудиті як новий XML-стовпець data_sensitivity_information. Він містить всі типи інформації, які були порушені під час аудиту.

В якості швидкого прикладу припустимо, що у мене є таблиця для зовнішніх підрядників:

CREATE TABLE dbo.Contractors
(
 FirstName sysname, 
 LastName sysname, 
 SSN char(9), 
 HourlyRate decimal(6,2)
);

Глянувши на таку структуру стає ясно, що всі чотири стовпця або потенційно уразливі для витоку, або повинні бути доступні лише ограниченуому кола осіб. Тут можна обійтися дозволами, але як мінімум необхідно загострити на них увагу. Таким чином, ми можемо класифікувати ці стовпчики по-різному:

ADD SENSITIVITY TO CLASSIFICATION dbo.Contractors.FirstName, dbo.Contractors.LastName
WITH (LABEL = 'Confidential – GDPR', INFORMATION_TYPE = 'Personal Info');

ADD SENSITIVITY TO CLASSIFICATION dbo.Contractors.SSN
WITH (LABEL = 'Highly Confidential', INFORMATION_TYPE = 'National ID');

ADD SENSITIVITY TO CLASSIFICATION dbo.Contractors.HourlyRate
WITH (LABEL = 'Highly Confidential', INFORMATION_TYPE = 'Financial');

Тепер, замість того, щоб дивитися в sys.extended_properties, можна побачити їх у sys.sensitivity_classifications:

І якщо ми проводимо аудитную вибірку (або DML) для цієї таблиці, нам не треба нічого спеціально змінювати; після створення класифікації, SELECT * занесе в журнал аудиту запис про це тип інформації в новий стовпець data_sensitivity_information:

<sensitivity_attributes>
 <sensitivity_attribute label="Confidential - GDPR" information_type="Personal Info" />
 <sensitivity_attribute label="Highly Confidential" information_type="National ID" />
 <sensitivity_attribute label="Highly Confidential" information_type="Financial" />
</sensitivity_attributes>

Зрозуміло, це не вирішує всі питання дотримання стандартів, але це може дати відчутну перевагу. Використання майстра для автоматичного визначення стовпців і переведення викликів sp_addextendedproperty у команди ADD SENSITIVITY CLASSIFICATION може істотно спростити задачу дотримання стандартів. Пізніше, я напишу про це окрему статтю.

Можна також автоматизувати створення (або відновлення) дозволів на основі мітки в метаданих – створення динамічного SQL скрипта, який забороняє доступ до всіх конфіденційних (GDPR) колонкам, що дозволить управляти користувачами, групами або ролямb. Пропрацюю це питання в майбутньому.

Доступність

 

Відновлювальна створення індексу в режимі реального часу

У SQL Server 2017 з’явилася можливість призупинити і відновити перестроювання індексу в реальному часі, що може бути дуже корисно, якщо вам потрібно змінити кількість використовуваних процесорів, продовжити з моменту припинення після події відмови або просто ліквідувати пробіл між сервісними вікнами. Я розповідав про цю функцію в попередній статті.

У SQL Server 2019 можна використовувати той же синтаксис для створення індексів в реальному часі, припинення та продовження, а також для обмеження часу виконання (завдання часу призупинення):

CREATE INDEX foo ON dbo.bar(blat)
WITH (ONLINE = ON, RESUMABLE = ON, MAX_DURATION = 10 MINUTES);

Якщо цей запит працює занадто довго, то для призупинення можна виконати ALTER INDEX в іншому сеансі (навіть якщо індекс ще фізично не існує):

ALTER INDEX foo ON dbo.bar PAUSE;

У поточних збірках можна зменшити ступінь паралелізму при поновленні, як у випадку з перестроением. При спробі зменшити DOP:

ALTER INDEX foo ON dbo.bar RESUME WITH (MAXDOP = 2);

Отримаємо наступне:

Msg 10666, 16 Level, State 1, Line 3
Cannot resume index build as required DOP 4 (DOP operation was started with) is not available. Please ensure sufficient DOP is available or abort existing index operation and try again.
The statement has been terminated.

Насправді, якщо спробувати це зробити, а потім виконати команду без додаткових параметрів, то отримаємо ту ж помилку, принаймні на поточних збірках. Думаю, що спроба відновлення була десь зареєстрована і система хотіла її використовувати знову. Для продовження необхідно вказати коректне (або більш високе значення DOP:

ALTER INDEX foo ON dbo.bar RESUME WITH (MAXDOP = 4);

Щоб було зрозуміло: можна збільшити DOP, при поновлення припиненого створення індексу, але ніяк не знижувати.

Читайте також  Записки IoT-провайдера. Трохи про частоти

Додаткова вигода від усього цього в тому, що можна налаштувати операції створення та/або відновлення індексів в реальному часі як режим за замовчуванням, використовуючи для нової бази даних пропозиції ELEVATE_ONLINE і ELEVATE_RESUMABLE.

Створення/перестроювання кластерних колоночных індексів в реальному часі

На додаток до поновлюваному створення індексу ми також отримуємо можливість створювати або перебудовувати кластеризовані стовпчик індекси в режимі реального часу. Це суттєва зміна, що дозволяє більше не витрачати час сервісних вікон на технічне обслуговування таких індексів або (для більшої переконливості) для перетворення індексів построчных в стовпчик:

CREATE TABLE dbo.splunge
(
 id int NOT NULL
);
GO

CREATE UNIQUE CLUSTERED INDEX PK_Splunge ON dbo.splunge(id);
GO

CREATE CLUSTERED COLUMNSTORE INDEX PK_Splunge ON dbo.splunge
 WITH (DROP_EXISTING = ON, ONLINE = ON);

Одне попередження: якщо існуючий традиційний кластеризованный індекс був створений в режимі реального часу, то його перетворення в кластеризованный колоночный індекс теж можливо тільки в такому режимі. Якщо він є частиною первинного ключа, вбудованого чи ні…

CREATE TABLE dbo.splunge
(
 id int NOT NULL CONSTRAINT PK_Splunge PRIMARY KEY CLUSTERED (id)
);
GO

-- or after the fact
-- ALTER TABLE dbo.splunge ADD CONSTRAINT PK_Splunge PRIMARY KEY CLUSTERED(id);

Отримаємо таку помилку:

Msg 1907, 16 Level
Cannot recreate index 'PK_Splunge'. The new index definition does not match the constraint being enforced by the existing index.

Спочатку необхідно видалити обмеження, щоб перетворити його в кластеризованный колоночный індекс, але обидві ці операції можна виконати в реальному часі:

ALTER TABLE dbo.splunge DROP CONSTRAINT PK_Splunge
 WITH (ONLINE = ON);
GO

CREATE CLUSTERED COLUMNSTORE INDEX PK_Splunge
 ON dbo.splunge
 WITH (ONLINE = ON);

Це працює, але на великих таблицях, ймовірно, займе більше часу, ніж якщо б первинний ключ був реалізований у вигляді унікального звичайна індексу. Не можу точно сказати, чи є це навмисним обмеженням або просто обмеженням поточних CTP.

Перенаправлення підключення реплікації від вторинного до первинного сервера

Ця функція дозволяє налаштувати перенаправлення без прослуховування, так що можна перемкнути з’єднання на первинний сервер, навіть якщо в рядку з’єднання безпосередньо вказаний вторинний. Дану функцію можна використовувати коли технологія кластеризації не підтримує прослуховування, при використанні AGs без кластера, або коли має місце складна схема перенаправлення в сценарії з кількома підмережами. Це запобіжить підключення від, наприклад, спроб операцій запису для реплікації, що знаходиться в режимі тільки для читання (і відмов, відповідно).

Розробка

 

Додаткові можливості графа

Відносини графа тепер підтримують оператор MERGE для вузла або граничних таблиць, використовуючи предикати MERGE; тепер один оператор може оновити існуючий ребро або вставити нове. Нове обмеження ребер дозволить визначити які вузли може з’єднувати ребро.

UTF-8

У SQL Server 2012 була додана підтримка UTF-16 і додаткових символів шляхом установки сортування за рахунок завдання імені з суфіксом _SC, типу Latin1_General_100_CI_AI_SC, для використання стовпців у форматі Unicode (nchar/nvarchar). У SQL Server 2017 можна імпортувати і експортувати дані у форматі UTF-8 з і в ці колонки за допомогою засобів типу BCP і BULK INSERT.

У SQL Server 2019 існують нові параметри сортування для підтримки примусового зберігання у вихідному вигляді даних UTF-8. Так що можна без проблем створювати колонки типу char або varchar і коректного храненить дані UTF-8, використовуючи нові параметри сортування з суфіксом _SC_UTF8, як Latin1_General_100_CI_AI_SC_UTF8. Це може допомогти поліпшити сумісність з зовнішніми програмами і СУБД, без витрат на обробку та зберігання nvarchar.

Пасхалка, яку я знайшов

Наскільки я пам’ятаю, користувачі SQL Server скаржаться на це невиразне повідомлення про помилку:

Msg 8152
String or binary data would be truncated.

У збірках CTP, з якими я експериментував, було помічено цікаве повідомлення про помилку, якого не було раніше:

Msg 2628
String or binary data would be truncated in table '%.*ls', column '%.*ls'. Truncated value: '%.*ls'

Я не думаю, що тут потрібно щось ще; це відмінне (хоча й досить запізніле) поліпшення, і обіцяє багатьох зробити щасливими. Однак ця функціональність не буде доступна в CTP 2.0; я просто даю можливість заглянути трохи вперед. Брент Озар перерахував всі нові повідомлення, знайдені ним в поточному CTP, і приправив їх декількома корисними коментарями у своїй статті sys.messages: виявлення додаткових функцій.

Висновок

SQL Server 2019 пропонує хороші додаткові можливості, які допоможуть поліпшити роботу з коханою платформою реляційних баз даних, і є ряд змін, про які я не говорив. Энергостойкая пам’ять, кластеризація служб для машинного навчання, реплікація та розподілені транзакції в Linux, Kubernetes, коннектори для Oracle / Teradata / MongoDB, синхронні реплікації AG піднялися до підтримки Java (реалізація аналогічна Python/R) і, що не менш важливо, новий ривок, під назвою «Кластер великих даних». Для використання деяких з цих функцій необхідно зареєструватися за допомогою цієї EAP форми.

Майбутня книга Боба Уорда, Pro SQL Server on Linux — Including Container-Based Deployment with Docker and Kubernetes, може дати деякі підказки про низку інших речей, які незабаром з’являться. І ця публікація Брента Озара говорить про можливе майбутнє виправлення скалярної користувацької функції.

Але навіть у цьому першому публічному CTP є щось істотне майже для всіх, і я закликаю випробувати його самостійно!

Степан Лютий

Обожнюю технології в сучасному світі. Хоча частенько і замислююся над тим, як далеко вони нас заведуть. Не те, щоб я прям і знаюся на ядрах, пікселях, коллайдерах і інших парсеках. Просто приходжу в захват від того, що може в творчому пориві вигадати людський розум.

You may also like...

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *