Настройка параметров приращения баз данных MS SQL Server

December 30, 2014, 4:20 am

≫ Next: Настройка SPN для MS SQL Server - просто

≪ Previous: Настройки серверов HP серии DL 580 и DL 980 для MS SQL Server

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

Цель статьи объяснить

- в мегабайтах или процентах указывать размер приращения?!
- размер самого приращения - 1, 30, или 500 мб?!

Немного теории.

При создании базы данных, как мы знаем, создается база, с параметрами базы данных model, а именно:
Размер файла данных 5 мб,
Размер приращения файла данных 1 мб,
Размер файла логов(транзакций) 1 мб,
Размер приращения файла логов(транзакций) 10 %
Рост файлов неограничен
Модель восстановления Full.

Так же эти параметры можно поменять при создании.

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

Итак, по вопросам:

Указывать приращение в процентах или в мегабайтах?!

Ответ – можно так и так, в зависимости от размера базы данных.

Если размер файла базы 300 мб, то приращение 10% это будет 30 мб, а если база данных 30 Гб, то 10 % будет 3000 Гб, разница есть? А если 100 Гб или более.
За какое время ОС прирастит к файлу в объем 10 Гб или более? Ответ - не мгновенно.

Но и это еще не все. К примеру, есть база dwhобъем 500 Гб, прирост которой небольшой и бывает редко, установлен прирост 10 %., т.е 50 Гб должен быть прирост файла когда в файле будет не хватать места. В итоге мы получим ситуацию, как описал выше, ОС долгое время будет найти место для данного файла на диске и его разметить. А что если на диске нет свободных 50 Гб, а только 40? Гб, в итоге база данных не будет доступна для изменения. Если был бы указано приращение в мб, к примеру 512 мб, то мы бы провели операцию приращения места в файлу довольно быстро, а оставшиеся место на диске использовали бы для других задач.

Думаю, понятно какие отрицательные свойства будут при приращение в процентах.

Размер приращения в мегабайтах?!

На основе вышеописанного про процент приращения, размер приращения в мегабайтах так же зависит от объемы базы данных.

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

Если база данных небольшая, к примеру до 10 Гб, то приращение 100-300 мб, будет достаточным, если база большая и имеет большое количество транзакций, то приращение стоит указывать 500 -1000 мб, но не более 1 Гб.

Почему не более 1 Гб? Из-за выше указанных причин по приращению большого объема к файлу возникают задержки обработки транзакций.

К, примеру, из опыта обращения за консультацией, попался сервер с базой данных несколько террабайт и размером файла лога 500 гб, а размер приращения файла лога 5 гб, в файле лога которого были сообщения:

Autogrow of file ‘bd_name_file' in database 'bd_name' took 129356 milliseconds. Consider using ALTER DATABASE to set a smaller FILEGROWTH for this file.

Что это значит?

Что база данных не может прирастить к файлу логов 5 Гб уже 129 секунд, а это более 2 минут.
Т.е 2 минуты сервер не обрабатывает транзакции на изменения в данной базе данных.

Из опыта общения с сотрудниками Майкрософт, они так же давали данную цифру, что объем приращения файлов sqlserverдолжен быть не более 1 Гб.

Некоторые скажут, а как же мне быть, у мне надо большое приращение перед массовой вставкой?

Ответ прост: самим следить за приращением, т.е перед вставкой делать операцию приращения несколько раз небольшими порциями, но лучше сначала сделать резервную копию лога, который очищает (помечает) неактивные и завершенные транзакции , позволяя использовать место в файле лога повторно.

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

Кратко, то журнал транзакций sqlserverобрабатывает через так называемые виртуальные журналы транзакций, количество и размер которых определяет sql server автоматически на основе размер файла приращения и самого размера файла лога. MSSQLServerстремится работать с небольшим количеством виртуальных журналов, но что будет, если размер приращения маленький и приращение выполняется часто – будет много виртуальных журналов. Результат таких неоптимальных настроек можно увидеть при восстановление из резервной копии базы, у которой много виртуальных журналов, после восстановления в логе mssqlserverбудет сообщение вида:

Database db_test2 has more than 1000 virtual log files which is excessive. Too many virtual log files can cause long startup and backup times. Consider shrinking the log and using a different growth increment to reduce the number of virtual log files.

Визуально мы можем увидеть следующую картину – что база данных согласно логам восстановлена на 100 %, но долгое время идут какие процессы внутри базы данных, которые могут занимать время в несколько раз больше самого восстановления бд до 100 % – причина как раз большое количество виртуальных журналов в файле лога(транзакций).

В реальности, это может повлиять и на доступность системы и время восстановления базы данных – т.е recoverytime.

Вы легко это можете проверить:
создайте базу данных с Fullмодель восстановления, размер приращения файла лога сделать 1 мб, создайте полную копию базы данных, создайте таблицу и запустите процесс вставки данных, до тех пор, пока файл лога не достигнет размера 5 гб. После этого сделайте полную копию базы данных и восстановите базу из этой копии. В файле лога вы увидите вышеуказанное сообщение, а визуально, то что прогресс восстановления 100 %, а база все еще не доступна.

У меня на тестовой базе, общее время восстановления было 1 минута 44 секунд, при этом до 100% база данных восстановилась за 20 секунда, 1 минуту 20 секунд база данных была недоступна.

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

Это мы сделали на тестовой базе, в реальности на базе данных с файлом лога(транзакций) более 100 Гб данное время будет занимать довольно много времени, что может оказаться критическим.

Еще, причина, установка приращения не более 1 гб, связанно с безопасностью данных. По умолчанию при приращение к файлу нового объема, ОС должна новое место на диске обнулить, т.е все что там было записать нулями. Если объем приращения довольно большой, то время приращения будет очень заметно. Данную информацию можно посмотреть вMSDNпо теме PerformVolumeMaintenanceTask. Если вы уверены в безопасности вашей информации на диске, то вы можете отключить данную операци, предоставив учетной записи под которой работает MSSQLServerправа PerformVolumeMaintenanceTaskв LocalSecurityPolicyВашего сервера. После этого скорость приращения так же увелисится.

Так же попытайтесь ответить на вопросы:

- Почему у вас происходит приращение файлов данных и файла транзакций(логов)?

- Не делайте ли вы лишние операции урезания файлов(shrink) и если делаете, то зачем?
Может стоит их отменить, а размер файла логов сделать достаточным, чтобы он не рост и его хватало между операциями резервного копирования файла логов?

- Какая модель восстановления у вас стоит на базе данных и нужна ли вам Fullмодель восстановления?

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

Общие выводы:

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

Поэтому проверьте настройки базы данных по пунктам:

- Установите нужную модель восстановления базы данных

- Установите изначально необходимый размер файла логов и файла при создании базы данных, чтобы избежать ненужных операций приращения в дальнейшем
- Устанавливайте размер приращения в мегабайтах, но не более 1 гб приращения и не слишком маленький, во избежание создания большого количества виртуальных журналов. Если файлы данных часто увеличиваются в размерах, делайте приращений в ручном режиме в моменты малой нагрузки и порциями не более 1 гб
- Настройте резервное копирование файла логов(транзакций) для ненужного роста файла логов
- Установите нужные параметры на базе данных model. Это вас избавит проблем от неправильных настроек при создании новых баз данных. Я как правило, ставлю модель восстановления Simple, нужные размеры инициализации файлов бд, а также размеры приращения файлов в мегабайтах.
- Уберите ненужные операции Shrink
- Определитесь с правами PerformVolumeMaintenanceTaskучетной записи sqlserver.

upd, интересный :

Как-то у одного заказчика при настройке зеркалирования на одной базе данных небольшого размера (40 мб), вылетала ошибка "error 1418", что зеркальный или конечная точка доступа недоступна, и соответственно зеркалирование не включалось.

В логах ms sql server-а была ошибка "error 1443"и "error 1474".

На этом же сервере была еще одна база данных, на ней зеркалирование настроено было без проблем. Отсюда было понятно, что проблема в базе данных, хотя может быть и вне установленных обновлениях ms sql server(была версия с sp1 еше)

Как оказалось, проблема была в размере приращения и VLF в файле логов.

Более подробно описано было здесь .

Решил следующим образом:

Установил правильные размеры приращения, сделал шрин файла логов.

После этого зеркалирование было настроено без проблем.

Если у вас есть проблемы c ms sql server, то здесь помогут.

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

Всего хорошего!

↧

Настройка SPN для MS SQL Server - просто

April 6, 2015, 8:56 am

≫ Next: Обслуживание системных баз данных MS SQL Server.

≪ Previous: Настройка параметров приращения баз данных MS SQL Server

Немного теории.
MSSQLServerподдерживает сетевую проверку через следующие типы проверок:

- NTLM

- Kerberos.

NTLMдовольно старый протокол, который еще появился с WindowsNT 4.0, вместо него рекомендуется использовать Kerberos.

Kerberos– это сетевой протокол, позволяющий реализовать надежную проверку подлинности в клиента и сервера в сети, основанный на главном ключе (masterkey) и, так называемых, зашифрованных билетах(tickets).
MSSQLServerподдерживает Kerberosдля следующих сетевых протоколов:
- TCP\IP
- Именованные каналы(Sharedpipes)
- Sharedmemory.

SQLServerподдерживает протокол Kerberosчерез WindowsSecuritySupportProvider(SSPI) если используется Windowsаутификация на сервере.

Если протокол Kerberosне может быть использован, то используется протокол вызов-ответ(NTLM).

Более подробно можно посмотреть на MSDN-е.

ну и практика:

Итак, после установки MSSQLServerнеобходимо зарегистрировать наши SPNдля нашего экземпляра MSSQLServer. SPNрегистрируется при установке, если изначально указали доменную учетную запись.

Первым признаком, что у вас не зарегистрированы SPNдля СУБД, это наличие ошибки в логах sqlserver-а при загрузке сервера:

The SQL Server Network Interface library could not register the Service Principal Name (SPN) [ MSSQLSvc/SRV.domen.net:1433 ] for the SQL Server service. Windows return code: 0x2098, state: 15. Failure to register a SPN might cause integrated authentication to use NTLM instead of Kerberos. This is an informational message. Further action is only required if Kerberos authentication is required by authentication policies and if the SPN has not been manually registered.

The SQL Server Network Interface library could not register the Service Principal Name (SPN) [ MSSQLSvc/ SRV.domen.net ] for the SQL Server service. Windows return code: 0x2098, state: 15. Failure to register a SPN might cause integrated authentication to use NTLM instead of Kerberos. This is an informational message. Further action is only required if Kerberos authentication is required by authentication policies and if the SPN has not been manually registered.

Так во время работы MSSQLServerпериодически появляются ошибки вида:

Cannot generate SSPI context

login failed for user NT Authority Anonymous

Login failed for user ‘NT AUTHORITY\ANONYMOUS LOGON’. (Microsoft SQL Server, Error: 18456)
Login failed for user ‘(null)’
Login failed for user ”
Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.
Linked server connections failing
SSPI handshake failed with error code 0x80090311 while establishing a connection with integrated security; the connection has been closed
SSPI handshake failed with error code 0x80090304 while establishing a connection with integrated security; the connection has been closed
.

Итак, регистрация SPNпроисходит следующим образом:

Способ 1 Через команду «setspn»в командной строке

Синтаксисsetspn –A <SPN> <Account>.

Пример: «setspn –A MSSQLSvc/SRV.domen.net:1433 domen\ServiceAccount»
Или«setspn –A MSSQLSvc/SRV.domen.net:inst1 domen\ServiceAccount»

Регистрировать SPNнеобходимо с указанием порта инстанса, так и на название инстанса. На один экземпляр MSSQLServerнужно регистрировать два SPN с указанием порта и без него.

Для кластера необходимо регистрировать для каждой ноды и общего имени, для AlwaysOnрешения так же для каждого инстанса на нодах плюс прослушиватель(Lisener).

Способ 2 Через консоль ADSI

В консоли ADSIищем нашу техническую учетную запись, открываем ее свойства, находим атрибут «ServiceProncipalName», вводим так же SPNсервера, жмем кнопку «добавить»

Способ 3, наиболее простой и легкий, приложение KerberosConfigurationManager

Данное по скачивается отсюда

После его установки, запускаем, указываем ваш сервер с MSSQLServer, доменную учетную запись

Приложение простое, но удобное. Если есть проблемы с SPNна сервере, то это будет отображено и предложит вам исправить это или сгенерировать cmdкод:

Если все ОК, то будет так:

После этого коннектов к MSSQLServerсвязанные с SPNу вас не должно быть.

Хороших коннектов Вам!.

↧

Обслуживание системных баз данных MS SQL Server.

June 30, 2015, 5:50 am

≫ Next: Приятные «плюшки» при установке MS SQL 2016

≪ Previous: Настройка SPN для MS SQL Server - просто

В MSSQLServerесть несколько системных баз данных:

master - В этой базе данных хранятся все данные системного уровня для экземпляра SQL Server.

Model - Используется в качестве шаблона для всех баз данных, создаваемых в экземпляре SQL Server. Изменение размера, параметров сортировки, модели восстановления и других параметров базы данных model приводит к изменению соответствующих параметров всех баз данных, создаваемых после изменения.
Msdb - Используется агентом SQL Server для планирования предупреждений и задач, так же является хранилищем пакетов SSIS, хранилищем информации по резервному копированию.
tempdb - База данных для временных объектов или для промежуточных результирующих наборов.
Resource- База данных только для чтения. Содержит системные объекты, которые входят в состав SQL Server. Системные объекты физически хранятся в базе данных Resource, но логически отображаются в схеме sys любой базы данных.

