Тут скорее вопрос внешняя разработка или внутренняя. При внутренней - как Вы описали. При внешней скорее как в статье. Я бы не рискнул делать разработку на заказ, без подготовленных и согласованных заказчиком бизнес требований и технического задания и без документирования каждого шага. Иначе, потом сдавать заколеблешься.
У меня вопрос, как в анекдоте, а что в армии один солдат "бизнес-аналитик"?
Сам процесс построения описан корректно. Но где разделение по ролям? Где архитектор? Где системный аналитик?
Имхо, бизнес аналитик заканчивается на этапе информационного обследования и построение бизнес требований, а дальше дело архитектора, системных аналитиков и разработчиков.
Конечно, тут вопрос терминологии видов аналитиков, но как минимум архитектор должен быть на проекте точно.
Слишком поверхностно, новичок не поймет, так как не разжевано, а тем кто понимает и не надо.
Было бы не плохо: 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 это сделать можно, и непонятно почему не сделан), без планов статья смысла не имеет.
Есть инкриментальй и камулятивный бэкап. Так что за ночь не надо бекапить терабайты.
Ну и многопоточный rman полный бэкап 2-3 тб бэкапит максимум час. Мы 100 тб бэкапим без проблем. Но еще раз это не надо, можно бэкапить инкремнет. И сжатие там есть.
Дальше все засисит от вашей политики бекапа, хоть за 10 лет храните и востанавливайтесь на любую секунду из 10 лет. Хоть часть, хоть все. Судя по вашим вопросам Вы не понимаете как рабтает rman.
Ну и самоое главное, любой новый DBA придет увидит rman и восстановит вам БД или ее часть с закрытыми глазами. В вашем случае специалист со стороны за сколько?
О боже, стендбай - НЕ БЕКАП. Накатили левый патч на базу, изменения ушли на стэндбай и привет. А то по вашему и raid из дисков бекап.
Дамп - НЕ БЕКАП, ибо не защищает базу целиком, не может использоваться для полноценного восстановления. Не содержит системные прав и прочее. Время восстановления ужасно. И в итоге имеем другую БД начиная с ID и кончая настройками и идентификаторами в БД.
В Oracle есть нормальный механизм резервного копирования, но надо изобретать яйцо фаберже...
Ох, зациклились Вы на схемах, если умеешь пользоваться молотком, то все вокруг кажется гвоздями.
Еденица бекапа в Oracle - табличное пространство. Сделайте соответствие между схемой и табличным пространством/ми и будет вам счастье. Надо перенести в другую базу, так есть transportable tablespace.
Все уже есть в Оракле, не надо изобретать велосипед, надо просто прочитать документацию.
Опять же если грамотно выработана ILM стратегия. И старые данные лежат в отдельных табличных пространствах так их можно сделат read only и забекапить один раз.
Конечно поддерживает, видимо лень было почитать про rman.
Ну и тут куча вопросов про восстановление и его время. Опять же такой бэкап подразумевает пересоздание индексов после восстановление а это время. Ну в итоге после этого новая БД получится, а не старая восстановленная. Другие идентификаторы в системных таблицах и все такое.
Из такого бэкапа получить клон бд скажем для стендбая тоже не реально.
Данная реализация скорее похожа на аудит, и не похожа на SCD2. Если точнее это SCD4. Трудоемкость получить состояние на определенное время у SCD4 выше чем у SCD2. Насколько я знаю есть несколько расширений для аудита, почему не использовать их?
Отдельный вопрос производительность: насколько использование триггеров замедляет скорость вставки? Проводилось ли тестирование? Какие текущие объемы и нагрузка?
Так же хранения истории ставит вопрос управление жизнью информации, Например, партиционирование и выведение старой информации из системы (удаление и архивирование), тут я этого не вижу.
Оно вчера работало идеально, сегодня перестало. Тут еще вопрос какой телек и какой провайдер.
Я думаю DPI отличается от провайдера к провайдеру.
Логика простая:
$SCRIPT $ARGS -запускает демона который курочит пакеты на 999 порту
а далее делаете сколько надо iptables -t nat -A PREROUTING -i br0 что бы отправить трафик по нужным портам и протоколам на обработку
у демона можно настроить список того что он обрабатывает через --hostlist $HOSTLISTFILE" , остальной трафик пойдет без изменений
Кусок скрипта про запуск:
SCRIPT=/jffs/zapret/tpws
PIDFILE=/var/run/tpws.pid
HOSTLISTFILE=/jffs/zapret/hostlist.txt
ARGS="--daemon --bind-addr 192.168.1.1 --port 999 --disorder --tlsrec=sni --split-pos=2 --pidfile $PIDFILE --hostlist $HOSTLISTFILE"
start() {if [ -f $PIDFILE ] && kill -0 $(cat $PIDFILE); then
echo 'Service TPWS is already running' >&2
return 1
fi
$SCRIPT $ARGS
iptables -t nat -A PREROUTING -i br0 -p tcp --dport 80 -j REDIRECT --to-port 999
iptables -t nat -A PREROUTING -i br0 -p tcp --dport 443 -j REDIRECT --to-port 999
iptables -t nat -A PREROUTING -i br0 -p udp --dport 443 -j REDIRECT --to-port 999
echo 'Started TPWS service'}
iptables -t nat -A PREROUTING -i br0 -p udp --dport 443 -j REDIRECT --to-port 999
Неа, VPN и обход DPI лечат, значит - блокируют
Если настроить на хосты TCP и UDP :
googlevideo.com
youtube.com
youtu.be
ytimg.com
youtube-ui.l.google.com
ytimg.l.google.com
ytstatic.l.google.com
youtubei.googleapis.com
То на компе и на телефоне работает.
Опции: --disorder --tlsrec=sni --split-pos=2
Телевизор Samsung перестал работать (вчера работал с теми же опциями)
Тут скорее вопрос внешняя разработка или внутренняя. При внутренней - как Вы описали. При внешней скорее как в статье. Я бы не рискнул делать разработку на заказ, без подготовленных и согласованных заказчиком бизнес требований и технического задания и без документирования каждого шага. Иначе, потом сдавать заколеблешься.
У меня вопрос, как в анекдоте, а что в армии один солдат "бизнес-аналитик"?
Сам процесс построения описан корректно. Но где разделение по ролям? Где архитектор? Где системный аналитик?
Имхо, бизнес аналитик заканчивается на этапе информационного обследования и построение бизнес требований, а дальше дело архитектора, системных аналитиков и разработчиков.
Конечно, тут вопрос терминологии видов аналитиков, но как минимум архитектор должен быть на проекте точно.
Слишком поверхностно, новичок не поймет, так как не разжевано, а тем кто понимает и не надо.
Было бы не плохо:
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. Насколько я знаю есть несколько расширений для аудита, почему не использовать их?
Отдельный вопрос производительность: насколько использование триггеров замедляет скорость вставки? Проводилось ли тестирование? Какие текущие объемы и нагрузка?
Так же хранения истории ставит вопрос управление жизнью информации, Например, партиционирование и выведение старой информации из системы (удаление и архивирование), тут я этого не вижу.