Имя: Пароль:
1C
1С v8
Как быстро клонировать SQL базу?
, ,
0 tciban
 
19.11.19
07:12
Коллеги! Есть такая проблема: довольно большая (1.5 террабайта) рабочая база, есть бакап (конечно), надо быстро развернуть 3 тесовых базы для 3-х разработчиков. Как это сделать наиболее быстро? Ну первую базу поднимаем из бакапа, а вот как быстро клонировать еще 2?
1 shadow_sw
 
19.11.19
07:14
хранилище и пусть сидят в одной базе
2 shuhard
 
19.11.19
07:16
(0) дык копия mdf + ldf, если сиквел MS
3 Sergz66
 
19.11.19
07:17
А точно всем разработчикам нужны полные копии рабочей базы? Может достаточно им пустые базы с нужной конфижкой сделать?
4 dmpl
 
19.11.19
07:26
(3) Ага, чтобы у разработчиков на тестовых данных работало, а на реальных - нет. Нужна не пустая база, а с реальными настройками и данными. Тут 2 варианта: копия рабочей базы, либо специально обученный человек делает тестовую базу по образу и подобию реальной, только с меньшим количеством данных (т.е. вводит тестовые примеры).
5 Sergz66
 
19.11.19
07:30
(4)Так о том и речь, что 4.5 Тбайта для разработки - это многовато...
6 ДенисЧ
 
19.11.19
07:31
(4) А если для этого обучить специально обученную программу? Зачем человек-то?
7 Sergz66
 
19.11.19
07:32
Как минимум после восстановления бэкапа выпилить из копии базы ненужные данные (например, сохраненные файлы, если они в базе лежат, может какие-то регистры, с которыми точно не будет работы)
8 sitex
 
naïve
19.11.19
07:35
(0) А что разработчикам нужны все данные в вашей базе ? Оставьте то что кому что нужно, остальное выпилить.
9 tciban
 
19.11.19
07:47
(1) Вот я не понял как это - в одной базе с помощью хранилища? Думал что много знаю про 1С, а тут прошу пояснить.
3 конфигуратора над одной базой не запустишь... Или ты имеешь ввиду над разными базами? Так нам нужны свежие данные.
10 tciban
 
19.11.19
07:48
(3) Точно. И чтоб ты сам над пустой базой разработку вел (это проклятие такое :))
11 tciban
 
19.11.19
07:52
(8) Да. У нас нет какого-то настолько жесткого деления. И выпиливать скорее всего дольше чем копировать
Уважаемые коллеги! Давайте отодвинем в сторону дисскусию про потребность разработчика (каждого) в реальной базе. Все на эту тему меж собой мы давно обсудили. Кто мог - с весны не обновлялся :) Но теперь изменений в базе накопилось столько что точно надо. Давайте не будем спорить об этом - мы уже поспорили за вас. И прошу прощения, что лишили вас этого удовольствия :)

Давайте лучше обсудим есть ли способ быстрого клонирования. Может средствами SQL как то?
12 Йохохо
 
19.11.19
07:55
(11) а что вам мешает еще 2 базы поднять из бекапа?
13 dk
 
19.11.19
07:58
(2) +1
14 dmpl
 
19.11.19
08:00
(6) Чтобы правильно настроить эту программу.
15 dmpl
 
19.11.19
08:01
(8) Вопрос в том, что будет дешевле - выпилить, или каждому разработчику полную копию организовать... и не забыть, что ее надо будет обновлять периодически.
16 tciban
 
19.11.19
08:06
(12) Ничто не мешает. Просто думал если уж у насесть одна база, то может еще две получить можно еще быстрее?
17 Йохохо
 
19.11.19
08:16
(16) ну (2) может быть быстрее, а может не быть. А может вы РазработчикаНаПолутораТерабайтах полдня будете из копии уговаривать выйти служебками
18 Irbis
 
19.11.19
08:19
отатачить, скопировать три раза и прицепить. Если времени и места хватит.
19 Sergz66
 