Задачей обслуживания данных баз данных является возможность восстановления данных баз данных во время их повреждения, неудачного обновления, выхода из строя оборудования и других возможных проблем.

Типичные задачи обслуживания для системных баз данных (за исключением БД TempDbи resource):

- Создание резервной копии баз данных (с глубиной хранения минимум 7 дней)

- Проверка целостности баз данных инструкцией DBCCCHECKDB

Все эти операции можно завернуть в задание sqlagent-а и выполнять ежедневно, благо объем данных баз данных обычно небольшой, то и операции проходят довольно быстро, а спокойствия прибавляет).

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

Как известно, в базе данных msdbхранится история резервных копий по базам данных. Теперь представим сервер, у которого баз данных более 50, каждые 10-15 минут проходит создание резервное копирование файла транзакций, какой объем будет таблиц с данной информацией?

На одном месте работы, когда я только туда пришел, на сервере было более 70 баз данных, серверу было более 2,5 лет и информация по резервному копированию никогда не чистилась, в итоге объем базы данных msdbбыл более 20 Гб!! А это уже совсем другое время и для создания резервной копии баз данных и для проверки целостности самой базы данных, и лишняя дисковая активность, плюс и время восстановления при аварии, в итоге имеем полно минусов, которые мы можем спокойно решить.

Очистка истории резервного копирования осуществляется через процедуру:

sp_delete_backuphistory [ @oldest_date = ] 'oldest_date'

где

[ @oldest_date = ] 'oldest_date'
Самая ранняя дата, сохраненная в таблицах журнала резервного копирования и восстановления. Аргумент oldest_date имеет тип datetime и не имеет значения по умолчанию
Одну информацию почистили, что еще там хранится?!

Почта. Настроен ли у вас DatabaseMail и происходит ли отсылка писем, а если еще с вложениями письма?

Вся история по нему так же хранится в базе данных msdb. Для очистки данной истории тоже есть системные процедуры:

sysmail_delete_mailitems_sp [ [ @sent_before = ] 'sent_before' ] [ , [ @sent_status = ] 'sent_status' ]

где
[ @sent_before = ] 'sent_before'
Удаляет сообщения электронной почты до даты и времени, указанных аргументом sent_before. Аргумент sent_before имеет тип datetime и не имеет значения по умолчанию. Значение NULL соответствует всем датам.

[ @sent_status = ] 'sent_status'

Удаляет сообщения электронной почты, тип которых указан аргументом sent_status. Аргумент sent_status имеет тип varchar(8) и не имеет значения по умолчанию. Допустимые значения: sent, unsent, retrying и failed. Значение NULL соответствует всем состояниям.

sysmail_delete_log_sp [ [ @logged_before = ] 'logged_before' ] [, [ @event_type = ] 'event_type' ]

где:

[ @logged_before = ] 'logged_before'

Удаляет записи вплоть до даты и времени, указанных в аргументе logged_before. Аргумент logged_before имеет тип datetime и значение по умолчанию NULL. Значение NULL соответствует всем датам.

[ @event_type = ] 'event_type'

Удаляет журнальные записи определенного типа, заданного аргументом event_type. Аргумент event_type имеет тип varchar(15) и не имеет значения по умолчанию. Допустимые записи: success, warning, error и informational. NULL соответствует всем типам событий.

С почтой мы решили, удалил старую информацию, что еще может быть там?

А есть ли у вас SSISпакеты и как часто они запускаются? История по их выполнению хранится в таблице [msdb].[dbo].[sysssislog].

Для очистки ее настроена простая инструкция:

delete

FROM [msdb].[dbo].[sysssislog] where starttime<@dt

Где @dt– дата, записи до которой следует удалить.

После этого, выше указанные операции:

- удаление истории резервного копирования
- очистка журнала DatabaseMail
- очистка таблицы истории [msdb].[dbo].[sysssislog]

Мы заворачиваем в mssqlagentзадание и запускаем пару раз в месяц, и в итоге имеем наши компактные системные базы данных:).

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

Возможно что-то пропустил, так что буду рад комментариям.

Будь аккуратны, держите рабочее место в чистоте!:).

↧

Приятные «плюшки» при установке MS SQL 2016

December 16, 2015, 4:00 am

≫ Next: Еще одна ошибка сборщика данных (Data Collector-а).

≪ Previous: Обслуживание системных баз данных MS SQL Server.

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

Итак, при установке MSSQLServer 2016 редакции (в предыдущей редакции они были не так представлены)

Microsoft SQL Server 2016 (CTP3.1) - 13.0.801.12 (X64 )

Мы получаем:

1 1) Во вкладке указания учетных записей служб MSSQLServer, есть возможность сразу предоставить права «PerformVolumeMaintenance» для учетных записей.

Мелочь, а приятная штука. Что это за права и на что она влияет, можно почитать по данной теме либо здесьлибо погуглив по теме «perform volume maintenance tasks sql server».

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

2) И очень приятная плюшка по настройке MSSQLServer, это связанная с настройкой базы данных Tempdb.

MSSQLServerсам определяет сколько ядер на сервере и ставит соответствующее количество файлов. У меня на виртуальной машине было 2 ядра, поэтому выставилось два файла. В этой же вкладке можно сразу выставить расположение файлов баз данных TempDB, их размер и приращения.

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

Больше плюшек при установке не заметил, если есть еще что-то, то ... это хорошо.

Так же хотелось, чтобы была возможность при установке устанавливать такие параметры как степень и стоимость параллелизма, установки памяти, но текщие плюшки хороши.

Всего хорошего!

↧

Еще одна ошибка сборщика данных (Data Collector-а).

February 18, 2016, 2:55 am

≫ Next: Обновление MS SQL Server в режиме AlwaysOn до новой версии MSSQL.

≪ Previous: Приятные «плюшки» при установке MS SQL 2016

Эта ошибка применима для MSSQLServer 2012, и тянется с SP2 CU6, после установки CU6 на CU5 SP2, перестает работать сбор данных QueryStatistics. Помнится, мы даже кейс в Майкрософте открывали, но решения они не предоставили, сообщив, что это текущий баг, предложив вариант решения, который мы уже на тот момент сделали. Я бы забыл про него, так как уже вышел SP3 для MSSQLServer, но тут снова эта ошибка повторилась после установки SP3 на MSSQLServer2012.

Итак, после установки SP3 на MSSQLServer2012 перестает работать сбор данных QueryStatistics, при этом в журнале ошибки:

«SSIS Error Code DTS_E_PRIMEOUTPUTFAILED. The PrimeOutput method on ODS - Get snapshot of dm_exec_requests returned error code 0xC020902A. The component returned a failure code when the pipeline engine called PrimeOutput(). The meaning of the failure code is defined by the component, but the error is fatal and the pipeline stopped executing. There may be error messages posted before this with more information about the failure.»«"RFS - Read current cache with dm_exec_requests" failed validation and returned validation status "VS_NEEDSNEWMETADATA".»

Решение, как и в прошлый раз, скопировать пакеты с другого сервера с версией до обновления.

Для начала, я скопировал пакет с MSSQLServer 2012 SP2 CU5, но ошибка осталась, затем проверил работу на тестовом сервере, где версия была SP3 CU1, там сборщик данных работал, поэтому решил скопировать пакеты с данного сервера. Так что возможно вам достаточно будет установки CU1 для SP3 и дальше действий не потребуется.

Итак, нужно скопировать два пакета:

QueryActivityCollect

QueryActivityUpload.

Для этого нам нужна служба IntegrationServices, на сервере с которого будем копировать.

Подключаемся к службе, выбираем пакет делаем экспорт:

Указываем наш проблемный сервер, разрешаем перезаписать текущие пакеты.

Так же импорт можно сделать командой, при наличии пакетов в файле:

C:\Users\user>dtutil /FILE "F:\DataCollector_rab\QueryActivityUpload.dtsx" /DestServer "sql-server" /COPY SQL;"Data Collector/QueryActivityUpload"

Так же разрешив перезаписать существующие пакеты.

После этого запускаем сборщик данных QueryStatisticsи смотрим на отсутствие ошибок.

Другую ошибку

Failed to create kernel event for collection set: {2DC02BD6-E230-4C05-8516-4E8C0EF21F95}. Inner Error ------------------>

Я описал здесь.

↧

Обновление MS SQL Server в режиме AlwaysOn до новой версии MSSQL.

March 17, 2016, 9:47 am

≫ Next: DBCC CLONEDATABASE

≪ Previous: Еще одна ошибка сборщика данных (Data Collector-а).

Пришлось обновлять MSSQLServer 2012 до версии 2014, при этом MSSQLServerработало в режиме AlwaysOn. Сложного ничего нет, но есть несколько моментов, которые нужно учитывать при работе и обновлении. Главное, это конечно предварительное тщательное тестирование.

Итак, имеем двух узловой кластер с установленным MSSQLServer 2012 EnterpriseEditionSp2, необходимо обновить до MSSQLServer 2014 Sp1 Cu1.

Подготовительные работы:

Тестирование
Еще раз тестирование
Создание резервных копий системных баз данных (master, msdb)
Еще раз проверяем наличие всех копий баз данных.

Далее на переводим AlwaysOnв режим асинхронный.

Обновляем вторичную реплику AlwaysOnдо 2014 версии, ставим SPи последние CU.

После этого переводим AlwaysOnв синхронный режим, в этом момент синхронизация проходит, но вторичная реплика(так которую мы обновили не доступна для чтения),

Создаем копии бд и делаем Failover.

Активный узел AlwaysOnу нас стал на MSSQLServer2014 и уже в этот момент синхронизация данных на вторичный узел не происходит (режим Suspendу баз данных), т.к там еще младшая версия mssqlserver.

После этого проводим тестирование вашего приложения на узле MSSQLServer2014, проверяем журналы SQLServerна отсутствие ошибок.

Надо понимать, что на этот момент мы можем либо откатиться на данные до начала работ(восстановление из копий), либо на момент Failoverна SQL2014. Необходимо будет просто перевести базы данных в режим доступный для изменения на сервере с 2012 версией командой

Restore Database DB with recovery

После того как все ОК, мы можем обновлять второй узел до MSSQLServer2014, ставить SP, CU.

Далее переводим базы данных группы доступности AlwaysOnиз режима “Suspend” в режим “Resume”, т.е. возобновляем передачу данных. После некоторого времени произойдет синхронизация узлов MSSQLServer, затем восстанавливаем автоматический Failover.

Все, наш MSSQLServerв режиме AlwaysOnобновлен до нового выпуска.

С чем мы столкнулись:

1) У одной базы данных слетело свойство «Trustworthy». Это свойство было включено на нескольких базах данных, но у одной оно слетело. Узнали только по ошибке, когда выполнялся код, которому необходимо было данной свойство.

2) Слетела affinityдля процессоров. На сервере было 80 ядер, mssqlserver-у было выделено 75 ядер, в итоге после обновления, он был привязан к половине -40 ядер. Выяснили только тогда, когда появилась нагрузка на CPU к 90 %.

3) Перестала работать почтовая рассылка с одним параметром (@query_no_truncate = 1). В MSSQLServer2012 она работала, в MSSQLServer2014 она перестала работать. Это уже огрехи тестирования, и насколько я понял, есть такой баг в sql 2014(Открыли кейс в Майкрософте, но решения пока нет)

Отсюда выводы, перед обновлением сохраните все свойства сервера и баз данных, после обновления их проверьте.

Вот вроде все, что делали и с чем встретились.

Хорошего обновления.

↧

DBCC CLONEDATABASE

July 25, 2016, 7:29 am

≫ Next: Есть AlwaysOn. Есть причина перейти на MS SQL Server 2016

≪ Previous: Обновление MS SQL Server в режиме AlwaysOn до новой версии MSSQL.

В MSSQLServer2014 после выхода SP2 появилась новая команда DBCC, команда

DBCC CLONEDATABASE

Данная команда создает новую базу данных с содержанием схему всех объектов и статистики исходной базы данных.

Более подробно это описано в kb3177838.

Там же описано более подробное назначение данной команды:

«Команда поддержки Майкрософт может вас попросить создать клон вашей базы данных данной команды для исследования проблемы производительности связанная с оптимизатором запросов.»

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

Что делает данная команда по шагам:

- создает новую базу данных согласно базе данных model(размер файлов и их приращение)

- создает внутренний моментальный снимок исходной базы данных

- копируется системные и пользовательские объекты из исходной базы данных в новую базу данных

- Копирует данные статистики из исходной базы данныхбез самих данных в базе (в документации указана статистика индексов, но на самом деле всю статистику в базе).

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

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

Синтаксис команды:

Он довольно простой

DBCC CLONEDATABASE (source_database_name, target_database_name)

Кто сможет выполнить данную команду - пользователи сервера с правами sysadmins.

Пример выполнения:

Есть база данных db1, в ней таблица с данными, на таблице созданы 2 индекса, а также дополнительная статистика без индекса.

После выполнения команды

DBCC CLONEDATABASE(db1,db1_clone)

Создается база данных «db1_clone» в статусе Read-Only.

Размещение файлов, там же где и исходная

DB_Name physical_name

db1 C:\data\db1.mdf

db1 C:\data\db1_log.ldf

db1_clone C:\data\db1_1992956780.mdf

db1_clone C:\data\db1_log_1697443590.ldf

к файлам дописывается случайное числовое значение.

