Есть инкриментальй и камулятивный бэкап. Так что за ночь не надо бекапить терабайты.
Ну и многопоточный rman полный бэкап 2-3 тб бэкапит максимум час. Мы 100 тб бэкапим без проблем. Но еще раз это не надо, можно бэкапить инкремнет. И сжатие там есть.
Дальше все засисит от вашей политики бекапа, хоть за 10 лет храните и востанавливайтесь на любую секунду из 10 лет. Хоть часть, хоть все. Судя по вашим вопросам Вы не понимаете как рабтает rman.
Ну и самоое главное, любой новый DBA придет увидит rman и восстановит вам БД или ее часть с закрытыми глазами. В вашем случае специалист со стороны за сколько?
О боже, стендбай - НЕ БЕКАП. Накатили левый патч на базу, изменения ушли на стэндбай и привет. А то по вашему и raid из дисков бекап.
Дамп - НЕ БЕКАП, ибо не защищает базу целиком, не может использоваться для полноценного восстановления. Не содержит системные прав и прочее. Время восстановления ужасно. И в итоге имеем другую БД начиная с ID и кончая настройками и идентификаторами в БД.
В Oracle есть нормальный механизм резервного копирования, но надо изобретать яйцо фаберже...
Ох, зациклились Вы на схемах, если умеешь пользоваться молотком, то все вокруг кажется гвоздями.
Еденица бекапа в Oracle - табличное пространство. Сделайте соответствие между схемой и табличным пространством/ми и будет вам счастье. Надо перенести в другую базу, так есть transportable tablespace.
Все уже есть в Оракле, не надо изобретать велосипед, надо просто прочитать документацию.
Опять же если грамотно выработана ILM стратегия. И старые данные лежат в отдельных табличных пространствах так их можно сделат read only и забекапить один раз.
Конечно поддерживает, видимо лень было почитать про rman.
Ну и тут куча вопросов про восстановление и его время. Опять же такой бэкап подразумевает пересоздание индексов после восстановление а это время. Ну в итоге после этого новая БД получится, а не старая восстановленная. Другие идентификаторы в системных таблицах и все такое.
Из такого бэкапа получить клон бд скажем для стендбая тоже не реально.
Данная реализация скорее похожа на аудит, и не похожа на SCD2. Если точнее это SCD4. Трудоемкость получить состояние на определенное время у SCD4 выше чем у SCD2. Насколько я знаю есть несколько расширений для аудита, почему не использовать их?
Отдельный вопрос производительность: насколько использование триггеров замедляет скорость вставки? Проводилось ли тестирование? Какие текущие объемы и нагрузка?
Так же хранения истории ставит вопрос управление жизнью информации, Например, партиционирование и выведение старой информации из системы (удаление и архивирование), тут я этого не вижу.
У нас было все просто, в игры можно было поиграть только те, что сам написал или друзья написали ))) В итоге был самописный тетрис, арканоид, пару экономических стратегий и несколько лабиринтов типа Rise Out.
А так ребенка при наличии современных игр заставить программировать тяжело. Попробуйте что то игровое, типа упомянутого в статье lego mindstorm.
Информатики как таковой не было, ЭВМ появилась в качестве эксперимента для планирования расписания, ну и был кружок. Преподаватели были замечательные, вплоть до того что когда мы готовились к олимпиаде по программированию, нам завуч просто давал ключи от кабинета с ЭВМ без взрослого контроля. Ну и тусовка была странная от 5 класников до 10 класников, человек 5.
Насколько я помню по гордским школьным олипиадам по программированию (да они проводились в Омске регулярно в 80х), что-то типа СМ 1420 было в 64 матшколе в те же времена. Ну и был с 1986 года кружок программирования в пединституте, там были Ямахи (MSX) и Агат (что на на 6502)
переименовываем a_tmp в a1, на пользователей не влияет, они работают с A
Ключ партиционирования можно взять любую колонку в таблице, например id, а лучше дату операции (тогда сможем выделить несколько партиций и ускорится), ступора у оптимизатора не будет, даже если нет ключа партиционирования в запросе, не придумывайте
Attach partition именно способ для быстрой замены данных, а не пополнения.
Теперь про ваш способ: вместо стандартных SQL команд, получилось "яйцо фаберже", с которым ничего сделать нельзя, партиционировать и менять часть данных - нельзя, вторичные ключи на него создать - нельзя.
Придут люди вам на замену и будут разбираться с экзотическим кодом.
Есть таблица A, она партиционирована, скажем партиции A1 и A2 (можно и одну партицию A1, что бы был ваш случай). Все приложения работают с A и про партиции ничего не знают, оптимизатор сам решает какие партиции брать для запроса.
Теперь готовим отдельно таблицу A3, индексируем ее, далее отключаем/удаляем скажем A1 и подключаем A3. Пользователи как работали с A, так и работают, никаких кастомных скриптов, штатные DETACH PARTITION и ATTACH PARTITION.
Зачем представление и дополнительная таблица мне не понятно.
Партиционирование и подключение/отключение партиций это стандартный паттерн для DWH, зачем изобретать велосипед с переименованием таблиц мне не понятно.
DV имеет проблемы в MPP и на очень больших хранилищах (нужно прорабатывать партиционирование/шардирование, хотя есть реализации на том же GP, Яндекс регулярно докладывает)
DV требует материализации в плоские витрины (ну так это же не все хранилище а просто слой из которого собираются витрины)
DV пихают везде, не понимая его преимуществ и недостатков.
Итого, мое мнение: DV всем не нужен. Применяя DV, Вы должны понимать, что вы теряете, и что от этого получите. Самое смешное, но DV в последнее время требуют заказчики (им не нужно просто хранилище им подавай фреймворк), и их зачастую приходится отговаривать.
НО, там где он подходит, и заказчик готов платить за разработку фреймворка и за лишние вычислительные ресурсы, DV существенно сокращает time2market.
Тут все сложнее. Все же Informatica шла в правильном направлении там и оффлоад появлялся. Но конечно ODI на голову выше продукт, 2 года назад я бы однозначно рекомендовал его.
Вы абсолютно правильно подметили, что DIY не дает Data Lineage.
Полностью с Вами согласен по поводу особенностей и недостатков Data Vault. Все грамотно описано.
Но надо четко понимать, для чего нужен Data Vault:
Полное версионирование хранилища (отсюда выделение SAT как SCD машина). Т.е. возможность увидеть данные как они были N дней назад.
Динамическое развитие/изменение хранилища, добавление новых связей, работа по agile (представьте что вам надо в звезде Кимбала добавить измерение) (отсюда выделение связи в LINK)
И Data Vault используют если Вы готовы пожертвовать местом/удобством и скоростью работы хранилища ради двух вышеуказанных преимуществ.
На нашем опыте, СТРОГО при наличии фреймворка, Data Vault дает преимущество по скорости развития хранилища (time2market) в 1.5-2 раза, с учетом наличии требования по версионированию данных.
Не делайте Data Vault если у Вас нет требования по версионированию и нет (не планируете создавать) автоматического фреймворка.
Кстати да хорошая идея.
Есть инкриментальй и камулятивный бэкап. Так что за ночь не надо бекапить терабайты.
Ну и многопоточный rman полный бэкап 2-3 тб бэкапит максимум час. Мы 100 тб бэкапим без проблем. Но еще раз это не надо, можно бэкапить инкремнет. И сжатие там есть.
Дальше все засисит от вашей политики бекапа, хоть за 10 лет храните и востанавливайтесь на любую секунду из 10 лет. Хоть часть, хоть все. Судя по вашим вопросам Вы не понимаете как рабтает rman.
Ну и самоое главное, любой новый DBA придет увидит rman и восстановит вам БД или ее часть с закрытыми глазами. В вашем случае специалист со стороны за сколько?
Вы упорно путаете дамп и бекап.
Ну и кто мешает, rman позволяет получить базу или ее часть на каждую секунду или scn, а дальше вопрос сколько хранить
О боже, стендбай - НЕ БЕКАП. Накатили левый патч на базу, изменения ушли на стэндбай и привет. А то по вашему и raid из дисков бекап.
Дамп - НЕ БЕКАП, ибо не защищает базу целиком, не может использоваться для полноценного восстановления. Не содержит системные прав и прочее. Время восстановления ужасно. И в итоге имеем другую БД начиная с ID и кончая настройками и идентификаторами в БД.
В Oracle есть нормальный механизм резервного копирования, но надо изобретать яйцо фаберже...
Ох, зациклились Вы на схемах, если умеешь пользоваться молотком, то все вокруг кажется гвоздями.
Еденица бекапа в Oracle - табличное пространство. Сделайте соответствие между схемой и табличным пространством/ми и будет вам счастье. Надо перенести в другую базу, так есть transportable tablespace.
Все уже есть в Оракле, не надо изобретать велосипед, надо просто прочитать документацию.
Опять же если грамотно выработана ILM стратегия. И старые данные лежат в отдельных табличных пространствах так их можно сделат read only и забекапить один раз.
Очень просто: если развести схемы по табличным пространствам, то Tablespace point in time recovery
Конечно поддерживает, видимо лень было почитать про rman.
Ну и тут куча вопросов про восстановление и его время. Опять же такой бэкап подразумевает пересоздание индексов после восстановление а это время. Ну в итоге после этого новая БД получится, а не старая восстановленная. Другие идентификаторы в системных таблицах и все такое.
Из такого бэкапа получить клон бд скажем для стендбая тоже не реально.
Данная реализация скорее похожа на аудит, и не похожа на SCD2. Если точнее это SCD4. Трудоемкость получить состояние на определенное время у SCD4 выше чем у SCD2. Насколько я знаю есть несколько расширений для аудита, почему не использовать их?
Отдельный вопрос производительность: насколько использование триггеров замедляет скорость вставки? Проводилось ли тестирование? Какие текущие объемы и нагрузка?
Так же хранения истории ставит вопрос управление жизнью информации, Например, партиционирование и выведение старой информации из системы (удаление и архивирование), тут я этого не вижу.
Инструкция рабочая, по ней собрать получилось. Спасибо.
Не хватает шага: pacman -S git
У нас было все просто, в игры можно было поиграть только те, что сам написал или друзья написали ))) В итоге был самописный тетрис, арканоид, пару экономических стратегий и несколько лабиринтов типа Rise Out.
А так ребенка при наличии современных игр заставить программировать тяжело. Попробуйте что то игровое, типа упомянутого в статье lego mindstorm.
Школа номер 66. Там в 1984 году появилась ЭВМ Искра 226 (https://ru.wikipedia.org/wiki/Искра_226). Потом появилась одна ДВК-2, а в конце 80х класс MSX.
Информатики как таковой не было, ЭВМ появилась в качестве эксперимента для планирования расписания, ну и был кружок. Преподаватели были замечательные, вплоть до того что когда мы готовились к олимпиаде по программированию, нам завуч просто давал ключи от кабинета с ЭВМ без взрослого контроля. Ну и тусовка была странная от 5 класников до 10 класников, человек 5.
Насколько я помню по гордским школьным олипиадам по программированию (да они проводились в Омске регулярно в 80х), что-то типа СМ 1420 было в 64 матшколе в те же времена. Ну и был с 1986 года кружок программирования в пединституте, там были Ямахи (MSX) и Агат (что на на 6502)
Мне кажется, что автор скорее критикует монолит, чем базы за ним.
Отдельная история, что говоря о новомодных базах, автор опускает тему надежности.
Еще детальнее:
готовим a_tmp
старую партицию a1 отключаем/удаляем
новую подключаем с ТЕМ ЖЕ FOR VALUES
переименовываем a_tmp в a1, на пользователей не влияет, они работают с A
Ключ партиционирования можно взять любую колонку в таблице, например id, а лучше дату операции (тогда сможем выделить несколько партиций и ускорится), ступора у оптимизатора не будет, даже если нет ключа партиционирования в запросе, не придумывайте
Attach partition именно способ для быстрой замены данных, а не пополнения.
Теперь про ваш способ: вместо стандартных SQL команд, получилось "яйцо фаберже", с которым ничего сделать нельзя, партиционировать и менять часть данных - нельзя, вторичные ключи на него создать - нельзя.
Придут люди вам на замену и будут разбираться с экзотическим кодом.
Извините, но вы видимо не поняли:
Есть таблица A, она партиционирована, скажем партиции A1 и A2 (можно и одну партицию A1, что бы был ваш случай). Все приложения работают с A и про партиции ничего не знают, оптимизатор сам решает какие партиции брать для запроса.
Теперь готовим отдельно таблицу A3, индексируем ее, далее отключаем/удаляем скажем A1 и подключаем A3. Пользователи как работали с A, так и работают, никаких кастомных скриптов, штатные DETACH PARTITION и ATTACH PARTITION.
Зачем представление и дополнительная таблица мне не понятно.
Партиционирование и подключение/отключение партиций это стандартный паттерн для DWH, зачем изобретать велосипед с переименованием таблиц мне не понятно.
А собственно почему нельзя просто партиционировать таблицу, и удалять а затем подключать новые партиции рассчитаные заранее?
Мы же говорим про DWH, как же там без партиционирования?!
Опять же такой механизм позволяет гибко работать не только подменяя всю таблицу, но и ее часть за конкретный период например.
Для приложения ничего не меняется, все блокировки PostgreSQL сам сделает
Ну я в DIS не работаю, как я понял, с их слов, они официально лицензировали ядро включая исходники, так что Информатика в курсе.
Если убрать эмоции, то я с Вами согласен:
DV имеет проблемы в MPP и на очень больших хранилищах (нужно прорабатывать партиционирование/шардирование, хотя есть реализации на том же GP, Яндекс регулярно докладывает)
DV требует материализации в плоские витрины (ну так это же не все хранилище а просто слой из которого собираются витрины)
DV пихают везде, не понимая его преимуществ и недостатков.
Итого, мое мнение: DV всем не нужен. Применяя DV, Вы должны понимать, что вы теряете, и что от этого получите. Самое смешное, но DV в последнее время требуют заказчики (им не нужно просто хранилище им подавай фреймворк), и их зачастую приходится отговаривать.
НО, там где он подходит, и заказчик готов платить за разработку фреймворка и за лишние вычислительные ресурсы, DV существенно сокращает time2market.
Тут все сложнее. Все же Informatica шла в правильном направлении там и оффлоад появлялся. Но конечно ODI на голову выше продукт, 2 года назад я бы однозначно рекомендовал его.
Вы абсолютно правильно подметили, что DIY не дает Data Lineage.
В FormIT Plus7 от DIS Group именно лицезированное ядро Informatica, так что это именно информатика под другим названием.
Полностью с Вами согласен по поводу особенностей и недостатков Data Vault. Все грамотно описано.
Но надо четко понимать, для чего нужен Data Vault:
Полное версионирование хранилища (отсюда выделение SAT как SCD машина). Т.е. возможность увидеть данные как они были N дней назад.
Динамическое развитие/изменение хранилища, добавление новых связей, работа по agile (представьте что вам надо в звезде Кимбала добавить измерение) (отсюда выделение связи в LINK)
И Data Vault используют если Вы готовы пожертвовать местом/удобством и скоростью работы хранилища ради двух вышеуказанных преимуществ.
И да, Data Vault ТРЕБУЕТ автоматического фреймворка, делать Data Vault руками - бред и самоубийство, я про это уже писал (https://habr.com/ru/companies/jetinfosystems/articles/721950/)
На нашем опыте, СТРОГО при наличии фреймворка, Data Vault дает преимущество по скорости развития хранилища (time2market) в 1.5-2 раза, с учетом наличии требования по версионированию данных.
Не делайте Data Vault если у Вас нет требования по версионированию и нет (не планируете создавать) автоматического фреймворка.