Отслеживание изменений в базе

← →
Sirus (2007-11-03 08:31) [0]

Привет Мастера!
Есть вопрос: Как можно реализовать отслеживание изменений в базе данных? Отслеживаться должны изменение, удаление и вставка записи в базу данных. При этом нужно еще хранить код пользователя проделавшего эти изменения.

Есть какие-нить соображения или наработки, поделитесь опытом.

← →
Reindeer Moss Eater © (2007-11-03 10:08) [1]

Триггеры

← →
atruhin © (2007-11-03 11:05) [2]

В IB Expert пункт меню "Инструменты\Менеджер протоколов данных", выбираешь что логировать,
он сам создаст нужные тригера и таблицы.

← →
Sergey13 © (2007-11-06 09:57) [3]

> [0] Sirus (03.11.07 08:31)

> Есть какие-нить соображения или наработки, поделитесь опытом.

Про тригеры уже сказали.
Но по моему опыту есть соображение, что делать такой логинг стоит ОЧЕНЬ осторожно и после тщательного думания на тему "А оно мне вообще надо?". Ибо объем лога будет на порядки выше объема данных и расти будет очень быстро. Соответственно и производительность будет ... ну ты понял.

← →
clickmaker © (2007-11-06 12:31) [4]

> Sirus (03.11.07 08:31)

не пускать юзера прямо в базу. А изменение, удаление и вставку записи выполнять либо черех ХП, либо через запросы, в которых уж можно протоколить все, что угодно

← →
stud © (2007-11-06 14:27) [5]

Sergey13 © (06.11.07 9:57) [3]
Ибо объем лога будет на порядки выше объема данных и расти будет очень быстро.

ну это если пользователи только и занимаются что исправлением только что введенных данных. при грамотной работе пользователей))) объем не такой уж и большой

← →
Sergey13 © (2007-11-06 14:38) [6]

> [5] stud © (06.11.07 14:27)
> ну это если пользователи только и занимаются что исправлением
> только что введенных данных.

А в чем по твоему заключается работа пользователей в БД? По моему как раз в воде, редактировании и удалении записей.

> при грамотной работе пользователей))) объем не такой уж
> и большой
Это типа поставить им ZUMA и отдыхать? 8-)

← →
PEAKTOP © (2007-11-06 14:51) [7]

>Sergey13 © (06.11.07 09:57) [3]
> Соответственно и производительность будет ... ну ты понял.

А ежели мы на железо денег не пожалеем, то можно и каждый чих в логи писать.

Тестировалось на Intel Core2duo / 4096DDR2 / RAID10 на SATA 160ГБ.

>Sirus (03.11.07 08:31) [0]

А есть ли у твоих заказчиков таке железо ?

← →
Sergey13 © (2007-11-06 15:06) [8]

> [7] PEAKTOP © (06.11.07 14:51)

Тормоза не гарантированы и на "бюджетном" железе. Просто надо понимать, что запись "каждого чиха" требует ресурсов, а они из воздуха не берутся и святым духом не питаются.

Кроме того (опять же из опыта) надо сначала найти человека, который этими данными будет реально пользоваться. Делать это только ради "чтоб було" смысла никакого.

← →
Desdechado © (2007-11-06 15:12) [9]

Такие данные единственно могут понадобиться для "разбора полетов", если кто-то что-то испортил и не признается.
Но при этом лог следует выгружать с заметной периодичностью во внешний файл и закатывать на болванки, очищая место в БД для нормальных данных.

← →
stud © (2007-11-06 15:52) [10]

Sergey13 © (06.11.07 14:38) [6]
А в чем по твоему заключается работа пользователей в БД? По моему как раз в воде, редактировании и удалении записей.

для пользователей основная работа - ввод данных. редактирование, удаление это уже побочный эффект связанный с некачественной "основной" работой.

Desdechado © (06.11.07 15:12) [9]
Такие данные единственно могут понадобиться для "разбора полетов", если кто-то что-то испортил и не признается.

и кстати как правило количество исправлений и удалений после разбора сокращается, иногда очень значительно)))

← →
clickmaker © (2007-11-06 15:55) [11]

> правило количество исправлений и удалений после разбора
> сокращается, иногда очень значительно

по закону сохранения энергии, оно увеличивается в других конторах, куда ушли уволенные после разбора сотрудники )

← →
Sergey13 © (2007-11-06 16:04) [12]

> [10] stud © (06.11.07 15:52)
> редактирование, удаление это уже побочный эффект связанный
> с некачественной "основной" работой.

Странно ты рассуждаешь. Если 1 юзер ввел новую запись и заполнил в ней 3 (из допустим 20) поля. Юзер 2 ввел свои данные - заполнил (отредактировал) еще 5 полей. Юзер 3 ... и т.д.
Тебя может удивит но иногда это все гуляет по кругу.