А вот физически параметры файлов бд взяты от model

А теперь к внутренностям клонированной базы данных:

В ней есть все объекты исходной базы данных:

Но без данных:

Но зато осталась дата обновления статистики и ее распределение в таблице:

Что и нужно для оптимизатора запросов при построение плана запроса.

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

Еще раз, данная команда появилась в MSSQL2014 SP2, в Microsoft SQLServer 2016(RTM)- 13.0.1601.5(X64)

данной команды пока нет, при выполнении будет ошибка

Msg 2526, Level 16, State 3, Line 1

Incorrect DBCC statement. Check the documentation for the correct DBCC syntax and options.

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

Database cloning for 'DB1' has started with target as 'DB1_clone'.

Msg 213, Level 16, State 1, Line 1

Column name or number of supplied values does not match table definition.

А так неплохое средство для диагностики поведения запросов на промышленной среде со временем и от зависимости данных в таблицах. В MSSQL 2016 есть QUERYSTORE, которое так же помогает отслеживает поведение запросов в течение рабочего дня, но это уже другая история…

↧

Есть AlwaysOn. Есть причина перейти на MS SQL Server 2016

September 9, 2016, 6:12 am

≫ Next: In-Memory tables. Таблицы в памяти - просто.

≪ Previous: DBCC CLONEDATABASE

AlwaysОn, пришедшая в MS SQLServerс версии 2012, очень хорошая технология, которая позволяет реализовать высокую доступность баз данных, а так же позволяет частично реализовать балансировку запросов к СУБД, правда только запросов на чтение, но и это уже хорошо.

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

Пойдем далее, администраторы настроили AlwaysOnи думают, что все будет хорошо при проблемах. Но нужно понимать, при каких проблемах будет все хорошо, а при некоторых проблемах – вы не узнаете, что у вас есть проблемы с доступностью ваших данных и необходимо вмешательство администратора.

Итак, простой, пример:

Имеем MicrosoftSQLServer 2014 (SP2) 12.0.5000 в конфигурации AlwaysOnс двумя узлами. Настроен автоматический Failover.

selectreplica_server_name ,failover_mode_desc

fromsys.availability_replicas

where group_id=(select group_id fromsys.availability_groups wherename='Group_3')

select t2.replica_server_name,role_desc,synchronization_health_desc from

sys.dm_hadr_availability_replica_states t1

innerjoinsys.availability_replicas t2 ont1.replica_id =t2.replica_id

where t1.group_id =(select group_id fromsys.availability_groups where name='Group_3')

Есть база данных, файлы которой расположены на диске E:\, к примеру, статус в рабочем состоянии должен быть ONLINE

select name,state_desc fromsys.databaseswhere name='AOGroup3'

name state_desc

AOGroup3 ONLINE

А давайте форматнем диск, к примеру, сделаем имитацию ухода диска в Offline

Что мы видим, База стала в состоянии RECOVERY_PENDING

а в журнале ошибочка :

Message
Unable to open the physical file "E:\data\AOGroup3.mdf". Operating system error 3: "3(The system cannot find the path specified.)".

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

Это один из минусов технологии AlwaysOn, что происходит внутри базы данных процесс RHS, который проверяет кластерные сервисы кластера Windowsне отслеживает, у него только есть проверки на уровне службы MSSQLServer: она работает и доступна, нет внутренних ошибок.

Но все меняется, когда пришел MSSQLServer2016 J.

Теперь, при создании группы доступности, необходимо указать параметр “DatabaseLevelHeathDetection”, (я работаю на Microsoft SQL Server 2016 (RTM-CU1)(KB3164674) - 13.0.2149.0):

Либо, кто любит T-SQL:

CREATEAVAILABILITYGROUP [AOGroupDisk]
WITH (AUTOMATED_BACKUP_PREFERENCE=NONE,DB_FAILOVER =ON,….)

Состояние нашей группы все ОК:

В группу я добавил тестовую бд FailoverTest2016.

Далее, еще раз форматнем наш диск E:\, где расположена наша база данных.

Давайте обратимся и сделаем запрос к нашей базе данных, результат:

The database FailoverTest2016 is not accessible.

Смотрим статус нашей группы доступности и базы данных:

selectreplica_server_name ,failover_mode_desc

fromsys.availability_replicas

wheregroup_id=(select group_id fromsys.availability_groups where name='AOGroupDisk')

select t2.replica_server_name,role_desc,synchronization_health_desc from

sys.dm_hadr_availability_replica_states t1

innerjoinsys.availability_replicas t2 on t1.replica_id =t2.replica_id

where t1.group_id =(select group_id fromsys.availability_groups where name='AOGroupDisk')

select name,state_desc fromsys.databaseswhere name='FailoverTest2016'

Что мы видим: произошел Failover и группа доступности переехала!!!

В журнале MSSQLServerмы имеем:

Error: 41653, Severity: 21, State: 1.
Message
Database 'FailoverTest2016' encountered an error (error type: 2 'DB_SHUTDOWN') causing failure of the availability group 'AOGroupDisk'. Refer to the SQL Server error log for information about the errors that were encountered. If this condition persists, contact the system administrator.

Кстати, надеюсь, алерты на Severity: 21у всех настроены)?!.

Далее, уже при обращении к данной базе, мы получаем информации со второго узла, то есть пользователи работают и счастливы.

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

В любом случае мы имеем еще более прекрасное средство высокой доступности баз данных реализованные на MicrosoftSQLServer.

Всем высоко доступных баз данных, Пока!

p.s: Если вам нужен администратор MS SQL Server- временно, постоянно,удаленно, на проект или просто сделать аудит, можете обратиться здесь или в комментариях.

↧

In-Memory tables. Таблицы в памяти - просто.

October 11, 2016, 8:19 am

≫ Next: Настройка репликации из MS SQL Server в DB2

≪ Previous: Есть AlwaysOn. Есть причина перейти на MS SQL Server 2016

Начиная с MSSQLServer 2014 Microsoftпредоставила к использованию технологию таблиц In-Memory, в 2016 данная технология получила продолжения и улучшения. Технология подразумевает, что определяется таблица, которая оптимизирована для нахождения в памяти сервера, что позволяет повысить производительность обработки данных в данной таблице, за счет быстроты работы данных в памяти и исключения задержек, связанные с вводом\выводом (хотя здесь есть свои нюансы). Постараюсь описать все нюансы и возможности в одной статье, чтобы не искать по разным страницам msdn, немного много, но зато все в одном.

Итак, требования

Чтобы вы могли в MSSQLServerиспользовать In-Memoryтаблицы, то должны проверить следующие требования:

- 64 – разрядный MS SQL Server 2014и выше редакции Enterprise, Developer или Evaluation

- достаточное объем самой оперативной памяти для данных и версионности строк, так же это зависит о нагрузки на использования таблиц в памяти

- Необходимо включить быструю инициализацию файлов, т.е предоставить учетной записи MSSQLServerправо на «Perform volume maintenance tasks» в локальных политиках сервера. Это требования желательное, в противном случае может сыграть отрицательно на производительность.

Немного теории.

Основным хранилищем для таблиц In-Memoryявляется основная память, т.е вся память находится в памяти. Строки записываются и считываются только из памяти. Для отказоустойчивости данный таблиц дублируются на диск, но можно настроить, чтобы таблица была только в памяти, это не создает дополнительной нагрузки на диск, но и все данные в таблицах хранятся до перезагрузки сервера. Все операции с таблицами транзакционны и соответствуют классификации ACID(atomic, consistent, isolated, durable) . Транзакционность выполняется за счет версионность строк, т.е. каждая изменённая строка создает новую версию строки, к которой будет дальнейшее обращение. Это позволяет практически сократить блокировки в таблицах.

Одновременно с появлением In-Memoryтаблиц, появился новый тип индексов –HASHиндексы. Создание HASH-индекса осуществляется с помощью внутренней hashфункции, которая является единственной для всего mssqlserverи является детерминированной, из этого следует, что несколько значений ключей индекса могут быть связаны с одним сопоставление хеш индекса, появляется конфликт хеша. Большое число конфликтов может отрицательно связаться на операции чтения. Использование hashиндексов нужно быть аккуратным, они используются только когда в предикате условия указаны все поля hashиндекса. К примеру: создали hashиндекс на Имя, Фамилию, а в запросе используется только Фамилия, то наш Hashиндекс работать не будет, нужно указать в Запросе и имя и Фамилию. Так же в HASHиндексах запрещен поиск по диапазону.

На таблицах In-Memoryмогут быть определены индексы как кластерные, не кластерные, так и новые HASHиндексы одновременно, возможно несколько HASHиндексов. Единственное замечание: все индексы создаются при создании таблицы инструкцией CREATETABLE, далее новые индексы создаются только через пересоздание таблицы.

Пример вполне можно создать данную таблицу:

CREATETABLE [dbo].[TblInMem_Index]

