На одном из занятий, которые мы с Кимберли вели на этой неделе на конференции SQL Connections, мы обсуждали, как выбирать эффективные типы данных. Я хотел бы поделиться этим обсуждением здесь на примере.
Показаны сообщения с ярлыком Storage. Показать все сообщения
Показаны сообщения с ярлыком Storage. Показать все сообщения
10.5.26
Как выбор типа данных влияет на производительность
28.4.26
Проверка узких мест ввода-вывода за 45 секунд
В этой статье я покажу вам, как выявить узкие места ввода-вывода SQL Server менее чем за 45 секунд с помощью специализированных динамических административных представлений (DMV). Перестаньте гадать между задержкой и пропускной способностью и начните исправлять реальные очереди к системе хранения!
27.4.26
В продолжение темы о промежуточной материализации (сбросе) в TempDB
Как мы говорили в предыдущей статье: когда загрузка ЦП в порядке, операции ввода-вывода в порядке, а запросы выглядят «нормально», но производительность нестабильна: иногда быстро, иногда медленно – настоящая проблема часто кроется в сбросах в TempDB. В этой второй части мы глубже разберём первопричину!
26.4.26
SQL101: Проверка согласованности данных на уровне приложения
Довольно часто случается, что компания, пережившая аварию, вызвавшую повреждение данных, но не имеющая действительных резервных копий для восстановления и возможности выполнить отработку отказа на избыточную вторичную реплику, просто запускает восстановление (repair), а затем немедленно снова начинает работать в продуктивной среде.
24.4.26
Работают ли многоядерные процессоры лучше, чем одноядерные?
Вот интересный вопрос, который прислал мне мой друг Стив Джонс из SQL Server Central — будет ли один процессор с двумя ядрами работать лучше, чем два одноядерных процессора? Оба варианта имеют два вычислительных ядра, но аппаратная архитектура разная — какой из них обеспечит лучшую производительность SQL Server? Что ж, однозначного ответа нет — всё зависит от многих факторов! Я обсуждал эту тему с Джеромом Халмансом, бывшим коллегой по команде Storage Engine в SQL Server, и с его разрешения я основываю эту статью на нашем обсуждении.
23.4.26
Проверка состояния TempDB за 45 секунд
В этой статье я покажу вам, как обнаружить нагрузку на TempDB менее чем за 45 секунд и, что ещё важнее, — как правильно её интерпретировать.
Потому что выявление истинного узкого места — это то, что отличает реактивных администраторов баз данных от инженеров по производительности.
Когда сервер работает медленно, но метрики CPU и ввода-вывода выглядят нормально. Когда планы выполнения выглядят приемлемо, но что-то всё равно не так. Когда запросы нестабильны — то быстры, то еле ползут — и пользователи жалуются, хотя вы не видите ничего очевидного...
Вот где многие администраторы баз данных тратят часы.
👉 Помните: TempDB часто оказывается замешана, но почти никогда не является первопричиной.
21.4.26
Индексы под всеми углами: Как определить, используется ли индекс?
Когда бы я ни обсуждал обслуживание индексов, и в частности фрагментацию, я всегда подчёркиваю: «Прежде чем что-либо делать с фрагментацией, убедитесь, что индекс используется».
Если индекс используется не очень активно, но при этом имеет очень низкую плотность страниц (много свободного места на страницах индекса), то он будет занимать гораздо больше дискового пространства, чем мог бы, и, возможно, его стоит уплотнить (с помощью перестроения или реорганизации), чтобы вернуть это дисковое пространство. Однако обычно нет особого смысла тратить ресурсы на устранение какой бы то ни было фрагментации, когда индекс не используется. Это особенно верно для тех, кто перестраивает все индексы каждую ночь или каждую неделю.
20.4.26
Чтение заголовков файлов SQL Server с помощью DBCC FILEHEADER
Недавно я глубоко погрузился в изучение дисковых структур SQL Server, и одно из моих любимых направлений — это перечитывание серии статей Пола Рэндала (Paul Randal) о страницах заголовков файлов. Если вы её не читали, сделайте это прямо сейчас. В ней рассказывается о том, что такое страницы заголовков файлов, что они содержат и что происходит при их повреждении. Эта статья развивает эту концепцию. Я буду использовать DBCC FILEHEADER для чтения заголовка каждого файла пользовательской базы данных на сервере и отвечу на вопрос, который возникает чаще, чем можно подумать: можно ли определить, какие файлы принадлежат одной базе данных, исключительно по заголовку файла, без обращения к sys.databases?
Короткий ответ — да, и поле, которое делает это возможным, называется BindingId. Давайте разбираться.
19.4.26
"Все" мифы о резервном копировании
Пришло время грандиозного финала!
Хотя было весело развенчивать все эти мифы, это было немного напряжённо — каждый день находить интересный и полезный миф для разоблачения.
В завершение я представляю вам 30 мифов о резервном копировании — по одному на каждый день апреля. Вчера вечером я сел писать эту статью и не добрал несколько мифов, поэтому обратился за помощью к великолепному сообществу SQL в Twitter — слишком много людей, чтобы перечислять (вы знаете, кто вы) — я благодарю вас!
Я очень надеюсь, что вам понравилась эта серия, и что множество мифов и заблуждений были развеяны раз и навсегда — я знаю, что многие из вас используют эти объяснения в качестве аргументов против сторонних поставщиков, разработчиков и других администраторов баз данных, которые настаивают на неправильных практиках.
Итак, поехали, последний выпуск…
17.4.26
Мифы о модели восстановления BULK_LOGGED
Модель восстановления BULK_LOGGED продолжает сбивать людей с толку…
15.4.26
Миф об использовании BACKUP WITH CHECKSUM для замены DBCC CHECKDB
Сегодня короткая статья, так как я занят работой с клиентами и сортировкой заявок на выступления для SQL Connections!
14.4.26
Миф про то, что вложенные транзакции реальны
Вложенные транзакции — это злое изобретение, предназначенное для того, чтобы позволить разработчикам сделать жизнь администраторов баз данных невыносимой. В SQL Server они ещё более злы…
13.4.26
Мифы о коэффициенте заполнения (fill factor)
Я выдохся после прошлой статьи с мифами о восстановлении, так что сегодня короткая статья, разоблачающая некоторые мифы о коэффициенте заполнения (fill factor), которые я развенчал ещё в SQL Server 2005 в Books Online.
11.4.26
Двадцать шесть мифов о восстановлении
Одна область, которую я ещё не затронул в этой серии, — это RESTORE (восстановление), и здесь существует тонна заблуждений (так много, на самом деле, что я не могу охватить их все в одной статье!). В одной статье было разоблачено 6 мифов о контрольных суммах страниц, а в другой — 5 мифов о FILESTREAM, так что сегодня мне нужно их превзойти.
10.4.26
Миф о том, что эскалация блокировок происходит сначала с уровня строки на уровень страницы, а затем с уровня страницы на уровень таблицы
Миф №23: эскалация блокировок происходит сначала с уровня строки на уровень страницы, а затем с уровня страницы на уровень таблицы.
ЛОЖЬ
Нет, никогда. Эскалация блокировок в SQL Server всегда переходит непосредственно к блокировке таблицы.
7.4.26
Миф о том, что регулятор ресурсов позволяет управлять активностью ввода-вывода
Регулятор ресурсов (Resource Governor) — это замечательная возможность с SQL Server 2008, но существуют некоторые заблуждения относительно того, что он может делать…
6.4.26
Миф о том, что повреждение базы можно исправить перезапуском SQL Server
Этот миф (и его производные) очень распространены среди не-администраторов баз данных, поскольку многие проблемы в Windows можно исправить перезагрузкой компьютера (да, я до сих пор вижу это на серверах, Windows 10 и т.д. — попробуйте изменить номер порта служб терминалов без перезагрузки).
5.4.26
Миф о том, что для перезапуска цепочки восстановления журнала требуется полная копия базы
Этот миф — один из самых распространённых, и я встречал очень мало людей, которые знают правду.
Миф №20: после разрыва цепочки резервного копирования журнала для её перезапуска требуется полная резервная копия базы данных.
ЛОЖЬ!
4.4.26
Структура каталогов FILESTREAM – откуда берутся GUID?
На этой неделе я вёл курс «Microsoft Certified Masters – Database» здесь, в Редмонде, и в первый день мы обсуждали структуру каталогов FILESTREAM. Мне задали вопрос: откуда берутся GUID имён каталогов? Поэтому я начал копаться в системных таблицах, пока Кимберли читала лекцию. Посмотрите мою предыдущую статью блога (Структура каталога FILESTREAM) за прошлую неделю, чтобы увидеть схему базы данных, с которой я работаю. Я воссоздал её снова и написал несколько запросов, чтобы найти, где хранятся GUID, поскольку они должны где-то храниться в базе данных.
31.3.26
Мифы о контрольных суммах страниц
Несколько человек предложили разобрать некоторые мифы, связанные с контрольными суммами страниц, так что сегодня у нас очередной экстравагантный «многомифобойный» день! Ну, по крайней мере, я в восторге :-)
Я подробно описывал контрольные суммы страниц в статье блога How to tell if the IO subsystem is causing corruptions?
Подписаться на:
Сообщения (Atom)