Главная страница  Карта сайта  Печать  Написать письмо  RSS
Войти
Кнопка открытия главного меню
Персональный сайт
Стеллецкого Владимира
Обновленные страницы
21.11.2024
Цитаты
14.11.2024
Авто
05.11.2024
С миру по нитке...

ещё

Новые комментарии
23.11.2024 17:09
swi
06.11.2024 22:04
Лена (отвечено)
23.04.2024 19:33
Мой комментарий

ещё

Обновлено: 27.02.2024 г.

Примеры с SQL

« первая   ‹ предыдущая   1   2   3   4   следующая ›   последняя »

Как заменить старые индексы и не сломать систему? (15.12.2017) #

Возможно, многие сталкивались с исторически сложившейся за годы, до появления на проекте, ситуацией, когда на таблице создали все возможные индексы со всеми include’ами. Я видела индекс на доставшейся «в наследство» БД, который содержал все поля таблицы. При этом, не всегда есть возможность быстро поменять индексы, так как часто нужна гарантия, что изменения не повлияют на работоспособность системы.

https://habrahabr.ru/post/344284/

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

Разреженные столбцы (05.12.2017) #

Рекомендую к прочтению статью Разреженные столбцы или sparse columns в MS SQL Server. Реальный опыт применения. В статье подробно описывается разбор проблемы с производительностью базы данных. Последовательно приводится анализ текущей ситуации, вариантов решения и описание преимуществ, ограничений и недостатков выбранного решения - использования разреженных столбцов (sparse columns).

Анализ работы MS SQL Server (27.09.2017) #

Наткнулся на серию статей по анализу работы MS SQL Server.
Первая часть мне не очень понравилась, а вот вторую считаю вполне полезной:

  • Анализ конкретного запроса - план выполнения, затраты процессора (SET STATISTICS TIME ON), дисковые операции сервера (SET STATISTICS IO ON), объем сетевого трафика.
  • Анализ нагрузки от приложения - profiler, ключевые (Stored Procedures RPC:Completed, TSQL SQL:BatchCompleted - все внешние sql-вызовы) и просто полезные события.
  • Анализ активности пользователей в целом по серверу - информация о сессиях (sys.dm_exec_sessions), запросы выполняющиеся в данный момент (sys.dm_exec_requests), сводная статистика (sys.dm_exec_query_stats).

Сжатие баз данных MS SQL (11.04.2017) #

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

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

Теперь в каждом файле основной базы данных (мы крупные связанные части базы данных выносим в отдельные файлы) у нас свободно места на полгода-год (учитывая прогнозируемую скорость роста), а также увеличение размера (приращение) файлов идёт по 512-1024МБ (про проценты лучше сразу забыть).

Комментарии

Мой комментарий (28.11.2017)
Недавно наткнулся на информацию, что в случае единоразового выделения SQL сервером на диске более 1ГБ могут быть "тормоза". К сожалению, ссылку сейчас найти не получается, поэтому предлагаю просто иметь это в виду.
У нас установлено по 1ГБ - проблем пока не замечено.

Повесть о кластеризованном индексе (24.02.2017) #

Интересная статья о хранении данных и кластерном индексе в MSSQL. Приведу здесь только алгоритм выбора индекса на роль кластерного:

Предлагается следующий алгоритм выбора:
  1. Определить все индексы, по которым происходит поиск одиночного значения. Если такой индекс единственный – его и нужно кластеризовать. Если несколько – перейти к следующему шагу.
  2. Добавить к индексам с предыдущего шага все индексы, по которым предполагается сканирование диапазонов. Если таковых нет – кластеризованный индекс не нужен, несколько индексов на куче будут работать лучше. Если есть – каждый из них следует сделать покрывающим, добавив все столбцы, которые нужны сканирующим запросам по этому индексу. Если такой индекс единственный – его следует кластеризовать. Если их больше одного – перейти к следующему шагу.
  3. Однозначно лучшего выбора кандидата на кластеризацию среди всех покрывающих индексов нет. Следует кластеризовать какой-то из этих индексов, принимая во внимание следующее:
    • Длина ключа. Ключ кластеризованного индекса является ссылкой на строку и хранится на листьевом уровне некластеризованного индекса. Меньшая длина ключа означает меньше места на хранение и более высокую производительность.
    • Степень покрытия. Кластеризованный индекс содержит все поля «бесплатно», и покрывающий индекс с самым большим набором полей – хороший кандидат на кластеризацию.
    • Частота использования. Поиск одиночного значения в покрывающем индексе – самый быстрый возможный поиск, а кластеризованный индекс – покрывающий для любого запроса.

https://habrahabr.ru/post/188704/

Кучи, кучи, кучи... (20.11.2016) #