19.11.19
08:21
(18) Не факт, что так быстрей будет, чем параллельно в три базы с одного бэкапа восстановить
20 sitex
 
naïve
19.11.19
08:25
(11) Тогда ответ (2). Быстрее чем так накатить средствами и скриптами SQL не получиться.
21 tciban
 
19.11.19
08:27
(18) бакап сильно меньше всей базы. Копировать его значительно быстрее.
бакап копируется полчаса (тестовые на отдельном сервере) восстановление из бакапа - 6 часов. Вопрос был собственно как уменьшить эти 6 часов.
22 Повелитель
 
19.11.19
08:30
(0) (21) А в чем собственно проблема?
6 часов это разве время. Поставить на ночь, как раз у всех троих будет к утру по свежей базе.

Можно одну из бэкапа поднять, а потом скопировать mdf + ldf елси MS SQL как выше писали, то всего займет 6 + 30 минут + 30 минут.
23 Irbis
 
19.11.19
08:33
(21) Зато разворачивается бэкап значительно дольше.
24 Fram
 
19.11.19
08:36
(21) 6 часов? из дт что ли поднимаете?.. поднимать 6 часов 1.5тб из архива SQL это не нормально
25 Повелитель
 
19.11.19
08:38
(24) Вполне нормальное время. У меня база 100 Гб, поднимается из бэкапа 30 минут.
А тут в 15 раз больше база.
26 Повелитель
 
19.11.19
08:38
(25) Даже просто скопировать по 1Гбитой сети 100Гб занимает около 15 минут.
27 piter3
 
19.11.19
08:40
(21) 6 часов,это персоналка что ли вместо сервера?
28 seevkik
 
19.11.19
08:40
а модель восстановления какая?
29 Fram
 
19.11.19
08:40
(25) ну может если копировать по сети 1.5тб, да - нормально. но если скопировать архив сначала локально на сервер, а потом поднять 6 часов - это долго
30 Повелитель
 
19.11.19
08:42
(27) Сейчас персоналка на SSD копирует быстрее, чем сервер с HDD последних моделей.
31 tciban
 
19.11.19
08:49
(21) Поднимаем из обычного SQL бакапа. Я не сисадмин, в настройках SQL не сильно то шарю, ускорить не знаю как.
32 Sergz66
 
19.11.19
08:52
(31)Так вы проанализируйте состав базы, какие таблицы самые большие. Наверняка найдете возможность грохнуть не сильно нужные для тестовой базы данные.
33 ptiz
 
19.11.19
08:54
(31) Без восстановления из бэкапа или копирования mdf - никак.
Ради интереса - все базы на одном сервере будут восстанавливаться? Там какая дисковая подсистема?
34 ptiz
 
19.11.19
08:55
Нам вот пришлось raid-10 на raid-5 поменять, чтобы места больше стало на сервере под базы.
35 Fram
 
19.11.19
08:56
(34) со скоростью записи на raid-5 тоже мириться пришлось?
36 sitex
 
naïve
19.11.19
09:01
(31) Посмотрите на http://www.sql.ru, там есть тема как уменьшить размера физ. базы. Это только для копирования.
37 piter3
 
19.11.19
09:02
Может скажу глупость ибо ни разу не админ,а почему бы дифами не обновить тестовую.Как вариант
38 Cyberhawk
 
19.11.19
09:02
SQL snapshot
39 mistеr
 
19.11.19
09:02
Предлагаю быстрое решение. Всех разработчиков пустить в одну базу. Пусть между собой договариваются. И сказать: "Если что испортите - восстановление 6 часов!" Это подействует.

А правильное решение — не давать разработчикам рабочие базы. Пусть тестовые примеры делают, а то совсем обленились. Сделать выгрузку из рабочей базы основных справочников и настроек через КД не так сложно.
40 ДенисЧ
 
19.11.19
09:03
Полтора терабайта скопировать быстрее, чем позволяет дисковая система - поможет только квантовый гуглёвский комп на 8096 кубитов...
41 Cyberhawk
 
