SQL - выгрузка - загрузка #111732


#0 by Sj
Добрый день... хотя ... Возможна ли организация автоматической выгрузки в одной базы и автоматической загрузки в другую силами SQL ( так как этот процесс намного скоротечнее, чем силами 1С)? Если первое возможно - указывается плановая выгрузка нужной базы. То как организовать загрузку??? ТО есть нужно чтобы утром при включении компа и запуска SQL сервера база 1 выгружалась, после чего, когда все процессы по выгрузке были бы завершены ( то бишь минут через 15 ), выгруженные данные подхватывались и загружилсь в базу 2. Если нетрудно, подробнее... Удачи Sj
#1 by vvv29бан
Зачем такой геморой?
#2 by Sj
Чтобы в копии работали а в оригинале производились какие-то монопольные работы.
#3 by denpro
А что если сервак на ночь не выключать, повесить в планировщик скрипты в 0:00 выгрузка, в 5:00 (для полной уверенности) загрузка.
#4 by Sj
не время шутки шутить
#5 by rsv
. Это возможно и делалось. В EM job надо настоить,если память не изменяет, и ручками SQL скрипт написать , чтоб еще и MD в придачу. По текстовке скрипта не подскажу. Давно это было.
#6 by Лис в курятнике
а урбд не катит?
#7 by Sj
Что за скрипт? В скриптах я полный пасс. Если нетрудно глянь, кинь. Про урбд я не думал что-то. Имхо, скулем быстрее получится.
#8 by Ferz
репликация моментальным снимком. (только это оч трудоемкий прцесс) необходимо настраивать
#9 by Sj
Всю ночь думал, переживал. Может возможна организация копирования таблиц из одной базы в другую? То есть: на скуле лежат две базы Б1 и Б2. Б1 - исходная. В какой то момент времени делается что-то вроде copy Б1*.* Б2*.*  ( только вот как мд перенести пока tit не увязал)
#10 by Ferz
см 8
#11 by Sj
10. Может быть, может быть... думаю, смакую... нашел вот это буду копать. спасибо. может еще что дельного есть?
#12 by Sj
Хотя почитал описание "Т.е. как только вы изменили что-то в одной базе (создали новый элемент справочника, изменили, ввледи документ) - тут же эти изменения появляются в другой. ТОЛЬКО ДЛЯ SQL" - не совсем, что надо.
#13 by Sj
Нашел Репликация В сервере SQL Server имеется три вида репликации: Репликация мгновенных снимков данных Копирование всего представления данных на другой компьютер. При этом представление данных в принимающей базе данных заменяется новой версией. При таком виде репликации происходит отправка данных по состоянию на определенный момент времени и отслеживание обновления данных не производится. Репликация мгновенных снимков данных наиболее подходит для среды с редко обновляемыми данными или в условиях, когда текущее состояние данных и задержки их обновления некритичны. Созданный во время синхронизации полный снимок данных рассылается подписчикам. Репликация транзакций Отправка исполняемых транзакций, операторов INSERT, UPDATE или DELETE с одного компьютера на другой. Этот вид репликации предполагает, что после получения подписчиками исходного снимка данных при обновлении этих данных подписчикам отправляются индивидуальные транзакции. Репликация транзакций полезна в следующих случаях. Данные о последовательных изменениях должны отправляться подписчикам по мере их возникновения. Транзакции должны удовлетворять свойствам атомарности (Atomic), непротиворечивости (Consistency), изолированности (Isolation) и долговечности (Durability, ACID). Подписчикам необходимо наличие надежной и регулярной связи с Издателем. Репликация с объединением данных Обновленные на компьютере данные позже реплицируются на другой компьютер. Репликация с объединением данных — это процесс распространения данных от издателя к подписчикам, позволяющий обеим сторонам обновлять данные при наличии связи или автономном режиме с последующим объединением всех изменений при возобновлении связи. Репликация с объединением данных допускает автономную работу узлов. При последующем объединении формируется единый общий результат. После передачи исходного снимка данных подписчикам можно отслеживать изменения этих данных на узлах издателя и подписчиков. Синхронизация данных между серверами осуществляется непрерывно, в назначенное время или по запросу. Поскольку обновления выполняются одновременно на нескольких серверах, одни и те же данные могут обновляться как на узле издателя, так и на узлах подписчиков. Это может привести к конфликтам при объединении данных. При репликации с объединением данных имеются стандартные и специальные способы разрешения, которые могут быть выбраны пользователем при настройке объединенной публикации. При возникновении конфликта агентом объединения данных вызывается процедура исправления ошибок, которая определяет, какие данные приемлемы для отправки на другие узлы. Репликация с объединением данных полезна в следующих случаях. Подписчики обновляют данные в разное время и рассылают свои изменения издателю и другим подписчикам. Подписчики получают данные, вносят в них изменения в автономном режиме, а затем синхронизируют обновления с издателем и другими подписчиками. Количество конфликтов, вызванных обновлением данных одновременно на нескольких узлах, невелико. Это обусловлено тем, что данные фильтруются по разделам и затем направляются другим подписчикам, или определяется особенностями использования приложения. Тем не менее, если конфликты действительно возникают, отклонения от ACID-свойств не выходят за допустимые рамки.
Тэги:
Ответить:
Комментарии доступны только авторизированным пользователям

В этой группе 1С