То что вьюхи полезны — я не спорю и рассматривать нужно каждый случай отдельно. Вполне вероятно, что автор самой статьи тоже не против такого подхода.
Возможно, это моя вина, как переводчика, что я не смог этого передать — читая саму статью, у меня не возникало мыслей, что от представлений вообще надо отказываться. Сорри.
Теперь к примеру.
Вот диаграмма с этими таблицами — FK есть.
Теперь запросы:
SELECT OrderDate
FROM
(
SELECT soh.SalesPersonID,
a.City,
soh.OrderDate,
soh.PurchaseOrderNumber,
soh.AccountNumber,
sd.OrderQty,
sd.UnitPrice
FROM Sales.SalesOrderHeader AS soh
JOIN Person.Address AS a
ON soh.ShipToAddressID = a.AddressID
JOIN Sales.SalesOrderDetail AS sd
ON soh.SalesOrderID = sd.SalesOrderID
)temp
WHERE SalesPersonID=277
Время выполнения 74 миллисекунды, 960 операций чтения.
SELECT soh.OrderDate
FROM Sales.SalesOrderHeader AS soh
WHERE soh.SalesPersonID = 277 ;
Время выполнения 59 мс, 703 операции чтения
Вместо внутреннего, LEFT JOIN:
SELECT OrderDate
FROM
(
SELECT soh.SalesPersonID,
a.City,
soh.OrderDate,
soh.PurchaseOrderNumber,
soh.AccountNumber,
sd.OrderQty,
sd.UnitPrice
FROM Sales.SalesOrderHeader AS soh
LEFT JOIN Person.Address AS a
ON soh.ShipToAddressID = a.AddressID
LEFT JOIN Sales.SalesOrderDetail AS sd
ON soh.SalesOrderID = sd.SalesOrderID
)temp
WHERE SalesPersonID=277
Время выполнения 70 мс, 931 операция чтения.
Скриншот с актуальными планами выполнения (они идут в том же порядке, как у меня перечислены запросы):
Не смотря на то, что выигрыш не настолько велик, как в оригинале, но он все равно есть. Мне кажется, что Грант (автор), поторопился с примером. Поскольку мне пришлось удалить данные из таблицы SalesOrderDetail — так, чтобы одной записи из SalesOrderHeader соответствовала одна запись из SalesOrderDeatil, иначе результаты запросов были разными.
Дак, как бы, в том и смысл, что когда пишем запрос вручную — мы не втыкаем лишние соединения, а когда «относимся ко вьюхам как к таблицам» и выбираем данные из вьюх — от них никуда не денешься.
Если навтыкать соединений — план будет точно такой же, как у запроса из вьюх, поскольку они все равно «разворачиваются» до запросов.
Или я вас не правильно понял?
Ага, нашел. Все зависит от приоритетов типов данных. Типы данных с более низким приоритетом, приводятся к типам с более высоким. В статье тип столбца nvarchar (практически самый низкий приоритет), соответственно он приводится к более высокому int'у. В вашем примере все тоже самое.
А вот, кстати, да. Тут надо будет покопать. Если выполнять пример из статьи — все будет как описано — Index Scan с неверным типом и Index Seek с правильным.
Да понятно, что AlwaysOn — это в разы круче зеркалирования (и, увы, дороже), просто удивило его первоначальное сравнение с репликацией :).
В зеркале, кстати, в случае Enterprise Edition, можно с партнера делать Snapshot'ы и обращаться к ним на чтение, так что не совсем «мертвый груз» :)
1. Ага, но в статье этого нет.
2. Database Mirroring имел «специфические» требования к модели восстановления. Она должна быть полной (про bulk-logged не уверен, но вроде даже в ней нельзя было использовать). Про ваше ИМХО понятно, но советую посмотреть это.
3. «возможность обеспечить отказоустойчивость данных малой кровью» — она была и раньше. Начиная с 2005-го сервера database mirroring работал в Standard и Enterprise редакциях, а вот AlwaysOn — только в Enterprise, плюс подразумевается наличие кластера Windows — а это уже, все-таки, не совсем «малой кровью». Надеюсь, что когда SQL Server окончательно избавится от зеркалирования, в Standard появится урезанная версия ALwaysOn.
Я это все к тому, что последняя фраза очень странная — SQL Server и так был «продуктом Enterprise-уровня».
Функция AlwaysOn (доступная, к слову, только в Enterprise Edition) предназначена для обеспечения отказоустойчивости баз данных.
Мне кажется, стоит добавить, что оно может обеспечивать отказоустойчивость не одной, а нескольких БД. Т.е. в одну Availability Group может входить несколько БД и они будут вместе «переезжать» в случае файловера.
Работает эта технология, осуществляя репликацию базы данных между серверами, точнее — лога транзакций
Эта штука скорее усовершенствованный Database Mirroring, а не репликация и именно из-за нее Database Mirroring в SQL Server 2012 — это «deprecated feature».
Появился функционал, который позволяет не кривя душой называть MS SQL 2012 продуктом Enterprise-уровня, с чем я нас всех и поздравляю.
А без Columnstore индексов нельзя было назвать MS SQL Server продуктом Enterprise уровня? AlwaysOn не считаем, поскольку он является фактически эволюционировавшим зеркалированием, которое появилось еще в 2005-м SQL Server.
Сорри, за долгое молчание, пропустил письмо с уведомлением о комменте.
Да, конечно, все SQL Server'а в сети вы можете найти, запустив sqlcmd (или osql) с параметром -L. Работает, ЕМНИП, только в том случае, когда запущены службы SQL Server Browser на всех машинах с SQL Server.
Плюс, хочу заметить, что в моем посте выводятся не все доступные SQL Server'а, а только те, которые зарегистрированы в SSMS на моей машине.
Это да. Изменение настроек почтового сервера может печально сказаться и обязательно обнаружится в самый неподходящий момент. У меня такой проблемы нет, поскольку кроме сообщений об ошибках, ко мне каждый день приходят письма с информацией о фрагментации индексов, удаленных бэкапах и состоянии зеркала за прошедшие сутки. Соответственно, если хоть одного из этих писем не будет — это уже будет поводом разбираться что там произошло.
Если сообщения отправляются с помощью алертов, в настройках алерта есть такая вещь как Delay between responses. Вроде то что вам надо.
Если сообщения отправляются из какого-нибудь, например, собственного джоба, через sp_send_dbmail — можно извратиться, создать табличку, пихать в нее время последней отправки и проверять перед отправкой, что прошло не меньше N минут.
Самым правильным вариантом, имхо, будет — найти причину задержек и «победить» ее. Либо изменить «критические» значения, при которых производится отправка сообщения, если система при них работает нормально.
А вы ответ провайдера об обрабатываемых ПДн получили в срок? Или после того как интернет появился — это уже стало неактуально?
Выше я просто пытался «влезть в шкуру» провайдера и оценить последствия от получения претензии и запроса. Доказать-то докажут, но проверка может уже начаться. А лишние проверки, даже если все хорошо, радости никому не доставляют.
Вы, имхо, путаете теплое с мягким. Для того, чтобы проверять исполнение этого закона есть аж три органа — РКН, ФСТЭК и ФСБ. Автор, насоклько я понимаю, к этим органам не относится (а если и относится, то действовал он как частное лицо). Договор между провайдером и автором заключался, следовательно согласия автора не требуется для обработки ПДн. Просто там, видимо, испугались письма в РКН — ибо кто его знает — ответ ему отправишь, а он все равно скажет, что ничего не приходило. Начнется проверка, увидят, что ответ-то приходил, но кучу других косяков найдут обязательно.
Если автор недоволен обслуживанием (провайдер не исполняет свои обязательства), пусть собирает доказательства и подает в суд.
А эта ситуация реально напоминает шантаж. Если бы претензия по качеству обслуживания и требование предоставить информацию по обрабатываемым ПДн предоставлялись в разное время — никаких вопросов бы не было.
Кстати, вопрос автору: ответ по ПДн от провайдера пришел? Есть уверенность, что руководитель службы ТП связался из-за 152 ФЗ, а не из-за претензии?
Защищённый с автоматическим восстановлением требует для автоматического восстановления использовать 3-й сервер (следящий) и в принципе полезен только если у вас в приложении можно указать резервный сервер для переключения в случае когда не работает основной.
Ну в общем-то резервный сервер далеко не всегда надо прописывать...msdn:Using Database Mirroring Да и «засирание информационного пространства следящим сервером» странная аргументация. Можно ведь использовать любой уже имеющийся в сети SQL Server, в т.ч. Express (ну, естественно, кроме тех, которые уже участвуют в этой сессии зеркалирования).
Делать-то особо ничего не надо, но если РКН придет с проверкой надо быть готовым ему это объяснить и, вероятно, доказать. Т.е. какой-то набор документов все равно должен иметься.
ну, в общем, согласен. Но фактически, о подготовке задумались только в прошлом году (и вопрос почему так поздно уже не ко мне :) — долго телепались юристы и руководство)
Возможно, это моя вина, как переводчика, что я не смог этого передать — читая саму статью, у меня не возникало мыслей, что от представлений вообще надо отказываться. Сорри.
Теперь к примеру.
Вот диаграмма с этими таблицами — FK есть.
Теперь запросы:
Время выполнения 74 миллисекунды, 960 операций чтения.
Время выполнения 59 мс, 703 операции чтения
Вместо внутреннего, LEFT JOIN:
Время выполнения 70 мс, 931 операция чтения.
Скриншот с актуальными планами выполнения (они идут в том же порядке, как у меня перечислены запросы):
Не смотря на то, что выигрыш не настолько велик, как в оригинале, но он все равно есть. Мне кажется, что Грант (автор), поторопился с примером. Поскольку мне пришлось удалить данные из таблицы SalesOrderDetail — так, чтобы одной записи из SalesOrderHeader соответствовала одна запись из SalesOrderDeatil, иначе результаты запросов были разными.
Если навтыкать соединений — план будет точно такой же, как у запроса из вьюх, поскольку они все равно «разворачиваются» до запросов.
Или я вас не правильно понял?
В зеркале, кстати, в случае Enterprise Edition, можно с партнера делать Snapshot'ы и обращаться к ним на чтение, так что не совсем «мертвый груз» :)
2. Database Mirroring имел «специфические» требования к модели восстановления. Она должна быть полной (про bulk-logged не уверен, но вроде даже в ней нельзя было использовать). Про ваше ИМХО понятно, но советую посмотреть это.
3. «возможность обеспечить отказоустойчивость данных малой кровью» — она была и раньше. Начиная с 2005-го сервера database mirroring работал в Standard и Enterprise редакциях, а вот AlwaysOn — только в Enterprise, плюс подразумевается наличие кластера Windows — а это уже, все-таки, не совсем «малой кровью». Надеюсь, что когда SQL Server окончательно избавится от зеркалирования, в Standard появится урезанная версия ALwaysOn.
Я это все к тому, что последняя фраза очень странная — SQL Server и так был «продуктом Enterprise-уровня».
Мне кажется, стоит добавить, что оно может обеспечивать отказоустойчивость не одной, а нескольких БД. Т.е. в одну Availability Group может входить несколько БД и они будут вместе «переезжать» в случае файловера.
Эта штука скорее усовершенствованный Database Mirroring, а не репликация и именно из-за нее Database Mirroring в SQL Server 2012 — это «deprecated feature».
А без Columnstore индексов нельзя было назвать MS SQL Server продуктом Enterprise уровня? AlwaysOn не считаем, поскольку он является фактически эволюционировавшим зеркалированием, которое появилось еще в 2005-м SQL Server.
>>И ничего нигде не надо регистрировать.
Я вас и не заставляю. Лично мне удобно иметь быстрый доступ к нужным мне серверам.
Да, конечно, все SQL Server'а в сети вы можете найти, запустив sqlcmd (или osql) с параметром -L. Работает, ЕМНИП, только в том случае, когда запущены службы SQL Server Browser на всех машинах с SQL Server.
Плюс, хочу заметить, что в моем посте выводятся не все доступные SQL Server'а, а только те, которые зарегистрированы в SSMS на моей машине.
Пруф
Если сообщения отправляются из какого-нибудь, например, собственного джоба, через sp_send_dbmail — можно извратиться, создать табличку, пихать в нее время последней отправки и проверять перед отправкой, что прошло не меньше N минут.
Самым правильным вариантом, имхо, будет — найти причину задержек и «победить» ее. Либо изменить «критические» значения, при которых производится отправка сообщения, если система при них работает нормально.
Выше я просто пытался «влезть в шкуру» провайдера и оценить последствия от получения претензии и запроса. Доказать-то докажут, но проверка может уже начаться. А лишние проверки, даже если все хорошо, радости никому не доставляют.
Если автор недоволен обслуживанием (провайдер не исполняет свои обязательства), пусть собирает доказательства и подает в суд.
А эта ситуация реально напоминает шантаж. Если бы претензия по качеству обслуживания и требование предоставить информацию по обрабатываемым ПДн предоставлялись в разное время — никаких вопросов бы не было.
Кстати, вопрос автору: ответ по ПДн от провайдера пришел? Есть уверенность, что руководитель службы ТП связался из-за 152 ФЗ, а не из-за претензии?
Ну в общем-то резервный сервер далеко не всегда надо прописывать...msdn:Using Database Mirroring Да и «засирание информационного пространства следящим сервером» странная аргументация. Можно ведь использовать любой уже имеющийся в сети SQL Server, в т.ч. Express (ну, естественно, кроме тех, которые уже участвуют в этой сессии зеркалирования).