База данных в памяти - улучшаем производительность SQL Server 2019

База данных в памяти в SQL Server 2019

Напомню, в предыдущей статье мы начали разговор об интеллектуальных возможностях по настройке производительности SQL Server 2019, и рассмотрели возможности по умной настройке запросов в SQL сервере. В этой статье мы разовьем тему и подробно поговорим об еще одной возможности у улучшению производительности данной СУБД. Речь пойдет о Базе данных в памяти  (In-Memory Database).


Оглавление статьи[Показать]


В SQL Server 2014 мы представили функцию OLTP в памяти (In-Memory OLTP), ключевой концепцией которой была концепция таблиц, оптими­зированных для выделения памяти. При использовании этой функции вся таблица хранится в памяти, но именно оптимизированный (читайте: без кратковременных блокировок, latch-free) доступ делает ее особенной. В SQL Server 2016 мы значительно усовершенствовали функцию In-Memory OLTP. Более подробно об этой функции рассказывается по ссылке.

Когда мы работали над новыми функциями для SQL Server 2019, Сла­ва Окс (Slava Oks), Пэм Лахуд (Pam Lahoud), Брайан Карриг (Brian Carrig), Аргенис Фернандес (Argenis Fernandez) и другие члены команды инжене­ров собрались вместе и решили совместно назвать новый набор функций базой данных в памяти (In-Memory Database). Это новое семейство функ­ций, в которые входит и In-Memory OLTP.

То, что в SQL Server 2019 названо базой данных в памяти, включает в себя целый набор различных функций:

  • In-Memory OLTP;
  • оптимизированные для выделения памяти метаданные TempDB;
  • гибридный буферный пул;
  • поддержка постоянной памяти.

Полный список этого набора функций доступен по адресу.

В этом разделе мы рассмотрим все эти новые возможности, кроме In-Memory OLTP (которая не является «новшеством» SQL Server 2019).

 

Метаданные TempDB, оптимизированные для выделения памяти

На протяжении всего времени, в течение которого я работал с SQL Server, производительность параллельных подключений при использовании вре­менных таблиц была очень низкой. Это приводило к тому, что почти каж­дый администратор SQL Server настраивал tempdb для использования нескольких файлов. Вы можете прочитать больше об истории приключе­ния с этими ресурсами:

Один из аспектов использования файлов tempdb, которому большинст­во профессионалов SQL не уделяют особого внимания (поскольку сейчас это стало обычной практикой), заключается в том, что вы создаете для механизма SQL Server схему разделения данных для доступа к страницам размещения, таким как страницы PFS, GAM и SGAM. Подобный тип схемы полезен, потому что работа с использованием временных таблиц приводит к «утяжелению» таких операций, как создание таблиц, выделение страниц, удаление таблиц. В этом случае возникает ситуация конкуренции на этих системных страницах размещения - так называемые кратковременные блокировки, или «защелки» (latches). Создавая несколько файлов, вы рас­пространяете на них и конкуренцию за временные блокировки на страни­цах этих файлов, что повышает производительность в ситуации, когда с tempdb работает множество параллельных подключений.

После создания нескольких файлов (начиная с версии SQL Server 2016 программа установки может сделать это автоматически, или же вы можете настроить этот параметр установки вручную) при более высокой одновре­менной рабочей нагрузке на базу данных tempdb число ожиданий временно заблокированных страниц может увеличиться. Эти ожидания затрагивают страницы, принадлежащие объектам, которые вы не можете распознать, например такие, как sysschobjs. Это ожидания блокировки страниц для страниц системных таблиц в базе данных tempdb. При быстром создании и удалении таблиц SQL Server должен выполнять внутренние операции чте- ния/записи на страницах системных таблиц, чтобы поддерживать согласо­ванность метаданных таблиц. Эти операции приводят к увеличению кон­куренции пользователей за страницы, где установлены кратковременные блокировки, и, следовательно, к увеличению времени ожидания пользо­вателей в очереди доступа к заблокированному ресурсу. В прошлом, когда клиенты сталкивались с высокой конкуренцией за заблокированные стра­ницы в системных таблицах и обращались ко мне в службу поддержки, я отвечал: «К сожалению, вы должны уменьшить нагрузку на базу данных tempdb, чтобы избежать этой проблемы».

