Создайте таблицу аудита истории

-2

В настоящее время мы имеем таблицу AuditLog, которая хранит более 11 миллионов записей. Независимо от индексов и статистики любой запрос, ссылающийся на эту таблицу, занимает много времени. Большинство отчетов не проверяют записи аудита за год, но мы все равно хотели бы сохранить эти записи. Каков наилучший способ справиться с этим?Создайте таблицу аудита истории

Я подумывал о том, чтобы таблица AuditLog сохраняла все записи меньше или равно годовалым. Затем переместите любые записи старше года в таблицу AuditLogHistory. Может быть, просто запускать пакетный файл каждую ночь, чтобы переместить эти записи, а затем обновить индексы и статистику таблицы AuditLog. Это хороший способ выполнить эту задачу? Или каким другим способом я могу хранить старые записи?

Записи, возвращенные из таблицы AuditLog, попали на связанный сервер и проверили 6 разных db, чтобы узнать, существует ли в них определенный член на основе условия. У меня нет доступа для внесения каких-либо изменений в связанный сервер db, поэтому можно оптимизировать только то, что у меня есть, это Auditlog. При попадании на связанный сервер db использует более 90% стоимости запросов. Поэтому я просто пытаюсь ограничить то, что могу.

источник

2017-02-10 user3199317

Попробуйте свои решения и составите список профи и консолей. – dfundako

Прежде чем пытаться что-либо, я хотел получить мнения, если это лучший способ сделать это. – user3199317

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

В любом случае ответ на ваш вопрос «разделение». Вы разделили бы по столбцу даты и обязательно включили это условие во все запросы. Это уменьшит объем данных и, вероятно, ускорит обработку.

documentation - хорошее место, чтобы начать изучение раздела.

источник

2017-02-10 18:58:30

Я согласен с тем, что разделение является ответом. Я просто хотел добавить одно. ОП упоминает индексацию своей таблицы AuditLog. Индексирование делает чтение быстрее, но также делает вставки медленнее. В таблице журналов, вероятно, будет много вставок и относительно немного читать. Поэтому они не должны добавлять индексы, если они им действительно не нужны. Это не повредит их отчетам, но может привести к тому, что процессы, которые загружаются в журнал медленнее. –

У меня был почти такой же сценарий, за исключением того, что у меня было две связанные таблицы аудита, одна из которых составляла около 100 М строк, и мне не нужно было хранить старые записи. Удаление записей аудита старше определенного времени было просто очень медленным. Оказалось, что в 80 раз быстрее переименуйте таблицу в auditlog_history, заново создайте таблицу журнала аудита, вставьте обратно в нее из переименованной таблицы, а затем обрезайте таблицу auditlog_history. В вашем случае вы можете просто пропустить усечение. Конечно, вам придется отбрасывать и воссоздавать любые внешние ключи или индексы. –

Создайте таблицу аудита истории

ответ

Смежные вопросы