Я не говорю что логирование всегда плохо и что это вообще плохо. Я говорю, что это накладно, и посему делать это надо ОПРАВДАНО.

← →
PEAKTOP © (2007-11-06 16:14) [13]

> Но при этом лог следует выгружать с заметной периодичностью во внешний файл и закатывать на болванки, очищая место в БД для нормальных данных.

Правильной дорогой идете, товарищь !

А еще можно хранить это г**но вообще в отдельной БД. Благо, ЖарПтица не накладывает ограничения на подключения.

← →
Desdechado © (2007-11-06 17:59) [14]

> можно хранить это г**но вообще в отдельной БД
В EXTERNAL TABLE - да, в отдельной БД - на уровне триггеров никак.

← →
Anatoly Podgoretsky © (2007-11-06 19:19) [15]

> stud (06.11.2007 14:27:05) [5]

Объем равен = количество изменений одной записи + дополнительная информация по записи.
Десять раз отредактируешь одну запись получишь 10 копий со служебной информацией, а без служебной информации лог мало чего стоит.

← →
Anatoly Podgoretsky © (2007-11-06 19:21) [16]

> Sergey13 (06.11.2007 14:38:06) [6]

> А в чем по твоему заключается работа пользователей в БД? По моему как раз в воде, редактировании и удалении записей.

В типовой, рядовой базе на это уходит менее одного процента, основные затраты идут на запросы, в которых ничего подобного не делается, есть конечно базы, к которым почти не делается запросов, а идут в основном добавления, но такие базы не типовые.

← →
Anatoly Podgoretsky © (2007-11-06 19:22) [17]

> PEAKTOP (06.11.2007 14:51:07) [7]

Для информации, у меня запись на диск происходит весьма редко, раз в две минуты, а сервер постоянно пашет.

← →
Anatoly Podgoretsky © (2007-11-06 19:23) [18]

> stud (06.11.2007 15:52:10) [10]

Боятся :-)

← →
Anatoly Podgoretsky © (2007-11-06 19:25) [19]

> Desdechado (06.11.2007 17:59:14) [14]

Не знаю про Firebird, но на MSSQL нет проблем, и не тольно в другой БД, но и на другой сервер, на другой машине.

← →
PEAKTOP © (2007-11-06 20:04) [20]

> Anatoly Podgoretsky © (06.11.07 19:22) [17]
> а сервер постоянно пашет.

С ума сойти... а что он еще делать должен ? :)

> Anatoly Podgoretsky © (06.11.07 19:25) [19]
> но на MSSQL нет проблем, и не тольно в другой БД, но и на другой сервер, на другой машине.

На Firebird тоже, если через UDF. Но это решение задачи по пути "истинного проктолога", ИМХО.
Гораздо кошернее решать ее через железо. 4Гб база данных (60% - логи) ? - ну и фиг с ней ! Работает.

← →
Anatoly Podgoretsky © (2007-11-06 20:50) [21]

> PEAKTOP (06.11.2007 20:04:20) [20]

Да я не возражаю, возражение не от меня было.
А то что упор на диски был не убедителен.
Диски становятся определяющим фактором при нехватке оперативной памяти, но тут уже надо подумать об переходе на 64 бита и наращивание до предела, например до 128 гб. Но и это может оказаться недостаточным для террабайтных баз с большой нагрузкой тогда SAN то 10 гб оптике с мультичанел.

Хорошее железо залог успеха.

← →
stud © (2007-11-07 08:25) [22]

Anatoly Podgoretsky © (06.11.07 20:50) [21]
Хорошее железо залог успеха.

хорошее железо развращает программистов)))

Anatoly Podgoretsky © (06.11.07 19:19) [15]
Объем равен = количество изменений одной записи + дополнительная информация по записи.

ну допустим не всегда, можно вести протокол по "критичным" полям записи а не по каждому "чиху", а служебная информация в данном случае занимает не так и много места, как правило это ведь данные типа "кто, когда, что сделал"

Anatoly Podgoretsky © (06.11.07 19:23) [18]
Боятся :-)
ишо как!!) пару раз разбор устраивали, тем более что с деньгами дело связано было. почемуто потом перестали паролями обмениваться))

← →
Sergey13 © (2007-11-07 08:44) [23]

> [16] Anatoly Podgoretsky © (06.11.07 19:21)

Твои слова, ИМХО, никак не противоречат моим. Понятно, что читающих запросов в БД на порядки больше чем модифицирующих, но работа пользователей (а не сервера) все таки в основном состоит из модификации информации, а не из наблюдения за ней в "типовой" БД.

← →
Anatoly Podgoretsky © (2007-11-07 08:54) [24]

