|
Частичный gbak
|
|||
---|---|---|---|
#18+
WildSerypiteroЕсли все сделано по уму, т.е. с выкидыванием ненужных констрэйнтов, то можно и порекомендовать...Объясните мне, где бэкап и где констрэйнты. А самое главное - как они связаны. А то я туплю. ну вообще то бэкап создается для того чтоб потом получить из него заресторенную базу, или не? для чего-то еще? тогда я ухожу.. PS прочитал топик внимательно - вижу что метаданные таки остаются, не бэкапятся данные. Уже не так интересно, но все равно вопрос в силе. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2009, 11:45 |
|
Частичный gbak
|
|||
---|---|---|---|
#18+
Вот этот момент мне как раз и не ясен - нафига создавать констрейнты, если их при б-р придётся выкинуть? Есть пример такой жизненной ситуации? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2009, 13:29 |
|
Частичный gbak
|
|||
---|---|---|---|
#18+
WildSeryВот этот момент мне как раз и не ясен - нафига создавать констрейнты, если их при б-р придётся выкинуть? Есть пример такой жизненной ситуации? конечно есть. в БД единое информационное пространство компании. Единая система учета жизнедеятельности. Клиент организован как ряд бинарников. Каждый из них юзает свое "логическое пространство", т.е. набор таблиц, слабо залезая в другие, за исключение справочников. Структура БД делится на логические "блоки" например - Справочники - Системные штучки (лог/журнал, настройки и т.д) - Торговля - Производство - Бухучет .... и т.д Скажем надо плотно потестить нового клиента производства. Для этого нужна тестовая база (есть изменения по данным, которые надо тоже проверить, а они свернут голову старому рабочему клиенту). В тестовой базе для работы производства совсем НЕ надо - Системные штучки (очч. тяжелые, один лог скока весит) - Бухучет - Торговля даже в случае если некоторые таблицы в производстве завязаны с торговыми - можно обойтись обрывом связи - не пострадает никто, разве что какая-нить аналитика у бухов, но нас это как раз мало волнует. Что-то из этого не нужно на уровне метаданных, что-то только по данным, но в том и другом случае констрэйнт надо рвать, потому как рестор вылетит с ошибкой потому что не сможет наложить этот констрэйнт - нужных где-то данных то нет... На вопрос "а почему не юзать всю базу" могу ответить, что процесс бэкап/рестора занимает на отнюдь не слабом сервере около 8часов. К тому же сейчас мы именно так и делаем.... Идея порезать базу уже на уровне бэкапа вытекает из данной ситуации? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2009, 14:43 |
|
Частичный gbak
|
|||
---|---|---|---|
#18+
pitero На вопрос "а почему не юзать всю базу" могу ответить, что процесс бэкап/рестора занимает на отнюдь не слабом сервере около 8часов. К тому же сейчас мы именно так и делаем.... RTFM nbackup? Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2009, 14:57 |
|
Частичный gbak
|
|||
---|---|---|---|
#18+
> RTFM nbackup? что предполагает в дальнейшем восстановление все же полной (по объему) "тестовой" БД. Если БД восстанавливается 8часов... представляешь, какого объема БД? Ну неудобно с такой работать, даже при сегодняшних жестких дисках. Мы тут у себя похожий велосипед изобрели. Прямо в самой программе "выгрузить данные", и галки: [v] производство [ ] бухгалтерия, по контрагенту <...> [ ] ... но после некоторого времени использования всеже сделали доп .возжность: просто выбрать таблицы и к каждой при необходимости дописать WHERE. потому как список таблиц пополняется, а "логическую выгрузку" в соответствие не приводят. у IBE есть подобное но... не всегда им удобно пользоваться. Зато теперь куча плюсов. "Логическая выгрузка": 0) ей может пользоваться и заказчик 1) звонит заказчик, "у меня проблема..." - "сделайте выгрузку по контрагенту и пришлите". 80Мб "тестовая" и 8Гб вся БД - есть разница? 2) "безопасность": заказчку не так страшно дать нам кусочек реальной БД, по одному контрагенту, за полгода. 3) время получения такой БД сокращается в разы. "потабличная выгрузка:" если заказчик дает терминальный доступ, то для отладки программисту проще самому выбрать некоторые таблицы, дописать WHERE... и потестировать у себя. Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2009, 15:52 |
|
Частичный gbak
|
|||
---|---|---|---|
#18+
piteroСкажем надо плотно потестить нового клиента производства.pitero...но в том и другом случае констрэйнт надо рвать, потому как рестор вылетит с ошибкой потому что не сможет наложить этот констрэйнт - нужных где-то данных то нет...Я, наверное, слегка параноик, но эти два высказывания выглядят противоречащими друг другу. Где гарантии, что "плотно потестированный" клиент производства не нарушает этот самый констрэйнт, которого нет? piteroпроцесс бэкап/рестора занимает на отнюдь не слабом сервере около 8часов.Да, жесть. Это каков объём БД? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2009, 15:56 |
|
Частичный gbak
|
|||
---|---|---|---|
#18+
WildSery Я, наверное, слегка параноик, но эти два высказывания выглядят противоречащими друг другу. Где гарантии, что "плотно потестированный" клиент производства не нарушает этот самый констрэйнт, которого нет? ну тут надо просто думать что делаешь. Гарантий никто никаких не дает, но как правило что и как тестировать - расписано. А на счет нарушения/ненарушения именно КЛИЕНТОМ констрэйнта - если честно, такие вещи даже никто и не проверяет. Это уже на уровне схемы в ервине забито, не говоря уж об отработке в движках работы с бд и набора функционала при визуализации гуишных форм. Если б мы еще каждую физ.связь тестировали - мы б опухли... тестируется тока бизнес-логика, все остальное уже написано и не сбоит, ну вероятность в мизерные проценты есть конечно, плюс разработчики бд - тоже люди... WildSery piteroпроцесс бэкап/рестора занимает на отнюдь не слабом сервере около 8часов.Да, жесть. Это каков объём БД? посмотрел. было 29Г, бэкап/рестор в пике (gbak-ом, fb1.5) 11 часов примерно. Сейчас она в 2раза меньше, много пехерено, опять же ввиду скорее неудобности работы, чем возможности содержания такой базы. И тут не время техбэкапа напрягает, а удобство. У нас сервера не 24/7, мы могли спокойно допустить и 48 часовой бэкап - 2 дня выходных есть. ЗЫ. Автор ветки ветку уже не читает? Ладно, все как обычно придется делать самому, если хочешь чтоб было сделано. На счет логической выгрузки постом раньше - неплохой вариант, но одно дело написать и отладить 3 списка таблиц для бэкапа тестерам или написать механизм, да еще обернуть его в gui - что быстрее? Уже встает вопрос в затратности. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.02.2009, 08:39 |
|
Частичный gbak
|
|||
---|---|---|---|
#18+
Бизнес-логика в воздухе не висит, а опирается на конкретные процедуры/запросы. Конечно, всё зависит от вашего уровня абстракций, но зачастую изменение бизнес-логики может привести к дублированию срабатывания какой-нибудь процедуры, пишущей в "оконстрэйнченую" таблицу, или опирающийся на ещё не записанные данные, связанные констрэйнтом, и в полном тестировании такой бизнес-процесс вылетит как неправильно спроектированный. Пример грубоват, и можно предусмотреть такие места, но вот положа руку на holybible, просматриваете такое взаимодействие на предмет возникновения? 29Г за 11ч? Такого размера _наша_ база ресторится полтора часа на "не самом" сервере. На "самом" - час. Сколько индексов, если не секрет? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.02.2009, 11:49 |
|
Частичный gbak
|
|||
---|---|---|---|
#18+
WildSeryПример грубоват, и можно предусмотреть такие места, но вот положа руку на holybible, просматриваете такое взаимодействие на предмет возникновения? 29Г за 11ч? Такого размера _наша_ база ресторится полтора часа на "не самом" сервере. На "самом" - час. Сколько индексов, если не секрет? ну никто ж не требует использовать частичный бэкап каждый раз. Если тестируем то, что никак не связано с другимим модулями - какая разница? Про наведенные ошибки знаю, ну вылезет на следующем этапе и что? не страшно. Индексов 653. таблиц около 200 ... |
|||
:
Нравится:
Не нравится:
|
|||
09.02.2009, 12:18 |
|
Частичный gbak
|
|||
---|---|---|---|
#18+
pitero,ЗЫ. Автор ветки ветку уже не читает? Я тут в запарках был. А что надо-то? ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2009, 11:03 |
|
Частичный gbak
|
|||
---|---|---|---|
#18+
Вопрос. Есть ли что-то подобное для ФБ 3.0? Есть битая база, которую gfix открыть не может, а gbak нормально открывает и ресторит практически всё, только в конце, на сохранении данных неважной таблицы падает. Мне очень помог бы такой gbak, умеющий данные не всех таблиц восстанавливать. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.07.2017, 14:50 |
|
|
start [/forum/topic.php?fid=40&msg=39482436&tid=1561505]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
157ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
40ms |
get tp. blocked users: |
1ms |
others: | 13ms |
total: | 251ms |
0 / 0 |