Пэм Лахуд (Pam Lahoud) очень хорошо описывает эту проблему в сво­ем блоге, размещенном по адресу.

В SQL Server 2019 появляется решение - метаданные tempdb, оптими­зированные для выделения памяти. В таблицах, оптимизированных для выделения памяти (помните известный проект Hekaton («Гекатон»)?) не может быть кратковременных блокировок страниц, поскольку все данные этих таблиц размещены и хранятся в памяти. Если таблицы, оптимизи­рованные для выделения памяти, являются «просто схемой», то у них нет ограничений, связанных со временем их жизни. Это идеальная платформа для системных таблиц tempdb. Поскольку база данных tempdb создается заново при каждом перезапуске сервера, системные таблицы не должны быть долговечными. А так как в таблицах, оптимизированных для выде­ления памяти, хранятся только метаданные (а не данные во временных таблицах), потребление памяти для них должно быть небольшим. Равиндер Вуппула (Ravinder Vuppula), ведущий разработчик этого проекта, назвал создание системных таблиц tempdb «гекатонизированным».

Метаданные tempdb по умолчанию не используют таблицы, оптимизи­рованные для выделения памяти, при установке SQL Server. Вы должны выполнить следующую команду T-SQL, чтобы включить эту возможность:

ALTER SERVER CONFIGURATION SET MEMORY_OPTIMIZED TEMPDB_METADATA = ON

Вы можете просмотреть мою демонстрацию данной функции на выступ­лении SQLBits 2019. Брент Озар (Brent Ozar) в своем блоге сказал об этой возможности, увидев ее демонстрацию на саммите PASS в 2018 году: «...это улучшение работы с TempDB просто великолепно. Это реальное улучшение, которое будет иметь огромную популярность. Люди долго боролись с неразрешимыми пробле­мами конкуренции TempDB и с блокировками и никак не могли справиться с этим».

Но вы должны попробовать эту возможность сами, чтобы увидеть ее в действии. Давайте рассмотрим пример того, как метаданные tempdb, оптимизированные для выделения памяти, могут значительно улучшить параллельную работу приложений, использующих временные таблицы. Все сценарии для этого примера размещены в каталоге tempdb. Этот пример немного сложнее, и для него потребуется координировать или эмулировать одновременную работу нескольких пользователей. Поэтому вам понадобится бесплатный инстру­мент для нагрузочного тестирования под названием ostress, который мож­но загрузить по ссылке. Этот инструмент в настоящее время доступен только для Windows. Данный при­мер будет по-прежнему работать с SQL Server, установленным на Linux; просто вам понадобится клиент Windows для управления параллельными пользовательскими подключениями с помощью ostress.

