SQL Server

You are currently browsing the archive for the SQL Server category.

По материалам статьи Craig Freedman Repeatable Read Isolation Level
9 мая 2007 г.

В двух предыдущих статьях (1, 2) было продемонстрировано как запросы с уровнем изоляции «read committed» могли порождать неожиданные результаты. Это становилось возможным из-за выполняющихся в одно и то же время изменений затронутых запросом строк. Чтобы недопустить подобных неожиданностей (но не всех), следует использовать для выборки уровень изоляции «repeatable read». В этой статье мы как раз и рассмотрим как одновременные изменения ведут себя с уровнем изоляции «repeatable read» (повторяемое чтение).
В отличие от просмотра с «read committed», просмотр с «repeatable read» удерживает блокировки каждой затронутой строки до окончания транзакции. На всём протяжении транзакции заблокированными могут оказаться даже некоторые строки, которые не соответствуют выборке в результате запроса. Такое блокирование гарантирует, что затронутые запросом строки не будут изменены или удалены в параллельном сеансе, пока текущая транзакция не будет завершена (независимо от того, будет ли она зафиксирована или произойдёт её откат). Эти блокировки не защищают от изменения или удаления те строки, которые еще не были охвачены просмотром, и не препятствуют вставке новых строк межу уже заблокированными строками. На рисунке ниже такое поведение проиллюстрировано графически: Read the rest of this entry »

Если выполнение отключения QS для базы данных блокируется системным процессом: QUERY STORE BACKGROUND FLUSH DB

SET DEADLOCK_PRIORITY HIGH
ALTER DATABASE [DATABASENAME] SET QUERY_STORE = OFF WITH NO_WAIT
GO

Подключиться через DAC и сделать:

TRUNCATE table sys.plan_persist_runtime_stats;
TRUNCATE table sys.plan_persist_runtime_stats_interval;
TRUNCATE table sys.plan_persist_plan;
TRUNCATE table sys.plan_persist_query;
TRUNCATE table sys.plan_persist_query_text;
TRUNCATE table sys.plan_persist_context_settings;

Подробности можно найти тут: Manually Clearing the Query Store

Если в журнале приложений есть ошибки для MSSQLService: “…TDSSNIClient initialization failed with error 0x80092004…” нужно В POWERSHELL создать самоподписной сертификат (заменив в скрипте имя SERVERNAME.DOMENNAME.ru на полное имя вашего сервера):

New-SelfSignedCertificate -Type SSLServerAuthentication -DnsName SERVERNAME.DOMENNAME.ru -KeyLength 2048 -KeySpec KeyExchange -KeyUsage KeyEncipherment -TextExtension @(“2.5.29.37={text}1.3.6.1.5.5.7.3.1”) -NotAfter (Get-Date).AddMonths(1200)
Далее нужно указать для протоколов созданный сертификат, как это описано в главе “Configuring SSL for SQL Server” статьи: https://docs.microsoft.com/en-us/previous-versions/sql/sql-server-2008-r2/ms189067(v=sql.105)

Craig Freedman, 2 мая 2007г. Оригинал статьи тут: https://blogs.msdn.microsoft.com/craigfr/2007/05/02/query-plans-and-read-committed-isolation-level/

В прошлый раз мы рассмотрели то, как одновременные изменения могут стать причиной просмотра на уровне изоляции read committed. Также было показано что эти условия могут привести к выборке одной и той же строки несколько раз или вообще к отсутствию строки в выборке.  Теперь давайте рассмотрим как одновременные изменения могут отразиться на работе более сложных планов запроса. Read the rest of this entry »

В этой статье отражён опыт построения и поддержания инфраструктуры для больших (больше 10Тб) баз данных. Статья не предлагает универсального решения всех возможных задач MS SQL Serverи не отражает всего разнообразия возможных типов нагрузки. Поэтому использовать представленные ниже выводы и рекомендации стоит с оглядкой на свою специфику. Всё, что тут описано, было апробировано на OLTP нагрузках с немалой долей больших аналитических запросов, агрегации, процессинга и массовых выгрузок/загрузок данных. Нагрузка была блочная, неоднородная во времени и по структуре. Характерными чертами нагрузки являлся высокий параллелизм, большое число блокировок, листаний, асинхронных операций, очередей, ожиданий процессора и окончания ввода-вывода. Сама нагрузка балансировалась на уровне логики работы приложения, ресурсы распределялись сообразно возможностям задач, запросы снабжались «хинтами», а распределения памяти для многих задач исчислялись десятками и сотнями Мегабайт. Статья предназначена для администраторов баз данных и хранилищ. Подразумевается, что она облегчит понимание особенностей размещения файлов данных и журналов SQL Server в сетях SAN.
Read the rest of this entry »

Одной из обязательных задач администрирования баз данных MS SQL Server является периодическое восстановление баз, дабы убедиться, что база восстанавливается успешно. Ещё одной такой задачей является периодическая проверка баз посредством DBCC CHECKDB. Зачастую, полезно эти задачи объединить, и запускать проверку базы после восстановления её на специально предназначенном для этого сервере. Если у базы имеется несколько файловых групп и размер базы настолько большой, что проверка каждой занимает несколько часов, резонно проверять не всю база сразу, а поочерёдно все файловые группы. Сократить время проверки также можно отказавшись от проверки индексов, например вот так: DBCC CHECKFILEGROUP (‘PRIMARY’, NOINDEX). Read the rest of this entry »

Не существует рекомендованного Майкрософт способа уведомления администраторов о том, что SQL Server выгрузил дамп страниц памяти на диск. Также весьма затруднительно отслеживать такие дампы средствами SQL Server или операционной системы, поскольку во время выгрузки дампа работа сервера баз данных и большинства системных процессов «замирает». Однако, вполне возможно обнаружить последствия выгрузки дампа, поскольку в указанной для дампов папке вместе с файлами дампа появится файл с именем: «SQLDUMPER_ERRORLOG.log». Имя этого файла неизменно, на этом и основан предлагаемый вашему вниманию способ слежений за появлением новых дампов. Настройка пути к папке дампов хранится в системном реестре. По этому пути можно посредством PowerShell узнать существует ли в папке дампов файл с именем «SQLDUMPER_ERRORLOG.log». Такую проверку можно делать по расписанию в задании Агента SQL Server. Если файл обнаружен, то можно совершить необходимое действие. Например, в приведенном ниже сценарии будет отправлено письмо электронной почты на указанный список адресов. Отправку осуществит подсистема SQL Server DatabaseMail. Для корректной отправки сообщения нужно указать существующий почтовый профиль.
Обычно, администраторы изучают причины, вызвавшие создание дампа по файлам текстовых описаний дампа и логу. Вместе с этим можно переименовать и/или скопировать файлы дампа в другое место, или удалить. Также, можно составить сценарий PowerShell таким образом, чтобы необходимые действия выполнялись в дополнение к предлагаемому ниже примеру сценария: Read the rest of this entry »

« Older entries