19.11.19
09:03
+(38) SQL Mirroring
42 ДенисЧ
 
19.11.19
09:03
(39) Ты так и делаешь со своими разаработчиками? Из могилы пишешь?
43 sitex
 
naïve
19.11.19
09:04
(39) Ужас.!
44 tciban
 
19.11.19
09:07
(32) Что бы их грохнуть - надо время. И сначала надо восстановить полную базу. потом грохнуть.

(39) Ага. А если тебе поручили разработать отчет? Будешь ручками заводить документы. Ну ну... У тебя получится быстрый отчет, который будет всю полноту данных учитывать. Ага, ага.
45 mistеr
 
19.11.19
09:08
(42) Обычно есть копия рабочей базы, но старая, обновляется раз в год примерно. Разворачивать копию на каждый чих смысла не вижу. Только если не удается воспроизвести ошибку.
46 ptiz
 
19.11.19
09:13
(35) SSD. Разницы не заметил никакой.
47 Йохохо
 
19.11.19
09:15
(46) умножение записи на рейд5 вроде х3 вместо х2, т.е. ресурс ссд / 1.5
48 Sergz66
 
19.11.19
09:34
(44)Ну так проанализировать один раз... На будущее... А дальше уже скулевыми скриптами можно будет обрезанные копии делать.
49 kauksi
 
19.11.19
09:47
разворачиваете одну копию, обрезаете по максимуму http://catalog.mista.ru/public/1154357/, отдаете обрезанную разработчикам
50 dk
 
19.11.19
09:48
(46) там разница будет при восстановлении работы в случае смерти одного или нескольких дисков, но для тестовой сойдет
51 Lama12
 
19.11.19
10:20
(0) Вопрос бюджета имеется?
52 pechkin
 
19.11.19
10:24
выпилить данные из рабочей базы будет сложнее и дольше чем просто скопировать эти 1.5т 3 раза
53 pechkin
 
19.11.19
10:25
ну и конечно тестовые примеры наше все. тогда рабочие данные нужны крайне редко
54 Cyberhawk
 
19.11.19
10:34
(53) Кто ж их генерить будет, один из ста)
55 Lama12
 
19.11.19
10:37
(53) Тестовые данные - супер. Только через 10 лет прогнул отдел аналитиков что б они отдельную базу вели с тестовым примером :-(, и то не уверен что приживется.
56 Cyberhawk
 
19.11.19
10:39
(55) Небось вручную колотить данные заставляешь, конечно не приживется
57 pechkin
 
19.11.19
10:40
(54) для каждой задачи свой пример.
калссическое тестирование бдд
58 pechkin
 
19.11.19
10:41
его генерит разработчик.
все равно он его генерит для разработки, так почему бы не оформить как следует
59 Lama12
 
19.11.19
10:42
(56) Пока вручную, дальше посмотрим. Может аварийные ситуации универсальным переносом будем из рабочей переносить.
(58) Разработчик сгенерит так, что у него все будет работать. :-) Проходили уже...
60 pechkin
 
19.11.19
10:43
(59) просто у вас нет культуры доработки тестовых примеров.
нашли контр пример - написали новый тест
61 Cyberhawk
 
19.11.19
10:44
(60) На чем тесты пишешь?
62 pechkin
 
19.11.19
10:45
xUnitFor1C
ванесса не зашла. да и вообще тестирование 1с через тестовый клиент- слишком медленно
63 Фрэнки
 
19.11.19
10:47
Вообще, было бы любопытно послушать аргументацию, зачем нужна для постоянной разработки база в 1,5 ТБ.

Я как раз в отличие от ТС проклинал разработку в такой базе. Все действия в нее, связанные с применением структурного изменения к базе могли влететь внезапно на реструктуризацию и? Я курить давно бросил, если что

Причем, не тестирование, а именно разработка.

