Подборка постов по 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.

Открыл для себя очередную группу - Blackfoot Sue. Напоминают, временами, горячо любимых Slade.

Лучшее из того, что я слушал за последнее время.

ДДУ, 214 ФЗ и прочая непонятная хрень

В начале ноября заключили договор уступки на покупку квартиры по договору долевого участия в строительстве, зарегистрировали в юстиции, посмотрели сроки сдачи 14.01.2013-15.02.2013 и были рады.
16.01.2013 позвонил я застройщику и спросил когда уже ключи будут выдавать. А застройщик мне молвит человеческим голосом - а мы из-за декабрьских морозов (видимо, изначально планировалось в Сочи этот дом строить и особенности температурного режима Сибирского Федерального Округа учтены не были) сроки переносим, давайте заключать дополнительное соглашение к договору о переносе сроков. Я у них спрашиваю - а насколько вы сроки переносите? Они отвечают уклончиво, мол, разрешение на строительство у нас выдано сроком до 31.03.2013, вот к этому времени сдать и должны. Я им сказал, что подумаю.
И подумал я вот что - если они мне сами позвонят и предложат подписать доп. соглашение, то я, пожалуй, не буду выпендриваться - всё-таки к тому что сроки сорвут я был готов. Но они звонить всё не решались и подумал я, что пусть так всё и остаётся. Однако, недавно, где-то 20.02.2013, звонят мне родители и говорят, что на моё имя пришло заказное письмо. Поскольку  адрес, при заключении договора, я указывал по прописке (ибо хрен его знает где мы завтра жить будем, а у родителей вроде как стабильность), то подумал, что письмо от застройщика. И вот вчера, 26.02.2013, выяснилось, что был прав.
Получил письмо, а там русским по белому написано, что были произведены замеры квартиры и квартира моя оказалась на 0,7 квадратных метра больше, чем в договоре указано. Т.е. застройщик от меня денюжек на 28,5 тысяч рублей меньше получил, чем хотелось бы. И пишут они, что в течение 20 дней эти деньги они очень бы хотели получить.
А сегодня звонят мне и наивным женским голосом спрашивают когда я буду так добр, что соизволю явиться и подписать доп. соглашение о переносе сроков. Т.е. с меня они деньги хотят в полном объёме получить, а вот за срыв сроков строительства они мне неустойку платить не хотят. В общем, будем смотреть что можно сделать. Вечером надо будет изучить договоры (вчера, увы, не успел) и 214 ФЗ "Об участии в долевом строительстве...", благополучно мной распечатанный.

upd

Сел вечером за изучение ДДУ и договора уступки. В моём ДДУ прописано, что в случае отличия реальной площади от проектной, разница выплачивается либо застройщиком, либо участником долевого строительства, т.е. как и в 214 ФЗ. В интернетах пишут, что обычно добавляется пункт, что такие выплаты не производятся, если реальная площадь отличается меньше чем на 1% от проектной, но у меня этого нет, значит будем платить.
Теперь если дом сдадут не раньше 30.03.2013 - сумма неустойки, которую должен выплатить застройщик за срыв сроков, как раз будет примерно равна сумме которую я им уплачу за доп. площадь. Будем посмотреть.