Подборка постов по SQL Server за неделю

Из-за болезни, на прошлой неделе, по работе не читал вообще ничего, а ссылки, тем временем, всё копились и копились. В итоге, большая подборка, за две недели.

1. Twitter Talk Theatre, Episode 1: “RAID is good enough!” - небольшой опрос Jen McCown  на тему - почему наличие RAID-массива не отменяет необходимости в бэкапах.

2. FAQ around sys.dm_db_index_usage_stats - Nacho Alonso Portillo отвечает на вопросы о sys.dm_db_index_usage_stats - DMV, предоставляющем информацию об использовании индексов.

3. Steps to Move SQL Server Log Shipping Secondary Database Files - Jugal Shah о том, как изменить физическое расположение БД, задействованной в log shipping, не перенастраивая этот самый log shipping.

4. How to recover a SQL Server login password - Geoff Albin о том насколько сложно "взломать" пароль, зная его хэш.

5. Hidden Tricks To SQL Server Table Cleanup. Как быстро удалить множество записей из таблицы? Об этом пишет Edward Polley.

6. Benchmark SQL Server Disk Latency - John Sterrett о том, как оценить производительность (точнее latency - задержки) жёстких дисков с помощью встроенных средств SQL Server.

7. Deleting large number of rows from a table in a VLDB - ещё один пост об удалении большого количества записей. На этот раз от Nakul Vachhrajani.

8. Transaction Log Configuration Issues - у журнала транзакций не так уж много настроек, но и их достаточно для того, чтобы обрести проблемы с производительностью. Как этого избежать рассказывает Paul Randal.

9. A Look At DBCC CHECKCONSTRAINTS and I/O - Erin Stellato пишет о том, как выполнение инструкции DBCC CHECKCONSTRAINTS влияет на производительность системы.

10. Disabling vs. Dropping Indexes - в какой ситуации индекс нужно удалять, а в какой достаточно его запретить? Об этом пост Jes Schultz Borland.

11. Autogrowth option for SQL Server database files - BatuhanYildiz пишет о том как влияют на производительность параметры Autogrowth для файлов данных и журналов транзакций.

12. THAT’S ACTUALLY A DUPLICATE INDEX - Jason Strate об обнаружении дублирующихся индексов.

13. Getting Started with Extended Events in SQL Server 2012 - в SQL Server 2012 появился удобный GUI для работы с Extended Events. Robert Sheldon рассказывает как им пользоваться.

14. Log Shipping Part 2: When Disaster Strikes (video) - получасовое видео от Jes Schultz Borland о том, что делать в случае "пожара" - как мониторить и делать fail-over на другой сервер при наличии Log Shipping.

15. Did You Restore It? - Chris Shaw о необходимости тестирования сделанных бэкапов.

16. Custom Log Shipping - пост от Chris Kempster о том как настроить Log Shipping без GUI.

17. CHECKDB From Every Angle: Complete description of all CHECKDB stages - подробнейшее описание того, как на самом деле работает и что делает DBCC CHECKDB от Paul Randal.

Замена Google Reader

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

Вчера "Авангард" проиграл всухую третий матч в серии с "Трактором" и у меня всплыл ещё один интересный момент из "Чёрного лебедя". Н.Н.Т. там использует такой пример.
Он предлагает двум людям - по одному из Среднестана и Крайнестана - рассчитать вероятность того, что при подкидывании монетки на 100-й раз выпадет решка. При этом уточняет, что монетка у него идеально сбалансированная, но при предыдущих 99-ти подкидываниях подряд, выпадал только орёл. Человек из Среднестана, по его словам, даст вероятность выпадения решки 50%, а человек из Крайнестана скажет, что такая вероятность не больше 1%, поскольку, раз в предыдущих 99-ти опытах подряд выпадали только орлы, то либо с монеткой что-то не так, либо подкидывающий хитрит.
И вот глядя на игры "Авангарда", я думаю, что если "монетку или подкидывающего не заменят", то сегодня шанс выиграть у нас не более 1%.

Ошибки восприятия