Сделал разработку. Нужен тест. Объем данных огромный. Кто в здравом уме пропустит этот тест на совесть просто разработчика и не выделить отдельный тестовый стенд с регламентом доступа к нему и с регламентом по признанию результатов? Ну если данные носят архиважный и критичный характер, иначе бы их никто и не хранил бы и уж тем более не тестировал.
64 Фрэнки
 
19.11.19
10:50
Ну и наличие быстрообновленных свежих копий при огромном объеме источника - это сама по себе не рядовая задача.
Не думаю, что файловое или подобное файловому клонирование будет для этого адекватным решением.
65 Надо работать
 
19.11.19
10:52
(0) поднимаешь одну из бекапа, сжимаешь средставими SQL? копируешь, подключаешь.

Экономия места и времени. Ну только на сжатие, но это один раз
66 Надо работать
 
19.11.19
10:53
(63) а если у тебя реструктуризация пройдет за 20 минут, а на проде не пройдет за ночь? тоже не вариант
67 ptiz
 
19.11.19
10:59
(63) "могли влететь внезапно на реструктуризацию " - именно для этого и надо вести разработку на такой копии. Чтобы с рабочей не влететь.
68 sitex
 
naïve
19.11.19
11:06
(67) Интересно даже сколько она будет на 1,5 ТБ крутится  и сколько памяти сожрет.
69 Фрэнки
 
19.11.19
11:12
Ага. Особенно, когда у тебя такая реструктуризация в процессе разработки над парой-тройкой параллельных заданий случится за один день несколько раз. А ты просто еще разрабатываешь. Тестить - это отдельно и это сделают все равно без тебя.
70 Cyberhawk
 
19.11.19
11:55
(66) Для этого существует препрод
71 Cyberhawk
 
19.11.19
11:56
(67) И тебе тоже (70)
72 Cyberhawk
 
19.11.19
11:59
Но даже если и нет препрода, то есть тестовый контур в виде центральной тестовой базы. База разработки совершенно точно не должна быть настолько большой, чтобы доставлять неудобства разработчику.
73 dmpl
 
19.11.19
12:11
(21) У вас где-то тормоза. 6 часов на 1,5 Тб - это средняя скорость 70 Мб/с. Нормальный дисковый массив может переварить ~500 Мб/с и выше. Нормальный SSD - 1 Гб/с и выше.
74 pechkin
 
19.11.19
12:12
(73) так еще и по сети наверно нужно качать.
ктож на продуктивах разворачивает тестовые базы для разработки
75 dmpl
 
19.11.19
12:14
(49) Ага, а потом бьетесь 100500 часов над глюком из-за того, что обрезали лишнее... Обрезать должен тот, кто конфигурацию знает от и до. Сколько там его час стоит?
76 assasu
 
19.11.19
12:14
(0) видел организацию где спец скриптами убирали лишнее из рабочей базы. оставалось только нужное для разработчика на 5 тб
77 ДенисЧ
 
19.11.19
12:15
(76) "на 5 тб" ?
78 Cyberhawk
 
19.11.19
12:16
(75) 20% усилий дадут 80% результата, а большего и не требуется. Сломать при этом что-то - это надо постараться)
79 pechkin
 
19.11.19
12:16
для таких больших баз нужно отдельно разрабатывыать механизм создания тестовой базы
80 assasu
 
19.11.19
12:16
рабочая была 20 тб
81 dmpl
 
19.11.19
12:19
(74) БД, если туда не насовали JPEG'ов, жмется раз в 10. Так что пары Гбит/с хватит.

(78) В случае с ERP сломать - это запросто. Безболезненно можно убирать только вложенные файлы.
82 pechkin
 
19.11.19
12:32
(81) а сколько времени будет жаться база на 1.5ТБ?
83 Trance_1C
 
19.11.19
13:00
Сжать файл журнала, скопировать базу в три каталога, подключить на сервере с разными именами, вроде все, зачем такую тему расплодили.
84 ДенисЧ
 
19.11.19
13:04
(83) 3 базы по 1.5 ТБ - это уже 5ТБ ))) И плюс время "скопировать базу"
85 Trance_1C
 
