Ошибка нехватки памяти при вставке файлов 600 МБ в sql server express как данные файлового потока

Команда SDAC сказала мне, что это ограничение диспетчера памяти Delphi.

Мне это показалось упрощенным ответом, и я исследовал. У меня нет компонентов SDAC, и я также не использую SQL Server, мои фавориты - Firebird SQL и набор компонентов IBX. Я попытался вставить большой двоичный объект размером 600 МБ в таблицу с помощью IBX, а затем попытался сделать то же самое с помощью ADO (охватывающий две технологии подключения, оба являются потомками TDataSet). Я обнаружил, что правда где-то посередине, это не совсем диспетчер памяти, это не вина SDAC (ну ... они в состоянии что-то с этим поделать, если многие другие люди попытаются вставить капли 600 Мб в баз данных, но это не имеет отношения к данному обсуждению). «Проблема» в коде БД в Delphi. Как оказалось, Delphi настаивает на использовании одного варианта для хранения любого типа данных, которые можно загрузить в параметр. И это имеет смысл, ведь мы можем загружать много разных вещей в параметр для INSERT. Вторая проблема заключается в том, что Delphi хочет рассматривать этот вариант как тип VALUE: он копирует его в список дважды, а может быть, и трижды! Первая копия создается сразу после загрузки параметра из файла. Вторая копия создается, когда параметр готов к отправке в ядро ​​базы данных.

Написать это легко:

var V1, V2:Variant;
V1 := V2;

и отлично работает для целых чисел, дат и небольших строк, но когда V2 представляет собой массив Variant 600 МБ, это назначение, по-видимому, создает полную копию! Теперь подумайте о пространстве памяти, доступном для 32-битного приложения, которое не работает в режиме «3G». Доступно всего 2 Гб адресного пространства. Часть этого пространства зарезервирована, часть этого пространства используется для самого исполняемого файла, затем есть библиотеки, а затем есть место, зарезервированное для диспетчера памяти. После выделения первых 600 Мбайт доступного адресного пространства может не хватить для выделения другого буфера 600 Мбайт! Из-за этого можно с уверенностью винить в этом диспетчер памяти, но опять же, почему именно БД нужна другая копия монстра 600 Мб?

Одно возможное исправление

Попробуйте разделить файл на более мелкие, более управляемые части. Настройте таблицу базы данных, чтобы иметь 3 поля: ID_DOCUMENT, SEQUENCE, DOCUMENT. Также сделайте первичный ключ в таблице (ID_DOCUMENT, SEQUENCE). Затем попробуйте это:

procedure UploadBigFile(id_doc:Integer; sFilePath: String);
var FS:TFileStream;
    MS:TMemoryStream;
    AvailableSize, ReadNow:Int64;
    Sequence:Integer;
const MaxPerSequence = 10 * 1024 * 1024; // 10 Mb
begin

  FS := TFileStream.Create(sFilePath, fmOpenRead);
  try
    AvailableSize := FS.Size;
    Sequence := 0;
    while AvailableSize > 0 do
    begin
      if AvailableSize > MaxPerSequence then
        begin
          ReadNow := MaxPerSequence;
          Dec(AvailableSize, MaxPerSequence);
        end
      else
        begin
          ReadNow := AvailableSize;
          AvailableSize := 0;
        end;
      Inc(Sequence); // Prep sequence; First sequence into DB will be "1"
      MS := TMemoryStream.Create;
      try
        MS.CopyFrom(FS, ReadNow);

        sqlInsertDoc.ParamByName('ID_DOC_FILE').AsInteger := id_doc; 
        sqlInsertDoc.ParamByName('SEQUENCE').AsInteger := sequence; 
        sqlInsertDoc.ParamByName('DOCUMENT').LoadFromStream(MS, ftblob); 
        sqlInsertDoc.Execute; 

      finally MS.Free;
      end;
    end;
  finally FS.Free;
  end;

  sqlInsertDoc.Close;       

end;