В довольно старых базах данных, да ещё если за время их существования сменилось несколько поколений разработчиков, чего только не увидишь. Случайно наткнулся на таблицу без кластерного индекса (кучу или HEAP). Заинтересовался много ли ещё таких таблиц и написал следующий SQL-запрос:

  1. -- все таблицы в базе без кластерного индекса (кучи)  
  2. select distinct top 1000  
  3.     s.name as [Schema],  
  4.     o.name as [TableName],  
  5.     ps.row_count as [RowCount]  
  6. from sys.objects o  
  7.     left join sys.schemas s  
  8.         on o.schema_id = s.schema_id  
  9.     inner join sys.indexes i  
  10.         on o.object_id = i.object_id  
  11.     inner join sys.dm_db_partition_stats ps  
  12.         on o.object_id = ps.object_id  
  13. where  
  14.     o.type_desc = 'USER_TABLE' and  
  15.     i.type_desc = 'HEAP'  
  16. order by  
  17.     [RowCount] desc  

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

Грабли при написании SQL-запросов для MS SQL-сервера. (15.11.2016) #

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

Для себя могу отметить следующее (далее пункты соответствуют пунктам в статье):

  1. Правильность типа данных очень важна.
  2. SELECT * - зло!
  3. Alias нужны всегда и для всех объектов.
  4. Нельзя ориентироваться на порядок колонок в таблице.
  5. Коварный NULL (его необходимо учитывать при сравнениях).
  6. Константы даты только YYYYMMDD (раньше писал с дефисами, больше не буду).
  7. Интересные решения по фильтрации по дате - вычисляемое поле и индекс.
  8. Нельзя преобразовывать колонки в WHERE.
  9. Всегда необходимо указывать правильный тип констант (строки в кавычках).
  10. Для поиска с начала только LIKE.
  11. Для констант в UNICODE всегда N (иначе будет приведение к ANSI).
  12. COLLATE очень важен.
  13. Для LIKE c %Value% можно использовать BINARY COLLATE.
  14. Имена всех объектов писать строго как в БД (иначе м.б. проблемы с COLLATE).
  15. Внимание с CHAR и VARCHAR (т.к. есть отличия в сравнении по LIKE).
  16. Важно указывать размерность типа (просто VARCHAR = VARCHAR(1), но в CAST/CONVERT будет VARCHAR(30)).
  17. ISNULL и COALESCE (первый приводит к меньшему типу, второй к большему, но работает медленнее).
  18. Внимательнее с математическими операциями - результат зависит от типов операндов.
  19. UNION vs UNION ALL (первый медленно, но может выполняться параллельно, второй быстро но последовательно).
  20. Внимательнее с подзапросами в SELECT - могут быть лишние чтения.
  21. В подзапросах может вернуться более одного результата (тогда ошибка).
  22. CASE WHEN - может привести многократному вычислению одних и тех же операторов.
  23. Scalar func - зло (особенно с параметрами и вычислениями).
  24. Внимательнее с VIEWs (могут быть проблемы с производительностью, если нужны не все колонки).
  25. CURSORs - зло (только если по-другому нельзя).
  26. Пока нет STRING_CONCAT - XML оптимальный вариант (90% случаев).
  27. SQL Injection - использовать sp_executesql с параметрами, вместо ручной склейки строки.

PS: Для отображение численных характеристик выполнения запроса можно использовать SET STATISTICS TIME, IO ON перед запросом и OFF после.

Комментарии

swi, www (20.11.2016)
Спасибо. Очень интересно!
Мне тоже статья понравилась (даже не поленился сделать себе конспект).

Microsoft SQL Server 2016 (20.10.2016) #

В понедельник на работе перешли на Microsoft SQL Server 2016. Учитывая, что переходили с довольно таки старого 2008, постарались подготовиться получше. Переход прошёл в целом очень хорошо, но всё же некоторые непредвиденные сложности возникли:

  • Несколько запросов перестало выполняться из-за использования некорректных типов данных.
  • Некоторые сложности возникли с правами для прилинкованного сервера. Сам сервер прилинковался "на ура", но вот запросы с него не выполнялись, выдавая следующую ошибку: Причём, у привилегированного пользователя всё работало, а у обычного нет. Но стоило выполнить запрос под привилегированным пользователем, как начинало работать и под обычным, правда, не долго - через какое-то время снова выдавало ошибку. По тексту ошибки и нескольким статьям в интернете предположили, что проблема в том, что "обычным" пользователям прилинкованный сервер не отдавал статистику, а без этого запросы не выполнялись.

Повреждение данных в SQL Server 2012 и 2014 при перестроении индексов в режиме online (17.09.2016) #

Коллега по работе прислал ссылку на интересную, а главное крайне полезную статью.
Кратко: без установленного исправления KB #2969896 в SQL Server 2012 и 2014 при перестроении индексов в режиме online может произойти повреждение индексов и даже потеря данных в таблице.

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

Полезные ссылки (27.03.2016) #

« первая   ‹ предыдущая   1   2   3   4   следующая ›   последняя »

  Вы 57 884 посетитель этой странички
с 07 октября 2006 года
© http://svv-home.ru
О сайте