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

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

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

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

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

Ответ 1

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

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

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

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

Ответ 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 строк за раз, уменьшая размер транзакции.

Ответ 3

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

Ответ 4

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

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

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

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

Как отменить запрос UPDATE на SQL Server 2005?

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

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

Ответ 5

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

Ответ 6

Код С#, использующий 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 и запустите:

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