Кроме того, я настроил свой SQL Server на виртуальной машине с восемью логическими процессорами. Когда я запустил программу уста­новки SQL Server, она автоматически создала восемь файлов данных tempdb. Я рекомендую вам убедиться, что у вас есть как минимум восемь файлов данных tempdb, если в вашей системе имеется восемь или более логических процессоров. Подробнее о том, как это сделать, читайте в следующей статье технической поддержки.

  1. Запустите сценарий disableopttempdb.cmd, чтобы отключить функ­цию оптимизации метаданных tempdb для выделения памяти. По умолчанию эта возможность отключена; однако рекомендуется запустить этот сценарий на тот случай, если она была включена в какой-то момент. Вам нужно запустить данный сценарий на том сервере, где установлен SQL Server (или использовать другой метод для удаленного перезапуска SQL Server). Для этого сценария пона­добится ввести имя учетной записи системного администратора и имя сервера. Вы можете изменить этот способ аутентификации и использовать встроенную аутентификацию, изменив -Usa на -E, и не забудьте заменить текущее значение параметра -S на имя вашего сервера:
    sqlcmd -Usa -idisableopttempdb.sql -Sbwsql2019
    
    net stop mssqlserver
    
    net start mssqlserver

    Как видите, этот сценарий дает инструкцию Windows Server перезапустить службу SQL Server (mssqlserver). Вы можете написать свой собственный сценарий для Linux, используя команду типа sudo systemctl restart mssql-server для перезапуска SQL Server.

    Сценарий disableopttempdb.sql содержит следующую инструкцию T-SQL:

    ALTER SERVER CONFIGURATION SET MEMORY_OPTIMIZED TEMPDB_
    METADATA = OFF
    GO
  2. Запустите сценарий T-SQL tempstress_ddl.sql, чтобы создать базу данных и хранимую процедуру, которая просто создает временную таблицу:
    DROP DATABASE IF EXISTS DallasMavericks
    GO
    CREATE DATABASE DallasMavericks
    GO
    USE DallasMavericks
    GO
    CREATE OR ALTER PROCEDURE letsgomavs
    AS
    CREATE TABLE #gomavs (col1 INT)
    GO

    Как видите, хранимая процедура на самом деле ничего не делает с временной таблицей. Это показывает минимальный объем рабочей нагрузки, который может повлиять на параллельную работу с мета­данными временной таблицы (поскольку любой выход из хранимой процедуры автоматически удаляет временную таблицу).

  3. Теперь вы готовы к тому, чтобы создать паралельную рабочую нагруз­ку на tempdb с помощью ostress. Используйте сценарий tempstress. cmd для создания этой рабочей нагрузки с применением ostress:
    ostress -Usa -Q"exec letsgomavs" -n50 -r10000
    -dDallasMavericks -Sbwsql2019

    Вам может потребоваться изменить некоторые из параметров сце­нария, например изменить -Usa на -E для использования встроенной аутентификации Windows. Вы также можете изменить имя сервера (изменив параметр -S). Параметр -n50 - это количество пользовате­лей, создающих рабочую нагрузку, а -r10000 - количество итераций для каждого пользователя. Обратите внимание на использование параметра -Q для непосредственного запуска хранимой процеду­ры - прием, который я узнал, работая над ранними версиями это­го сценария для демонстрации. Использование параметра -Q для ostress для непосредственного запуска запроса работает быстрее, чем инструкция сценария с -i.

    Если вы используете учетную запись администратора (-Usa), вам бу­дет предложено ввести пароль, после чего гонки начнутся. В зависи­мости от мощности вашего компьютера этот нагрузочный сценарий будет выполняться несколько минут.

  4. Пока он выполняется, создайте новое подключение к SQL Server и откройте сценарий T-SQL pageinfo.sql:
    USE tempdb
    GO
    SELECT object_name(page_info.object_id), page_info.*
    FROM sys.dm_exec_requests AS d
    CROSS APPLY sys.fn_PageResCracker(d.page_resource) AS r
    CROSS APPLY sys.dm_db_page_info(r.db_id, r.file_id,
    r.page_id,'DETAILED')
    AS page_info
    GO

    Этот сценарий использует новые функциональные возможности в SQL Server 2019 для извлечения информации о странице из ресурса, указанного в sys.dm_exec_requests, и для выгрузки в многоколоноч­ном формате полей заголовка страницы.

    Почему и в каком случае вам нужно использовать этот сценарий? Потому, что когда у вас появляются ожидания кратковременных блокировок страниц для базы данных tempdb, вы одновременно с этим видите отчет о ресурсах в формате <dbid>: <fileid>: <pageid>. До того, как появилась эта функция, вам нужно было вручную выпол­нять команду DBCC PAGE (команду, которая официально не поддер­живается), чтобы выяснить, к какому объекту относится страница, для которой наблюдается ожидание снятия кратковременной бло­кировки. Метод, продемонстрированный здесь, теперь официально поддерживается при определении страницы в сценарии ожидания снятия кратковременной блокировки.

    Ваши результаты при выполнении запроса на предыдущем шаге должны выглядеть примерно так, как показано на рис. 1.

    Кратковременная блокировка страницы: ожидание системных таблиц в базе данных tempdb

    Рис. 1. Кратковременная блокировка страницы: ожидание системных таблиц в базе данных tempdb

    Как описано выше, sysschobjs - это системная таблица, являющаяся «уз­ким местом», поскольку временные таблицы создаются и удаляются.

  5. Теперь давайте включим оптимизацию метаданных tempdb для выделения памяти. Запустите сценарий optimizetempdb.cmd на сервере, где установлен SQL Server. Этот сценарий выполняет следую­щее, однако вы можете использовать другие методы для включения функции и перезапуска SQL Server:
    sqlcmd -Usa -ioptimizetempdb.sql -Sbwsql2019
    
    net stop mssqlserver
    
    net start mssqlserver

    Сценарий optimizetempdb.sql содержит следующую инструкцию T-SQL:

    ALTER SERVER CONFIGURATION SET MEMORY_OPTIMIZED TEMPDB_METADATA = ON
    GO

     

  6. Убедитесь, что оптимизация метаданных tempdb для выделения па­мяти включена, изучив файл журнала ошибок SQL Server ERRORLOG. Вы должны увидеть такую запись в ERRORLOG:
    Tempdb started with memory-optimized metadata.
  7. Теперь снова запустите сценарий tempstress.cmd, создающий рабо­чую нагрузку. На этот раз при той же рабочей нагрузке, без изме­нений в приложении, для выполнения сценария потребуется чуть более 30 секунд.
  8. Запустите сценарий pageinfo.sql еще раз, чтобы увидеть, имеет ли место ожидание снятия кратковременной блокировки страницы. Ваши результаты должны содержать 0 строк!
  9. Пока выполняется сценарий, запущенный на предыдущем шаге, соз­дайте новое подключение к SQL Server и в нем запустите сценарий T-SQL find_memoptimized_tables.sql. Ваши результаты должны вы­глядеть примерно так, как показано на рис. 2.

     Системные таблицы tempdb после оптимизации для выделения памяти