> Sergey13 (07.11.2007 08:44:23) [23]

В большинстве баз, пользователям вообще запрещено что либо делать кроме запросов, только очень ограниченный круг пользователей могут менять базу. И это как правило очень крупные базы. И основная работа тоже не сводится к наблюдению, а к получению информации с помощью запросов.
Я посмотрю, что большинство пользователей сможет сделать с базой, например Интерпола.

← →
Sergey13 © (2007-11-07 09:01) [25]

> [24] Anatoly Podgoretsky © (07.11.07 08:54)

> В большинстве баз...
> ...например Интерпола.

Ты думаешь автор топика пишет для Интерпола или ЮНЕСКО с ООН? Сомневаюсь.
Мне кажется он пишет очередной склад/бухгалтерию/документооборот, в которой все таки меняют инфу чаще. 8-)
Для меня например подобные БД являются более "типовыми".

← →
Anatoly Podgoretsky © (2007-11-07 09:14) [26]

> Sergey13 (07.11.2007 09:01:25) [25]

Таких баз, в которых чаще меняют, чем читают почти нет

← →
Sergey13 © (2007-11-07 13:24) [27]

> [26] Anatoly Podgoretsky © (07.11.07 09:14)

Я тебе про Фому, а ты мне про Ерему.
Оператор на складе меняет информацию?

ЗЫ: Разговор переместился в сторону от вопроса, ИМХО. Стоит ли продолжать?

Оператор это не база.

Нашли общую точку соприкосновения.

← →
StriderMan (2007-11-27 14:15) [31]

Удалено модератором

> [31] StriderMan (27.11.07 14:15)

1. Нафига поднимать чужой топик трехнедельной давности?
2. То, что это работает на порядки быстрее логирования понятно. Непонятно как это относится к логированию.

← →
StriderMan (2007-11-27 14:46) [33]

Удалено модератором

← →
Sergey Masloff (2007-11-27 22:58) [34]

Вставлю свои 5 копеек.
1. По моим наблюдениям (это не прикидки а статистические замеры на реальных базах) доля модифицирующих операций конечно не 1% но практически редко превышает 5%

2. Вот на скорость работы базы фактически write-only таблица лога не повлияет вообще никак. А диски сейчас дешевые так что если лог нужен то пиши спокойно и не парься.

>Sergey Masloff (27.11.07 22:58) [34]
Хм... базы разные бывают )
Бывают базы на CD, в которые запись возможна только чисто теоретически.
Бывают базы хранящие статистику разных датчиков пишущююся посекундно и выдающие оператору отчет раз в сутки.
Бывают разные наколенные блининги которые в MySQL базейку заливают весь NetFlow (свят-свят-свят), а потом один раз его считывают и агрегируют, расчитывают всякие разности, делают отчеты... такой себе цыкл жизни записи: insert -> select -> to_archiv

А вот про скорость работы, это вы зря ) Логирование на тригерах хорошо подгружает сервер при редактировании данных. Конечно если в базе 3 таблички по 100 записей, а машинка какой-нибудь там коре-два-дуо-и-еще-раз-дуо, то на глаз разницы не увидишь. Я раньше тестировал свои подел на пеньке 133. Вот там очень(!) хорошо видно любое бутылочное горлышко... и иногда даже бутылочное донышко )

> Sergey Masloff (27.11.07 22:58) [34]
это все так, пока транзакции, в которых происходит логирование, не начинают биться за какой-нить ресурс. И вот тут совсем небольшое уменьшение скорости работы продавщицы (время транзакции) может начать заметно увеличивать длину очереди

> Sergey Masloff (27.11.07 22:58) [34]
Не совсем так.
Если логирование ведется один-в-один, то да - сдублировать запись проблемы нет. А вот если приходится расшифровывать кучу внешних ключей из справочников, то изменение одной записи приводит к множеству дополнительных чтений, а это уже не фигня.

← →
Sergey Masloff (2007-11-28 21:06) [38]

Andrey © (28.11.07 10:05) [35]
В данный момент это база с 4500 пользователей объемом 0.6 терабайт и ростом впримерно в 20 Гб в неделю. Расходы на полное логгирование - пара-тройка процентов ресурсов сервера. Все ходы записаны.

← →
Sergey Masloff (2007-11-28 21:09) [39]

Petr V. Abramov © (28.11.07 11:25) [36]
>это все так, пока транзакции, в которых происходит логирование, не >начинают биться за какой-нить ресурс.
Так оно же в той же транзакции что и изменение данных. И как раз в нем ничего военного нет - просто прямая запись. Мизерная нагрузка по сравнению с собственно редактированием. На таблицах логов естественно никаких ключей и так далее. Не за что там конкурировать

Отслеживание изменений в базе Найти похожие ветки