(

[id] [int] NOTNULL,

[val1] [nchar](36)COLLATE Cyrillic_General_BIN2 notNULL,

[val2] [nchar](36)COLLATE Cyrillic_General_BIN2 NOTNULL,

INDEX[Hass_ind] NONCLUSTEREDHASH

(

[val2]

)WITH (BUCKET_COUNT= 1048576),

INDEX [idx2] NONCLUSTERED

(

[val1] ASC,

[val2] ASC

PRIMARYKEYNONCLUSTERED

(

[id] ASC

)

)WITH (MEMORY_OPTIMIZED=ON,DURABILITY= SCHEMA_AND_DATA )

В которой мы определили три индекса:

Кластерные по полю Id

Не кластерный [idx2]

Hash индекс [Hass_ind].

Так же существуют два вида таблиц: таблицы оптимизированные с параметром DURABILITY=SCHEMA_AND_DATA – это таблицы, которые размещены в памяти, но и существуют на диске, второй тип таблиц это таблицы с параметром DURABILITY= SCHEMA_ONLY, это значит , что данные находятся в памяти и доступны только до перезагрузки сервера, так же эти данные не будут доступны и при создание резервной копии, с параметром DURABILITY=SCHEMA_AND_DATA данные в таблице In-Memoryбудут доступны после восстановления из резервной копии.

Параметр WITH(MEMORY_OPTIMIZED=ON,DURABILITY= SCHEMA_ONLY)определяется для всей таблицы: вне зависимо есть ли в ней новые HASHиндексы или кластерные, при значении параметра DURABILITY=SCHEMA_ONLY- данные хранятся до перезагрузки ms sql server.

Обращение к таблицам In-Memoryпроисходит с помощью стандартных инструкций T-SQLс явным указанием уровня изоляции SNAPSHOT, REPETABLEREADили SERIALIZABLEили помощью так называемых процедур скомпилированные в собственном коде (NativeCompiledStoredProcedures). В обращение к таблицам In-Memoryесть много ограничений, следует это учитывать.

Процедуры, скомпилированные в собственном коде (NativeCompiledStoredProcedures) –это наиболее быстрый доступ к таблицам In-Memory, но и имеющий много особенностей. На «физическом» уровне после создания NativeCompiledпроцедуры мы имеем dllбиблиотеку, которая компилируется один раз при создании или при рестарте сервера.

Особенности NativeCompiledпроцедур:

- код процедуры определяется разово, далее ее можно изменить только через пересоздание

- внутри процедуры транзакция определяется как BEGIN ATOMIC, что определяет свои требования

- объекты, на которые ссылается процедура, не могут быть изменены при наличие данных процедур

- нельзя просмотреть актуальный план данных процедур

- нельзя получить статистику выполнения данных процедур

- для соединения таблиц внутри хранимой процедуры используется только NETEDLOOP

- не используется параллелизм

- план выполнения NativeCompiledпроцедуры определяется в момент ее создания, в MSSQLServer2016 для перекомпиляции процедуры можно использовать процедуру sp_recompile

Пример создания NativeCompiledпроцедурs:

createprocedure [dbo].[InsertIntoMemoryTable](@i int)

withnative_compilation,schemabinding,executeasowner

beginatomicwith (transactionisolationlevel=snapshot,language=N'English')

declare @id int=convert(int,RAND()*1000000000)

declare @val1 nchar(36)

set @val1=convert(nvarchar(36),newid())COLLATECyrillic_General_BIN2

declare @val2 nchar(36)

set @val2='text'+convert(nchar(8),@i)COLLATE Cyrillic_General_BIN2

insertinto [dbo].[TblInMem1]

values (@id,@val1,@val2)

end

withnative_compilation,schemabinding,executeasowner- При определение данной процедуры обязательно

beginatomicwith (transactionisolationlevel=snapshot,language=N'English') – так же обязательные параметры, требования ATOMIC

После создания данной процедуры в каталоге баз данных будет создана папка xtpдалее папка номер базы данных, внутри которой будут файлы нашей процедуры:

xtp_t_9_1973582069_183184666479020.xml

xtp_t_9_2037582297_183184668414697.c

xtp_t_9_2037582297_183184668414697.dll- сама dllбиблиотека

xtp_t_9_2037582297_183184668414697.obj

xtp_t_9_2037582297_183184668414697.out

xtp_t_9_2037582297_183184668414697.pdb

Содержимое которых вы можете посмотреть, оно связано с определением процедуры на коде C. Файлы вы можете изменить\удалить, но mssqlserverпридется их заново создать, что потребует время при вызове процедуры.

В имени файла выше 9 это номер базы данных, 2037582297 – номер объекта из sysobjects.

Кстати, выше процедура будет работать только в MSSQLServer 2016, т.к в MSSQL Server 2014 текстовые поля все должны быть в UNICODформате. В MSSQLServer 2014 нужно немного поменять определение

set @val2=N'text'+convert(nchar(8),@i)COLLATECyrillic_General_BIN2

иначе будет ошибка:

Msg 12329, Level 16, State 103, Procedure InsertIntoMemoryTable1, Line 21

The data types char(n) and varchar(n) using a collation that has a code page other than 1252 are not supported with natively compiled stored procedures.

Ограничение при работе с таблицами In-Memory:

Ниже описаны наиболее явные ограничения в MSSQLServerна таблицы In-Memory, которые чаще всего мы привыкли использовать при обычных diskтаблицах. Приведена только часть ограничений, полные ограничения можно изучить в msdn.

Общие ограничения для MSSQL 2014 и MSSQL 2016:

Для баз данных с таблицами In-Memoryзапрещены свойство AUTO_CLOSE

Запрещена операция CREATE DATABASE с параметром ATTACHE_REBUILD_LOG

Запрещена операция создания DATABASESNAPSHOT

Операции проверки целостности DBCCCHECKDB, CHECKTABLEпропускают таблицы In-Memory

Не поддерживаются межбазовые запросы и транзакции, а также обращения со связанными серверами

Не поддерживаются вычисляемые столбцы в таблицах In-Memory

Не поддерживается репликация для таблиц In-Memory

Не поддерживаются столбцы SPARSE

Не поддерживаются операции TRUNCATE

Не поддерживается сжатие, секционирование таблиц

Не поддерживается репликация, зеркалирование

В NativeCompiledпроцедурах Функции MIN и MAX не поддерживаются для типов nvarchar, char, varchar, varchar, varbinary и binary

В NativeCompiledпроцедурах DISTINCT не поддерживается в предложении ORDER BY

В NativeCompiledпроцедурах не поддерживаются WITH TIES и PERCENT в предложении TOP

В NativeCompiledпроцедурах не поддерживается многостроковая вставка через INSERT.

В NativeCompiledпроцедурах не поддерживается SELECTINTO

В NativeCompiledпроцедурах не поддерживается инструкция CASE

Таблицы In-Memoryс SCHEMA_ONLYвбазах данных в группе доступности AlwaysOnбудут пустыми.

Не поддерживаются типы данных: datetimeoffset, geography, geometry, hierarchyid, rowversion,xml, sql_variant, определяемые пользователем типы

Операция MERGE только в качестве назначения

Доступ из модулей CLR запрещен к таблицам In-Memory

Табличные подсказки

Фильтруемые индексы не поддерживаются

Не поддерживаются курсоры в Native Compiled процедурах

Ограничения MSSQL 2014

все ограничения выше +

Использование только UNICODтипов данных

Использование Collation _Binдля символьных полей индексов

Ограничение общего объем всех таблиц в памяти не должен превышать 250 Гб

Не авто обновляется статистика для таблиц In-Memory, необходимо вручную обновлять

Не поддерживаются LOB объекты

Пример создания таблиц.

Для начала нужно иметь базу данных, далее в базе данных создается файловая группы базы данных для таблиц In-Memory

USE [master]

ALTERDATABASE [INMemDB] ADDFILEGROUP [InMemory_filegroup] CONTAINS MEMORY_OPTIMIZED_DATA

Добавляем новый файл группы в нашу файловую группу для таблиц In-Memory

USE [master]

ALTERDATABASE [INMemDB] ADDFILE

( NAME =N'InMemoryFile',FILENAME=N'C:\Data\InMemory2014\InMemoryFile')

TOFILEGROUP [InMemory_filegroup]

В этот момент в указанном каталоге создается каталог InMemoryFile с содержимым аналогично каталогу FileStream:

Далее создаем нашу таблицу:

CREATETABLE [dbo].TblInMem

(

[id] [int] NOTNULL,

[val1] [char](20)NULL,

[val2] [char](20)NOTNULL,

PRIMARYKEYNONCLUSTEREDHASH

(

[id],

[val2]

)WITH (BUCKET_COUNT=1000000)

)

WITH (MEMORY_OPTIMIZED=ON,DURABILITY= SCHEMA_AND_DATA);

Создали, ОК, далее. СТОП далее, нужно уточнить, что выше создалась таблица в MSSQLServer2016, в 2014 она не создается, т.к в 2014 в таблицах In-Memoryвозможно использовать только UNICODEтипы данных

В 2014 создаем таблицу:

CREATETABLE [dbo].[TblInMem1]

(

[id] [int] NOTNULL,

[val1] [nchar](36)COLLATECyrillic_General_CI_AS NULL,

[val2] [nchar](36)COLLATECyrillic_General_BIN2 NOTNULL,

PRIMARYKEYNONCLUSTEREDHASH

(

[id],[val2]

)WITH (BUCKET_COUNT= 1048576)

)WITH (MEMORY_OPTIMIZED=ON,DURABILITY= SCHEMA_AND_DATA )

Таблица определена с одним hashиндексом.

Немного об синтаксисе создания таблицы:

PRIMARYKEYNONCLUSTEREDHASH – создается не кластерный HASH индекс, HASH индекс поддерживается только для In-Memory таблиц, без него мы не сможем создать нашу таблицу в памяти, обязательный параметр.

WITH(BUCKET_COUNT=1000000) – так же обязательный параметр при создание HASHиндексов, указывается так называемые количество контейнеров для hashиндексов, которое желательно должно быть в 2 раза более уникальных значений нашего индекса. Если выбрано неоптимальное значение то, может привести к деградации производительности при обращении к данной таблице.

Далее сделаем тест на загрузку данных.

Я сделал несколько простых тестов на вставку:

setnocounton

declare @start datetime2(7)=SYSDATETIME()

declare @stop datetime2(7)

select @start

declare @i int=0

while @i<1000000

begin

begintry

insertinto [dbo].[TblInMem]

values (convert(int,RAND()*1000000000),convert(varchar(36),newid()),'text'+convert(nchar(8),@i))

set @i=@i+1

endtry

begincatch

print @i

endcatch

end

set @stop =SYSDATETIME()

select @stop

selectDATEDIFF(ss,@start,@stop)

setnocountoff

Использовал таблицы, созданные выше в пример создания таблицы,

CREATETABLE [dbo].[TblInMem1]

(

[id] [int] NOTNULL,

[val1] [nchar](36)COLLATE Cyrillic_General_CI_AS NULL,

[val2] [nchar](36)COLLATE Cyrillic_General_BIN2 NOTNULL,

PRIMARYKEYNONCLUSTEREDHASH

(

[id],[val2]

)WITH (BUCKET_COUNT= 1048576)

)WITH (MEMORY_OPTIMIZED=ON,DURABILITY= SCHEMA_AND_DATA )

структура во всех тестах была одинакова, за исключением менял параметр DURABILITY, а так же изменял поля в MSSQLServer2016.

Результаты тестирования:

Parameters of Test	MS SQL Server 2014	average val, sec	MS SQL Server 2016	average val, sec
Table with DURABILITY = SCHEMA_AND_DATA	585/584/584/588	585,25	626/637/610/616	622,25
Table with DURABILITY = SCHEMA_AND_DATA with no UNICODE column, BIN			610/604/585/606/	601,25
Table with DURABILITY = SCHEMA_AND_DATA , UNICODE, не BIN поле			588/604/614/617	605,75
Table with DURABILITY = SCHEMA_ONLY	38/37/39	38	47/55/52	51,3
Table with DURABILITY = SCHEMA_ONLY with no UNICODE column, BIN			44/46/49	46,3
Table with DURABILITY = SCHEMA_ONLY , UNICODE, не BIN поле			53/50/52	51,7
Native procedure with DURABILITY = SCHEMA_AND_DATA	560/553/559	557,3	564/584/581	576,3
Native procedure with DURABILITY= SCHEMA_ONLY	28/26/30/	28	38/38/37	37,7
Disk table	614/605/596	605	633/637/634	634,67

По результатам тестирования:

Наиболее интересные результаты выделил желтым цветом. В целом вставка в In-Memoryтаблиц смотрится хорошо, можно заметить, что в MSSQLServer 2014 она даже быстрее чем в 2016, видно из-за того, что в 2016 было снято множество ограничений, что немного повлияло на скорость. По таблице заметен выигрыш NativeCompiledпроцедур.

Тесты «TablewithDURABILITY = SCHEMA_AND_DATA, UNICODE, не BINполе» -это тестирование в MSSQLServer 2016 с полями таблицы не UNICODEи не BINcollationвидно, что они не сильно влияют на скорость, но заметно что не BINи не UNICODEполей и при DURABILITY = SCHEMA_AND_DATAданные чуть ниже, возможно из-за меньших типов данных при хранении.

По результатам TablewithDURABILITY = SCHEMA_AND_DATAи Disktableрезультаты не сильно отличаются в пользу In-memoryтаблиц. У меня disktableтаблицы и файлы файловой группы In-Memoryрасположены на одних дисках, так что все упирается в них. На практике, для данных таблиц In-Memoryжелательно выделять отдельный диск, а лучше SSDдиск, тогда производительность таблиц In-Memoryбудет заметна. К примеру, у вас есть база данных 1 тб, вы покупаете отдельный диски 120 Гб , строите Raidмассив, и располагаете на них вашу файловую группу In-Memory, то в данном случае мы получим довольно хороший выигрыш.

Тесты запускались больше количество раз, чем указано выше в таблице, все результаты были в этих границах.

Наблюдение таблиц In-Memory

Ниже несколько запрос по получению информации по таблицам In-Memoryна вашем сервере:

Получение общей информации, сколько таблицы занимают в памяти:

--получение общей информации, объем таблиц в памяти

SELECTtype

,name

,pages_kb/1024 AS pages_MB

FROMsys.dm_os_memory_clerksWHEREtypeLIKE'%xtp%'

В общем, объекты, связанные с таблицами In-Memory, выделяются префиксов xtp.

По таблицам

---распределение в памяти по таблицах

SELECTobject_name(t.object_id)AS [Table Name]

,memory_allocated_for_table_kb

,memory_allocated_for_indexes_kb

FROMsys.dm_db_xtp_table_memory_stats dms JOINsys.tables t

ON dms.object_id=t.object_id

WHERE t.type='U'

Размер файлов таблиц In-Memory на диске:

--размер файлов на диске, размер папки InMemoryFile на диске

SELECTSUM(df.size)* 8 / 1024 AS [On-disk size in MB]

FROMsys.filegroups f JOINsys.database_files df

ON f.data_space_id=df.data_space_id

WHERE f.type=N'FX'

Потипамфайлов

SELECTstate_desc

, file_type_desc

,COUNT(*)AS [count]

,SUM(CASE

WHENstate= 5 AND file_type=0 THEN 128*1024*1024

WHENstate= 5 AND file_type=1 THEN 8*1024*1024

WHENstateIN(6,7)THEN 68*1024*1024

ELSE file_size_in_bytes

END)/ 1024 / 1024 AS [on-disk size MB]

FROMsys.dm_db_xtp_checkpoint_files

GROUPBYstate, state_desc, file_type, file_type_desc

ORDERBYstate, file_type

Для диагностики таблиц In-Memoryв плане достаточности параметра BUCKET_COUNT, есть запрос:

SELECTobject_name(hs.object_id)AS'object name',

i.name as'index name',

hs.total_bucket_count,

hs.empty_bucket_count,

floor((cast(empty_bucket_count asfloat)/total_bucket_count)* 100)AS'empty_bucket_percent',

hs.avg_chain_length,

hs.max_chain_length

FROMsys.dm_db_xtp_hash_index_stats AS hs

JOINsys.indexesAS i ON hs.object_id=i.object_idAND hs.index_id=i.index_id

Необходимо обратить на значения:

empty_bucket_count – указывает число пустых контейнеров в hash индексе.

Меньше 10, то число значение BUCKET_COUNT слишком малое, идеально значение более 33 и более.

avg_chain_length –указывает среднюю длину цепочек в hashконтейнерах. Если значение avg_chain_length больше 10 и empty_bucket_percent больше 10, то, вероятнее всего, имеется много одинаковых значений ключей индекса и использование некластеризованного индекса будет более целесообразным. Средняя длина цепочки, равная 1, является оптимальной.

Заключение.

Технология In-Memoryдовольно полезное дополнение, которое позволяет получить огромную производительность в базах данных на MSSQLServer. Но, как и везде, для этого нужно правильно организовать и построить вашу базу данных, просто взять и включить опцию In-Memoryна ваших таблицах недостаточно, в некоторых случаях мы можем вообще получить деградацию.

Необходим глубокий анализ структуры таблиц и данных, запросов, а может и архитектуры ваших приложений. Для новых систем и приложений, лучше сразу планировать поддержку данной технологии, это будет легче чем потом пытаться подстроить базу под In-Memoryтехнологию, тем более в MSSQLServer 2016 снято много ограничений.

Так что тестируйте, используйте, улучшайте.

↧

Настройка репликации из MS SQL Server в DB2

November 25, 2016, 8:21 am

≫ Next: Что нам скажет SQL Server ERRORLOG?!

≪ Previous: In-Memory tables. Таблицы в памяти - просто.

Недавно была задача настроить MSSQLServerрепликацию на сервер IBMDB2 AS/400, задача получилась непростая и интересная. В процессе настройки репликации было много проблем, описание которых в Интернете было довольно мало. Ниже постараюсь описать проблемы и шаги настройки данной репликации:

Настройку репликации можно разделить на несколько шагов:

1) Установка драйвера провайдера Microsoft OLE DB Provider for DB2