Рис. 2. Системные таблицы tempdb после оптимизации для выделения памяти

В окне результатов вы можете видеть все системные таблицы, оптими­зированные для выделения памяти (ваш результат может содержать даже больше таблиц, поскольку эта функция улучшается). Обратите внимание на серьезные изменения значений в sysschobjs (но это не единственная системная таблица, которую затронула оптимизация).

Вы можете задаться вопросом: сколько дополнительной памяти потреб­ляется при использовании этой функции? Пока вы все еще работаете в дан­ной среде, выполните запрос к DMV sys.dm_os_memory_clerks. Вы увиди­те строку, в которой будут содержаться записи: type = MEMORYCLERK_XTP и name = DB_ID_2. Столбец pages_kb - это примерное количество памяти, потребляемой метаданными tempdb, оптимизированными для выделения памяти. Как мы видим, для этого примера оно составляет около 200 Мб.

На данном этапе вы можете оставить флаг, переключающий опти­мизацию для выделения памяти метаданных tempdb, включенным для своего сервера, но если вы хотите выключить его, используйте сценарий disableopttempdb.cmd.

Вы можете видеть преимущества этой функции, встроенной в ядро СУБД. Вам нужно лишь установить один параметр конфигурации сервера, перезапустить SQL Server - и уже можно начинать работать.

Если вы имеете доступ к представлениям каталога (catalog views) в базе данных tempdb, то можете заметить, что при использовании метаданных tempdb, оптимизированных для выделения памяти, существует несколь­ко ограничений. Вы можете прочитать об этих ограничениях, а также най­ти более подробную информацию об этой возможности, в документации, размещенной по адресу.

