Ага, нашел. Все зависит от приоритетов типов данных. Типы данных с более низким приоритетом, приводятся к типам с более высоким. В статье тип столбца 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 (ну, естественно, кроме тех, которые уже участвуют в этой сессии зеркалирования).
Делать-то особо ничего не надо, но если РКН придет с проверкой надо быть готовым ему это объяснить и, вероятно, доказать. Т.е. какой-то набор документов все равно должен иметься.
ну, в общем, согласен. Но фактически, о подготовке задумались только в прошлом году (и вопрос почему так поздно уже не ко мне :) — долго телепались юристы и руководство)
Ну не совсем так. ФИО и дата рождения — это очень даже персональные данные. Просто относятся они к категории 4 — обезличенные или общедоступные. А то о чем говорите вы — это персональные данные категории 3 — позволяющие однозначно идентифицировать субъекта. Классификация ПДн и ИСПДн
C нуля — естественно не факт, но речь шла не об этом.
Мне вообще кажется, что для систем которые только создаются намного легче соответствовать 152 ФЗ. Если бы он появился лет 10 назад, когда инфраструктура нашего предприятия только создавалась, нам было бы намного легче. Например, мы могли бы засунуть в отдельное помещение отдел кадров и зарплатчиков, по другому планировать схемы БД и многое другое. А вот сейчас, перестраивать имеющуюся систему намного сложнее.
Я рад за вас что они уже есть. Мы про вас или про вообще?
Вообще-то, я про себя. И про тех, у кого уже используется лицензионное, но не сертифицированное ФСТЭК ПО.
Вы уверены что у вас все приобретенные Windows той версии? :)
Да, уверен. Им наплевать, на самом деле, на дистрибутив. Главное, чтоб на диске было написано Service Pack 2 или Service Pack 3.
Хорошо. Это произошло что дальше? Кем осуществляется поддержка, откуда берутся обновления и кем после обновления подтверждается что у вас все еще все сертифицировано? :)
О да. Это отдельный разговор. У них какое-то свое ПО для обновлений. Есть даже возможность централизованной установки этих обновлений. Что-то типа своего WSUS'a с преферансом и девицами.
Сами сертифицированные обновления входят во все пакеты (состав пакетов), а вот софтину надо покупать.
В зеркале, кстати, в случае 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 (ну, естественно, кроме тех, которые уже участвуют в этой сессии зеркалирования).
Классификация ПДн и ИСПДн
Мне вообще кажется, что для систем которые только создаются намного легче соответствовать 152 ФЗ. Если бы он появился лет 10 назад, когда инфраструктура нашего предприятия только создавалась, нам было бы намного легче. Например, мы могли бы засунуть в отдельное помещение отдел кадров и зарплатчиков, по другому планировать схемы БД и многое другое. А вот сейчас, перестраивать имеющуюся систему намного сложнее.
Вообще-то, я про себя. И про тех, у кого уже используется лицензионное, но не сертифицированное ФСТЭК ПО.
Да, уверен. Им наплевать, на самом деле, на дистрибутив. Главное, чтоб на диске было написано Service Pack 2 или Service Pack 3.
О да. Это отдельный разговор. У них какое-то свое ПО для обновлений. Есть даже возможность централизованной установки этих обновлений. Что-то типа своего WSUS'a с преферансом и девицами.
Сами сертифицированные обновления входят во все пакеты (состав пакетов), а вот софтину надо покупать.