2) Настройки на стороне DB2

3) Получить строку подключения к DB2 AS/400

4) Настройка самой репликации и ее проверка

Имеем:

1) Сервер MS SQL Server 2014 12.0.5000.0 Enterprise Edition

2) Таблицу для репликации с первичным ключом

3) Подписчик в виде сервера IBM DB2 AS/400

Начинаем:

1) Скачиваем и устанавливаем драйвера DB2OLEDB

К сожалению, найти их в Интернет была проблем, ссылка в поиске вела на сайт Microsofthttps://www.microsoft.com/en-us/download/details.aspx?id=29100но там была документации по ним, да и многие ссылки в msdn-е были битые и вели на несуществующие страницы. Драйвера я нашел у себя на сервере, когда –то давно скаченные. Если найдете где они сейчас, сообщите, укажу адрес.

У меня они были версии V3.0

Установка простая, ничего сложного.

После установки имеем кроме провайдера в MSSQLServer, еще и приложение DataAccessTool, которое нам очень пригодится.

2) Настройки на стороне DB2

Тут работы администраторы DB2 AS/400, что он должен выполнить:

Создать отдельно выделенного пользователя и указать ему схему по умолчанию.

Указать для библиотеки, что данные логируются, или проще говоря включить журналирование для объектов библиотеки пользователя в DB2 AS/400. Без этого репликация не поднимется. Данный параметр был получен случайно, т.к для первоначального пользователя журналирование было отключено и были ошибки.

3) Получаем строку подключения к DB2 AS/400.

После установки выше драйверов имеем приложение DataAccessTool, с помощью данного приложения получаем строку подключения:

Создаем новый Data Source

Выбираем платформу DB2, у нас DB2/AS400

Далее имя AS400 и порт подключения AS/400:

Далее специфические настройки коннекта, необходимо указать выделенные поля, они обязательны:

Данные параметры необходимо получать от администраторов DB2 AS/400, к сожалению, у меня не все администраторы точно могли сказать, что нужно указать.

“Initialcatalog” я указал так же как у нас называется сервер

“PackageCollection” и “Defaultschema” данные параметры соответствуют понятию названию библиотеки пользователя в DB2 AS/400.

В следующем окне выбирается кодировка, - у себя оставил по умолчанию.

В настройках безопасности, как обычно, указываем пользователя и пароль к DB2 AS/400:

В следующем окне – без изменений.

Проверяем настройки и доходим сохранения информации по коннекту:

И после Finish. Информация сохраняется, но не проверяется. После этого необходимо выполнить проверку подключения и проверку тестового запроса:

Должны быть результаты:

а на тестовый запрос должны отобразиться элементы библиотеки

Если этого нет или другие сообщения, необходимо добиваться данного результата, возможно необходимы права.

После этого мы получаем нашу строку коннекта

Копируем и используем далее.

4) Настройка самой репликации и ее проверка

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

Итак, настройка репликации как обычно
,

Предварительно у вас должен быть установлен компонент репликации MSSQLServerи активирован Distributor, я использовал Distributor-а на том же сервере, где и источник данных.

Делать удобнее Wizard-ом, далее можно получить скрипт и его поправить при необходимости:

Выбираем нашу базу данных, где находятся таблицы для репликации, выбираем «Transactionpublication», выбираем таблицу, одну или несколько:

И выбираем «ArticleProperties» для выделенной таблицы:

Обратите внимание на то, как и что я указал:

Поле «Destinationobjectname» указал имя нашей таблицы с БОЛЬШОЙ буквы – это очень важно, что будет если оставить по умолчанию, опишу ниже. В MSSQLServerтаблица определена с маленькой буквы, как видите

Обязательно указать владельца назначения «Destinationobjectowner” и тоже с большой буквы, мы ее определили для пользователя в п. 2 настоящего руководства. В DB2 as/400под этим подразумевается библиотека пользователя.

Поле «Actionifnameisinuse» я указал оставить существующую без изменений, у меня подразумевает не трогать таблицу в DB2 AS/400 если она там есть. Другие значения можно выбирать, с ними репликация так же работала.

Так же я отключил создание индексов и уникального ключа, все это можно будет создать на таблице вручную. Почему, чуть ниже укажу.

Инструкции доставки данных – тестировал только на указанных в скриншоте, другие способы не получилось проверить:

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

Создаем подписчика Non-SQLподписчика:

Указываем произвольно имя источника:

В окне «DistributionAgentSecurity» необходимо указать учетную запись с паролем

И самое, главное строку подключения к DB2 AS/400, полученная в п. 3, ее вставляем без изменений. У себя на стенде я скопировал и с учетной запись и паролем в строке

Далее, необходимо быть аккуратным в параметрах инициализации:

У меня выбрано, что я не инициализирую репликацию, почему объясню ниже. Если у вас таблица небольшая и таблица не существует на подписчике, то инициализация нужна.

После этого подписчик создан.

Если после создания репликации «Монитор репликации» показывает статус ОК, это не значит, что все с репликацией хорошо.

После создания репликация обязательно сделайте тестовые транзакции: Insert\Update\Delete. Если транзакции успешно доставляются, то только тогда можно сказать, что репликация из MSSQLServerв DB2 AS/400 РАБОТАЕТ!

А теперь самое интересное, с чем пришлось столкнуться и решать методом тестирования:

НЮАНСЫ:

1) Почему использовать большие буквы:

Есть три таблицы определения:

Самым правильным и удобным для DB2 AS/400 будет таблица 2, где указано имя таблицы с большой таблицы и столбцы с большой таблицы.

Для таблицы 3, где имя таблицы с маленькой буквы, нужно в свойствах таблицы репликации указать таблицу с большой буквы, тогда все работать будет штатно.

Таблицы 1, не будет работать в репликации.

А что будет:

Если мы не укажем имя таблицы у подписчика с большой буквы, на DB2 создастся таблица не совсем наша, а таблица у которой имя и название столбцов будут заключены в кавычки.

К примеру:

на MSSQLServerтаблица tblна DB2 as/400 она будет “tbl”

поля в таблице id, valна DB2 AS/400 они будут: “id”, “val”.

Т.е это совсем другие таблицы, вы это можете даже поменять в скриптах инициализации, но таблицы будут именно такими.

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

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

Эти параметры были получены экспериментально, натолкнул ответ в форуме, но немножко по другому вопросу.

2) Указать пользователя с единственной схемой.

Если у пользователя доступ к несколько схемам(библиотекам) на DB2 AS/400 и указана нужная схема по умолчанию, даже в этом случае репликация не будет работать. Да, при инициализации таблицы MSSQLServerбудут созданы в нужной схеме, а вот служебную таблицу MSREPL7будет создавать в схеме QSYS.

Ошибки по нюансам 1 и 2 будут вида:

user?COLLECTION in QSYS type *N not found. SQLSTATE: 42704, SQLCODE: -204

Column FTSUB00001 not in table *N in *N. SQLSTATE: 42703, SQLCODE: -205 (Source: MSSQL_REPL_DB2, Error number: -205)

Кстати, ошибка «ColumnFTSUB00001 notintable *Nin *N..», значение FTSUB00001 это не поле таблицы, а название таблицы, данного поля в таблице нет, и эта ошибка будет как раз из-за регистра создаваемых таблиц.

3) Инициализации таблиц

Т.к DB2 AS/400 не родная СУБД для MSSQLServer, инициализации больших данных будет происходит очень долго. Таблица сначала выгружается в файл, далее построчно заливается в DB2 AS/400, что очень долго.

К примеру, таблица с 6 мл строк заливалась около часа, а у нас были таблицы с 120 млн строками и более, считали это будет более 10 дней).

В данном случае поступается следующим образом, вы другим способом передаете данные в уже существующие таблицы в DB2 AS/400, а затем как у меня выше, в свойствах репликации указывать не трогать данные при наличии таблицы и не проводить инициализацию репликации. Для этого, кстати, можно использовать драйвера iSeriesи с помощью запросов OPENQUERYзалить данные в DB2 AS/400.

На небольшие таблицы вы спокойно можете производить инициализацию данных.

4) Проблемы со схемой назначения в репликации.

В студии MSSQLServerесть небольшой баг при настройке репликации. Вы создали публикацию, указали конечную схему назначения и сохранили репликацию. Все ОК. Но после того как вы добавили подписчика или сделали изменения в репликации, схема по умолчанию слетает и все скрипты таблиц для инициализации снова без схемы. Даже если у пользователя в Db2 AS/400 указана схема по умолчанию, таблицы создаются в схеме QSYS.

Это было замечено на 10-х тестах при создании этой репликации.

Возможно это издержки студии, хотя использовал родную 2014 студию с последним SP.

По нюансам вроде все.

И ниже предоставляю работающий скрипт создания репликации на DB2 AS/400 без инициализации:

USE [testDb] -- my test database

--create my test table

CREATETABLE [dbo].[TBL2](

[ID] [int] NOTNULL,---!!! CASE sensitive is important

[VAL] [nchar](10)NULL, ---!!!CASE sensitive is important

CONSTRAINT [PK_TBL2] PRIMARYKEYCLUSTERED

(

[ID] ASC

)WITH (PAD_INDEX=OFF,STATISTICS_NORECOMPUTE=OFF,IGNORE_DUP_KEY=OFF,

ALLOW_ROW_LOCKS=ON,ALLOW_PAGE_LOCKS=ON)ON [PRIMARY]

)ON [PRIMARY]

-- Enabling the replication database

usemaster

execsp_replicationdboption@dbname =N'testDb', @optname =N'publish', @value =N'true'

exec [testDb].sys.sp_addlogreader_agent@job_login =null, @job_password =null, @publisher_security_mode = 1

-- Adding the transactional publication

use [testDb]

execsp_addpublication@publication =N'tbl2',

@description =N'Transactional publication of database ''testDb'' from Publisher ''SERVER1SQL''.',

@sync_method =N'character', @retention = 0, @allow_push =N'true', @allow_pull =N'false',

@allow_anonymous =N'false',@enabled_for_internet =N'false',@snapshot_in_defaultfolder =N'true',

@compress_snapshot =N'false', @ftp_port = 0, @allow_subscription_copy =N'false', @add_to_active_directory =N'false',

@repl_freq =N'continuous', @status =N'active',@independent_agent =N'true', @immediate_sync =N'false',

@allow_sync_tran =N'false',@autogen_sync_procs =N'false', @allow_queued_tran =N'false',@allow_dts =N'false',

@replicate_ddl = 0, @allow_initialize_from_backup =N'false', @enabled_for_p2p =N'false',@enabled_for_het_sub =N'true'

execsp_addpublication_snapshot@publication =N'tbl2', @frequency_type = 1, @frequency_interval =0, @frequency_relative_interval = 0,

@frequency_recurrence_factor = 0,@frequency_subday = 0,@frequency_subday_interval = 0, @active_start_time_of_day =0,

@active_end_time_of_day = 235959,@active_start_date = 0,@active_end_date = 0,@job_login =null,

@job_password =null, @publisher_security_mode = 1

-- Adding the transactional articles

use [testDb]

execsp_addarticle@publication =N'tbl2', @article =N'TBL2', @source_owner =N'dbo', @source_object =N'tbl2',

@type =N'logbased', @description =N'', @creation_script =N'', @pre_creation_cmd =N'none',

@schema_option =0x0000000000004071,@identityrangemanagementoption =N'none',@destination_table =N'TBL2',

@status = 8, @vertical_partition =N'false',@ins_cmd =N'SQL', @del_cmd =N'SQL', @upd_cmd =N'SQL'

-- Adding the transactional subscriptions

use [testDb]

execsp_addsubscription@publication =N'tbl2', @subscriber =N'TBL2',

@destination_db =N'(default destination)',@subscription_type =N'Push', @sync_type =N'replication support only',

@article =N'all', @update_mode =N'read only', @subscriber_type =3

execsp_addpushsubscription_agent@publication =N'tbl2', @subscriber =N'TBL3',

@subscriber_db =N'(default destination)',

@job_login =null, @job_password =null, @subscriber_security_mode = 0,

@subscriber_login =N'mdmbuf3',@subscriber_password =null,

@subscriber_provider =N'DB2OLEDB',@subscriber_datasrc =N'tbl2',

@subscriber_provider_string =

N'Provider=DB2OLEDB;User ID=MDMBUF2;Password=PASSWORD1;Initial Catalog=ALFA;Network Transport Library=TCPIP;Host CCSID=37;

PC Code Page=1252;Network Address=172.10.10.111;Network Port=446;Package Collection=MDMBUF2;Default Schema=MDMBUF2;

Process Binary as Character=False;Units of Work=RUW;DBMS Platform=DB2/AS400;Defer Prepare=False;

DateTime As Char=False;Rowset Cache Size=0;DateTime As Date=False;Auth Encrypt=False;AutoCommit=True;

Authentication=Server;Persist Security Info=True;Connection Pooling=False;Derive Parameters=False;',

@frequency_type =64, @frequency_interval = 1, @frequency_relative_interval = 1,

@frequency_recurrence_factor = 0,

@frequency_subday =4, @frequency_subday_interval = 5,@active_start_time_of_day = 0,

@active_end_time_of_day = 235959,@active_start_date = 0,@active_end_date = 0,@dts_package_location =N'Distributor'

По настройке репликации вроде все. Есть вопросы, комментарии пишите. Возможно есть недочеты, особенно в частности Db2, так же сообщайте, поправлю.

Спасибо.

Использованные источники:

https://msdn.microsoft.com/ru-ru/library/ms151864.aspx

https://msdn.microsoft.com/ru-ru/library/ms152492.aspx

http://www.sqlservercentral.com/Forums/Topic516890-149-1.aspx

http://www.dbforums.com/showthread.php?1662981-Must-double-quote-table-name

p.s: Из-за служебных символов съезжает форматирование текста. движок автоматически создает страшных код, который трудно читать, так что пока так.

↧

Что нам скажет SQL Server ERRORLOG?!

June 29, 2017, 6:50 am

≫ Next: Обновление MS SQL Server Reporting Services 2014 до 2017

≪ Previous: Настройка репликации из MS SQL Server в DB2

Что такое ERRORLOG?! Некоторые специалисты, которые сопровождают MSSQLServerпервый раз слышат о нем или не подозревают, что он есть.

ERRORLOG– это журнал MSSQLServer, физически это текстовый файл. По умолчанию он находится в каталоге установке SQLServerв папке Log, к примеру, в «C:\Program Files\Microsoft SQL Server\ MSSQL13.SQL2016\ MSSQL\Log». В нем регистрируются как информационные сообщения, ошибки различной серьезности, пользовательские ошибки информация по dump-ам sqlserverи другая полезная инфомарция, хотя бывает и не очень полезная.

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

Даже при установке обновлений SQLServer, происходит несколько рестартов служб, что так же создает новый журнал.

В данный журнал записывается информация как об ошибках работы сервера, информация о sqlдампах, безопасности, так и информация информационного характера.

Журналы можно просмотреть несколькими способами:

Через SQL Server Management Studio, вкладка Management -> SQL Server Logs, дважды щелкнув на нужный файл.

2. Открыть текстовым любым текстовым редактором из каталог Log.

Текущий всегда будет без расширения и с именем ERRORLOG, далее по возрастанию от 1 и выше, 1 это предпоследний.

3. Использовать хранимую процедуру.

execmaster..xp_ReadErrorLog

Когда журнал большой, лучше его отфильтровать, к примеру таким способом, меню Filter в Log File Viewer:

Или через T-SQL:

createtable #t

( logdate datetime,

processinfo char(15),

textnvarchar(max)

)

insertinto #t

execxp_ReadErrorLog

select*from #t wheretextlike'%Error%'

droptable #t

Если сервер давно не перезагружали или сервер имел много событий, файл журнала событий может вырасти в размере и открытие его будет проблематичным. В данном случае, активный журнал можно пересоздать командой:

EXECsp_cycle_errorlog

После этого создастся новый текущий журнал, а в файле отразится информация вида:

Message

Attempting to cycle error log. This is an informational message only; no user action is required.

Message

The error log has been reinitialized. See the previous log for older entries.

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

Итак, что говорит нам SQLServerLog?

Возьмем, для примера, файл с одного с рабочих серверов:

2017-06-18 12:26:50.31 Server Microsoft SQL Server 2016 (SP1-CU3) (KB4019916) - 13.0.4435.0 (X64)

Apr 27 2017 17:36:12

Enterprise Edition: Core-based Licensing (64-bit) on Windows Server 2016 Datacenter 6.3 <X64> (Build 14393: )

Сразу можно определить версию SQLServer, установленные обновления и ОС, время старта SQLServer. Довольно часто, обновления не ставят на сервер, но имеют проблемы. Как-то обратился клиент, у него имелось куча проблем, попросил данный журнал SQLserver, а у них версия SQL server 2008R2 RTM, при том что за окном уже SQLверсии 2017 на подходе. Первое рекомендация и необходимость дальнейшей работы – установить обновления последния.

Идем далее по файлу:

2017-06-18 12:26:50.32 Server UTC adjustment: 3:00

Локальное время на сервере.

2017-06-18 12:26:50.32 Server (c) Microsoft Corporation.

2017-06-18 12:26:50.32 Server Server process ID is 8112.

2017-06-18 12:26:50.32 Server System Manufacturer: 'FUJITSU', System Model: 'PRIMERGY RX4770 M3'.

Вендор и модель сервера, тоже важно. При виртуализации это здесь так же видно.

2017-06-18 12:26:50.32 Server Authentication mode is MIXED.

Вид аутефикации на сервере - здесь смешанная.

2017-06-18 12:26:50.32 Server Logging SQL Server messages in file 'C:\SQL\MSSQL13.MSSQLSERVER\MSSQL\Log\ERRORLOG'.

Каталог расположения этого самого журнала.

2017-06-18 12:26:50.32 Server The service account is 'AD\SQL_USER'. This is an informational message; no user action is required.

Учетная запись, под которой работает служба SQL Server. Сразу и легко определяес под кем работает служба, далее можно у админов ОС запросить проверку прав в ОС или что-то подобное.

2017-06-18 12:26:50.32 Server Registry startup parameters:

-d C:\SQL\MSSQL13.MSSQLSERVER\MSSQL\DATA\master.mdf

-e C:\SQL\MSSQL13.MSSQLSERVER\MSSQL\Log\ERRORLOG

-l C:\SQL\MSSQL13.MSSQLSERVER\MSSQL\DATA\mastlog.ldf

-T 2371

-T 4135

-T 2546

Параметры старта SQL server, здесь видим флаги запуска службы SQL server, располжения системных баз данных.

2017-06-18 12:26:50.32 Server Command Line Startup Parameters:

-s "MSSQLSERVER"

2017-06-18 12:26:52.86 Server SQL Server detected 4 sockets with 24 cores per socket and 48 logical processors per socket, 192 total logical processors; using 192 logical processors based on SQL Server licensing. This is an informational message; no user action is required.

2017-06-18 12:26:52.86 Server SQL Server is starting at normal priority base (=7). This is an informational message only. No user action is required.

Видим, сколько процессоров на сервере и включен ли HT.

2017-06-18 12:26:52.86 Server Detected 3193980 MB of RAM. This is an informational message; no user action is required.

Память на сервере, здесь 3 Тб.

2017-06-18 12:26:52.86 Server Using locked pages in the memory manager.

2017-06-18 12:26:52.86 Server Large Page Allocated: 32MB

2017-06-18 12:26:52.87 Server Large Page Allocated: 32MB

Видим, что учетной записи SQL server предоставлены права блокировать память на сервере, а также выделение больших страниц в памяти.

2017-06-18 12:26:57.71 Server Machine supports memory error recovery. SQL memory protection is enabled to recover from memory corruption.

2017-06-18 12:27:00.82 Server Default collation: Cyrillic_General_CI_AS (us_english 1033)

Collation на сервере,

2017-06-18 12:27:00.82 Server Automatic soft-NUMA was enabled because SQL Server has detected hardware NUMA nodes with greater than 8 physical cores.

Включается soft-Numa в SQL 2016.

2017-06-18 12:27:00.90 Server Buffer pool extension is already disabled. No action is necessary.

Buffer pool extension- выключен. Далее идет определения DAC, soft-numa, параметры блокировок:

2017-06-18 12:27:01.04 Server InitializeExternalUserGroupSid failed. Implied authentication will be disabled.

2017-06-18 12:27:01.04 Server Implied authentication manager initialization failed. Implied authentication will be disabled.

2017-06-18 12:27:01.13 Server The maximum number of dedicated administrator connections for this instance is '1'

2017-06-18 12:27:01.13 Server This instance of SQL Server last reported using a process ID of 8116 at 6/18/2017 1:06:37 PM (local) 6/18/2017 10:06:37 AM (UTC). This is an informational message only; no user action is required.

2017-06-18 12:27:01.13 Server Node configuration: node 0: CPU mask: 0x0000000000555555:0 Active CPU mask: 0x0000000000555555:0. This message provides a description of the NUMA configuration for this computer. This is an informational message only. No user action is required.

…..

2017-06-18 12:27:01.14 Server Node configuration: node 15: CPU mask: 0x0000aaaaaa000000:3 Active CPU mask: 0x0000aaaaaa000000:3. This message provides a description of the NUMA configuration for this computer. This is an informational message only. No user action is required.

2017-06-18 12:27:01.31 Server Using dynamic lock allocation. Initial allocation of 2500 Lock blocks and 5000 Lock Owner blocks per node. This is an informational message only. No user action is required.

2017-06-18 12:27:01.31 Server Lock partitioning is enabled. This is an informational message only. No user action is required.

2017-06-18 12:27:01.34 Server Database Instant File Initialization: enabled. For security and performance considerations see the topic 'Database Instant File Initialization' in SQL Server Books Online. This is an informational message only. No user action is required.

2017-06-18 12:27:01.41 Server CLR version v4.0.30319 loaded.

2017-06-18 12:27:01.51 Server Query Store settings initialized with enabled = 1,

Включается компонент Query Store

Начинается старт системных бд:

2017-06-18 12:27:01.53 spid10s Starting up database 'master'.

2017-06-18 12:27:01.53 Server In-Memory OLTP initialized on highend machine.

2017-06-18 12:27:01.59 Server Common language runtime (CLR) functionality initialized using CLR version v4.0.30319 from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\.

2017-06-18 12:27:01.72 spid10s CHECKDB for database 'master' finished without errors on 2017-06-21 03:35:10.293 (local time). This is an informational message only; no user action is required.

2017-06-18 12:27:01.72 spid10s Resource governor reconfiguration succeeded.

2017-06-18 12:27:01.72 spid10s SQL Server Audit is starting the audits. This is an informational message. No user action is required.

2017-06-18 12:27:01.73 spid10s Audit: Server Audit: 65537, Initialized and Assigned State: START_FAILED

2017-06-18 12:27:01.73 spid10s Audit: Server Audit: 65537, Initialized and Assigned State: STARTED

На сервере есть аудиты.

2017-06-18 12:27:01.74 spid10s SQL Server Audit has started the audits. This is an informational message. No user action is required.

2017-06-18 12:27:01.78 spid10s Server name is 'server1'. This is an informational message only. No user action is required.

Имя сервера, как не странно)

2017-06-18 12:27:01.80 spid10s Database mirroring has been enabled on this instance of SQL Server.

2017-06-18 12:27:01.80 spid20s Always On: The availability replica manager is starting. This is an informational message only. No user action is required.

2017-06-18 12:27:01.81 spid20s Always On Availability Groups: Waiting for local Windows Server Failover Clustering service to start. This is an informational message only. No user action is required.

2017-06-18 12:27:01.81 spid20s Always On Availability Groups: Local Windows Server Failover Clustering service started. This is an informational message only. No user action is required.

Сервер является частью кластера, включен компонент AlwaysOn.

2017-06-18 12:27:01.81 spid12s Starting up database 'mssqlsystemresource'.

2017-06-18 12:27:01.81 spid20s Always On Availability Groups: Waiting for local Windows Server Failover Clustering node to start. This is an informational message only. No user action is required.

2017-06-18 12:27:01.81 spid20s Always On Availability Groups: Local Windows Server Failover Clustering node started. This is an informational message only. No user action is required.

2017-06-18 12:27:01.81 spid20s Always On Availability Groups: Waiting for local Windows Server Failover Clustering node to come online. This is an informational message only. No user action is required.

2017-06-18 12:27:01.81 spid31s Starting up database 'DB'.

2017-06-18 12:27:01.81 spid22s Starting up database 'DB2'.

2017-06-18 12:27:01.81 spid25s Starting up database 'DB3'.

2017-06-18 12:27:01.81 spid26s Starting up database 'DB4'.

2017-06-18 12:27:01.82 spid24s Starting up database 'msdb'.

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

2017-06-18 12:27:01.82 spid16s Server is listening on [ 'any'<ipv6> 1433].

2017-06-18 12:27:01.82 spid16s Server is listening on [ 'any'<ipv4> 1433].

Получили TCP порты на которые настроен SQL Server

2017-06-18 12:27:01.82 spid16s Server local connection provider is ready to accept connection on [ \\.\pipe\SQLLocal\MSSQLSERVER ].

2017-06-18 12:27:01.82 spid16s Server local connection provider is ready to accept connection on [ \\.\pipe\sql\query ].

2017-06-18 12:27:01.82 Server Server is listening on [ 'any'<ipv6> 1434].

2017-06-18 12:27:01.82 Server Server is listening on [ 'any'<ipv4> 1434].

2017-06-18 12:27:01.82 Server Dedicated admin connection support was established for listening remotely on port 1434.

Порт DAC

2017-06-18 12:27:01.83 spid31s [INFO] HkHostDbCtxt::Initialize(): Database ID: [13] 'DB'. XTP Engine version is 2.9

В базе данных используются компоненты InMemory

2017-06-18 12:27:01.83 spid12s The resource database build version is 13.00.4435. This is an informational message only. No user action is required.

2017-06-18 12:27:01.83 spid16s SQL Server is now ready for client connections. This is an informational message; no user action is required.

2017-06-18 12:27:01.83 Server SQL Server is attempting to register a Service Principal Name (SPN) for the SQL Server service. Kerberos authentication will not be possible until a SPN is registered for the SQL Server service. This is an informational message. No user action is required.

Проблемы с SPN, возможные, возможно SPN уже есть, просто нет прав на просмотр SPN.

2017-06-18 12:27:01.84 spid26s [INFO] HkHostDbCtxt::Initialize(): Database ID: [8] 'DB3'. XTP Engine version is 2.9.

2017-06-18 12:27:01.87 spid12s Starting up database 'model'.