Гибридный буферный пул

Устройства с постоянной памятью существуют уже несколько лет, но сейчас они начинают набирать популярность. Концепция основана на постоянно работающей аппаратной памяти с бесперебойным источником питания. Подумайте о скорости оперативной памяти, обладающей еще одним новым преимуществом: любые сохраненные данные гарантирован­но выдержат перезапуск питания. Одним из наиболее популярных реше­ний в области постоянной памяти является постоянная память от Intel под названием Optane.

Наша команда разработчиков SQL Server все время ищет способы опти­мизировать доступ к данным, и при наличии постоянной памяти сущест­вует несколько возможностей для такой оптимизации. Фактически еще в SQL Server 2016 существовала функция, называемая «остатком кеширова­ния журнала», основанная на использовании постоянной памяти (см. сооб­щение в блоге Кевина Фарли (Kevin Farlee) на эту тему).

Поскольку постоянная память - это одна из разновидностей памяти, SQL Server может обращаться к любым данным, хранящимся на постоянном запоминающем устройстве, как будто это обычная память. Это означает, что SQL Server может найти способ обойти код ядра при обработке вво­да-вывода, выполняемого при доступе к данным на устройствах постоян­ной памяти.

Одной из таких новых возможностей является гибридный буферный пул. Идея заключается в том, что если вы разместите файлы данных вашей базы данных в постоянной памяти, SQL Server может просто получить доступ к страницам файла данных с этого устройства без необходимости копировать данные из файла данных на страницу буферного пула. Гибридный буфер­ный пул использует вызовы ядра, привязанные к памяти, чтобы реализо­вать концепцию базы данных в памяти. Если страница базы данных была изменена, ее необходимо скопировать в буферный пул и затем в конечном итоге записать обратно на постоянное запоминающее устройство.

Производительность такой системы может варьироваться в зависимости от возможности использования тех преимуществ, которые предоставляет использование гибридного буферного пула, но обычно от этой технологии можно ожидать некоторого повышения производительности, особенно если для вашей базы данных характерны высокие нагрузки на чтение.

В SQL Server, если вы разместили один или несколько файлов базы данных на постоянном запоминающем устройстве, вы можете включить гибридный буферный пул для всех баз данных для вашего сервера с по­мощью оператора T-SQL:

ALTER SERVER CONFIGURATION SET MEMORY_OPTIMIZED HYBRID_BUFFER_POOL = ON

Примечание. При включении гибридного буферного пула для всех баз данных необ­ходимо перезапустить SQL Server.

Вы можете включить гибридный буферный пул для конкретной базы данных с помощью следующего оператора T-SQL (при этом вам не потре­буется перезапускать сервер):

ALTER DATABASE <имя_базы_данных> SET MEMORY_OPTIMIZED = ON

Чтобы узнать больше о том, как включить на ваших устройствах посто­янную память для баз данных, как отключить гибридный буферный пул и как использовать гибридный буферный пул, обратитесь к документации по адресу.

Поддержка постоянной памяти

Если вы не хотите включать гибридный буферный пул, но хотели бы, чтобы SQL Server использовал возможности чтения и записи данных и жур­нала транзакций на устройствах с постоянной памятью, вы можете настро­ить используемое устройство как устройство постоянной памяти в Linux. SQL Server автоматически обнаружит его и будет использовать операции на основе памяти для перемещения данных в кеш SQL Server и на устрой­ство, минуя стек ввода-вывода ядра Linux. Этот процесс называется «про­светлением» (элементом паравиртуализции).