19.11.19
13:17
А размеры таблиц не смотрели, может у вас там история версий и регистр с проводками все место занимают.
чистятся одним запросом за 5 сек. Только не из 1С.
86 Trance_1C
 
19.11.19
13:19
Подчистите самые жирные таблицы, все записи старше года в документах и регистрах, база похудеет заметно.
87 Cyberhawk
 
19.11.19
13:29
(81) Что-то ты придуриваешься
88 dmpl
 
19.11.19
17:32
(82) Зависит от настроек сжатия. Можно использовать что-то типа алгоритма, которым при гибернации жмут - там сотни МБ/с на ядро скорость даже на слабых ЦП. В принципе, MS SQL сам умеет жать бэкапы на лету довольно шустро.
89 Креатив
 
19.11.19
20:03
Я бы заархивировал mdf и ldf на другой носитель(не на тот, где файлы sql). Потом обратно в три каталога разархивировал. Это ежели не заморачиваться с оптимизацией базы.
90 sergeyspb13
 
19.11.19
23:16
http://qaru.site/questions/37050/how-can-i-clone-an-sql-server-database-on-the-same-server-in-sql-server-2008-express
можно из бэкапа сразу в новые базы развернуть... только и правда надо ли разработчикам столько
91 vde69
 
19.11.19
23:27
1.5 тб средствами SQL на нормальном железе это 50...100 минут выгрузить и загрузить на соседнем сервере по сети (без копирования файла), штатно из энтерпрайса мышкой это не делается, а вот скриптом - легко, то есть если не переносить файл экономи по времени примерно минут 30....60 будет
92 Bigbro
 
20.11.19
07:00
(21) это странно. в нормальном режиме восстановление SQL бэкапа идет практически со скоростью копирования, а у вас разница в 12 раз.
что то с дисковой системой?
93 tciban
 
20.11.19
07:53
(63) К вопросу зачем нужна большая база. Вот как раз для того, что бы оценить за какое время и как пройдет реструктуризация например. Мы должны понимать насколько долго будет происходить перенос наших изменений в рабочую базу. Работа круглосуточная, рабочую больше чем на час в день (в обед) не дают. Если на тестовой мы видим, что реструктуризация или иное изменение займет слишком долгое время - либо ищем другое решение, либо выбираем подходящий день когда отгрузка минимальна и нет иных мероприятий, договариваемся со всеми отделами. Например одно изменение пришлось откладывать 2 недели, сначала хотели в одну пятницу (там после 12 инвентаризация, отгрузки долго нет), но вдруг оказалось, что в этот день много работы у кассира, зарплата, заберем у нее базу - будут толпы людей злиться у кассы. Пришлось отложить до следующей пятницы.

В общем нужно иметь полноценный макет на котором можно заранее отработать все изменения и увидеть что будет с рабочей базой.
Как в космической отрасли, когда они на земле оставляют точную копию того, что летит в космос, что бы посмотреть в живую всякое ;)
94 Индиго
 
20.11.19
09:14
(93)Откуда такой монстр 1,5 Тб?   Вы обрезку не делаете что ли из принципа?
95 Sergz66
 
20.11.19
09:17
(93)Вопрос-то в чём... нахрена несколько полных копий? Небольшие базы для разработки, полноценная копия - предпрод (ну может быть еще одна для тестирования пользователями), но разработка в базе в 1.5 Тб на железе, которое скорей всего хуже, чем на проде - это то еще развлечение...
96 unregistered
 
20.11.19
09:24
(94) > Вы обрезку не делаете что ли из принципа?

А зачем?
Поиметь геморрой с выверкой остатков только ради того, чтобы копии для разрабов быстро делались? Боюсь пользователи не оценят. Это во-первых.

А во-вторых, в зависимости от структуры и особенностей конфигурации свёртка может не давать достаточно большого уровня снижения объёмов базы. То есть геморрой получим, а уменьшение базы - нет. Типичный пример - почти все типовые конфигурации. В какой-нибудь бухне если из 10 лет ведения учёта свернуть данные за 5 лет, то сокращение объёма будет не на 50% (как может показаться), а в лучшем случае - 20-25%%, а реально ~15%. Но зато головняка с выверками остатков - вагон и маленькая тележка.
97 Vstur
 
