Эффективная стратегия отъезда журнала аудита / история изменений для приложений DB?
В дополнение полезный ответ briantist :
Блок сценария, переданный в Invoke-Command, (по назначению) выполнен на удаленном пульте , используя по умолчанию переменные машины remote .
Таким образом, чтобы использовать переменную (значение) local , дополнительные этапы (иначе говоря, внутри блока сценария, выполняемого удаленно, вы не можете просто ссылаться на локальные переменные, как обычно, например $dest):
- PS v3 + предлагает
using:для непосредственного использования локальной переменной внутри блока сценария - см. первую команду briantist. Обратите внимание, чтоusing:работает только тогда, когдаInvoke-Commandфактически нацеливается на удаленный компьютер. - Единственная опция, которая также работает в более ранних версиях, - передать локальную переменную в качестве параметра в блок сценария. - см. вторую команду briantist.
Для получения дополнительной информации см. Get-Help about_Remote_Variables или документы в Интернете .
6 ответов
В прошлом я использовал триггеры для построения дб, обновляют/вставляют/удаляют вход.
Вы могли вставить запись каждый раз, когда одно из вышеупомянутых действий сделано на определенной таблице в регистрирующуюся таблицу, которая отслеживает действие, какой пользователь дб сделал это, метка времени, таблица, это было выполнено на, и предыдущее значение.
существует, вероятно, лучший ответ, хотя, поскольку это потребовало бы, чтобы Вы кэшировали значение, прежде чем фактические удалят, или обновление было выполнено, я думаю. Но Вы могли использовать это, чтобы сделать откаты.
Одной из стратегий, которую вы можете использовать, является MVCC, Multi-Value Concurrency Control. В этой схеме вы никогда не обновляете ни одну из ваших таблиц, вы просто делаете вставки, сохраняя номера версий для каждой записи. Это дает преимущество в предоставлении точного снимка в любой момент времени, а также полностью обходит проблемы блокировки обновлений, которые мешают многим базам данных.
Но это делает для огромной базы данных, и для выбора всех требуется дополнительное предложение для выбора текущей версии записи.
Если Вы используете, в спящем режиме, смотрят на JBoss Envers. От домашней страницы проекта:
проект Envers имеет целью включать легкое управление версиями персистентных классов JPA. Все, что необходимо сделать, аннотируют персистентный класс или некоторые его свойства, которым Вы хотите присвоить версию с @Versioned. Для каждого имеющего версию объекта будет составлена таблица, который будет содержать историю изменений, внесенных в объект. Можно тогда получить и запросить исторические данные без особых усилий.
Это несколько подобно подход Eric , но вероятно намного меньше усилия. Не знайте, какой язык/технологию Вы используете для доступа к базе данных, все же.
Единственная проблема с использованием Триггеров состоит в том, что оно добавляет к производительности наверху любого, вставляют/обновляют/удаляют. Для более высокой масштабируемости и производительности, требуется свести транзакцию базы данных к минимуму. Аудит через триггеры увеличивает время, требуемое сделать, транзакция и в зависимости от объема может вызвать проблемы производительности.
иначе должен исследовать, если база данных обеспечивает какой-либо способ добыть журналы "Восстановления", как имеет место в Oracle. Журналы отката - то, что использование базы данных воссоздать данные в случае, если они перестали работать и должны восстановиться.
Подобный триггеру (или даже с) Вы можете иметь каждый огонь транзакции регистрирующееся событие асинхронно и иметь другой процесс (или просто распараллелить), на самом деле обрабатывают вход. Было бы много способов реализовать это в зависимости от Вашего приложения. Я предлагаю иметь огонь приложения событие так, чтобы это не вызывало ненужную нагрузку на Вашу первую транзакцию (который иногда приводит к блокировкам из каскадных контрольных журналов).
, Кроме того, можно быть в состоянии улучшить производительность до основной базы данных путем хранения базы данных аудита в отдельном месте.
Я использую SQL Server, а не PostgreSQL, поэтому я не уверен, сработает ли это для вас или нет, но у Попа Риветта была отличная статья о создании журнала аудита: Часто задаваемые вопросы о SQL Server Поп Риветта. 5: Откройте журнал аудита
Создайте таблицу аудита, затем создайте триггер для каждой таблицы, которую вы хотите проверить.
Подсказка: используйте Codesmith для создания своих триггеров.