Dell EMC показала значительные улучшения производительности при использовании «просветления», как описано в публикации www.emc.com/ about/news/press/2019/20190402-01.htm. По словам Dell, «благодаря новой посто­янной памяти Intel® Optane™ DC клиенты могут ускорить работу баз дан­ных в оперативной памяти, виртуализации и анализа данных, увеличив объем памяти в 2,5 раза для отдельных серверов PowerEdge. Используя постоянную память Intel® Optane™ DC, PowerEdge R740xd обеспечива­ет увеличение объема обрабатываемых транзакций до 2,7 раза, по срав­нению с числом транзакций в секунду, обеспечиваемым дисками NVMe в виртуализированной среде предварительного просмотра Microsoft SQL Server 2019, работающим на VMware ESXi.1».

Вы можете прочитать все подробности о том, как включить устройство постоянной памяти в Linux для SQL Server, по ссылке.

Конфликт вставки на последней странице

Давайте рассмотрим распространенную проблему пользователей SQL Server, которая оставалась нерешенной в течение очень долгого време­ни. Вы хотите построить таблицу с первичным ключом, который будет использоваться в кластеризованном индексе. И для этого первичного клю­ча используются последовательные значения. Другими словами, каждая вставка строки приводит к добавлению нового значения ключа в порядке увеличения. Наиболее распространенным примером такого ключа являет­ся столбец, использующий объект SEQUENCE или свойство IDENTITY.

Хотя этот подход в большинстве случаев работает нормально, все же здесь скрывается сложная проблема, связанная с производительностью приложений. Каждый раз, когда запрос должен изменить страницу, SQL Server должен физически защищать другие запросы от одновременного изменения или чтения структуры страницы (даже при наличии такой воз­можности, как блокировка на уровне строк), используя кратковременную блокировку страницы.

Если бы все пользователи пытались изменить одну и ту же страницу, производительность вашего приложения ухудшилась бы из-за конкурен­ции за блокировку страницы. Если вы строите кластеризованный индекс по последовательному ключу, данные сортируются по этому ключу. Каждая вставка будет пытаться вставить новую строку на последней странице листового уровня кластеризованного индекса. И если многие пользова­тели одновременно выполняют вставки, все они могут в конечном ито­ге попытаться изменить последнюю страницу индекса, отсюда и термин «конфликт вставки на последней странице».

Хотя описанная ситуация и не идеальна, она, как правило, не вызыва­ет больших проблем, пока не произойдет явление, называемое «колонной» кратковременных блокировок. Пэм Лахуд (Pam Lahoud), старший руко­водитель программы в команде, работающей над SQL Server (известная также как @SQLGoddess), показала мне следующий ресурс, посвященный проблеме с «колонной». В контексте проблемы конкуренции за вставку на последней странице для SQL Server разделение страницы является примером сценария, в котором может сформироваться «колонна». Разделение страницы может произой­ти, если на странице недостаточно строк для нового INSERT и в кластеризо­ванном индексе должна быть создана новая страница. Пэм также провела отличную аналогию с проблемой «колонны». По словам Пэм, «пробки - обычная аналогия, используемая при описании этой проблемы. Если у вас есть дорога, по которой движется транспортный поток, равный макси­мальной пропускной способности этой дороги, то пока весь поток продол­жает двигаться с одинаковой скоростью, движение будет постоянным, хотя и немного замеделенным. Как только на дороге происходит что-то, при­водящее к тому, что водители нажимают на тормоза, например впереди оказывается водитель, едущий слишком медленно, возникает опасность на дороге или автомобили приближаются к сложной развязке, движение затрудняется. Если автомобили продолжают подъезжать к месту затора движения с той же скоростью, что и раньше, ситуация на дороге становит­ся все хуже и хуже. Водители все еще продвигаются вперед, но очень мед­ленно. На этом этапе пропускная способность не восстановится до тех пор, пока число автомобилей, въезжающих на дорогу, резко не уменьшится и не станет намного ниже, чем то значение транспортного потока, которое соответствует пропускной способности дороги».