20.11.19
09:24
(93) логично. Сам затратные изменения обкатываю на полной копии базы, чтобы оценить временные интервалы. 365/7/24
98 Vstur
 
20.11.19
09:25
(96) +100500
99 tciban
 
20.11.19
09:32
(94) В частности главбух хочет иметь всю(!) историю. И не моя работа ее переубеждать...

(96) Кроме того свертак базы не даст экономии места потому, что (внезапно) надо будет оставить копию базы до свертки.

Разработка на урезанной базе. Вот пример - сделал некоторую обработку, почти месяц назад, пару дней назад пользователи наткнулись на особенности в одном документе, которые я не учел. Поскольку база разработки у меня свежая, я спокойно сейчас переделываю обработку используя этот пример. А если бы у меня его не было, то что бы я делал?
100 Фрэнки
 
20.11.19
09:34
(93) Никто не спорит, что Тестовая база, равная по всем показателям текущей, рабочей должна быть.

Оспаривается мнение, что полных копий нужно обязательно много и каждый разработчик просто обязан заниматься разработкой исключительно в полной копии.

Между прочим, есть ситуации, когда, даже при огромном желании разработчика получить полную копию боевой базы в свое владение и под полный контроль, ему категорически в этом отказывают. Причем, если базы действительно огромные, то отказ обосновывается не только и не столько вопросами коммерческой и какой-то еще тайной, но и техническими возможностями серверов заказчика, например.
101 Фрэнки
 
20.11.19
09:45
Я просто не хочу указывать на конкретные имена работодателей и периоды работы у них, но это реальные ограничения, которые известны мне из практики работы на Заказчика, когда сводная команда 1с-специалистов у этого Заказчика насчитывала порядка 20+ программистов только, не считая всех остальных консультантов и прочих. И вся эта толпа спецов работала фактически в удаленных режимах, т.е. только для разработчиков была установлено две фермы со средним числом активных сеансов порядка 10 штук на каждой - т.е. около 20 сеансов конфигуратора (не пользователей) я видел через оснастку администрирования 1С сервера и понятно, что каждому конфигуратору своя базочка.
102 tciban
 
20.11.19
09:47
(100) (101) Я не оспариваю того, что случаи бывают разные, но я и мои коллеги находятся в конкретной ситуации, которую и обсуждаем.
103 mistеr
 
20.11.19
10:50
(99) >А если бы у меня его не было, то что бы я делал?

Подключился бы к боевой, посмотрел его особенности и создал бы такой же ручками. Или выгрузил в XML.

Разработчики типовых, к примеру, вообще не имеют доступа к боевым базам и ничего, не жалуются.
104 Bigbro
 
20.11.19
11:14
(103) жалуются потом пользователи этих типовых. и программисты на местах, когда признанные ошибки существуют годами без исправления.
105 tciban
 
20.11.19
11:33
(103) Я не один такой, нас тут 4-ро. И у каждого может возникнуть потребность в отладке возникшей ситуации. При том у кого то - срочная, без этого типа работа встала, а у кого-то надо просто исправить, но не немедленно. Собственно так мы работаем по текущему дню, когда тестовую не обновить.
106 tciban
 
20.11.19
11:35
(104) Во-во! Недано писали кто т она хабре как в 1С работал, отмечал что они там от земли оторвались давно. Хорошо работать в уютненькой тестовой базке с идеальными данными. А вот пользователи такого могут наворотить...
107 unregistered
 
20.11.19
11:54
По сути вопроса.
Восстанавливать из бекапа одну базу.
Вторую и третью - тупо копированием файлов первой восстановленной базы.
Можно нарисовать скрипты и хоть бы даже по расписанию их запускать, чтобы каждое утро иметь три актуальных копии базы.