Ну, не обязательно. У меня в в голове PCM-ке есть кнопка Phone, но при нажатии хрен догадаешься, что она не активирована - выглядит будто не соединиться. Когда захотел активировать, то оказалось, что микрофона в плафоне нет. Естественно у дилера замена плафона + активация - от 175000 :(. Хорошо есть клубный сервис - провели микрофон (родной) и прошили...
Формально — это проблема того, с кем у вас договор. Т.е. если вас отключают по причине того, что считают вашу активность вредительской, а оказывается, что они полагались на неверные выводы своих средств автоматизации, то они фактически попадают на компенсационные выплаты ввиду нарушения договора о предоставлении услуг.
Установил тут corretto на MacOS. Они единственные ставят JDK в JavaVirtualMachines не пофайлово, а пакетом. Мелочь, а приятно.
Из плюсов — то же соответствие по TCK, ну и очевидно откуда финансирование: у Amazon куча сервисов на Java и они посчитали целесообразнее сопровождать jdk самостоятельно.
Из минусов мне видится, что как только они переползут целиком на Java 11, то Java 8 забросят, но к тому времени — думается — большинство переползёт.
P.S.> Если вы разрабатываете на MacOS, то рекомендую рассмотреть corretto как jdk для рабочего ПК.
Спасибо, как то так я и вытягивал список, но вот сама ссылка на хабик исключительно полезна — много готовых скриптов в зоне досягаемости, а то у самого руки не доходят всё в облако или хаб свалить. Мерси, плюсую.
Вещь, конечно, полезная из разряда must to know, но вы с постом лет на 20 опоздали…
В UNIX подобных системах (а MacOS X это — фактически — клон FreeBsd), а так же в Linux-системах с помощью утилит
mknod и mkfifo возможно создание именованного канала. На современных FreeBSD системах уходят от использования mknod (утилита объявляется как deprecated), а — как правило — используют mkfifo.
В 90-х гг. использовал для упаковки/распаковки на лету дампов СУБД Oracle при экспорте/импорте при ограниченности свободного дикого пространства.
Да — удобно, но это из разряда базовых знаний, sorry.
P.S.> Но всё равно плюсую…
Ну, для phisical I/O всё по честному — это в секундах. Т.е. с 0.6-0.9 секунды мы упали до 0.045-0.065
Для logical I/O не поделено на кол-во процессов и всё это в сантисекундах. Поскольку всё в относительных величинах, то я как то не обращал внимание на единицы измерения — главное сравнивать всё в рамках одних единиц. В общем, для logical I/O для перевода в те же единицы, что и при phisical I/O надо разделить на 100 (процессов) и на 100 (всё в сантисекундах), т.е. — в итоге — поделить на 10000.
Как то так.
То, где я всё это тестировал это был HP SuperDome с подключенным Raid массивом — или какой-то из XP или NetApp (я уже не помню, что именно под эту задачу мне выдали). У заказчика это всё было задействовано на SuperDome + XP. Система хранения у нас — raw-девайсы (такую базу мне дали), а у заказчика и raw-девайсы и ASM (у каждого заказчика свой vision). Уровень RAID — думаю, что 5, хотя может быть и 7+2. Я снимал данные и не было цели подставлять оптимальную систему хранения.
Объёмы — за 3 года, секции по периоду (от 3 секций на день до секций по несколько дней в зависимости от заказчика), подсекций — от 16 до 64. На самом деле у заказчиков со временем данные стали выноситься во внешнюю систему и доступ к ним через dblink (так захотели), а в оперативной хранятся только 3-6 месяцев. По мере устаревания секции тоже сливались вместе на более длинные периоды (до месяца) — там же данные трогать не надо, хранятся упорядоченно и индексы на них сбалансированны.
P.S.> Средний дневной объём — 80-120 млн. записей/сутки. Точнее не скажу, но порядок такой.
P.P.S.> Естественно, что размеры периодов, количества подсекций, как мёрджить периоды и надо ли и т.д. полностью кастомно под заказчика, его объёмы, возможности техники, цели и т.п.
Если на уровне Statement, то да, но есть ещё на уровне соединения: класс — OracleConnection, метод — setDefaultRowPrefetch(...).
Да, и коль скоро мы заговорили про ARRAYSIZE,- есть такой интересный момент:
если мы, например, открываем курсор и тащим из него %fetchSize% строк, а последние строки попали из блока базы данных NNN, то после .next() нам будет передана следующая порция строк и если блок NNN был вычитан не полностью и там ещё есть нужные нам строки, то будет произведена операция повторного логического чтения данного блока. Таким образом, можно предположить, что если размер данных от %fetchSize% строк будет достаточно мал в сравнении с размером блока базы данных, то количество логических чтений будет выше реально необходимого (может даже в несколько раз).
В том то и дело, что после реорганизации таблицы в регулярную, выключением event-а и перезапуском базы данных в DBA_FEATURE_USAGE_STATISTICS следов по использованию опции не осталось. Та строчка, что есть присутствовала с момента создания базы и говорит об использовании опции системой.
Да, при некоторых задачах успеха может и не быть по объёму трафика, но сокращение roundtrip тоже дает эффект.
Касательно сокращения трафика между бэком и веб-клиентом — это вопрос не данной темы. Здесь рассматривается взаимодействие между бэком и сервером базы данных либо между клиентом и сервером базы данных, а точнее — работа с СУБД Oracle посредством SQL*Net протокола.
Ну, если вы используете ODBC или JDBC*OCI, то все вызовы проходят через те же Oracle Call Interface функции и результат будет такой же (только ARRAYSIZE надо определять через header соединения). Касательно JDBC*Thin думаю, что тоже будет всё ОК, но это надо проверять. Там реализован тот же SQL*Net протокол, но средствами Java Native и — естественно — некоторые аспекты могли быть опущены.
Ну, у себя я обнаружил это на обычных данных по абонентам. В среднем на абонента приходилось 7-14 записей, строчки ~ 1200 байт, в строке выборки находились данные по id абонента и имени клиента + несколько низкоселективных атрибутов. Запрос был аналитический типа STAR с групировками (там всякие агрегаты были). Базово сортировало не по абоненту, записей — около 48млн. При сортировке по клиенту, id абонента,… ужалось порядка 35%. Как повлиял ARRAYSIZE уже не скажу — на тот момент я его уже увеличил.
По поводу вашего вопроса — использовались реальные имена клиентов в истории, даты — естественно — были разные (
т.е. ближе ко второму вашему примеру).
Таки да — нормально. Есть системы, где в принципе не предусмотрена обработка данных на стороне сервера. Возможны ситуации, когда данные пакетно обрабатываются через определённые интервалы — выгружается некий объём и обсчитывается внешней по отношению к серверу подсистемой. Есть системы многомерного анализа и т.д.
Да и обычные OLTP системы могут создать сложности в плане избыточной нагрузки. Сократив количество roundtrip-ов можно убрать bottleneck с транзакционного ограничения канала, а сократив объем — с пропускного.
Когда система упирается в нехватку некоторого ресурса, то это — как правило — говорит о том, что мы подбираемся к границам возможностей системы (ну или просчитались где-то в плане выделения ресурса), но редко бывает, что заканчивается всё и сразу и при возникновении «bottleneck» в качестве первой помощи мы — как правило — пытаемся заткнуть нехватку одного ресурса избыточностью другого. Например — нехватку памяти свопом на диск, нехватку CPU выделением большего объёма памяти и т.д. Не всегда такие «решения» высокоэффективны в плане базовых, но могут быть исключительно полезны в частных задачах.
Если вы упираетесь в пропускную способность канала, который доставляет SQL*Net пакеты, то можете попробовать увеличить её, заплатив дополнительной нагрузкой на CPU и память сервера базы данных (хоть ресурс и дорогой, но если он избыточен, то почему бы и нет).
Так мы, вроде, уже давно используем tcmalloc в проектах в компании (нп. в HAS), разве что кроме Windows так как там не понравилось встревание либы напрямую в таблицу вызовов и правка её. Но у нас и особо нагруженных сервисов под Windows не наблюдается. tcmalloc особо эффективен на малых аллокациях (например — до 64к), а на больших ему уже могут составить конкуренцию и другие либы, но для наших задач tcmalloc в большинстве случаев подходит отлично. Насколько я понимаю — в большинстве проектов у нас и используется tcmalloc и уже довольно давно, а посему ваша делема в выборе меня удивила. Хотелось бы узнать над чем вы работали.
P.S.> Да, и tcmalloc у нас вроде как портирован под HP уже внутри компании.
P.P.S.> Но за статейку всё равно спасибо — цифры довольно интересные.
Блин, XXI век.
Приходишь в салон, заказываешь тест-драйв.
Понравилось — покупаешь ЧЕРЕЗ ИНТЕРНЕТ В СОСЕДНЕМ ШТАТЕ С ДОСТАВКОЙ.
Можно и дальше пойти — склад рядом разместить и доставят через пять минут;).
Ээээмммм… Я как бы специально вставил пункт P.P.P.S. Тема не про то как решать конкретную задачу, а то, что есть побочный эффект от oracle result cache благодаря которому можно организовать переключение состояния и использовать тяжелую функцию в ограниченном количестве вызовов.
2. Если попытаться из пакета сбросить result cache функции этого же пакета, то кэш не сбрасывается. В остальных моментах всё зависит от правильности настройки параметров result-cache.
3.?..
4. Ещё раз повторюсь — это не законченное решение, а пример использования
5. Мне как-то один человек говорил, что то-то и то-то мы писать не будем — а вдруг программист ошибётся :)…
Тема про PLSQL Developer — ИМХО — здесь лишняя.
Формат изложения «DBMS_METADATA and session sequence» и «Pagination, массивы и run-time расчёт количества строк для fetch» больше похож на заметки на полях.
Но в общем — как я уже сказал — полезно.
P.S.> Баги проверил — живёханьки, а вот local_listener dbca у меня на OEL прописал, но коллеги тоже сталкивались с отсутствием регистрации на листенере…
Ну, не обязательно. У меня в в голове PCM-ке есть кнопка Phone, но при нажатии хрен догадаешься, что она не активирована - выглядит будто не соединиться. Когда захотел активировать, то оказалось, что микрофона в плафоне нет. Естественно у дилера замена плафона + активация - от 175000 :(. Хорошо есть клубный сервис - провели микрофон (родной) и прошили...
Из плюсов — то же соответствие по TCK, ну и очевидно откуда финансирование: у Amazon куча сервисов на Java и они посчитали целесообразнее сопровождать jdk самостоятельно.
Из минусов мне видится, что как только они переползут целиком на Java 11, то Java 8 забросят, но к тому времени — думается — большинство переползёт.
P.S.> Если вы разрабатываете на MacOS, то рекомендую рассмотреть corretto как jdk для рабочего ПК.
У вас написано:
Давайте вызовем:
Вы пишете об исключении… Уупс — результат будет Infinite значение Double, а не ExecutionException, как пишете Вы
В UNIX подобных системах (а MacOS X это — фактически — клон FreeBsd), а так же в Linux-системах с помощью утилит
mknod и mkfifo возможно создание именованного канала. На современных FreeBSD системах уходят от использования mknod (утилита объявляется как deprecated), а — как правило — используют mkfifo.
В 90-х гг. использовал для упаковки/распаковки на лету дампов СУБД Oracle при экспорте/импорте при ограниченности свободного дикого пространства.
Да — удобно, но это из разряда базовых знаний, sorry.
P.S.> Но всё равно плюсую…
Для logical I/O не поделено на кол-во процессов и всё это в сантисекундах. Поскольку всё в относительных величинах, то я как то не обращал внимание на единицы измерения — главное сравнивать всё в рамках одних единиц. В общем, для logical I/O для перевода в те же единицы, что и при phisical I/O надо разделить на 100 (процессов) и на 100 (всё в сантисекундах), т.е. — в итоге — поделить на 10000.
Как то так.
Объёмы — за 3 года, секции по периоду (от 3 секций на день до секций по несколько дней в зависимости от заказчика), подсекций — от 16 до 64. На самом деле у заказчиков со временем данные стали выноситься во внешнюю систему и доступ к ним через dblink (так захотели), а в оперативной хранятся только 3-6 месяцев. По мере устаревания секции тоже сливались вместе на более длинные периоды (до месяца) — там же данные трогать не надо, хранятся упорядоченно и индексы на них сбалансированны.
P.S.> Средний дневной объём — 80-120 млн. записей/сутки. Точнее не скажу, но порядок такой.
P.P.S.> Естественно, что размеры периодов, количества подсекций, как мёрджить периоды и надо ли и т.д. полностью кастомно под заказчика, его объёмы, возможности техники, цели и т.п.
Да, и коль скоро мы заговорили про ARRAYSIZE,- есть такой интересный момент:
если мы, например, открываем курсор и тащим из него %fetchSize% строк, а последние строки попали из блока базы данных NNN, то после .next() нам будет передана следующая порция строк и если блок NNN был вычитан не полностью и там ещё есть нужные нам строки, то будет произведена операция повторного логического чтения данного блока. Таким образом, можно предположить, что если размер данных от %fetchSize% строк будет достаточно мал в сравнении с размером блока базы данных, то количество логических чтений будет выше реально необходимого (может даже в несколько раз).
Касательно сокращения трафика между бэком и веб-клиентом — это вопрос не данной темы. Здесь рассматривается взаимодействие между бэком и сервером базы данных либо между клиентом и сервером базы данных, а точнее — работа с СУБД Oracle посредством SQL*Net протокола.
По поводу вашего вопроса — использовались реальные имена клиентов в истории, даты — естественно — были разные (
т.е. ближе ко второму вашему примеру).
Да и обычные OLTP системы могут создать сложности в плане избыточной нагрузки. Сократив количество roundtrip-ов можно убрать bottleneck с транзакционного ограничения канала, а сократив объем — с пропускного.
Когда система упирается в нехватку некоторого ресурса, то это — как правило — говорит о том, что мы подбираемся к границам возможностей системы (ну или просчитались где-то в плане выделения ресурса), но редко бывает, что заканчивается всё и сразу и при возникновении «bottleneck» в качестве первой помощи мы — как правило — пытаемся заткнуть нехватку одного ресурса избыточностью другого. Например — нехватку памяти свопом на диск, нехватку CPU выделением большего объёма памяти и т.д. Не всегда такие «решения» высокоэффективны в плане базовых, но могут быть исключительно полезны в частных задачах.
Если вы упираетесь в пропускную способность канала, который доставляет SQL*Net пакеты, то можете попробовать увеличить её, заплатив дополнительной нагрузкой на CPU и память сервера базы данных (хоть ресурс и дорогой, но если он избыточен, то почему бы и нет).
P.S.> Да, и tcmalloc у нас вроде как портирован под HP уже внутри компании.
P.P.S.> Но за статейку всё равно спасибо — цифры довольно интересные.
Приходишь в салон, заказываешь тест-драйв.
Понравилось — покупаешь ЧЕРЕЗ ИНТЕРНЕТ В СОСЕДНЕМ ШТАТЕ С ДОСТАВКОЙ.
Можно и дальше пойти — склад рядом разместить и доставят через пять минут;).
P.S.> И налоги заплатятся в соседнем штате…
2. Если попытаться из пакета сбросить result cache функции этого же пакета, то кэш не сбрасывается. В остальных моментах всё зависит от правильности настройки параметров result-cache.
3.?..
4. Ещё раз повторюсь — это не законченное решение, а пример использования
5. Мне как-то один человек говорил, что то-то и то-то мы писать не будем — а вдруг программист ошибётся :)…
Формат изложения «DBMS_METADATA and session sequence» и «Pagination, массивы и run-time расчёт количества строк для fetch» больше похож на заметки на полях.
Но в общем — как я уже сказал — полезно.
P.S.> Баги проверил — живёханьки, а вот local_listener dbca у меня на OEL прописал, но коллеги тоже сталкивались с отсутствием регистрации на листенере…