Как стать автором
Обновить
0
0.1
Виктор Езерский @Mapar

Пользователь

Отправить сообщение

Тут скорее вопрос внешняя разработка или внутренняя. При внутренней - как Вы описали. При внешней скорее как в статье. Я бы не рискнул делать разработку на заказ, без подготовленных и согласованных заказчиком бизнес требований и технического задания и без документирования каждого шага. Иначе, потом сдавать заколеблешься.

У меня вопрос, как в анекдоте, а что в армии один солдат "бизнес-аналитик"?

Сам процесс построения описан корректно. Но где разделение по ролям? Где архитектор? Где системный аналитик?

Имхо, бизнес аналитик заканчивается на этапе информационного обследования и построение бизнес требований, а дальше дело архитектора, системных аналитиков и разработчиков.

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

Слишком поверхностно, новичок не поймет, так как не разжевано, а тем кто понимает и не надо.

Было бы не плохо:
1. привести сводную таблицу в которой видно различия в подходах
2. взять конкретный пример, и показать как он реализуется в разных подходах.

"Кроме того, объединение нескольких таблиц может приводить к блокировке большого объема данных на длительное время, что затруднит обновление данных другими операциями. "

Это что за такие блокировки? В Oracle читатели не блокируют никого.

Согласен со всеми предыдущими постами, дайте планы.

По факту в PL/SQL вариантами вы руками сделали Nested Loop, какие соединения в планах первых двух запросов.

И главное последний вариант:

where event_name = l_rec.event_name and (attribute_1 like '%XX_IF_ERRORS%' or attribute_1 is NULL)

второй вариант:

(upper(p.attribute_1) like '%' || t2.log_name || '%' or p.attribute_1 is NULL)

Т.е. upper есть в одном запросе и нет в другом, кроме того в первом запросе константа.

Итого: запросы не равнозначны, построен Nested Loop (на SQL это сделать можно, и непонятно почему не сделан), без планов статья смысла не имеет.

Google rman trasportable tablespace

Не вопрос и в другую

Кстати да хорошая идея.

Есть инкриментальй и камулятивный бэкап. Так что за ночь не надо бекапить терабайты.

Ну и многопоточный 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)

Мне кажется, что автор скорее критикует монолит, чем базы за ним.

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

Еще детальнее:

  1. готовим a_tmp

  2. старую партицию a1 отключаем/удаляем

  3. новую подключаем с ТЕМ ЖЕ FOR VALUES

  4. переименовываем a_tmp в a1, на пользователей не влияет, они работают с A

  5. Ключ партиционирования можно взять любую колонку в таблице, например id, а лучше дату операции (тогда сможем выделить несколько партиций и ускорится), ступора у оптимизатора не будет, даже если нет ключа партиционирования в запросе, не придумывайте

    Attach partition именно способ для быстрой замены данных, а не пополнения.

Теперь про ваш способ: вместо стандартных SQL команд, получилось "яйцо фаберже", с которым ничего сделать нельзя, партиционировать и менять часть данных - нельзя, вторичные ключи на него создать - нельзя.

Придут люди вам на замену и будут разбираться с экзотическим кодом.

Извините, но вы видимо не поняли:

Есть таблица A, она партиционирована, скажем партиции A1 и A2 (можно и одну партицию A1, что бы был ваш случай). Все приложения работают с A и про партиции ничего не знают, оптимизатор сам решает какие партиции брать для запроса.

Теперь готовим отдельно таблицу A3, индексируем ее, далее отключаем/удаляем скажем A1 и подключаем A3. Пользователи как работали с A, так и работают, никаких кастомных скриптов, штатные DETACH PARTITION и ATTACH PARTITION.

Зачем представление и дополнительная таблица мне не понятно.

Партиционирование и подключение/отключение партиций это стандартный паттерн для DWH, зачем изобретать велосипед с переименованием таблиц мне не понятно.

1

Информация

В рейтинге
2 730-й
Откуда
Россия
Зарегистрирован
Активность