Вы можете перебрать байтовый поток объекта, который вы пытаетесь вставить, и по существу буферизовать его часть за раз в своей базе данных, пока вы не сохраните весь ваш объект.

Я бы посмотрел на метод Buffer.BlockCopy (), если вы используете .NET.

На мой взгляд, метод анализа вашего файла может выглядеть примерно так:

        var file = new FileStream(@"c:\file.exe");
        byte[] fileStream;
        byte[] buffer = new byte[100];
        file.Write(fileStream, 0, fileStream.Length);
        for (int i = 0; i < fileStream.Length; i += 100)
        {
            Buffer.BlockCopy(fileStream, i, buffer, 0, 100);
            // Do database processing
        }

Вот пример, который читает файл с диска и сохраняет его в столбце FILESTREAM. (Предполагается, что у вас уже есть контекст транзакции и FilePath в переменных «filepath» и «txContext».

'Open the FILESTREAM data file for writing
Dim fs As New SqlFileStream(filePath, txContext, FileAccess.Write)

'Open the source file for reading
Dim localFile As New FileStream("C:\temp\microsoftmouse.jpg",
                                FileMode.Open,
                                FileAccess.Read)

'Start transferring data from the source file to FILESTREAM data file
Dim bw As New BinaryWriter(fs)
Const bufferSize As Integer = 4096
Dim buffer As Byte() = New Byte(bufferSize) {}
Dim bytes As Integer = localFile.Read(buffer, 0, bufferSize)

While bytes > 0
    bw.Write(buffer, 0, bytes)
    bw.Flush()
    bytes = localFile.Read(buffer, 0, bufferSize)
End While

'Close the files
bw.Close()
localFile.Close()
fs.Close()

Вероятно, вы где-то сталкиваетесь с проблемами фрагментации памяти. Игра с действительно большими блоками памяти, особенно в любой ситуации, когда их может потребоваться перераспределение, имеет тенденцию вызывать ошибки нехватки памяти, когда теоретически у вас достаточно памяти для выполнения работы. Если ему нужен блок 600 Мбайт, и он не может найти дыру шириной 600 Мбайт, значит, нехватка памяти.

Хотя я никогда не пробовал это сделать, я предпочитаю обходной путь создать очень минимальную программу, которая выполняет ТОЛЬКО одну операцию. Сделайте это максимально простым, чтобы минимизировать выделение памяти. Когда вы сталкиваетесь с такой рискованной операцией, обратитесь за помощью к внешней программе. Программа запускается, выполняет одну операцию и завершает работу. Дело в том, что новая программа находится в собственном адресном пространстве.

Единственное настоящее исправление - 64-разрядная версия, и у нас пока нет такой возможности.

Недавно у меня возникла аналогичная проблема при запуске DBCC CHECKDB на очень большой таблице. Я бы получил такую ​​ошибку:

Недостаточно системной памяти во внутреннем пуле ресурсов для выполнения этого запроса.

Это было на SQL Server 2008 R2 Express. Интересно то, что я мог контролировать возникновение ошибки, добавляя или удаляя определенное количество строк в таблице.

После обширных исследований и обсуждений с различными экспертами по SQL Server я пришел к выводу, что проблема связана с комбинацией нехватка памяти и ограничение памяти 1 ГБ SQL Server Express.

Мне была дана рекомендация:

1. Приобретите машину с большим объемом памяти и лицензионной версией SQL Server или ...
2. Разделите таблицу на большие части, которые может обработать DBCC CHECKDB.

Из-за сложной природы синтаксического анализа этих файлов в объекте FILSTREAM я бы рекомендовал filesystem и просто использовать SQL Server для хранения местоположения файлов.

«Хотя нет никаких ограничений на количество поддерживаемых баз данных или пользователей, оно ограничено использованием одного процессора, 1 ГБ памяти и 4 ГБ файлов базы данных (файлы базы данных 10 ГБ из SQL Server Express 2008 R2)». Важен не размер файлов базы данных, а «1 ГБ памяти». Попробуйте выплюнуть файл размером 600MB +, но поместить его в поток.