Плотно работаем с Эком-ом. Техподдержка огонь, как-то днём пытался дозвониться — ждал ответа 50 минут, после 30-й минуты ожидания даже музыка перестала играть. Проблему приняли и неделю не решали. Персональный менеджер уволился, а телефон нового сообщить не могут.
Есть ещё опыт работы с провайдером Доклинк (Сислинк) — днём техподдержка нормальная, ночью и в выходные такие ребята сидят, что хочется головой об стену биться. Если проблема сложнее, чем неправильное заполнение формы на веб-портале — решения нужно ждать до обеда следующего рабочего дня минимум.
Цены с сайтов — это, наверное, круто, но они все готовы двигаться по цене, причём значительно, если объём документов превышает минимальный.
Интеграция с 1С — я видел интеграцию Контура, Экома и Доклинка — это страх божий. У кого-то внешняя обработка, у кого-то отдельная конфигурация и работать со всем этим неудобно жуть.
Индексы лучше создавать после переноса данных — это ускорит сам перенос.
На таблицу-приёмник лучше накладывать блокировку TABLOCK, а БД-приёмник должна быть с моделью восстановления simple или bulk-logged, чтобы sql server мог выполнять insert с минимальным протоколированием.
С identity-колонками по-любому геморрой.
>>7) Готово! Вы перенесли базу из нового сервера SQL в старый, хоть это и считалось невозможным. Причем перенос осуществляется примерно со скоростью передачи данных по сети, т.е. очень быстро.
1) это не считалось невозможным;
2) это гораздо медленнее чем передача данных по сети, особенно в таком исполнении, как в статье.
Понимаю, что прошла куча времени после публикации, но всё-таки оставлю это здесь. Вдруг ещё какой-нибудь слоупок прочитает и ему будет полезно.
Утилита SQL Fragmentation Analyzer, судя по всему, абсолютно бесполезна. На скриншоте большая часть индексов с размером < 64 КБ, т.е. тех, которые занимают меньше 8 страниц данных и, соответственно, хранятся в смешанных экстентах. Как смешнный экстент не дефргаментируй, толку от этого не будет.
Кроме того, сами пороговые значения (threshold) под вопросом. Сам Пол Рэндал писал, что в BOL их написал практически от балды, просто потому, что нужно было что-то написать. Человеку, который понимает какими должны быть эти пороговые значения для его баз данных, такая утилита, скорее всего, не нужна. А тому, кто не понимает — ну, вреда, наверное не будет, но диски он будет насиловать зазря, не понимая, почему этот дурацкий индекс на 30 килобайт никак не удаётся дефрагментировать.
Проблема в том, что если РКН начнёт проверку, гораздо удобнее вывалить ему согласия, чем доказывать, что ПДн обрабатываются согласно договору и согласия не требуется. Не знаю как сейчас, но когда закон вступил в силу, отсутствие согласия РКН воспринимал как нарушение закона о ПДн, даже при наличии договора.
Блин, уже не могу комментарий отредактировать. Не увидел вот это
Рост происходит ночью примерно на объем базы.
99%, что 1С-ники по умным рекомендациям 1С настроили на SQL Server job, который проходит по всем индексам в БД и делает ALTER INDEX REBUILD. В этом случае перевод в SIMPLE должен помочь — ЖТ как вырастет на (объём самого большого индекса в бд)*2, так и останется. Вообще, по хорошему, стоит это переделать — на хабре были посты про переиндексацию.
1% остаётся на то, что регламентное задание в 1С что-то шарашит. В принципе, тут тоже перевод в SIMPLE поможет, ЖТ один раз вырастет на нужный ему объём и больше расти не будет.
Зачем обрезка? Место жалко? Может проще тогда бэкап ЖТ почаще делать?
На то время, пока файл журнала транзакций увеличивается, БД становится доступной только для чтения, все запросы на запись ждут пока операция приращения завершится.
Переведите в simple. Проблема уйдёт.
Журнал транзакций дорастёт до определённого размера (вряд ли он будет превышать 2-3 гб на базе в 20 гб) и устаканится. В simple, при нормальной работе, его размер, примерно будет равен (максимальный объём данных, обрабатываемых в одной транзакции) * 2. Если растёт и не останавливается даже в simple — где-то есть незакрытая транзакция.
Я думаю автор не уделял особого внимания этому запросу. Всё-таки дальше он пишет, что лучше из метаданных брать информацию о количестве записей, а это так — для примера и сравнения сколько времени займёт. Конечно, с dynamic SQL удобнее.
Совершенно верно, запрос сработает только для объектов внутри схемы по-умолчанию — dbo, или внутри схемы текущего пользователя. Для других схем их имя надо указать явно. Более того, все имена объектов нужно заключать в квадратные скобки
Нужно всего лишь поправить запрос для курсора:
Спасибо.
Ну и еще вагон и маленькая тележка замечаний к коду автора статьи
Действительно, код не идеален. Но он рабочий (а там где возможны проблемы — я постарался описать в каких ситуациях они могут возникнуть) и, при необходимости, каждый сможет допилить его под себя без особых проблем.
Окей. Поправлю на «скалярные UDF». Относительно 2012-го сервера — нашёл вот такую штуку и там же в комментах перечислена часть (а может быть и все возможные) причин, из-за которых план может не быть параллельным.
Я при переводе ориентировался на ту статью, на которую ссылался автор поста, а тот, в свою очередь, вот на эту. А в этой последней статье, прилеплена pdf-ка, в которой есть вот такой лист:
Ну и, соответственно, написал про UDF (сорри за длинное объяснение, хотел всю цепочку показать).
Если вы располагаете другой информацией, помогите, пожалуйста, правильно переформулировать 7-й пункт :).
По поводу WITH (NOLOCK) — многие пользуются. На счёт того, что думают, что блокировок никаких не накладывает — тоже есть пример (и не один).
По поводу ORDER BY — никто не говорит, что им нельзя пользоваться. ИМХО, Брент, в своём UPD, достаточно чётко высказал свою позицию — «Если без него можно обойтись, лучше обойтись». Я с ним согласен. Серверу баз данных и так есть чем себя занять, а порядок строк, в ряде случаев важен не с точки зрения логики приложения/запроса, а только для пользователя — вот пусть у этого конкретного пользователя, в этих случаях, и сортируется.
Была такая мысль, но автор, добавляя в «режим автопилота» кластерный индекс (index id = 1), использует такую строку:
DBCC AUTOPILOT (6, 9, 37575172, 1, 0, 0, 0) — Clustered Index with TypeID 6
Хотя тип 6 в sys.indexes никак не может соответствовать кластерному индексу.
А гипотетический индекс (index id = 5) он добавляет строкой:
DBCC AUTOPILOT (0, 9, 37575172, 5, 0, 0, 0) — All other index with TypeID 0
хотя 0 должно быть кучей.
Есть ещё опыт работы с провайдером Доклинк (Сислинк) — днём техподдержка нормальная, ночью и в выходные такие ребята сидят, что хочется головой об стену биться. Если проблема сложнее, чем неправильное заполнение формы на веб-портале — решения нужно ждать до обеда следующего рабочего дня минимум.
Цены с сайтов — это, наверное, круто, но они все готовы двигаться по цене, причём значительно, если объём документов превышает минимальный.
Интеграция с 1С — я видел интеграцию Контура, Экома и Доклинка — это страх божий. У кого-то внешняя обработка, у кого-то отдельная конфигурация и работать со всем этим неудобно жуть.
С такими утилитами сталкиваться пока не приходилось и надеюсь (тьфу-тьфу-тьфу) не придётся, поэтому подсказать не могу.
На таблицу-приёмник лучше накладывать блокировку TABLOCK, а БД-приёмник должна быть с моделью восстановления simple или bulk-logged, чтобы sql server мог выполнять insert с минимальным протоколированием.
С identity-колонками по-любому геморрой.
>>7) Готово! Вы перенесли базу из нового сервера SQL в старый, хоть это и считалось невозможным. Причем перенос осуществляется примерно со скоростью передачи данных по сети, т.е. очень быстро.
1) это не считалось невозможным;
2) это гораздо медленнее чем передача данных по сети, особенно в таком исполнении, как в статье.
Утилита SQL Fragmentation Analyzer, судя по всему, абсолютно бесполезна. На скриншоте большая часть индексов с размером < 64 КБ, т.е. тех, которые занимают меньше 8 страниц данных и, соответственно, хранятся в смешанных экстентах. Как смешнный экстент не дефргаментируй, толку от этого не будет.
Кроме того, сами пороговые значения (threshold) под вопросом. Сам Пол Рэндал писал, что в BOL их написал практически от балды, просто потому, что нужно было что-то написать. Человеку, который понимает какими должны быть эти пороговые значения для его баз данных, такая утилита, скорее всего, не нужна. А тому, кто не понимает — ну, вреда, наверное не будет, но диски он будет насиловать зазря, не понимая, почему этот дурацкий индекс на 30 килобайт никак не удаётся дефрагментировать.
99%, что 1С-ники по умным рекомендациям 1С настроили на SQL Server job, который проходит по всем индексам в БД и делает ALTER INDEX REBUILD. В этом случае перевод в SIMPLE должен помочь — ЖТ как вырастет на (объём самого большого индекса в бд)*2, так и останется. Вообще, по хорошему, стоит это переделать — на хабре были посты про переиндексацию.
1% остаётся на то, что регламентное задание в 1С что-то шарашит. В принципе, тут тоже перевод в SIMPLE поможет, ЖТ один раз вырастет на нужный ему объём и больше расти не будет.
На то время, пока файл журнала транзакций увеличивается, БД становится доступной только для чтения, все запросы на запись ждут пока операция приращения завершится.
Журнал транзакций дорастёт до определённого размера (вряд ли он будет превышать 2-3 гб на базе в 20 гб) и устаканится. В simple, при нормальной работе, его размер, примерно будет равен (максимальный объём данных, обрабатываемых в одной транзакции) * 2. Если растёт и не останавливается даже в simple — где-то есть незакрытая транзакция.
Я думаю автор не уделял особого внимания этому запросу. Всё-таки дальше он пишет, что лучше из метаданных брать информацию о количестве записей, а это так — для примера и сравнения сколько времени займёт. Конечно, с dynamic SQL удобнее.
Спасибо.
Действительно, код не идеален. Но он рабочий (а там где возможны проблемы — я постарался описать в каких ситуациях они могут возникнуть) и, при необходимости, каждый сможет допилить его под себя без особых проблем.
Вчера такой же купил. В целом, за эти деньги более чем доволен.
Ну и, соответственно, написал про UDF (сорри за длинное объяснение, хотел всю цепочку показать).
Если вы располагаете другой информацией, помогите, пожалуйста, правильно переформулировать 7-й пункт :).
По поводу ORDER BY — никто не говорит, что им нельзя пользоваться. ИМХО, Брент, в своём UPD, достаточно чётко высказал свою позицию — «Если без него можно обойтись, лучше обойтись». Я с ним согласен. Серверу баз данных и так есть чем себя занять, а порядок строк, в ряде случаев важен не с точки зрения логики приложения/запроса, а только для пользователя — вот пусть у этого конкретного пользователя, в этих случаях, и сортируется.
DBCC AUTOPILOT (6, 9, 37575172, 1, 0, 0, 0) — Clustered Index with TypeID 6
Хотя тип 6 в sys.indexes никак не может соответствовать кластерному индексу.
А гипотетический индекс (index id = 5) он добавляет строкой:
DBCC AUTOPILOT (0, 9, 37575172, 5, 0, 0, 0) — All other index with TypeID 0
хотя 0 должно быть кучей.