Добрый день. Спасибо за статью. Для vim-а был такой замечательный проект, превращавщий vim в практически полнокровное консольное IDE для oracle - VoraX
Спасибо за отзыв. А не знаю, что за сумрачный разум и зачем задизайнил такую табличную модель. Мне задачу поставили - надо чтобы были реплики, от этого, вот там, делай. Пытался отбиться, тыкал пальцем в гг-доку, говорил что - расхождения будут, что потом будем сидеть сверки делать, расхождения устранять между таблицами и репликами. Ну. Этим и закончилось Да это исторические таблицы, в большинстве своём.
@sargon5000 Спасибо за содержательный коммент. Ради чего то такого и решился на публикацию. Да, действительно. Тут даже можно усилить пример: по свойствам xor-операции A xor A = 0; Т.е., например, две таблицы, с чётным, но разным, кол-вом одинаковых строк - дадут один и тот же xor-дайджест, увы.
Спасибо за статью. Вариант с голденгейтом не рассматривали? Ну т.е.: слепить, какую надо, целевую таблицу, с какими надо индексами, грантами. И запустить на неё репликацию из исходной (старой) таблицы. Когда среплициуются все, или, хотя бы - какие надо строки, собрать цбо-стату на новую таблицу, выставить лок на старую таблицу, репликацию остановить, старую таблицу переименовать, создать синоним на новую таблицу, провайдящий старое имя, доработать целевую таблицу (триггеры например, если надо, создать) валидировать всё что развалидось от удаления старой таблицы.
Не упомянули про тонкости с лицензированием, например вот тут они, вполне доходчиво обсуждаются.
Прикручивать NFS-шару, для обмена арх-логами, ну, да, прикручивают, куда деватся. Но. Лучше использовать какой нибудь incrond+rsync, для пуляния в standby-сторону арх. логов, как только они появились, на стороне primary-бд. И на стороне standby-бд, тоже incrond-демон, реагирующий на появление файла архлога, запускающий шелл-скрипт, для наката его на standby-бд. А nfs-шару держать для складирования/расшаривания на/с неё бэкапов, в т.ч. бэкапов арх-логов.
Спасибо, интересная статья. Чем то напомнило процесс работы гаусовых микстур-моделей кластеризации.
Погуглил, почитал примеры фромскратч-кодирования BOA, например. YuraLia спасибо за ссылку на хабр-статью, добавила, да, к понимаю, наглядно.
Можно ещё уточню: я правильно понимаю что в BOA — таки делается какое то, именно — волюнтаристкое (ну. в смысле — не строго формально обоснованное), допущение о том как именно устроена функция правдоподобия.
Добрый день. Спасибо за статью. Это: только по бизнес-функциональным требованиям так делаете? По технико-эксплуатационным нормам работы нового сервиса как требования собираете? Ну там, понятно — часть таких требований: выводится из нагрузочного/стресс тестирования, однако часть требований — может существовать априорно, ещё на этапе формирования бизнес-функциональных требований к сервису.
Только — пониматься, эта часть, может, всеми сторонами проекта — по разному.
Ну там, один считает что бизнес-операции должны приходить в систему с таким то рейтом/параллелизмом/перцентилем корректной обработки.
Другой считает что — нет, не с таким и не совсем вот эти бизнес-операции.
Третий — ещё что нибудь считает.
Также собираете, сводите, согласовываете требования?
Разделение — оно, конечно, разделением. Но тут тонкий момент возникает, с появлением доступа к образу продовой бд, на виртуалке под лепление тестовой базы, из этого образа.
Если и это перекрыть — т.е.: не подавать туда образ базы, никак, ну а как тогда, вообще, на этой виртуалке, выделенной под лепление тестовой бд, слепить тестовую бд.
При БФТ, на лепление тестовых баз, таких что "нам нада всё, что в проде, и акутальное. и чтобы быстро тестовая база у нас была, через час времени, у нас проект, у нас сроки." — тут, без подачи образа продовой бд, на виртуалку, предназначенную для вылепливания из него тестовой бд — никак.
Значит что — как то спойлить/перекрывать доступ к табличным данным ещё до подачи образа продовой бд на эту вм, так получается.
А как? VPD какое то что ли?
да, продовый и тестовый контур: должны быть разделены.
в этой схеме — такое разделение вполне себе можно получить.
тонкий-скользкий момент тут будет возникать с момента когда на виртуалку, ну в терминах статьи — на devdb-вм, т.е.: там где тестовую бд лепить, подаётся образ продовой бд.
Вот начиная с этого момента в отношении пропалить продовые данные — риски, есть, да.
Понятно что можно как то уменьшить эти риски.
Ну там, выполнять монтирование ресурса с кластерной фс, на devdb, под спец-учёткой ОС-и, на devdb.
Выполнять обработку образа продовой бд, на devdb, в т.ч.: спойлинг табличных данных, под спец-учёткой ОС-и.
Шифрацию там какую то, канала связи между devdb и кластером.
Но — всё это только минимизация. Но не исключение. Всегда есть вероятность существования какой нибудь уязвимости позволяющий зловреду, даже из DMZ-зоны подключится к серверу и наделать своих делов.
Этот момент — тоже был интересен, я пока набирал статью пытался его удержать в голове, но в итоге — благополучно забыл акцентировать в статье.
Байесовская оптимизация. Здесь значения гиперпараметров в текущей итерации выбираются с учётом результатов на предыдущем шаге. Основная идея алгоритма заключается в следующем – на каждой итерации подбора находится компромисс между исследованием регионов с самыми удачными из найденных комбинаций гиперпараметров и исследованием регионов с большой неопределённостью (где могут находиться ещё более удачные комбинации).
А генетические алгоритмы оптимизации: разве не этим же и, практически, так же занимаются? Там только по другому всё называется — конкретная комбинация значений параметров поиска: хромосома, «самые удачные из найденных комбинаций» — это хромосомы с лучшим значением функции приспособленности, они отбираются в следующую популяцию.
Отличное дополнение к той статье, спасибо.
Ещё, в тему резалт-кеша и вообще кэширования в oracle-субд, сразу вспомнился доклад Александра Токарева, из датаарт.
Интересная статья, спасибо.
Ещё добавлю что, если говорить про подключения к oracle-субд, ч/з нативного oracle-клиента, в данном случае, можно воспользоваться taf-ом: такая разновидность тнсалиасов.
Причём, поскольку тут standby-бд: оно, при выводе в работу standby-бд, с полной её актуализацией, ещё и состояние курсоров восстановит, в скл-сессиях.
Есть ещё рабоче-крестьянский вариант: на машинах с праймари/стандбу-базами ставится какое нибудь кластерваре попроще.
коросинк например, сойдёт, если между машинами не очень большое расстояние, в смысле сетевых латенсей.
Ну и, собственно, всё, можно в этом кластере из двух (и более) нод определить кластерный ресурс — ip-адрес.
И перемещать его, т.о. чтобы он всегда был на той машине на которой сейчас находится активная субд.
Как перемещать — вопрос отдельный.
Для машин которые далеко разнесены друг от друга, типа DR-сайт в другом цод-е/городе, ну, bgp-протокол с анонсами.
Ну и всё, собственно, к ip-шнику прописывается в днс-е какой то фкнд, на этот фкнд создаются тнсалиасы, или всякие там jdbc|odbc строки подключения из клиентский приложений и вот оно по нему ходит в базу.
Есть свои плюсы/минусы в таком варианте.
В статье не упомянут главный минус: попробуйте переопределить код хранимки, в бд, в том случае если это — популярная хранимка.
Полное b2b (только не бизнес-ту-бизнес, а Боль-Тоска-Безисходность) и очереди заблокированных скл-сесий в бд.
Удивительно почему в комментариях об этом никто не вспомнил.
Отдельный треш начинается если среди хранимок — есть функции и если (о ужас) их начинают использовать в скл-запросах.
Например в предикатах.
Или (ужас в квардрате) в качестве датасорсов, например в виде table-функций (если в терминах oracle-субд).
Представте как тут цбо-оптимизатору здорово «получается» всякие кардиналити расчитывать, при оптимизации таких запросов.
рдбмс-субд были придуманы в первую очередь как скл-энжин.
Именно и только в таком качестве, в общем случае, они и должны использоваться, не надо туда пихать логику.
Для логики есть мидл-тиер.
Кроме того, запихав логику в бд потом вдруг выясниться, что между базой и клиентами базы — крайне трудно впихнуть какой то кеш-слой например.
Бикоз-оф вынос логики в базу провоцирует клинетов, обращаться в бд, не на уровне скл-команд, а на уровне апи этой логики — дёргая хранимки.
Ну и, стало быть, если потом захочется (а захочется, прям очень) кеш какой то, между клиентами и базой — надо будет чтобы этот кеш — понимал протокол вызова хранимок, как минимум.
Добрый день. Спасибо за статью.
Для vim-а был такой замечательный проект, превращавщий vim в практически полнокровное консольное IDE для oracle - VoraX
Замечательная статья.
Спасибо за отзыв.
А не знаю, что за сумрачный разум и зачем задизайнил такую табличную модель.
Мне задачу поставили - надо чтобы были реплики, от этого, вот там, делай.
Пытался отбиться, тыкал пальцем в гг-доку, говорил что - расхождения будут, что потом будем сидеть сверки делать, расхождения устранять между таблицами и репликами.
Ну. Этим и закончилось
Да это исторические таблицы, в большинстве своём.
@sargon5000 Спасибо за содержательный коммент. Ради чего то такого и решился на публикацию.
Да, действительно. Тут даже можно усилить пример: по свойствам xor-операции A xor A = 0;
Т.е., например, две таблицы, с чётным, но разным, кол-вом одинаковых строк - дадут один и тот же xor-дайджест, увы.
Про запятые. Ну. Простите. Не писатель.
Спасибо за статью.
Вариант с голденгейтом не рассматривали?
Ну т.е.: слепить, какую надо, целевую таблицу, с какими надо индексами, грантами.
И запустить на неё репликацию из исходной (старой) таблицы.
Когда среплициуются все, или, хотя бы - какие надо строки, собрать цбо-стату на новую таблицу, выставить лок на старую таблицу, репликацию остановить, старую таблицу переименовать, создать синоним на новую таблицу, провайдящий старое имя, доработать целевую таблицу (триггеры например, если надо, создать) валидировать всё что развалидось от удаления старой таблицы.
Не упомянули про force logging режим работы субд.
Не упомянули про тонкости с лицензированием, например вот тут они, вполне доходчиво обсуждаются.
Прикручивать NFS-шару, для обмена арх-логами, ну, да, прикручивают, куда деватся. Но. Лучше использовать какой нибудь incrond+rsync, для пуляния в standby-сторону арх. логов, как только они появились, на стороне primary-бд. И на стороне standby-бд, тоже incrond-демон, реагирующий на появление файла архлога, запускающий шелл-скрипт, для наката его на standby-бд. А nfs-шару держать для складирования/расшаривания на/с неё бэкапов, в т.ч. бэкапов арх-логов.
Погуглил, почитал примеры фромскратч-кодирования BOA, например.
YuraLia спасибо за ссылку на хабр-статью, добавила, да, к понимаю, наглядно.
Можно ещё уточню: я правильно понимаю что в BOA — таки делается какое то, именно — волюнтаристкое (ну. в смысле — не строго формально обоснованное), допущение о том как именно устроена функция правдоподобия.
Только — пониматься, эта часть, может, всеми сторонами проекта — по разному.
Ну там, один считает что бизнес-операции должны приходить в систему с таким то рейтом/параллелизмом/перцентилем корректной обработки.
Другой считает что — нет, не с таким и не совсем вот эти бизнес-операции.
Третий — ещё что нибудь считает.
Также собираете, сводите, согласовываете требования?
Если и это перекрыть — т.е.: не подавать туда образ базы, никак, ну а как тогда, вообще, на этой виртуалке, выделенной под лепление тестовой бд, слепить тестовую бд.
При БФТ, на лепление тестовых баз, таких что "нам нада всё, что в проде, и акутальное. и чтобы быстро тестовая база у нас была, через час времени, у нас проект, у нас сроки." — тут, без подачи образа продовой бд, на виртуалку, предназначенную для вылепливания из него тестовой бд — никак.
Значит что — как то спойлить/перекрывать доступ к табличным данным ещё до подачи образа продовой бд на эту вм, так получается.
А как? VPD какое то что ли?
в этой схеме — такое разделение вполне себе можно получить.
тонкий-скользкий момент тут будет возникать с момента когда на виртуалку, ну в терминах статьи — на devdb-вм, т.е.: там где тестовую бд лепить, подаётся образ продовой бд.
Вот начиная с этого момента в отношении пропалить продовые данные — риски, есть, да.
Понятно что можно как то уменьшить эти риски.
Ну там, выполнять монтирование ресурса с кластерной фс, на devdb, под спец-учёткой ОС-и, на devdb.
Выполнять обработку образа продовой бд, на devdb, в т.ч.: спойлинг табличных данных, под спец-учёткой ОС-и.
Шифрацию там какую то, канала связи между devdb и кластером.
Но — всё это только минимизация. Но не исключение. Всегда есть вероятность существования какой нибудь уязвимости позволяющий зловреду, даже из DMZ-зоны подключится к серверу и наделать своих делов.
Этот момент — тоже был интересен, я пока набирал статью пытался его удержать в голове, но в итоге — благополучно забыл акцентировать в статье.
А генетические алгоритмы оптимизации: разве не этим же и, практически, так же занимаются? Там только по другому всё называется — конкретная комбинация значений параметров поиска: хромосома, «самые удачные из найденных комбинаций» — это хромосомы с лучшим значением функции приспособленности, они отбираются в следующую популяцию.
Ещё, в тему резалт-кеша и вообще кэширования в oracle-субд, сразу вспомнился доклад Александра Токарева, из датаарт.
Ещё добавлю что, если говорить про подключения к oracle-субд, ч/з нативного oracle-клиента, в данном случае, можно воспользоваться taf-ом: такая разновидность тнсалиасов.
Причём, поскольку тут standby-бд: оно, при выводе в работу standby-бд, с полной её актуализацией, ещё и состояние курсоров восстановит, в скл-сессиях.
Есть ещё рабоче-крестьянский вариант: на машинах с праймари/стандбу-базами ставится какое нибудь кластерваре попроще.
коросинк например, сойдёт, если между машинами не очень большое расстояние, в смысле сетевых латенсей.
Ну и, собственно, всё, можно в этом кластере из двух (и более) нод определить кластерный ресурс — ip-адрес.
И перемещать его, т.о. чтобы он всегда был на той машине на которой сейчас находится активная субд.
Как перемещать — вопрос отдельный.
Для машин которые далеко разнесены друг от друга, типа DR-сайт в другом цод-е/городе, ну, bgp-протокол с анонсами.
Ну и всё, собственно, к ip-шнику прописывается в днс-е какой то фкнд, на этот фкнд создаются тнсалиасы, или всякие там jdbc|odbc строки подключения из клиентский приложений и вот оно по нему ходит в базу.
Есть свои плюсы/минусы в таком варианте.
Полное b2b (только не бизнес-ту-бизнес, а Боль-Тоска-Безисходность) и очереди заблокированных скл-сесий в бд.
Удивительно почему в комментариях об этом никто не вспомнил.
Отдельный треш начинается если среди хранимок — есть функции и если (о ужас) их начинают использовать в скл-запросах.
Например в предикатах.
Или (ужас в квардрате) в качестве датасорсов, например в виде table-функций (если в терминах oracle-субд).
Представте как тут цбо-оптимизатору здорово «получается» всякие кардиналити расчитывать, при оптимизации таких запросов.
рдбмс-субд были придуманы в первую очередь как скл-энжин.
Именно и только в таком качестве, в общем случае, они и должны использоваться, не надо туда пихать логику.
Для логики есть мидл-тиер.
Кроме того, запихав логику в бд потом вдруг выясниться, что между базой и клиентами базы — крайне трудно впихнуть какой то кеш-слой например.
Бикоз-оф вынос логики в базу провоцирует клинетов, обращаться в бд, не на уровне скл-команд, а на уровне апи этой логики — дёргая хранимки.
Ну и, стало быть, если потом захочется (а захочется, прям очень) кеш какой то, между клиентами и базой — надо будет чтобы этот кеш — понимал протокол вызова хранимок, как минимум.