Сделать SQL Server быстрее при манипулировании данными - отключить ведение журнала транзакций?

Question

Я использую SQL Server 2005 в качестве хранилища данных, для которых я выполняю аналитическую работу. Это не транзакционная база данных, поскольку я не загружаю ее обновлениями и не собираю данные в реальном времени. Я получаю несколько гигабайт данных от своих клиентов, загружаю их в SQL Server и выполняю серию манипуляций. Затем я собираю биты этих данных и помещаю их в R, где я делаю большую часть своего анализа. Затем я помещаю немного данных в таблицы в SQL Server и, возможно, делаю соединение или два.

У меня чертовски много времени, когда журналы в SQL Server становятся большими, и я предполагаю, что для их создания требуются определенные затраты. Как я могу настроить SQL Server так, чтобы он работал практически без регистрации? Если что-то испортится, я с радостью начну с самого начала. Есть идеи как сделать все это быстрее?

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

Должен ли я использовать более простую БД, чем Sql Server? Не стесняйтесь сказать мне, что я убиваю муравья кувалдой. Но, пожалуйста, порекомендуйте молоток более подходящего размера. :)

Answer 1

Как я могу настроить SQL Server так, чтобы он работал практически без регистрации? I

Я не верю, что ты можешь.

Однако, если вы сконфигурируете базу данных (каждая база данных на сервере может отличаться) для простых резервных копий, файл журнала не будет расти, пока вы не создадите резервную копию. Это делается путем установки режима восстановления на «простой».

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

Answer 2

Одним из способов избежать регистрации при работе с большими наборами данных является использование SELECT / INTO. Это создаст новую таблицу, но ни одна из них не будет зарегистрирована.

Есть несколько вещей, на которые нужно обратить внимание при этом:

• Вычисляемые столбцы становятся обычными столбцами данных
• Должны быть установлены также столбцы индексации и идентификации

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

Альтернатива - это то, что я сейчас делаю, например:

UPDATE [MyTable] 
SET    [Message] = REPLACE([Message], N'Content_Type', N'Content-Type')

Работает нормально, но обновляет всю таблицу, создавая один огромный набор транзакций, вместо этого вы можете сделать:

DECLARE @IDs TABLE ([id] int)
DECLARE @Batch TABLE ([id] int)

INSERT INTO @IDs ([ID]) SELECT [ID] FROM [MyTable]

WHILE EXISTS (SELECT TOP 1 [ID] FROM @IDs)
BEGIN
  INSERT INTO @Batch ([ID]) SELECT TOP 1000 [Id] FROM @IDS

  UPDATE [MyTable] 
  SET    [Message] = REPLACE([Message], N'Content_Type', N'Content-Type') 
  WHERE  [Id] IN (SELECT [Id] FROM @Batch)

  DELETE @IDs WHERE [Id] IN (SELECT [Id] FROM @Batch)
  DELETE @Batch
END

Это обновляет таблицу на 1000 строк одновременно, уменьшая размер транзакции.

Answer 3

Вы можете минимизировать потребление журналов на сервере SQL, изменив модель восстановления базы данных на простую, см. Эту ссылку . Поскольку вы не имеете дело с параллелизмом и транзакциями, рассматривали ли вы Microsoft Access?

Answer 4

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

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

Основная причина этого заключается в том, что журнал транзакций при полном восстановлении может быть вашей единственной надеждой на восстановление в случае случайно выполненного UPDATE, DELETE или TRUNCATE, когда у вас нет резервных копий или все данные не находятся в резервных копиях.

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

Как откатить запрос ОБНОВЛЕНИЕ в SQL Server 2005?

Как отменить операцию удаления в SQL Server 2005?

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

Answer 5

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

Answer 6

c # Код с использованием EntityFramework для настройки базы данных, как описывает ответ Ричардса:

using (var dbInstance = new YourEntityFrameworkDB_Context())
{
    var sqlConfigConn = dbInstance.Database.Connection as SqlConnection;
    sqlConfigConn.Open();

    using (var sqlCmd = new SqlCommand())
    {
        sqlCmd.Connection = sqlConfigConn as SqlConnection;
        sqlCmd.CommandText = String.Format("ALTER DATABASE model SET RECOVERY SIMPLE");
        var result = sqlCmd.ExecuteNonQuery();
    }
    sqlConfigConn.Close();
}

А чтобы проверить успешность, просто запустите Management Studio и запустите:

РЕДАКТИРОВАТЬ февраль 2018 :

MSDN описание модели восстановления

╔══════════╦══════════════════════╦══════════════════════════════════════════╗
║ Recovery ║    Description       ║      Recover to a point in time?         ║
║  model   ║                      ║                                          ║
╠══════════╬══════════════════════╬══════════════════════════════════════════╣
║ Simple   ║ No log backups       ║ Can recover only to the end of a backup. ║
║          ║                      ║                                          ║
║ Full     ║ Requires log backups ║ Can recover to a specific point in time, ║
║          ║                      ║ assuming that your backups are complete  ║
║          ║                      ║ up to that point in time.                ║
║          ║                      ║                                          ║
║ Bulk     ║ Requires log backups ║ Can recover to the end of any backup.    ║
║ logged   ║                      ║                                          ║
╚══════════╩══════════════════════╩══════════════════════════════════════════╝