Я использую SQL Server 2005. У меня есть две таблицы, которые содержат совокупную информацию. Информация постоянно обновляется, генерируя почти 5 ГБ данных журнала в день. (Это больше, чем вся база данных!) Я бы хотел отключить ведение журнала в этих таблицах, так как откат не является действительно необходимым. Однако я хотел бы продолжать входить в другие таблицы в базе данных.
Можно ли отключить ведение журнала для определенных таблиц в базе данных? Если нет, могу ли я поместить две таблицы в одну схему, а затем отключить ведение журнала в схеме? Является ли единственной возможностью переместить две таблицы в отдельную базу данных и отключить ведение журнала там?
Обновление: я думаю, я объясню, почему мне действительно не нужно регистрировать активность в этих таблицах.
Две таблицы заполнены данными GPS, поэтому они становятся довольно большими. Первая таблица захватывает необработанные местоположения из шести таблиц Android на местах. Новые данные с каждого планшета поступают каждые 5-10 секунд. Эта информация затем агрегируется как locationA, locationB, travelTime. Цель состоит в том, чтобы в конечном итоге обеспечить кратчайшее время в пути между всеми точками на основе фактических данных вождения. Данные предназначены только для небольшого города и точны только до четырех десятичных знаков, поэтому ими можно управлять. Тем не менее, по мере поступления новых необработанных данных, требуется более медленное время прохождения, которое необходимо обновить, и новые, которые необходимо вставить.
Как только необработанные данные агрегируются, они удаляются. Мы не собираемся возвращаться назад к более длительному времени в пути, поэтому откат не имеет большого значения в этих таблицах.
источник
Ответы:
Регистрация пользовательских операций не может быть отключена.
Существует класс операций , называемых минимально регистрируемых операций , что позволяет только транзакция быть свернутым назад (в отличие от также возможность катиться вперед ). Однако не похоже, чтобы то, что вы делаете, соответствовало бы критериям для этого, и я не думаю, что это решит проблему в любом случае.
Решение SQL Server заключается в размещении промежуточных таблиц в новой базе данных для
SIMPLEвосстановления, отдельно от базы данных результатов агрегации, которая, как я полагаю, находится в процессеFULLвосстановления. Хотя это не уменьшит объем ведения журнала, это устранит необходимость в резервном копировании журнала, созданного загрузкой данных. (См. Мой блог здесь о журналировании и некоторых факторах, влияющих на выбор модели восстановления базы данных.)Разделение таблиц в другой базе данных обеспечило бы гибкость для размещения файла журнала в более быстрой подсистеме ввода-вывода, возможно, в небольшом массиве локально подключенных твердотельных накопителей.
Кроме того, учтите, что SQL Server сам по себе может быть не лучшим решением для решения проблемы. Существуют и другие решения СУБД, которые позволяют полностью отключить ведение журнала для определенных таблиц. Данные могут быть размещены и объединены в другой системе, а результаты объединены в существующую базу данных SQL Server, которая хорошо защищена за счет полного ведения журнала и резервного копирования.
источник
Нет, нет способа предотвратить вход в SQL Server независимо от схемы, таблицы или уровня базы данных.
Фактически каждая транзакция, которая выполняет модификации или изменения в базе данных SQL Server, регистрируется, за исключением транзакций, связанных с хранилищем версий, включая TempDB, когда используется изоляция моментального снимка. (регистрация в журнале транзакций гарантирует, что транзакцию можно будет откатить (для определенных операций вы можете уменьшить ведение журнала (это называется минимально зарегистрированными операциями), изменив модель восстановления на BULK Logged - вы можете узнать больше об этом в электронной документации по SQL Server здесь
источник
Ответ, как всегда, зависит.
Когда вы сказали:
Что это за агрегация?
Попробуйте вместо этого использовать VIEW, не нужно обновлять и не регистрировать.
Если это не вариант, попробуйте использовать более короткие транзакции и создать резервную копию журнала между ними.
Использование другой базы данных означает накладные расходы на администрирование безопасности и т. Д. И будет иметь собственный журнал транзакций (даже при использовании модели восстановления SIMPLE журнал записывается, SQL Server просто усекает журнал автоматически, но не освобождает дисковое пространство), поэтому я бы не рекомендовал этот вариант ,
источник