Вимкнення журналу в певних таблицях

Я використовую SQL Server 2005. У мене є дві таблиці, що містять сукупну інформацію. Інформація постійно оновлюється, генеруючи майже 5 ГБ даних журналу на день. (Це більше, ніж уся база даних!) Я б хотів відключити ведення журналу в цих таблицях, оскільки відкочування насправді не потрібне. Однак я хотів би вести журнал на інших таблицях бази даних.

Чи можна відключити ведення журналу в певних таблицях в базі даних? Якщо ні, то чи можу я розмістити дві таблиці в одній схемі, а потім вимкнути журнал на схемі? Є єдиний варіант переміщення двох таблиць в окрему базу даних та відключення журналу там?

Оновлення: я думаю, я поясню, чому мені дійсно не потрібно реєструвати активність у цих таблицях.

Дві таблиці заповнені даними GPS, тому вони отримують досить великі розміри. Перша таблиця фіксує необроблені місця з шести таблиць Android у цьому полі. Нові дані з кожної таблетки надходять кожні 5-10 секунд. Потім ця інформація агрегується як locationA, locationB, travelTime. Мета полягає в тому, щоб, зрештою, мати найкоротший час подорожі між усіма локаціями, виходячи з фактичних даних про водіння. Дані є лише для невеликого міста, і точні лише до чотирьох знаків після коми, тому вони керовані. Однак у міру надходження нових необроблених даних є повільніші часи подорожей, які потрібно оновити, та нові, які потрібно вставити.

Після того як необроблені дані агрегуються, вони очищаються. Ми не збираємось назад у більш тривалий час подорожі, тому саме відкат назад у цих таблицях не так важливий.

• Чи можна відключити ведення журналу в певних таблицях в базі даних?
• Чи можу я розмістити дві таблиці в одній схемі, а потім вимкнути журнал на схемі?
• Є єдиний варіант переміщення двох таблиць в окрему базу даних та відключення журналу там?

Реєстрацію операцій користувача не можна відключити.

Існує клас операцій, який називається операціями з мінімально зареєстрованим журналом, які дозволяють лише повернути транзакцію (на відміну від того, що також можна прокататись вперед ). Однак це не здається, що те, що ви робите, відповідало б критеріям, які потрібно застосувати, і я не думаю, що це все-таки вирішить проблему.

Рішенням SQL Server було б закріпити таблиці SIMPLEвідновлення в новій базі даних для відновлення, окремо від бази даних результатів агрегації, яка, як я вважаю, знаходиться у FULLвідновленні. Хоча це не зменшить обсяг журналу, це усуне необхідність резервного копіювання журналу, генерованого навантаженнями даних. (Дивіться мій блог тут про реєстрацію подій, а також деякі з факторів , що беруть участь у виборі моделі відновлення створюється бази даних.)

Виділення таблиць в іншу базу даних забезпечить гнучкість розміщення файлу журналу на більш швидкій підсистемі вводу-виводу, можливо, невеликому масиві локально приєднаних твердотільних дисків.

Також врахуйте, що SQL Server сам по собі не може бути найкращим рішенням для вирішення проблеми. Є й інші рішення RDBMS, які пропонують можливість повністю відключити ведення журналу для певних таблиць. Дані можуть бути поетапно розміщені та агреговані в іншій системі, а результати об'єднані в існуючу базу даних SQL Server, яка добре захищена повним журналом та резервними копіями.

Ні, немає способу запобігти входу в систему SQL Server незалежно від схеми, таблиці або рівня бази даних.

Фактично, кожна транзакція, яка виконує зміни або зміни в базі даних SQL Server, реєструється, за винятком транзакцій, пов’язаних із зберіганням версій, що включають TempDB, коли використовується знімок знімка. (вхід в журнал транзакцій гарантує, що транзакцію можна повернути назад (для певної операції ви можете зменшити журнал (це називається мінімально зареєстрованими операціями), змінивши модель відновлення на BULK Logged --- ви можете дізнатися більше про це в книжках SQL Server Online тут

Відповідь, як завжди, залежить.
Коли ви сказали:

У мене є дві таблиці, які містять сукупну інформацію. Інформація постійно оновлюється

Що це за агрегація?
Спробуйте скористатись VIEW замість цього, не потрібно оновлюватись та не вести журнал.

Якщо це не варіант, спробуйте скористатися коротшими транзакціями та створити резервну копію журналу між ними.

Використання іншої бази даних означає управління накладними витратами тощо і матиме власний журнал транзакцій (навіть при SIMPLE моделі відновлення журнал пишеться, SQL Server просто усікає журнал автоматично, але не звільняє місце на диску), тому я не рекомендував би цей варіант .