2017-06-18 12:27:01.89 Server The SQL Server Network Interface library could not register the Service Principal Name (SPN) [ MSSQLSvc/server1.ad.ru ] for the SQL Server service. Windows return code: 0x2098, state: 15. Failure to register a SPN might cause integrated authentication to use NTLM instead of Kerberos. This is an informational message. Further action is only required if Kerberos authentication is required by authentication policies and if the SPN has not been manually registered.

2017-06-18 12:27:01.89 Server The SQL Server Network Interface library could not register the Service Principal Name (SPN) [ MSSQLSvc/server1.ad.ru:1433 ] for the SQL Server service. Windows return code: 0x2098, state: 15. Failure to register a SPN might cause integrated authentication to use NTLM instead of Kerberos. This is an informational message. Further action is only required if Kerberos authentication is required by authentication policies and if the SPN has not been manually registered.

2017-06-18 12:27:01.94 spid12s CHECKDB for database 'model' finished without errors on 2017-06-21 03:38:53.560 (local time). This is an informational message only; no user action is required.

2017-06-18 12:27:01.94 spid12s Polybase feature disabled.

2017-06-18 12:27:01.94 spid12s Clearing tempdb database.

2017-06-18 12:27:02.06 spid12s Starting up database 'tempdb'.

- стартовали системные бд, дальше идут уже сообщения относящиеся к базам данных, работе сервера или ошибки.

Итак, мы прошлись по журналу ERRORLOGSQLServer, как видим, он содержит много полезной информации и может служит начальной точкой при начале диагностике проблем в MSSQLServer.

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

Удачи!.

↧

Обновление MS SQL Server Reporting Services 2014 до 2017

February 19, 2018, 3:00 pm

≫ Next: BACKUP –да знаем, BUFFERCOUNT- нет, не знаем.

≪ Previous: Что нам скажет SQL Server ERRORLOG?!

Имеем сервер отчетов на основе MSSQLServer2014, более 100 отчетов, столько же DataSet-ов, 10-к каталогов отчетов с разделенными правами, плюс два десятка строк подключений, где прописаны строки подключения с паролями. База данных ReportingServicesтак же хранится локально на MSSQLServer2014. Время идет и текущий сервер необходимо обновлять до версии 2017. В данной статье опишу шаги, которые позволяют обновить SQLReportingServices.

Итак, первое самое главное при начале любых работ по изменению конфигураций, это наличие резервных копий, в нашем случае это баз данных ReportingServices, по умолчанию базы данных

[ReportServer]

[ReportServerTempDB]

и ключ шифрования. Создать резервную копию ключа шифрования можно в разделе «EncryptionKeys» приложения «ReportingServicesConfigurationManager»

При создании, укажите пароль, который понадобится при восстановлении.

После этого нам необходимо, обновить СУБД SQLServerи службу ReportingServices, либо мы можем все удалить и поставить чистый экземпляр SQLServerи ReportingServices. Для уменьшения простоя недоступности, мы обновим SQLServerповерх, выбрав в установщике MSSQLServer2017 обновлений MSSQLServerдо версии 2017. Во время выбора параметров, установщик вам сообщит, что для обновления MSSQLReportingServicesтекущий экземпляр нужно удалить, а для установки версии 2017 ReportingServicesнужно отдельно скачать и установить данное приложение:

Так и делаем, обновляем SQLServerи удаляем службу MSSQLReportingServices. Далее скачиваем с сайта Microsoftустановщик MSSQLReportingServices2017 и запускаем его установку:

При установке выбираем редакцию ReportingServices, можно выбрать пробную версию на 180 дней, Expressредакцию, Developer, только нужно учесть, чтобы MSSQLServerтоже должен быть Developerредакции или указать ключ продукта, к примеру, по которому установлен MSSQLServer.

После этого устанавливаем Reporting Services и настраиваем его приложении «Reporting Services Configuration Manager»

Указываем учетную запись запуска службы, в разделе «Database» указываем сервер с нашими базами данных, сервер который мы обновили до версии 2017. И самое главное, в разделе «EncryptionKeys» нужно восстановить наш ключ, сделанный в 2014 версии:

После того как указали при восстановление наш ключ и пароль и нажали "Apply", будет восстановлен ключ шифрования и сделан рестарт службы ReportingServices, наши отчеты станут доступны, как и прежде, все права и строки подключения с паролями будут работать.

Кстати, выше указанный план, это не только план миграции, но и почти полностью план восстановления самой службы ReportingServices, так, что кто не делал ни разу, пока еще не поздно, сделайте восстановление вашего сервера отчета MSSQLServer.

Хорошей миграции!

↧

BACKUP –да знаем, BUFFERCOUNT- нет, не знаем.

May 11, 2018, 9:26 am

≫ Next: Ошибка при создания SQL задания… Try again later.

≪ Previous: Обновление MS SQL Server Reporting Services 2014 до 2017

Операцию резервного копирования знает каждый администратор и разработчик.

Кто-то делает это через графический интерфейс, кто-то через команду BACKUPDATABASE. Если база данных небольшая, то команда backupпроисходит довольно быстро и каких либо проблем не создает, но если база данных уже более 500 Гб, то создание резервной копии может создавать проблемы и создание резервной копии будет занимать уже достаточное время, еще хуже будет если размер базы данных будет 1Тб-ы, а то и 10-100- и терабайт, тогда уже необходимо думать над оптимизацией команды резервного копирования.

Мы не будем заострять внимание на схеме резервного копирования, а остановимся на некоторых дополнительных параметрах резервного копирования. Мало кто использует дополнительные параметры в команде. Полное описание параметров команды BACKUPDATABASEесть на сайте MS.

Среди этих параметров есть параметры:

BUFFERCOUNT = { buffercount | @buffercount_variable }

MAXTRANSFERSIZE = { maxtransfersize | @maxtransfersize_variable }

Их описание:

BUFFERCOUNT = { buffercount | @buffercount_variable }
Указывает общее число буферов ввода-вывода, которые будут использоваться для операции резервного копирования. Можно указать любое целое положительное значение, однако большое число буферов может вызвать ошибку нехватки памяти из-за чрезмерного виртуального адресного пространства в процессе Sqlservr.exe.

MAXTRANSFERSIZE = { maxtransfersize | @maxtransfersize_variable }
Указывает наибольший объем пакета данных в байтах для обмена данными между SQL Server и носителем резервного набора. Поддерживаются значения, кратные 65 536 байтам (64 КБ), вплоть до 4 194 304 байт (4 МБ).

Итак, давайте их проверим и протестируем. Для начала необходимо понять с какими значениями данных параметров запускается команда Backupкогда мы их не указываем. Для этого необходимо включить флаги трассировки перед созданием резервной копии:

DBCC TRACEON(3213, 3605,-1);

Флаг 3213 собирает информацию об операции резервного копирования, а флаг 3605 позволяет эту информацию вывести в файл журнала SQL Server.

Получаем примерно такого вида информацию:

После того как мы получили текущие параметры выполнения команды BACKUPпо умолчанию, можно провести эксперименты на команды отличные от по умолчанию.

Ниже приводится результаты создания резервных копий для базы данных 5,2 Тб с файлом журнала транзакций 10 Гб свободным место в базе 8 Гб.

Делаются два теста. 1-ый тест с параметром Buffersize1 мб, второй тест 4 мб. В каждом тесте 4 под теста по три запуска с разными параметрами BufferCount. Значение по умолчанию BufferCount=60, далее повышал данное значение (80,120,180)

Колличество ядер на сервере 80 с HT.

Таблица тестов:

Test 1:BufferSize 1024kb	BufferCount	Total buffer space(Мb)	Duration1(min)	Duration2(min)	Duration3(min)	AverageDur(min)
Default BufferCount	60	180	60	83	76	73,00
Count of Cores	80	240	46	44	44	44,67
	120	360	39	43	38	40,00
	180	540	38	43	38	39,67
Test 2: BufferSize 4096kb
Default BufferCount	60	720	43	46	50	46,33
Count of Cores	80	960	62	44	49	51,67
	120	1440	39	41	39	39,67
	180	2160	38	39	41	39,33

График на основе результатов:

Из результатов тестирования видно, что уже изменяя один из параметров, мы сокращаем время созданий резервной копии примерно на 40%.

