Лирическое вступление (можно пропустить):
Было замечательное солнечное утро, регламентные работы по обновлению конфигурации прошли штатно, как тогда казалось. Спустя пол часа картина изменилась. Включилось старое фоновое задание, которое за один запуск затерло основной регистр сведений. Дело в том что, до определенного момента текущая база забирала данные этого регистра из другой, но в один прекрасный момент архитектура изменилась и мастер-базой регистр стала текущая.
Первое что нас спасло это бекап перед релизом. Всегда помним про бекап!!! Далее, Регистр большой и универсальными обработками загружать/выгружать пришлось бы до морковкиного заговенья, хотя сначала мы конечно предприняли подобные попытки))). Минуты шли напряжение росло и тогда было принято решение резать не дожидаясь перитонита!))) Мы открыли SQL Server Management Studio и проблема была решена в мгновение ока.
Быстрое восстановление затертого регистра сведений из бекапа по средствам SQL:
- Просим развернуть бекап созданный перед релизом.
- Открываем SQL Server Management Studio
- Запускаем «SQL Server Import and Export Wizard», для этого необходимо встать на конкретную БД. Правой кнопкой вызвать контекстное меню и нажать:
TasksàExport Data или TasksàImport Data
Если Вы планируете загрузить таблицу в текущую БД тогда TasksàImport Data
Если Вы планируете скопировать из текущей БД таблицу тогда: TasksàExport
Мы в нашей ситуации использовали TasksàExport
- Открывается окошко мастера:
- Жмем «Next»
- В открывшемся окне:
-
- Data source выставляем в значение «SQL Server Native Client 11.0» (последнее значение в списке)
-
- Проверяем тот ли сервер указан в поле «Server name», с которого мы планировали скопировать таблицу (в нашем случае там где поднят бекап)
- Проверяем та ли база указана в поле «Database» (база в которую развернут бекап)
- Если все ок, жмем «Next»
- В открывшемся окне, необходимо настроить параметры принимающей стороны (в нашем случае рабочая БД):
-
- Устанавливаем у «Destination» значение «SQL Server Native Client 11.0» (так же низ списка)
- В поле «Server name» (в нашем случае имя SQL сервера рабочей БД ) рекомендуется вводить значение серввера приемника таблицы вручную, так как в случае выбора происходит сканирование сети на предмет имеющихся в ней SQL серверов.
- В поле «Database» выбираем БД в которую хотим скопировать табличку (в нашем случае имя рабочей БД).
- Кроме того, поскольку предполагается запись в БД приемник, то необходимо указать пользователя и пароль под которым должна производиться запись!!!
- Если все ок, жмем «Next»
- В появившемся меню выбираем верхний пункт, так как мы хотим скопировать конкретную таблицу, а не написать произвольный запрос для получения данных. После чего жмем «Next»
- Выбираем таблицу(цы) которую(рые) мы хотим скопировать, если в месте куда копируем уже есть такая таблица (а в нашем случае это было именно так) то нужно изменить наименование таблицы, например добавить постфикс «_new»
Далее жмем «Next»
- Ели все проверили и готовы копировать выбираем «Run immediately» и ждем пока произойдет копирование
Жмем «Finish»
- Отлично табличка регистра сведений скопирована, дело за малым произвести переименование текущей таблицы (в нашем случае рабочей Бд), добавив постфикс «_old», пусть она побудет еще какое-то время в БД для разбора полетов. Позже ее можно будет удалить. Так же нужно будет убрать у вновь созданной таблицы постфикс «_new» и ОБЯЗАТЕЛЬНО НУЖНО СОЗДАТЬ ИНДЕКСЫ!!!
- Итак генерируем скрипт для дальнейшего создания индексов:
-
- Встаем на таблицу, подлежащую замещению и жмем кнопку «F7» на клавиатуре
-
- Дважды щелкаем по папке «Indexes»
-
- В открывшемся окне выделяем все индексы открываем правой кнопкой мыши контекстное меню и создаем скрипт
Пример скрипта:
Сохраняем скрипт в некий текстовый файл и продолжаем.
- Переименовываем таблицу с некорректными данными:
- Но это не все нужно так же переименовать индексы:
- Теперь убираем постфикс «_new»
- Как видно из скриншота, у перенесенной, таблицы отсутствуют индексы. Так что пришло время воспользоваться скриптом созданным в 11 пункте. Выполняем его
Индексы появляются:
- Ура все готово. После того как все проверите и поймете, что старая таблица не нужна ее можно будет удалить.
Так буквально за 5 минут вы можете скопировать 30 000 000 строк.
Типовыми обработками 1С это у вас точно не получится.
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Мне всегда было интересно знать — что побуждает людей затирать названия баз? Каким образом эти данные могут угрожать безопасности? Автор, у вас скуль «наружу» смотрит что ли?
(1) опередил)))
Вообще не понимаю, зачем все эти извраты с выгрузкой? Insert into newdb.dbo.table select * from oldbase.dbo.table спасает. А таблицу моздать можно сгенерировав скрипт create и выполнив его в newbase.
А вот для постгреса такой механизм вполне актуален, т.к. там в 1Сном варианте перенести данные из одной базы в другую запросом будет не так просто, ибо одно соединение — одна база данных.
У меня вопрос, что на это скажет 1с?
Вроде, запрещено обращаться к SQL напрямую. поправьте, если я не прав.
BULK INSERT
правильно писать «посредством SQL»
Хорошая статья и грамотный подход. К сожалению, запрещённый фирмой 1С.
(8) Обоснуйте, пожалуйста.
(1)Вы абсолютно правы! Вариантов решения, описанной мной проблемы много. Я просто опубликовал максимально подробно описанный вариант решения. Так сказать «Из коробки».
(3)Вы абсолютно правы! Вариантов решения, описанной мной проблемы много. Я просто опубликовал максимально подробно описанный вариант решения. Так сказать «Из коробки». Над написанием подобной статьи (1С + PSQL) подумаю. Спасибо за идею.
(2)Тут все просто: наша безопасность так требует.
(4)Да Вы абсолютно правы. Но когда стоит вопрос жизни и смерти. Ответ очевиден.
(5)Я понимаю, что краткость сестра таланта. Но человеку у которого пропали данные из РС (или еще какой то таблицы) будет удобнее воспользоваться статьей с более подробной информацией.
(7)Спасибо большое! Сам часто пользуюсь коллективным разумом Infostart. Вот решил внести посильную лепту.
(10) Ну, предположим, «хорошая статья» это субъектив, не требующий обоснования. Мне понравилось оформление, последовательное изложение, наличие конкретики и нужная степень «разжёвывания». Грамотный подход — без претензии на универсальность, кичливых лозунгов «всё на свете за пару телодвижений», оговаривание тонких моментов. Насчёт запрета фирмой 1С — прямое обращение к СУБД в обход движка 1С разве уже разрешили? Имхо, нет.
А вы, сударь, отреагировали по-хамски. Стрелку перекинули (видать, просто наехать, да непросто обосновать, хе-хе), да ещё и на «ты» перешли. Посему цена вашему комментарию известно какая)
(17) ну по поводу этого момента в лицензионном соглашении, то на курсах экспертов оба ведущих говорят в качестве ответа на проблемы производительности, не решаемые стандартными средствами, что «нужно нарушать лицензионное соглашение — вы же эксперты, типа-опа…».
По-сути ограничение этого ЛС в том, что компания 1С не будет помогать в решении вопросов, если база данных подверглась такому вот воздействию, т.к. не гарантирует ее жизнеспособность при этом.
Кстати, самый простой пример, когда приходится нарушать это ЛС — случай невозможности войти в базу после обновления (обычно, динамического), когда из-за того, что платформа валится, остаются неконсистентные записи в таблице configsave. И есть два пути: грохнуть эту таблицу или восстановить бэкап. Я не уверен, что даже Вы при размере базы в хотя бы сотню гигов выберете второе. Но, конечно, хозяин — барин…
(18) Да, Морозов на курсах так и говорит. Но это не отменяет юридической формулировки — суть, не суть, а сказано то, что сказано. Не хочется потом в суде отвечать, знаете ли, и ссылаться на некие курсы.
Особенно если это делает маленький франч, а не большие дяди из большого Раруса, к примеру. Я видел такой прецедент и повтора не хочу.
(19)
А за что отвечать в суде? типа иск к 1С, что у нас вальнулась база, но т.к. я ее «трогал ручками», то 1С теперь ни при чем, и я сам себе в колено выстрелил? В чем предмет судебной тяжбы?
Вообще, если говорить о крупном бизнесе, то сама 1С своим ЦУП все свои ЛС нарушает, внедряя систему, которая лезет в SQL-базу. Куче крупняка ставят решения от софтпоинта (или как его там), которые подменяют данные запросов, генерируемых 1С к SQL. Что-то не видял на просторах ИТС ссылок на софтпоинтовские продукты.
Суть этого пункта ЛС в том, что желтая компания прикрывает свою задницу от возможных исков, а не в том, что желтая компания может за это засудить тебя, ибо во втором случае предмета спора нет.
(22)Вы предложите еще проще вариант, ну скажем на китайском статью прочесть! Я уверен все 1с-ники знают китайский.))) Именно поэтому статьи на Infostart.ru в основном на русском. Кроме того, в приведенной Вами статье не все описано, что есть в моей. А так да, статей на тему копирования таблиц в MS SQL море. Вот только от моей их отличает то, что моя это пошаговая инструкция. А имеющиеся на просторах интернета требуют доработки напильником.
(24) Вы странный человек. Я Вам про Фому, а Вы мне про Ерему.)))