Многие пользователи в сообществе SQL, технической поддержке и раз­работке решали эту проблему различными способами на протяжении мно­гих лет. О многих из них упоминается в статье технической поддержки, размещенной на странице. А как насчет решения, реализованного внутри самого ядра СУБД и которое не потребу­ет внесения изменений в приложение? Когда я увидел, что наше решение появилось в версии SQL Server 2019 CTP 3.1, я знал, что эта проблема уже обсуждалась нашей командой инженеров, рассмотревших множество воз­можных решений. Я расспросил Вонсок Ким (Wonseok Kim), ведущего раз­работчика этой функции, об истории ее реализации. Он показал мне вет­ку сообщений электронной почты, которая на самом деле имелась в моей почтовой папке, но я забыл о ней. Оказывается, в переписке, относящей­ся к работе над этим подходом, часто встречалось знакомое имя - Слава Окс (Slava Oks). Слава работал над этой идеей вместе со многими другими выдающимися программистами из команды разработчиков SQL Server.

Решение теперь существует в виде нового параметра для создания индек­сов - OPTIMIZE_FOR_SEQUENTIAL_KEY. Добавив этот параметр в ограни­чение индекса или первичного ключа, вы сообщаете SQL Server, что нужно использовать новый код, чтобы попытаться избежать проблем с «колон­ной» . Этот параметр не устраняет кратковременные блокировки страниц и не предотвращает проблему конфликта кратковременных блокировок. Что он делает, так это старается избежать серьезных проблем в ситуации, когда образуется «колонна», чтобы выровнять вашу рабочую нагрузку на сервер, сделать ее постоянной.

Подробнее об этой возможности и о том, как ее использовать, вы може­те прочитать в документации по ссылке.

Примечание. Если вы используете этот параметр, то можете заметить появившийся новый тип ожиданий (wait_type) с названием BTREE_INSERT_FLOW_CONTROL. Он яв­ляется частью механизма, позволяющего избежать или уменьшить проблему с «колонной».

Однако этот вариант не для всех. Если вы не используете последователь­ные значения ключа для кластеризованного индекса или не видите серьез­ных конфликтов, я бы не рекомендовал включать этот параметр. Факти­чески вы можете сильно ухудшить производительность вашей системы, слепо применяя его в любом кластеризованном индексе.

Если вы хотите попробовать это сами, убедитесь, что у вас есть достаточ­но «широкая» таблица. Когда я тестировал эту возможность, в моем слу­чае простое создание таблицы с одним столбцом IDENTITY не привело к существенному увеличению производительности. Что вам нужно сделать - так это вызвать условия, при которых происходит достаточное количество разбиений страниц, чтобы заметить проблему с «колонной».

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

 

Выводы

Эта серия статей была очень длинной и показала невероятные возможности интеллектуальной настройки производительности, встроенные в SQL Server 2019, призванные помочь вам повысить производительность без изменения уже работающих приложений. Я привел в ней много подробных примеров, чтобы вы могли сами убедиться в богатых возможностях новых функций, а также посмотреть, как они могут помочь повысить производи­тельность и сэкономить ваше время, затрачиваемое на настройку произво­дительности как при развертывании SQL Server 2019 в вашей организации, так и в разработке пользовательских приложений.

 

Вас заинтересует / Intresting for you:

Что нового в SQL Server 2019? ...
Что нового в SQL Server 2019? ... 331 просмотров Doctor Mon, 15 Feb 2021, 19:46:52
SQL Server 2019: Интеллектуаль...
SQL Server 2019: Интеллектуаль... 295 просмотров Doctor Mon, 01 Mar 2021, 15:47:54
SQL Server 2019: Гибридный пул...
SQL Server 2019: Гибридный пул... 325 просмотров Doctor Sat, 27 Feb 2021, 19:09:38
SQL Server 2019: Интеллектуаль...
SQL Server 2019: Интеллектуаль... 314 просмотров Doctor Sat, 27 Feb 2021, 16:01:18
Войдите чтобы комментировать