Загрузка данных SQL - Требуются предложения

Question

Gurus,

Мы находимся в процессе настройки пакета служб SSIS для загрузки отформатированного текстового файла на сервер SQL. Он будет иметь около 100 миллионов строк, а размер файла будет (несколько файлов по 15 ГБ каждый) 100 ГБ. Формат файла приведен в соответствие с XML-схемой, как указано ниже ... загрузка файла в таблицы сервера SQL занимает около 72 часов ...

Формат файла

EM | 123 | XYZ | 30 | Объем продаж | 20000 | AD | 1 Улица 1 | State1 | City1 | US | AD | 12Street 2 | State 2 | City2 | UK | CON | 2012689648 | CON | 42343435

EM | 113 | WYZ | 31 | Уровень продаж | 200 | AD | 12 Улица 1 | State2 | City2 | US | AD | 1Street 22 | Штат 3 | Город 3 | UK | CON | 201689648 | CON | 423435

EM | 143 | rYZ | 32 | Sales Egr | 2000 | AD | 113Street 1 | State3 | City3 | US | AD | 12Street 21 | Штат 4 | City 5 | UK | CON | 201269648 | CON | 443435

Данные поступят в вышеуказанном формате. Это означает, что «EM» до «AD» - это данные сотрудника, такие как код, имя, возраст, назначение, зарплата, а «AD» - это адрес, например, улица, штат, город, страна. Адресные данные могут быть множественными для одного и того же сотрудника ... аналогично "CON" - это контактная информация с номером телефона, который также может быть множественным.

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

Мы спроектировали пакет подобным образом, имели в качестве источника компонент Script и построчно анализировали с помощью сценариев .NET, создавая несколько выходных буферов для каждой таблицы и добавляли строку в сценарий. Отображение выходных данных компонента Script на 3 адресата OLE DB (таблицы SQL Server).

Наш сервер Quad Core с 48 ГБ виртуализированной оперативной памяти, и у нас есть 2 ядра с 24 ГБ, выделенных для БД. Наша база данных SQL-сервера (модель простого восстановления) имеет файлы данных в общей сетевой папке, которая является хранилищем SAN. Для повышения производительности мы создали каждую таблицу в отдельном файле данных (первичном и вторичном) ... но все же это занимает около 72 часов.

Нужны указания по следующим пунктам.

1. Можно ли использовать BCP, если да, есть какие-либо указатели .. (Надеюсь, BCP будет работать лучше)

2. Любые предложения по указанному решению.

3. Любые альтернативы ...

В таблице не определены индексы и триггеры ... Мы даже установили defaultMaxbufferzie равным 100 МБ

Жду ответа .. Любая помощь очень ценится.

Answer 1

1.) При необходимости упростите / сведите ваш XML-файл с помощью XSLT, как показано здесь: http://blogs.msdn.com/b/mattm/archive/2007/12/15/xml-source-making-things-easier-with-xslt.aspx

2.) Используйте источник XML, как показано здесь: http://blogs.msdn.com/b/mattm/archive/2007/12/11/using-xml-source.aspx

3.) Отбросить все индексы в таблицах назначения

4.) Если ваши исходные данные являются пуленепробиваемыми, отключите ограничения для таблиц с помощью:

ALTER TABLE [MyTable] NOCHECK CONSTRAINT ALL

5.) Загрузка данных через OLEDB-адресат

6.) Повторно включить ограничения

7.) Пересоздание индексов

Answer 2

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

• Когда вы запускаете импорт, сколько строк вы импортируете каждую секунду (вы можете сделать «SELECT COUNT (*) FROM yourtable WITH READUNCOMMITTED» во время импорта, чтобы увидеть) Эта скорость остается постоянной или делает это замедлить к концу вашего импорта?
• Как уже говорили другие, есть ли у вас какие-либо индексы или триггеры в таблицах назначения?
• Во время выполнения импорта как выглядят ваши диски? В perfmon очередь дисков выглядит как сумасшедшая, указывая на то, что ваши диски являются узким местом? Какова пропускная способность этих дисков при обычном тестировании производительности? У меня был опыт, когда неправильно сконфигурированный iSCSI или неправильно выровненное хранилище SAN могут сбрасывать мои диски с 400 МБ / с до 15 МБ / с - все еще хорошо при обычном использовании, но слишком медленно, чтобы что-либо массово делать.

Вы также говорите о загрузке 100 ГБ данных, что немалое количество - загрузка не должна занимать 72 часа, но она не загрузится и через 20 минут, так что ожидайте разумного. Примите во внимание эти и другие узкие места, о которых люди спрашивали, и мы можем помочь вам изолировать вашу проблему.

Answer 3

Если у вас есть какой-то контроль над способом создания файлов, я бы отошел от отношения «один ко многим», которое у вас есть с |EM| и |AD|, |CON|, и сделал бы что-то вроде это:

|EM|EmpID|data|data|

|AD|EmpID|data|data|

|CON|EmpID|data|data|

Кроме того, если вы сможете разделить записи на три разных файла, вы сможете использовать компонент источника плоских файлов с фиксированной спецификацией для каждого источника для массовой обработки данных.

Answer 4

Вы говорите, что файлы данных находятся в общей сетевой папке. Одним из улучшений будет добавление жесткого диска и запуск задания на сервере SQL, так как вы устраните задержки. Я думаю, что даже подключение USB-накопителя для чтения файлов будет лучше, чем использование сетевого расположения. Конечно, стоит немного проверить, на мой взгляд.