За время проведённое на больничном, полезного я сделал совсем немного. Даже больше - совсем ничего. Единственное, что было несколько полезно для меня - это то, что я прочёл "Чёрного лебедя" Талеба.
Первое упоминание об этой книге я увидел в компьютерре совсем недавно, потом статьи в википедии и по ссылкам оттуда. Ну и в конце концов, добрался до книги.
Читалась она, надо сказать, тяжело. Вроде бы и нет формул, нет каких-то совсем уж "заумностей", но шла она с огромным трудом. Свою роль в этом, наверное, сыграло то, что читал я книгу на телефоне и вернуться к предыдущим главам, чтобы что-то уточнить было тяжелее, чем с бумагой (пролистать бумажную книгу и найти интересующий фрагмент гораздо удобнее). Боюсь, что понял я из этой книги совсем немного.
Не буду сейчас говорить о самих "чёрных лебедях" (хотя, по сути, сам мой больничный, лично для меня, стал таким "чёрным лебедем", хотя жена сказала - "Ну я же говорила, что надо было к врачу идти раньше"). Меня заинтересовала в книге мысль об ошибках восприятия (или интерпретации) - это термин не из книги, не помню как там это звучало, а моя "интерпретация". Суть в следующем: Н.Н.Т. (как сам себя именует автор в книге) приводит такой пример - у человека с подозрением на рак берут часть клеток (пункция, или как там это называется) и, если в этом образце раковых клеток не обнаружено, говорят, что раком он не болен. Но это не обязательно правда. Вот если бы раковые клетки были обнаружены - тогда можно было бы со стопроцентной уверенностью сказать, что рак есть. Но то, что во взятой пробе не обнаружено раковых клеток, вовсе не означает, что их нет в "соседних" клетках. И мы, в своей жизни, часто ошибаемся таким образом.
Меня этот пример заинтересовал вот чем. У SQL Server есть такое свойство БД как "модель восстановления" (возможно, однажды я-таки подробно их разберу). Внешне у них есть такое различие. Если у БД стоит "простая" (simple recovery model) модель восстановления, её журнал транзакций, обычно, представляет собой небольшой файл, который не растёт с течением времени. Если же у БД "полная" (full recovery model) модель восстановления, то её журнал транзакций постоянно увеличивается в размерах (при определённых условиях, но эти условия обычно возникают именно у тех, кто допускает ту самую ошибку восприятия о которой я расскажу чуть дальше).
Т.е., если представить, что на одном сервере баз данных есть две абсолютно одинаковых БД, в которых одними и теми же людьми производятся одни и те же действия, то у БД1 (с моделью восстановления simple) журнал транзакций будет занимать, например, 256 мегабайт, какие бы действия с базой не производились, а у БД2 (с моделью восстановления full), при тех же самых действиях с БД, журнал транзакций может, через какое-то время, занимать и 100 гигабайт и продолжит расти до тех пор, пока не займёт всё свободное место на жёстком диске. Человек, понимающий как работает SQL Server с моделями восстановления, не увидит в этом ничего удивительного, а человек, не знающий этих "особенностей" часто делает такой вывод:
При использовании модели восстановления simple, SQL Server не использует журнал транзакций (ничего не записывает в журнал транзакций), объясняя это тем, что журнал транзакций, с течением времени, не изменяется в размерах.
Этот пример всплыл у меня в памяти, потому что я неоднократно разубеждал в этом пользователей на форумах, но не уверен, что у меня получалось.
Вообще любопытно. Надо внимательнее понаблюдать за собой, вполне вероятно, что у меня так же куча "ошибок восприятия".

Подборка постов по SQL Server за неделю

Очередная подборка постов по SQL Server, понравившихся мне на этой неделе.

1. Полезная информация по зеркальному отображению баз данных от Don Castelino.

2. Как и что именно хранится в файлах MDF и LDF, плюс 30 минутный вебинар, посвящённый этой же теме от Brent Ozar.

3. Как узнать сколько ещё будет работать SQL Server Evaluation Edition пишет G Bowerman. 

4. Отличная серия постов по disaster recovery от Robert Davis ("зеркало").

5. В том случае, если нужно установить несколько SQL Server с одинаковыми настройками, поможет пост Jugal Shah. 

6. Пост о влиянии плана энергосбережения процессора на производительность SQL Server от Bradley Ball.

7. Ещё один вебинар от Brent Ozar, на этот раз посвящённый настройке log shipping.

8. Отличный каталог утилит (как платных, так и бесплатных) для SQL Server на mssqltips.com.

9. 15 вопросов и ответов для интервьюирования разработчиков SQL Server от Thomas Kovarik.