Создать интересный контент наверное тоже нужно уметь. Тратить на это все свое свободное время, в большинстве своем свою молодость (16-25 лет, если смотреть на текущих топов). Другое дело, что практически у большинства блогеров медийное «время жизни» ограничено. И вот чем они будут заниматься потом ближе к 30-ти годам?..
Странная новость. Каждая из этих компаний по отдельности не внушает доверие ни по качеству услуг, ни по клиентскому сервису, ни по сохранению персональных данных клиентов и т.д. Остается надеяться что «минус» на «минус» даст плюс, хотя мы ведь все всё прекрасно понимаем…
Читаешь вот такие новости и можно искренне порадоваться за землян, НАСА, за их успехи в освоении космоса, марса… Хотелось бы видеть в таких новостях наших ученных, наши компании занимающиеся разработками в освоении марса, но мы ведь все прекрасно понимаем, что мы так отстаем (возможно еще не все потерянно) технически, материально и в помощь нам только батут.
Вот так почитаешь новости про взломы отечественных компаний и утечку персональных данных россиян и никаких комментариев, требований от РНК (вот например вчерашняя статья про взлом ДОМ.РУ). А вот к фейсбуку нужно применить весь административный ресурс, вдруг появится повод ограничить скорость.
Служба безопасности организации проверила «целостность работ всех других систем банка и не выявила нарушений»
почесали репу и ничего не поняли
В настоящий момент СБ банка совместно с правоохранительными органами начали внутреннее расследование и предпринимают необходимые работы по предотвращению распространения утекших данных
Ну теперь можно спать спокойно. Ни каких вам выводов о произошедшем, никаких дисциплинарных мер к непосредственно нарушителям, либо их руководителям. ничего.
Специально постарался поискать подробнее новости и ничего кроме аналогичного описания новости нет.
нагруженных систем, логов обычно не 100 или 1000 в день, а от десятков миллионов.
Согласен, наверное в случае миллионов логов в день, то лучше использовать промышленное решение. В одной компании (в которой я работал раньше и где уже был реализовано подобное логирование) с течением времени перешли на коммерческое решение для логирования всего массива событий. Такой качественный переход был осуществлен только тогда, когда появилось понимание, что вышеописанного логирования недостаточно чтобы покрыть нужды компании.
Поэтому я в описании статьи делаю упор на то, что подобное логирование нужно создавать именно на «начальных» этапах построения БД.
Спасибо за комментарий. Все commit выполняются в автономной транзакции. Хинт «APPEND» можно использовать только (желательно) при insert в рамках одной сессии. Если выполнять insert из разных сессий с хинтом «APPEND», то текущий insert будет блокировать таблицу для других сессий.
И в целом, мне кажется вы чуть-чуть преувеличиваете важность таблицы логирования событий. Чтоб вы понимали, за весь вчерашний день 31.03.2021 в таблице лога на прод сервере у нас появилось 124 строчки (3 с типом Err и 121 с типом Msg).
По поводу хранения логов во внешней среде, то я уже видел подобные реализации. Во-первых, основная проблема это в дальнейшем использовании этих логов (неудобно анализировать их, искать конкретную ошибку и т.д.). Во-вторых, файлы периодически заполняют все свободное место.
В дальнейших статьях я постараюсь описать как мы настроили мониторинг событий в самом Oracle. Мы в текущей компании используем qlikview для визуализации событий.
Я вижу у вас партиции, следовательно это решение предназначено для прода а не для разработки.
Вот здесь если честно я не понял о чем речь. У нас на всех стендах от развернуто подобное логирование. На данный момент могу сказать, что им пользуются разработчики на dev-стенде, тестировщики на своем (прелайв) стенде и пользователи используют лог на прод-сервере.
Используем plog для не очень важных/нагруженых мест и где не так сильно много логов
Я об этой ситуации написал в статье:
Также, часто в командах появляются разработчики, которые говорят: «Зачем логировать все процедуры (функции)? Давайте вести логирование только важных и нужных процедур (функций)!».
У всех разработчиков разное понимание «не очень важных/нагруженых мест» и если использовать такой критерий логирования, то тогда наверное такое логирование будет бесполезным.
Используем plog ...
Это все хорошо до тех пор, пока вы не попадете в крупную ИТ-компанию, например Сбер, ВТБ. На коммерческий продукт для логирования ошибок в Oracle в проекте никто никогда не закладывает бюджет, а использовать оперсоурсные по, библиотеки и прочее вам скорее всего не дадут «безопасники».
Потому что логи в таблицу — это фу
По своему опыту использования таблиц для логов, могу сказать, что в среднем в партицию за один квартал прилетает примерно 5-6 тыс строк. В период активного внедрения нового функционала кол-во ошибок возрастает, но со временем цифра усредняется. Зачем изобретать велосипед и если не в Oracle, то тогда где вести лог ошибок? В файлах на удаленном сервере? И ведь такой «лог» ошибок практически бесполезен, я не говорю о том, что рано или поздно файлы лога забьют свободное место на дисках. Контролировать наполнение таблицы лога вы всегда можете своими силами (силами отдела разработки или сопровождения), а вот файловый сервер это как правило зона ответственности администраторов. И по своему опыту в таком банке могу сказать, что такой лог ошибок часто «ронял» сервер.
Это уже тонкости реализации. Обычно все гораздо проще: при наступлении нового квартала партиция с данными предыдущего квартала остается, все что старее удаляется таким образом мы храним в истории события предыдущего квартала. Локальные индексы внутри партиции можно создать, но это уже тема отдельного обсуждения. Повторюсь, что всё очень индивидуально в разных компаниях разные цели и задачи от функционала логирования событий.
Вы говорите про существенное усложнение модели логирования, которая сложна как разработке так и поддержании в актуальном состоянии. В статье приведен пример простейшего логирования и зачастую в большинстве компаниях вообще нет и такого логирования ошибок (событий). В дальнейших статьях постараюсь описать способ выявления «критичных» ошибок из общего пулла записей в таблице лога.
В текущей статье способ партицирования выбран для примера. Я специально не стал подробно описывать способы индексирования т.к. в разных компаниях, в разных командах разработчиков свои взгляды. Большей проблемой при создании логирования в компании, является сам факт создания и поддержание логирования в актуальном состоянии (о чем я пытался довести в статье).
Спасибо за подсказку, если честно даже и не знал, что есть такой готовый продукт, но этот продукт не рассматривал. Конечно можно внедрить уже готовый проект, я же хотел показать о способе создания «своего» лога на этапе построения БД. Более того, сейчас чуть внимательнее посмотрел на реализацию «log4plsql» и в принципе есть схожести. Но если я смогу дописать весь цикл статей, то наверное моё логирование буде содержать функционал которого нет в «log4plsql».
почесали репу и ничего не поняли
Ну теперь можно спать спокойно. Ни каких вам выводов о произошедшем, никаких дисциплинарных мер к непосредственно нарушителям, либо их руководителям. ничего.
Специально постарался поискать подробнее новости и ничего кроме аналогичного описания новости нет.
Согласен, наверное в случае миллионов логов в день, то лучше использовать промышленное решение. В одной компании (в которой я работал раньше и где уже был реализовано подобное логирование) с течением времени перешли на коммерческое решение для логирования всего массива событий. Такой качественный переход был осуществлен только тогда, когда появилось понимание, что вышеописанного логирования недостаточно чтобы покрыть нужды компании.
Поэтому я в описании статьи делаю упор на то, что подобное логирование нужно создавать именно на «начальных» этапах построения БД.
И в целом, мне кажется вы чуть-чуть преувеличиваете важность таблицы логирования событий. Чтоб вы понимали, за весь вчерашний день 31.03.2021 в таблице лога на прод сервере у нас появилось 124 строчки (3 с типом Err и 121 с типом Msg).
По поводу хранения логов во внешней среде, то я уже видел подобные реализации. Во-первых, основная проблема это в дальнейшем использовании этих логов (неудобно анализировать их, искать конкретную ошибку и т.д.). Во-вторых, файлы периодически заполняют все свободное место.
В дальнейших статьях я постараюсь описать как мы настроили мониторинг событий в самом Oracle. Мы в текущей компании используем qlikview для визуализации событий.
Вот здесь если честно я не понял о чем речь. У нас на всех стендах от развернуто подобное логирование. На данный момент могу сказать, что им пользуются разработчики на dev-стенде, тестировщики на своем (прелайв) стенде и пользователи используют лог на прод-сервере.
Я об этой ситуации написал в статье:
У всех разработчиков разное понимание «не очень важных/нагруженых мест» и если использовать такой критерий логирования, то тогда наверное такое логирование будет бесполезным.
Это все хорошо до тех пор, пока вы не попадете в крупную ИТ-компанию, например Сбер, ВТБ. На коммерческий продукт для логирования ошибок в Oracle в проекте никто никогда не закладывает бюджет, а использовать оперсоурсные по, библиотеки и прочее вам скорее всего не дадут «безопасники».
По своему опыту использования таблиц для логов, могу сказать, что в среднем в партицию за один квартал прилетает примерно 5-6 тыс строк. В период активного внедрения нового функционала кол-во ошибок возрастает, но со временем цифра усредняется. Зачем изобретать велосипед и если не в Oracle, то тогда где вести лог ошибок? В файлах на удаленном сервере? И ведь такой «лог» ошибок практически бесполезен, я не говорю о том, что рано или поздно файлы лога забьют свободное место на дисках. Контролировать наполнение таблицы лога вы всегда можете своими силами (силами отдела разработки или сопровождения), а вот файловый сервер это как правило зона ответственности администраторов. И по своему опыту в таком банке могу сказать, что такой лог ошибок часто «ронял» сервер.