Так же заметно, что достаточно поменять один из параметров: либо buffercount, либо MAXTRANSFERSIZE.Одновременное изменения не приводят к дополнительным улучшениям создания копий. Оптимальный вариант получить значение buffercountпо умолчанию и увеличить его в два раза. Увеличение в более раз не сокращает время создания резервной копии, а только больше выделяет памяти на процесс резервного копирования в ОС(значение Total buffer space(Мb), которое берет вне процесса SQLserver. Но все это нужно тестировать, благо влияние и ресурсов на это много не надо.

Хочу отметить здесь самое главное, что данные улучшения мы получим, если нет проблем с резервным копированием в других местах, таких как задержки ввода\вывода на источнике резервного копирования, на дисках под восстанавливаемой базой данных, сетевые задержки, достаточно памяти. При восстановлении по сети, операция резервного копирования потребляет до 1,8 2 Гб\сек, т.е уже на сетевом адаптере 1 Гб вы получите слабое место для резервного копирования.

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

Удачного резервного копирования.

↧

Ошибка при создания SQL задания… Try again later.

May 25, 2018, 10:20 am

≫ Next: Reporting Services. Делаем доверенным сайт отчетов.

≪ Previous: BACKUP –да знаем, BUFFERCOUNT- нет, не знаем.

После переноса SQLзадания на новый SQLServerполучил ошибку при создании и правки SQLзадания:

Cannot perform this operation while SQLServerAgent is starting. Try again later.

При том, что сервер работает уже давно, а создать новое задание не дает.

Смотрим журналы SQlагента, видим ошибки:

[191] Warning [4]: Possible date calculation spin for Schedule 38

Date 16.05.2018 13:22:08

Log SQL Server Agent (Archive #1 - 16.05.2018 13:22:00)

Message

[192] Date calculation spin detected for Schedule 38

Ошибка связана тем, что SQLне "может рассчитать"время запуска для некоторых расписаний.

Смотрим расписания SQL агента:

Обращаем на задания которые созданы давно и их частота запуска очень большая: каждые Nсекунд , минуты.

Решения: меняем время активации данных заданий на текущую дату.

Проблема в том, что SQL«просто не может рассчитать время запуска» с момента старта расписания.

Как такое может быть - SQLрасписание переносится в процессе миграций с SQLзаданиями, при обновлениях SQLверсий и т.к. Даже выше у меня есть расписание, созданное в 2008 году, т.е более 10 лет, и если бы оно еще запускалось каждые 10 секунд, то была бы выше указанная проблема.

Эти расписания можно получить так же запросом:

use msdb

select name , active_start_date,date_created,* from dbo.sysschedules order by 2

После того как исправил дату , все рассчиталось и проблема исчезла.

↧

Reporting Services. Делаем доверенным сайт отчетов.

June 6, 2018, 9:02 am

≫ Next: Rerporting Services. Статистика выполнения отчетов.

≪ Previous: Ошибка при создания SQL задания… Try again later.

После установки ReportingServicesна сервер и привязки webресурса к протоколу SSL,где по умолчанию прописывается сертификат сервера, сайт все еще считается не безопасным и не разрешенным.

Получается вроде сайт безопасный, а браузер говорит нет:

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

Итак, привязку к сертификату и установка порта HHTPSпроизводится в Reporting Services ConfigurationManager:

В HTTPSCertificateуказываем сертификат.

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

Запускается консоль mmc“ManagerComputerCertificates” и добавляется наш сертификат:

После этого снова запускаем “ReportingServicesConfigurationManager” и В HTTPSCertificateуказываем наш сертификат. Нажимаем Apply и ожидаем Success результат.

После этого имеем доверенный сервер отчетов:

Но, было бы так легко, не описывал эту статью.

Дело в том, что после смены сертификата с сертификата компьютера на безопасный сертификат, возникла ошибка:

An HTTPS binding already exists for the specified IP address and port combination

Microsoft.ReportingServices.WmiProvider.WMIProviderException: An SSL binding already exists for the specified IP address and port combination. The existing binding uses a different certificate from the current request. Only one certificate can be used for each IP address and port combination. To correct the problem, either use the same certificate as the existing binding, or remove the existing SSL binding and create a new binding using the certificate of the current request.

Full error:

Microsoft.ReportingServices.WmiProvider.WMIProviderException: An HTTPS binding already exists for the specified IP address and port combination. The existing binding uses a different certificate from the current request. Only one certificate can be used for each IP address and port combination. To correct the problem, either use the same certificate as the existing binding, or remove the existing SSL binding and create a new binding using the certificate of the current request.

---> System.Runtime.InteropServices.COMException: TabletPC inking error code. Queue is full (Exception from HRESULT: 0x80040238)

--- End of inner exception stack trace ---

at Microsoft.ReportingServices.WmiProvider.RSWmiAdmin.ThrowOnError(ManagementBaseObject mo)

at Microsoft.ReportingServices.WmiProvider.RSWmiAdmin.CreateSSLCertificateBinding(String application, String certificateHash, String ipAddress, Int32 port)

at ReportServicesConfigUI.WMIProvider.RSReportServerAdmin.CreateSSLCertificateBinding(UrlApplication app, String certificateHash, String ipAddress, Int32 port)

т.е нельзя более одного сертификата на указанный SSLпорт.

Начал разбираться, нашел такое решение:

https://social.msdn.microsoft.com/Forums/sqlserver/en-US/e0dc4485-10f3-491f-9a6e-1cbc298e0a40/cannot-update-ssl-certificate-for-sql-2k8-r2-ssrs?forum=sqlreportingservices

через команду

netsh http delete sslcert ipport=[::]:443

Команда успешно выполнялась, но привязка сертификата не происходила.

Далее, обнаружил, что на сервере стоит IISи в нем так же стоит привязка сертификата к SSL. Через меню "Binding"в разделе "Actions" мы удаляем указанный там сертификат:

И снова делает привязку сертификата и запускаем “ReportingServicesConfigurationManager” и В HTTPSCertificateуказываем наш сертификат. Нажимаем «Apply» и ожидаем Successрезультат.

В этот раз должно все выполниться успешно.

Прекрасных отчетов Вам!

Документация:

https://docs.microsoft.com/en-us/previous-versions/sql/sql-server-2008/ms345223(v=sql.100)

https://docs.microsoft.com/ru-ru/sql/reporting-services/security/configure-ssl-connections-on-a-native-mode-report-server?view=sql-server-2017

https://blogs.msdn.microsoft.com/mariae/2007/12/12/ssl-configuration-and-reporting-services/

↧

Rerporting Services. Статистика выполнения отчетов.

June 15, 2018, 8:47 am

≫ Next: Сжимаем ииии разжимаем. Compressed and uncompressed.

≪ Previous: Reporting Services. Делаем доверенным сайт отчетов.

В продолжении темы с ReportingServices.

Предыдущие были про обновление ReportingServices и про SSL и с ним связанной ошибки. Теперь, после того как обновили до последней версии наш сервер отчетов, настроили SSL, мы решили провести аудит своих более 200 отчетов:

Какие отчеты используются? Как часто и кем? Что вообще не используются?

Получение данной информации не составит труда и база данных ReportingServicesуже содержит необходимую информацию для ответов наших вопросов в предоставлении [dbo].[ExecutionLog] которая берет информацию из таблицы [dbo].[ExecutionLogStorage].

В данной таблице содержится информация об истории выполнения отчетов. По умолчанию срок хранения равен 60 дням, но можно его изменить в настройках ReportingServicesв ManagementStudio:

Итак, к примеру, можно получить количество выполнения отчетов:

selectdistinct c.Name,c.Path,count(*)as CountExec

FROM ExecutionLog e

innerjoinCatalog c on e.ReportID=c.ItemID

groupby c.Name, c.Pathorderby 3 desc

Получим сколько раз отчет из каталог c.Path выполнялся за время хранения в журнале информации.

Добавим себя, можно убрать себя из статистики

selectdistinct c.Name,c.Path,count(*)as CountExec

FROM ExecutionLog e

innerjoinCatalog c on e.ReportID=c.ItemID

where UserName!=SUSER_NAME()

groupby c.Name, c.Pathorderby 3 desc

Можно получить самых активных пользователей Вашего сервера отчетов:

selectdistinct username ,count(*)as CountExec FROM ExecutionLog

groupby UserName orderby 2 desc

Если вы имеет в результате пользователя подобного «NT SERVICE\SQLServerReportingServices» или пользователя службы RS, то это отчёты выполняющиеся по расписанию по подписке.

У нас, лидером оказался пользователь системы монитонга J.

Отчеты , которые не запускались за время хранения истории выполнения:

select Path,Namefrom [dbo].[Catalog]

where ItemID notin(select ReportID FROM[ReportServer].[dbo].[ExecutionLogStorage])

andName!='System Resources'

Так что вот так, парочку простых запросов и можно получить статистку вашего сервера отчетов.

Дополнительная информация:

https://docs.microsoft.com/en-us/previous-versions/sql/sql-server-2012/ms159110(v=sql.110)

https://docs.microsoft.com/en-us/sql/reporting-services/report-server/report-server-executionlog-and-the-executionlog3-view?view=sql-server-2017

↧

Сжимаем ииии разжимаем. Compressed and uncompressed.

December 4, 2018, 9:27 am

≫ Next: Ошибка при обновлении MS SQL Server 0x851A0044

≪ Previous: Rerporting Services. Статистика выполнения отчетов.

В MSSQLServerесть возможность сжатия данных на уровне строк или на уровне страниц.

Информация по данной возможности описана на страницах Microsoft:

https://docs.microsoft.com/ru-ru/sql/relational-databases/data-compression/enable-compression-on-a-table-or-index?view=sql-server-2017#Restrictions

https://docs.microsoft.com/ru-ru/sql/relational-databases/data-compression/data-compression?view=sql-server-2017

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

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

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

После этого база данных живет, таблица наполняется данными. Для примера я приведу результаты моей таблицы архивных данных:
- первая таблица результат загруженных данных в пустую секцию с включенным сжатием
- вторая таблица результат расзжатия этой же таблицы\секции
- и третья таблица, повторное сжатие секций этих же данных.

Как видим, включение сжатие на пустой таблице дает результат сжатия, размер секций меньше секций без включенного сжатия, но максимальное сжатие можно получить, если сжать эти же секции еще раз.
Так что сжимайте и разжимайте секции, благо все делается с параметром ONLINE=ON.

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

CREATETABLE [dbo].[Tbl_test](

[id] [int] NOTNULL,

[val] [nchar](10)NOTNULL,

CONSTRAINT [PK_Tbl_test] PRIMARYKEYCLUSTERED

(

[id] ASC

)WITH (PAD_INDEX=OFF,STATISTICS_NORECOMPUTE=OFF,IGNORE_DUP_KEY=OFF,

ALLOW_ROW_LOCKS=ON,ALLOW_PAGE_LOCKS=ON)ON [PRIMARY]

)ON [PRIMARY]

CREATENONCLUSTEREDINDEX [NonClusteredIndex_val] ON [dbo].[Tbl_test]

(

[val] ASC

)WITH (PAD_INDEX=OFF,STATISTICS_NORECOMPUTE=OFF,SORT_IN_TEMPDB=OFF,DROP_EXISTING=OFF, OLINE=OFF,ALLOW_ROW_LOCKS=ON,ALLOW_PAGE_LOCKS=ON)ON [PRIMARY]

Далее включим сжатие, либо командой:

ALTERTABLE [dbo].[Tbl_test] REBUILDPARTITION=ALL

WITH (DATA_COMPRESSION=PAGE)

Либо графически, что для некоторых удобно:

что одно и тоже с командой выше. После этого мы думаем, что сжатие включено, но если посмотреть на данные, то не все так есть:

select object_name(p.object_id)as TblName,i.name,p.data_compression_desc

fromsys.partitions p

innerjoinsys.indexes i on p.object_id=i.object_idand i.index_id=p.index_id

where p.object_id=object_id('[dbo].[Tbl_test]')

orderby i.index_id asc

TblName	name	data_compression_desc
Tbl_test	PK_Tbl_test	PAGE
Tbl_test	NonClusteredIndex_val	NONE

Сжатым оказался только кластерный индекс, некластерный индекс не сжат. Некластерный сжимается отдельно командой ALTER

USE [TestDb]

ALTERINDEX[NonClusteredIndex_val] on [dbo].[Tbl_test] REBUILDPARTITION=ALL

WITH (DATA_COMPRESSION=PAGE)

После этого таблица полностью сжата:

TblName	name	data_compression_desc
Tbl_test	PK_Tbl_test	PAGE
Tbl_test	NonClusteredIndex_val	PAGE

Так что проверьте, все ли у вас сжато!

Удачного сжатия и разжатия!

P.S.:

Ну про то, что тип сжатия (ROW или PAGE)для каждой таблицы нужны выбирать индивидуально и желательно только через реальный тест, а не предварительный расчет студии, уже не буду упоминать. Иногда предварительный выигрыш показывает, а реальный выигрыш очень небольшой по сравнению потраченными ресурсами и наоборот.

↧

Ошибка при обновлении MS SQL Server 0x851A0044

December 25, 2019, 6:37 am

≫ Next: Ошибка DistributedCOM 10016 на серверах SQL Server

≪ Previous: Сжимаем ииии разжимаем. Compressed and uncompressed.

Иногда при установке очередного CU или SP на MS SQL Server возникает ошибка установки и установить обновления не получается.
Подробный текст ошибки:

Detailed results:
Feature: Database Engine Services
Status: Failed: see logs for details
Reason for failure: An error occurred during the setup process of the feature.
Next Step: Use the following information to resolve the error, and then try the setup process again.
Component name: SQL Server Database Engine Services Instance Features
Component error code: 0x851A0044
Error description: The User Log directory in the registry is not valid. Verify DefaultLog key under the instance hive points to a valid directory.
Error help link: http://go.microsoft.com/fwlink?LinkId=20476&ProdName=Microsoft+SQL+Server&EvtSrc=setup.rll&EvtID=50000&ProdVer=12.0.6024.0&EvtType=0xD8FB5EBA%400x97A656BB%401306%4068&EvtType=0xD8FB5EBA%400x97A656BB%401306%4068

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

Решение:

Указать актуальный путь для файлов баз данных ,либо через MS SQL Management Studio Server Properties -> Database Settings , либо через команды:

USE [master]

EXEC xp_instance_regwrite N'HKEY_LOCAL_MACHINE', N'Software\Microsoft\MSSQLServer\MSSQLServer', N'BackupDirectory', REG_SZ, N'E:\Backup_01'

EXEC xp_instance_regwrite N'HKEY_LOCAL_MACHINE', N'Software\Microsoft\MSSQLServer\MSSQLServer', N'DefaultData', REG_SZ, N'E:\Data_01\data'

EXEC xp_instance_regwrite N'HKEY_LOCAL_MACHINE', N'Software\Microsoft\MSSQLServer\MSSQLServer', N'DefaultLog', REG_SZ, N'E:\Logs_01\log'

. и после этого запустить снова установку обновления MS SQL Server.

↧

Ошибка DistributedCOM 10016 на серверах SQL Server

June 29, 2021, 2:38 am

≫ Next: Ускорение работы Database Mail

≪ Previous: Ошибка при обновлении MS SQL Server 0x851A0044

Страниц в интернет по данной ошибке полно, но эта ошибка довольно часто встречает на промышленных серверах с MS SQL Server решил еще одну написать.

Имеем ошибку вида:

The Application-Specific Permission Settings Do not Grant Local Activation Permission for the COM Server Application with CLSID {} and APPID {} to the User DOMAIN\User from address LocalHost (Using LRPC) running in the application container Unavailable SID (Unavailable). This security permission Can Be Modified using the Component Services Administrative Tool.

Event ID 10006

Source - DistributedCOM

В логах System мы можем видеть такие сообщения в разной частоте их(может раз в день, а может и несколько раз в минуту):

Решение простое, нужно предоставить права указанной учетной записи в консоли Component Services:

1) Открыть консоль

Click Start -> Run -> Type -> dcomcnfg, expand Component Services -> Computers -> My Computer -> DCOM Config.

В русской ОС в панели пуск введите Component, должно появиться эта консоль в результатах поиска.

2) Найти по ApplicationID в ошибке компонент. Обычно на серверах MS SQL Server это компонент MS SQL Server Intergration Services . Поиск в данной вкладке не работает, так что ищем вручную

3) Открываем свойство приложения и предоставляем указанной учетной записи в ошибке права.

Обычно достаточно Local Actication, но иногда нужно и Remote .

Все , ошибка должны исчезнуть. Рестарт служб или сервера не нужен.

Хотелось бы добавить:

В реальности, из опыта управления сотнями серверов, данная ошибка редко является проблемой для приложений и работы. Скорее ,эта ошибка создает неудобства , засоряет журналы ОС . Но если есть возможность исправить, то исправьте.

и немного ссылок:

https://docs.microsoft.com/en-us/troubleshoot/windows-client/application-management/event-10016-logged-when-accessing-dcom

https://docs.microsoft.com/en-us/answers/questions/215020/the-application-specific-permission-settings-do-no.html

↧

Ускорение работы Database Mail

January 24, 2022, 2:06 pm

≫ Next: C0000005 - Server terminating - страшное слово для SQL Server

≪ Previous: Ошибка DistributedCOM 10016 на серверах SQL Server

В данной небольшой статье хочу описать ускорение работы Database mail компонента SQL Server.

В конец месяца, года обычно делается массовая рассылка из систем: клиентам банка отчеты , к примеру годовые налоги или финансовые отчеты, в торговых компаниях отчеты контрагентам и так далее.

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

Как пример, на одном из финансовых сервере баз данных создалась очередь отправки писем с вложенными файлами примерно 300000 клиентам. Скорость отправки была примерно 6000 тысяч файлов в час, что очень медленно и при том новые письма на отправку постоянно создаются. Это могло вылится в проблему в несколько дней.

При изучение, было замечено что процесс Database mail сканирует таблицу -кучу в msdb.sysmail_attachments.

Это куча, в моем состоянии она весила 250Гб и для каждого письма происходило сканирование данной кучи. Логично создать индекс:

USE [msdb]

CREATE NONCLUSTERED INDEX [INDX_mailitem_id] ON [dbo].[sysmail_attachments]

(

[mailitem_id] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF,

ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]

После создания индекса план запросов был следующий:

после этого количество сессий Database mai увеличилось с одного до 50

Ниже статистика отсылки писем до создания индекса и после:

Результат на лицо вместо 60-90 писем в минуту до 3000 писем в минуту.

В итоге очередь из сотни тысяч писем была разослана за несколько десятков минут.

Почему изначально данного индекса нет- возможно не предполагалась такая нагрузка на почтовый агент.

В любому случае индекс не стал лишнем, но так же не забываем, что системную бд msdb нужно обслуживать.

↧