|
|
-
Давно не открывал свой аккаунт в Azure, но совсем недавно на горизонте появился новый заказчик, который не боится держать свои данные в Azure. Давно хотел поработать с облаком в реальном проекте и к новому проекту отнёсся с энтузиазмом. Приводя в порядок этот проект, наряду с рядовыми проблемами, столкнулся с некоторыми особенностями Azure (опишу в следующих постах). Но первое что бросилось в глаза, это новый вариант разворачивания проекта (думаю он не так нов, но я проморгал момент его появления). И сегодня я как раз о нём и собираюсь рассказать. Читать дальше…
|
-
Вышло очередное обновление SQL Azure, которое предоставляет доступ к новому набору фич. Появилось копирование базы данных. Эта функциональность была в планах очень давно и её появление ожидалось в этом году. Появились новые разделы в MSDN и обновился проект Code-Named “Houston”. Теперь обо всём по-порядку. Читать дальше…
|
-
Совсем недавно, один мой друг, директор одной из Харьковских софтверных компаний, спрашивал меня относительно сертификации: процедуры сертификации и действующих скидок. Так что тема сертификации сотрудников, как бы кто ни ругался на саму систему сертификации, остаётся актуальной. Саму процедуру сдачи экзаменов я описывать не буду, а вот про скидки скажу пару слов. Читать дальше…
|
-
Фоновые операции с индексами вызывают краткосрочные блокировки в начале и в конце операции, что может привести к значительным проблемам с производительностью. Читать дальше…
|
-
Параметр 'max degree of parallelism' опеределяет максимальное количество потоков, на которые SQL Server может распараллелить запрос. По умолчанию этот параметр равен нулю – что означает использование числа процессоров сервера. Например, если у вас 24 ядра – фактическое значение 'max degree of parallelism' будет равно 24 и оптимизатор, если он посчитает нужным, может распараллелить запрос на 24 потока. В общем случае это хорошо, но не всегда. Также, далеко не всегда хорошо использование значения этого параметра по умолчанию. Читать дальше…
|
-
Именно такую задачу на вечер поставил перед нашей командой заказчик. Поиск в базе объявлений, содержащих "нехорошие" слова, и выставление всем подобным записям флага Is18YearsOnly. Конечно только этим задача не ограничивалась, её решение включало в себя доработку кода на соответствие требованиям и обновление базы. С кодом мы успешно справились в рабочее время, а вторую часть я взял на дом. По дороге домой, и уже дома, сидя за компьютером, я думал над тем как решить эту задачу наиболее эффективно. И вот что придумал… Читать дальше…
|
-
Миф №7 – База данных может иметь несколько зеркал FALSE Сам миф довольно банален – зеркалирование предполагает только одну зеркальную базу данных. Если же вы хотитие иметь более одной копии основной базы данных, то для этого рекомендуется воспользоваться механизмом доставки журналов (Log Shipping). Используя доставку журналов вы можете иметь столько копий вашей базы данных, сколько вам будет нужно. К тому же, доставка журналов имеет одну просто потрясающую возможность – настройку задержки загрузки для вторичных баз… Читать дальше…
|
-
-
Ну вот я и попробовал сжатие на реальной системе и на реальных базах данных. Пару слов о том, что это такое и переходим к делу. Компрессия данных появилась в SQL Server 2008 и со стороны её можно представить в виде айсберга. На верхушке которого – уменьшение занимаемого дискового пространства, а скрыто от глаз ещё более интересное преимущество – снижение нагрузки на ввод/вывод за счёт меньшего количества читаемых данных. Ну и конечно же, не могу обойти стороной один не очень хороший момент – увеличение нагрузки на CPU, но без этого никак. Более того, сам алгоритм сжатия данных не преследует цель максимально зажать данные, а призван соблюдать разумный баланс между процентом сжатия данных и затратами на упаковку/распаковку данных. Сжатие работает в двух режимах: Row Compression и Page Compression. И в своём посте я расскажу о том как и насколько я зажал данные реальных баз и как это сказалось на работе приложений. Компрессия данных, для своей настройки требует минимум телодвижений. Включить компрессию для таблицы можно следующим образом: ALTER TABLE Test REBUILD WITH (DATA_COMPRESSION = PAGE);
GO
В этом случае будет сжат либо кластерный индекс таблицы (если он есть) либо данные таблицы хранящиеся в куче. Здесь нужно помнить, что некластерные индексы не будут сжаты в этом случае. А при использовании индексов с конструкцией INCLUDE это может быть довольно значительный объём данных. Более подробно о сжатии таблиц, индексов и различных аспектов, связанных со сжатием можно почитать здесь - Создание сжатых таблиц и индексов. Я же хочу показать свой вариант сжатия всей базы данных одним махом  Для этого я использую недокументированную процедуру sp_MSforeachtable (вместо символа вопроса хранимка подставляет имя таблицы, таким образом код выполняется для всех таблиц в базе данных):
EXEC sp_MSforeachtable 'ALTER INDEX ALL ON ? REBUILD WITH (DATA_COMPRESSION = PAGE)'
GO
Таким образом мы убиваем двух зайцев – кластерные и некластерные индексы , при этом код получился довольно элегантным. Единственным исключением такого кода будет то, что таблицы без кластерного индекса останутся не сжатыми.
Посмотреть фактический объём данных базы можно при помощи следующего скрипта:
CREATE TABLE #t (name SYSNAME, rows CHAR(11), reserved VARCHAR(18),
data VARCHAR(18), index_size VARCHAR(18), unused VARCHAR(18))
EXEC sp_msforeachtable 'INSERT INTO #t EXEC sp_spaceused ''?'''
SELECT SUM(CONVERT(INT, SUBSTRING(data, 1, LEN(data)-3))) FROM #t
DROP TABLE #t
Запустив этот скрипт до и после компрессии, можно посмотреть эффект, произведённый сжатием. На моих базах (размером от 10-и до 50 Гб) объём данных уменьшился примерно на одну четвёртую. Также вы может сделать замеры показателей использования CPU и памяти в моменты нагрузки системы и сравнить их с показателями до включения сжатия. Напоследок хочу сказать, что недостатков включения компрессии я не почувствовал, только преимущества . Система работает стабильно уже на протяжении нескольких недель, что не может не радовать Но в то же время, на нашем сервере, на котором стоит сиквел, процессор используется далеко не по полной. И я бы не рекомендовал рисковать и включать компрессию на системах с дефицитом процессорного времени.
Ссылки по теме:
- Создание сжатых таблиц и индексов
- Реализация сжатия строк
- Реализация сжатия страниц
- Data Compression: Why Do we need it?
- Сжатие в Microsoft SQL Server 2008
|
-
Здравствуйте, друзья! Сегодня я хочу рассказать о довольно значимом для меня событии – присвоении мне статуса MVP. Совсем недавно, сидя на работе, я поздравлял коллег с реноминацией, и тут в мой почтовый ящик упало письмо которое начиналось так: “Dear Denys Rieznik, Congratulations! We are pleased to present you with the 2010 Microsoft® MVP Award!”. Сердце забилось быстрее… Я MVP! Какое-то время я привыкал к новому статусу, и вот сейчас, когда эмоции немного поутихли, по просьбам участников сообщества, я хочу рассказать о себе и о том, как я получил статус MVP. Цитата: Корпорация Майкрософт присваивает статус MVP (Most Valuable Professionals) специалистам в области технологий за их выдающийся вклад в жизнь всемирного технического сообщества. О том кто такие MVP и как пополнить их ряды, я писать не буду, но об этом можно прочесть в блоге нашего MVP Lead Юлии Беляниной – “Как стать звездой”. В этом посте я расскажу о своём пути к Microsoft MVP. Я считаю, что мой путь к MVP начался с тех пор, как я понял, что SQL Server это моё. Это то, что мне нравится, это та технология, с которой я хочу работать и совершенствовать свои навыки. Вся моя карьера в IT была так или иначе связана с SQL Server: учёба, работа, обучение (уже в качестве тренера). И в определённый момент времени, я понял, что я достиг определённого уровня знаний, который позволял мне не только успешно справляться с различными задачами, но и помогать другим в их решении. У меня спрашивали совета коллеги по работе, со мной советовались ребята из других фирм. Я начал вести свой блог, отвечать на форумах, чуть позже выступать на встречах юзер-группы UNETA. Я отчётливо помню свои первые чувства. Это чувства и мысли такого плана: “А вдруг это никому не интересно? А вдруг, то что я рассказываю никому не нужно? Зачем вообще писать посты о том, вот я выступил на встрече юзер-группы, вот материалы моего доклада” и т.д. и т.п. Но каждый раз, после выступления или другого проявления активности ничего страшного не происходило, и даже наоборот! Многим нравились доклады, посты, ответы на форумам многим помогли. И в один прекрасный день, я проснулся утром от телефонного звонка Сергея Байдачного: «Добрый день, Денис. Вы писали на своём блоге о том, что выступали на встрече UNETA с докладом по SQL Server 2008 R2. Не хотите ли выступить с этим же докладом у нас в Киеве на Developer Days». Да! Конечно хочу! Опыта выступлений на таком уровне у меня не было, но я поехал и выступил. С тех пор я не задаю себе вопрос о том, стоит ли писать в блоге о прошедшей встрече юзер-группы, и о том нужно ли это кому-то. Я просто получаю удовольствие от публичных выступлений, от того, что пишу в блог интересные и полезные статьи, от того что моё сообщение на форумах помечают как ответ. И поверьте мне, это кайф! И я полностью согласен с теми, кто считает, что MVP это стиль жизни. Да, это награда. Да, это признание со стороны Майкрософт и цель для многих специалистов. Но кроме этого это ещё и состояние души.
|
-
Null Bitmap хранят в себе информацию о том, какие столбцы в записи имеют значение null. Это сделано в целях повышения производительности и позволяет избавиться от чтения всех записей центральным процессором когда нулловые столбцы присутствуют в списке выборки – это позволяет минимизировать использование кэша процессора (здесь можно почитать о работе кэшей процессора и о MESI протоколе). И всвязи с этим, существует три мифа, которые будут развенчаны прямо сейчас: Миф №6a – Null Bitmap создаётся не всегда FALSE Null Bitmap *всегда* существует в каждой записи данных (в куче, или на листовом уровне кластерного индекса) – даже если таблица не содержит нулловых столбцов. В то же время Null Bitmap *не* всегда присутствует в индексных записях (листовой уровень некластерного индекса, не листовой уровень кластерного и некластерного индекса). Всё это довольно легко проверить при помощи следующего скрипта: CREATE TABLE NullTest (c1 INT NOT NULL);
CREATE NONCLUSTERED INDEX
NullTest_NC ON NullTest (c1);
GO
INSERT INTO NullTest VALUES (1);
GO
EXEC sp_allocationMetadata 'NullTest';
GO
Используйте ID страницы, полученные в результате выполнения sp_allocationMetadata (столбец First Page), в следующем скрипте:
DBCC TRACEON (3604);
DBCC PAGE (foo, 1, 152, 3); -- page ID from SP output
where Index ID = 0
DBCC PAGE (foo, 1, 154, 1); -- page ID from SP output
where Index ID = 2
GO
Примечание: синтаксис DBCC PAGE: DBCC PAGE('имя_базы_данных' | id_базы_данных, номер_файла, номер_страницы, формат). Подробнее о DBCC PAGE можно почитать здесь – How to use DBCC PAGE. В выводе sp_allocationMetadata First Page будет представлена в следующем виде: (1:80), где 1– номер файла, 80– номер страницы.
Теперь смотрим на первый дамп DBCC PAGE, который соответствует записи кучи:
Slot 0 Offset 0x60 Length 11
Record Type = PRIMARY_RECORD Record Attributes = NULL_BITMAP
Memory Dump @0x685DC060
И на второй, соответствующий записи некластерного индекса:
Slot 0, Offset 0x60, Length 13, DumpStyle BYTE
Record Type = INDEX_RECORD Record Attributes = <<<<<<< No null bitmap
Memory Dump @0x685DC060
Миф №6b – Null Bitmap содержит биты только для нулловых колонок
FALSE
Null Bitmap, когда существует, содержит по биту на каждую колонку, плюс 'заполняющие' биты для несуществующих полей для того, чтобы полностью заполнить байт в Null Bitmap. Я уже развенчивал этот миф в своём старом посте - Misconceptions around null bitmap size.
Миф №6c – Добавление в таблицу новой строки приводит к немедленному выполнению size-of-data операции
FALSE
Единственный случай, когда добавление в таблицу нового поля приводит к выполнению size-of-data операции (операции, которая затрагивает каждую строку таблицы) это добавление столбца, имеющего значение по умолчанию отличное от NULL. В остальных случаях Storage Engine запоминает что есть один или несколько столбцов, которые в действительности могут не присутствовать в записях таблицы. Я объяснял это более детально в своём посте Misconceptions around adding columns to a table.
Об авторе:
Пол С. Рэндал (Paul S. Randal) — генеральный директор SQLskills.com является MVP по SQL Server. Он работал в группе подсистемы хранилища SQL Server в корпорации Майкрософт с 1999 по 2007 г. Пол является автором DBCC CHECKDB/восстановления SQL Server 2005 и в ходе разработки SQL Server 2008 отвечал за программу базовой подсистемы хранилища. Пол является специалистом по аварийному восстановлению, высокой доступности и обслуживанию базы данных и часто дает презентации на различных конференциях по всему миру. Он ведет блог по адресу SQLskills.com/blogs/paul.
Ссылки по теме:
- Оригинал статьи
- Misconceptions around null bitmap size
- Misconceptions around adding columns to a table
- How to use DBCC PAGE
- Ковыряем DBCC PAGE
|
-
Миф №5 – AWE (Address Windowing Extensions) должны быть включены на 64-битных серверах FALSE Существует *большая* путаница, относительно настроек AWE, блокировок страниц, того что работает/неработает и того что нужно/не нужно на 32-х битных и 64-х битных серверах разных редакций. В двух словах: - На 64-битных системах (2005 +): - Включение AWE не обязательно (более того, это ничего не даст) - Включение параматра "Locked Pages in Memory" препятствует выгрузке страниц из буферного пула - Когда включен параметр "Locked Pages in Memory", SQL Server использует Windows AWE API для резервирования памяти, так как это работает немного быстрее - "Locked Pages in Memory" поддерживается в Standard и Enterprise Edition (в этом посте рассказано о том, как включить это в Standard Edition) - На 32-битных системах (2005 +): - AWE должно быть включено для использования расширенного виртуального адресного пространства Примечание: Фактически это означает использование более 3-х Гб оперативной памяти
- Параметр "Locked Pages in Memory" должен быть включен до включения AWE
- AWE поддерживается в Standard и Enterprise Editions
Неудивительно, что это немного приводит в замешательство!
Об авторе:
Пол С. Рэндал (Paul S. Randal) — генеральный директор SQLskills.com является MVP по SQL Server. Он работал в группе подсистемы хранилища SQL Server в корпорации Майкрософт с 1999 по 2007 г. Пол является автором DBCC CHECKDB/восстановления SQL Server 2005 и в ходе разработки SQL Server 2008 отвечал за программу базовой подсистемы хранилища. Пол является специалистом по аварийному восстановлению, высокой доступности и обслуживанию базы данных и часто дает презентации на различных конференциях по всему миру. Он ведет блог по адресу SQLskills.com/blogs/paul.
Ссылки по теме:
- Оригинал статьи
- Fun with Locked Pages, AWE, Task Manager, and the Working Set…
- SQL SERVER – AWE (Address Windowing Extensions) Explained in Simple Words
- How to: Enable the Lock Pages in Memory Option (Windows)
- AWE и locked pages in memory на 64-х битной платформе
|
-
Миф №4 – DDL триггеры (появились в SQL Server 2005) являются INSTEAD OF триггерами FALSE DDL триггеры в SQL Server реализованы как AFTER триггеры. Это означает то, что возникающие операции перехватываются DDL триггером (и опционально откатываются, если вы включили инструкцию ROLLBACK в тело триггера). А это значит, что они не такие легковесные, как можно подумать. Представьте себе такую операцию: ALTER TABLE MyBigTable ADD MyNewNonNullColumn VARCHAR (20) DEFAULT 'Paul';
В этом случае, если DDL триггер навешен на событие ALTER_TABLE, или что-нибудь более специфическое, вроде DDL_TABLE_EVENTS, мы получим следующее: каждая строка таблицы будет расширена, чтобы принять в себя новую колонку (так как она имеет не нулловое значение по умолчанию), и только после этого сработает триггер и ваша операция откатится. Согласитесь, это не есть хорошо (попробуйте сами и посмотрите лог при помощи fn_dblog – вы увидите откат операции).
В этом случае будет лучше явно выдавать разрешения на ALTER операции, или создавать хранимые процедуры, при помощи которых выполнять только заранее определённые DLL операции.
В любом случае, DDL триггеры позволяют эффективно реализовать откат операции, но довольно дорогой ценой. К тому же, они позволяют реализовать аудит действий, происходящих на сервере.Так что, я не говорю: "Не используйте", – просто будьте осторожны.
Об авторе:
Пол С. Рэндал (Paul S. Randal) — генеральный директор SQLskills.com является MVP по SQL Server. Он работал в группе подсистемы хранилища SQL Server в корпорации Майкрософт с 1999 по 2007 г. Пол является автором DBCC CHECKDB/восстановления SQL Server 2005 и в ходе разработки SQL Server 2008 отвечал за программу базовой подсистемы хранилища. Пол является специалистом по аварийному восстановлению, высокой доступности и обслуживанию базы данных и часто дает презентации на различных конференциях по всему миру. Он ведет блог по адресу SQLskills.com/blogs/paul.
Ссылки по теме:
- Оригинал статьи
- "EXECUTE AS" and an important update your DDL Triggers (for auditing or prevention)
- Триггеры DDL
|
-
Выход SQL Azure я считаю знаменательным событием. Это новая веха в развитии технологий баз данных. Но наряду со всеми своими преимуществами SQL Azure имеет и ряд недостатков, одним из которых является мониторинг производительности. Здесь у нас нет ни Profiler, ни Activity Monitor, ни Performance Data Collection. И, изначально, не было Dynamic Management Views, которые могли бы помочь в выявлении проблем с производительностью. Причина того, что DMV's не было изначально в SQL Azure, заключается в распределённой архитектуре SQL Azure и в необходимости доработки этого механизма под SQL Azure. Работы в этой области ведутся и сейчас уже доступен небольшой набор DMV's которыми можно пользоваться в SQL Azure. Итак, вот они: - sys.dm_tran_active_transactions - sys.dm_tran_database_transactions - sys.dm_tran_locks - sys.dm_tran_session_transactions - sys.dm_exec_connections - sys.dm_exec_query_stats - sys.dm_exec_requests - sys.dm_exec_sessions - sys.dm_exec_sql_text - sys.dm_exec_text_query_plan - sys.dm_db_partition_stats Более полную информацию о DMV's, доступных в SQL Azure, и о способах их применения можно прочесть в недавно вышедшей Whitepaper от команды SQL Azure - "Troubleshooting and Optimizing Queries with SQL Azure". Ссылки по теме: - Troubleshooting and Optimizing Queries with SQL Azure - Скачать Troubleshooting and Optimizing Queries with SQL Azure Whitepaper - Monitoring SQL Azure Using Dynamic Management Views - Портал SQL Azure - SQL Azure Developer Portal
|
-
Итак, на подходе третий миф, встречайте! Миф №3 – Мгновенная инициализация файлов может быть a) включена и b) выключена из SQL Server a) FALSE b) TRUE соответственно Мгновенная инициализация – не очень известная возможность SQL Server (2005/2008), которая позволяет избежать инициализации файла данных (неприменимо к файлам лога транзакций) нулями при операциях с ним (создание БД, увеличение размера БД, и т.д.). Это потрясающий способ уменьшить время простоя при восстановлении после сбоя, когда нужно восстанавливать базу с нуля – так как создание файлов не будет занимать часы (возможно) для инициалиции нулями до того, как начнётся сама операция восстановления. Вы *не можете* включить мновенную инициализацию файлов из SQL Server, т.к. SQL Server проверяет только один раз (при старте) то, что у пользователя под которым запущена служба SQL Server есть необходимые права на уровне операционной системы (Perform Volume Maintenance Tasks a.k.a. SE_MANAGE_VOLUME_NAME) и что мгновенная инициация файлов включена для экземпляра. На эту тему есть отличный пост Kimberly Tripp - Instant Initialization - What, Why, and How, в котором подробно рассказывается об этой возможности и о том как её включить. Вы *можете* проверить включена ли мновенная инициализация файлов из SQL Server. Для этого нужно включить флаг трассировки 3004 (и 3605 для того, чтобы output писался в errorlog), после чего создать новую базу данных. В errorlog вы увидите сообщения о том, что файл лога инициализирован нулями. Если мгновенная инициализация файлов НЕ включена, в логе также будут видны сообщения о том, что файл данных инициализирован нулями. Вы *можете* выключить мновенную инициализацию файлов из SQL Server (но только временно). Включение флага трассировки 1806 отключит мгновенную инициализацию файлов, пока флаг будет включён. Для полного отключения необходимо отключить необходимые права на уровне операционной системы. Если у вас есть возможность включить эту функциональность – включите её! Об авторе: Пол С. Рэндал (Paul S. Randal) — генеральный директор SQLskills.com является MVP по SQL Server. Он работал в группе подсистемы хранилища SQL Server в корпорации Майкрософт с 1999 по 2007 г. Пол является автором DBCC CHECKDB/восстановления SQL Server 2005 и в ходе разработки SQL Server 2008 отвечал за программу базовой подсистемы хранилища. Пол является специалистом по аварийному восстановлению, высокой доступности и обслуживанию базы данных и часто дает презентации на различных конференциях по всему миру. Он ведет блог по адресу SQLskills.com/blogs/paul. Ссылки по теме: - Оригинал статьи - Мгновенная инициализация - Что, Почему и Как - Инициализация файлов базы данных - Misconceptions around instant file initialization
 Денис Резник .Net Team Lead at LPP Soft Trainer at Microsoft Innovation Center Харьков, Украина
|
|
|