Что регистрировать/прослеживать в Продуктивной среде
Нет! Тот же план выполнения, посмотрите на эти две таблицы:
CREATE TABLE table1 (
id INT,
name VARCHAR(20)
);
CREATE TABLE table2 (
id INT,
name VARCHAR(20)
);
план выполнения относительно запроса с помощью внутреннего объединения:
-- with inner join
EXPLAIN PLAN FOR
SELECT * FROM table1 t1
INNER JOIN table2 t2 ON t1.id = t2.id;
SELECT *
FROM TABLE (DBMS_XPLAN.DISPLAY);
-- 0 select statement
-- 1 hash join (access("T1"."ID"="T2"."ID"))
-- 2 table access full table1
-- 3 table access full table2
И план выполнения относительно запроса с помощью оператора Where.
-- with where clause
EXPLAIN PLAN FOR
SELECT * FROM table1 t1, table2 t2
WHERE t1.id = t2.id;
SELECT *
FROM TABLE (DBMS_XPLAN.DISPLAY);
-- 0 select statement
-- 1 hash join (access("T1"."ID"="T2"."ID"))
-- 2 table access full table1
-- 3 table access full table2
3 ответа
Это действительно зависит от вас, нет жестких правил.
Пару месяцев назад мы работали над этим Java-приложением и использовали log4j для ведения журнала, в log4j мы смогли определить в коде наши журналы как отладка, предупреждение, ошибка, информация и т. д.
Наш журнал отладки велся почти при каждом запуске и завершении функций, каждая успешная неуспешная транзакция регистрировалась как «информация», «ошибка» в исключениях регистрировалась и аналогично.
После того, как мы переместили приложение в производственную среду примерно через месяц, мы отключили все отладочные журналы через файлы .properties без перезапуска приложения, и все было в порядке.
В производственной среде у меня по умолчанию для ведения журнала установлено значение «INFO» (с использованием log4net), и на этом уровне я записываю достаточно информации, чтобы иметь очень хорошие шансы диагностировать любые ошибки. Итак, что такое «достаточная» информация? Что ж, все зависит от вашей системы. В нашей системе я регистрирую точки входа и выхода из наиболее важных методов, включая их входные параметры и возвращаемые значения (если это не много данных). Я готов согласиться с 5-10% накладными расходами на ведение журнала (но вы должны это измерить).
Мой предпочтительный формат выглядит следующим образом:
Запись метода:
-> MyMethod (1, "arg1")
Выход метода:
<- MyMethod (1, "arg1") = true
Стрелки означают, что я могу легко увидеть, вход это или выход. Включая аргументы и возвращаемое значение, я получаю наиболее важные данные для диагностики ошибок. У меня всегда есть только одна точка возврата из моих методов, поэтому мне не нужно беспокоиться о нескольких точках выхода для моей регистрации.
Регистрируя вход / выход метода, я обнаружил, что мне не нужно больше регистрировать - если ваш код правильно разложен на методы, то это документирует поток выполнения через ваше приложение.
Не допускайте ошибки, не регистрируя достаточно информации, потому что вы беспокоитесь о снижении производительности - измерьте это, чтобы вы были довольны накладными расходами, но уверены, что вы регистрируете достаточно, чтобы диагностировать неисправности исключительно на основе информации, которая находится в журнале. Чего вы не хотите делать, так это переключать регистрацию на более подробную после того, как ваш клиент сообщил о неисправности, а затем надеяться, что неисправность возникнет снова.
Я также использую уровень ведения журнала DEBUG, который регистрирует практически все. Это используется только при разработке / тестировании или, возможно, в производстве, но только после консультации с заказчиком.
Мне нравится использовать разные уровни. Наименее подробные показывает запуск и выключение обслуживания, а также ошибки и исключения. Самый подробный может доходить до отображение значения каждой локальной переменной, входа / выхода функции и т. д.
Чем больше деталей вы можете легко получить, тем меньше копаться и тем меньше вероятность чтобы прыгнуть в самолет, чтобы добраться туда, где проблема. . . .
K