Member 10521029 Ответов: 1

Проводной поведения Майкрософт.туз.oledb для.12.0 64 бит

Мы используем 64-разрядный кластер SQL Server 2014 в Windows server 2012 R2. У нас есть огромное количество файлов MS Access. mdb, поступающих из распределенных областей. Мы используем OpenRowSet для загрузки данных из Access. mdb в SQL Server. Пока мы не перешли на 64-битный сервер, он работал нормально. После миграции на 64-битный SQL Server мы обнаружили, что Jet.4.0 не имеет 64-битной версии, поэтому мы переключились на Ace.12.0 64bit. После обновления до Ace. 12. 0 64-битная производительность была снижена. Результат теста проводной.

SQL 2008R2 64 бит-от 7 секунд до 10 минут
SQL 2008R2 32 bit-7sec
SQL 2014 64-битный кластер-7сек-10мин
Мы не можем взять на себя инициативу по тестированию SQL Server 2014 в 32-битном режиме.

Тестировался на том же сервере по тому же запросу. Я обнаружил, что после перезапуска либо сервера, либо SQL Server SQL 2014 64bit и 2008R2 32bit/64bit занимают 7 секунд для выполнения, и по прошествии времени они постепенно увеличиваются для 64bit. Время выполнения не является стабильным на 64-битном SQL server, но 32-битный SQL server занимает фиксированные 7 секунд, чтобы выполнить запрос в любое время. Ace. 12. 0 и Jet.4.0 занимают одинаковое время в 32-битном режиме, но Ace.12.0 не стабилен в 64-битном режиме.

Мы используем 16-ядерный процессор с 128 ГБ оперативной памяти, 2Node с San-коммутатором. Все сетевые коммутаторы являются гигабайтными коммутаторами. 9 ТБ полезного хранилища.

Любая помощь будет высоко оценена.

Что я уже пробовал:

выбрать * из инструкции openrowset('Microsoft для.Туз.Oledb для.15.0','\\\сведения HD2016050088.МБР';'админ';",ХХХ)
выбрать * из инструкции openrowset('Microsoft для.Туз.Oledb для.12.0','\\\сведения HD2016050088.МБР';'админ';",ХХХ)
выбрать * из инструкции openrowset('Microsoft для.Джет.Oledb для.4.0','\\\сведения HD2016050088.МБР';'админ';",ХХХ)

Wendelius

Как происходит погрузка? Используете ли вы SSIS, есть ли у вас хранимая процедура, отдельная программа или что-то еще?

Member 10521029

У нас есть vb.net программа, которая отправляет запрос openrowset на SQL server для выполнения. На самом деле я проверил этот факт своими vb.net программа, а также из SQL server management studio также.

1 Ответов

Рейтинг:
2

Wendelius

Я бы попробовал использовать BULK варианты для OPENROWSET. Особенности определения ROWS_PER_BATCH и ORDER это может повлиять на производительность в зависимости от того, где вы загружаете данные. Для получения дополнительной информации см. OPENROWSET (Transact-SQL)[^] и Импорт массовых данных с помощью BULK INSERT или OPENROWSET (BULK...) (SQL Server)[^]

Если это ничего не даст, попробуйте выполнить команды непосредственно на SQL-сервере. В то же время контролируйте использование памяти, диска, сети и процессора, чтобы увидеть, что на самом деле вызывает узкое место. Вы можете использовать например Монитор Производительности Windows[^] для сбора данных.

Member 10521029

Спасибо, Мика. Я попробую навалом, и я уже давно проверил монитор производительности, но никаких результатов. Я не думаю, что там может быть бутылочное горлышко. В 32-битном режиме все в порядке. После перезагрузки сервера 64-битный также файл. Постепенно он становится медленным.

Wendelius

Если он постепенно замедляется, это может указывать, например, на утечку памяти и т. д. Из-за этого основная память может стать узким местом и вызвать, например, подкачку. Это то, что вы увидите при мониторинге производительности сервера. Ведь должна же быть причина для замедления.

Member 10521029

Ты права, Мика, очевидно, должна быть причина. Я думаю, что есть что-то вроде утечки памяти. Так что должна быть и фиксация. Надеюсь, вы знаете, как защитить это. Если вы поделитесь, я буду благодарен.

Wendelius

Я думаю, что лучший вариант-собрать данные и сообщить в Microsoft, если результаты обнаружат проблему. Постоянно ли растет потребление памяти при выполнении запроса, что происходит при перезапуске SQL-сервера, что показывают счетчики в мониторе производительности и т. д. Если это действительно утечка памяти, то MS должна иметь для нее исправление.

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

Member 10521029

Я обнаружил, что потребление памяти постепенно увеличивается до полной памяти(128 ГБ). Я погуглил и обнаружил, что SQL Server 2014 имеет эту функцию, чтобы потреблять полную память. Я изменил максимальную память сервера на 50% в свойствах сервера. Теперь около 60 Гб памяти всегда свободны.

Wendelius

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

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

Однако мне было бы интересно услышать, действительно ли это решило проблему!

Member 10521029

После перезагрузки сервера вчера я обнаружил полную производительность. Затем я выполнил тот же запрос с некоторым интервалом и получил ту же производительность в течение дня, которая составляет 7 секунд для таблицы лагера. Последний раз я выполнил запрос в 6 вечера, который работал с шармом. После этого я пошел домой и вернулся сегодня в 9 утра, и я выполнил то же самое, и он снова вел себя странно. Для одного и того же запроса требуется 22 секунды. Нет никакой нагрузки на сервер. Он точно простаивает. Бог знает, что происходит.

Спасибо, Мика, за сотрудничество.

Wendelius

Рад, если все получилось!

Member 10521029

Я нашел проблему, связанную с сетью, на узле 01. Сейчас я работаю над Node02. До сих пор он работает нормально. Надеюсь, что он будет работать нормально до тех пор, пока процесс не завершится. Еще раз спасибо, Мика.

Member 10521029

Мика, наконец-то я обнаружил, что есть ошибка сетевого уровня. При пинге на имя кластера или IP-адрес время ответа очень велико.Он идет до 500 мс+. Поэтому я думаю, что здесь должна быть проблема лжи. Над этим работают наши сетевые эксперты. Надеюсь, скоро все будет хорошо.

Wendelius

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

Member 10521029

После долгого анализа я наклонился к службе анализа SQL, и все начало работать нормально. Как только я остановил службу SQL Reporting Service, она стала еще лучше работать.
Итак, наконец я обнаружил, что служба SQL Analysis Service/SQL Reporting Service может привести к снижению производительности. В этих сервисах должны быть конфигурации для оптимизации, но в моем случае остановка этих сервисов сделала свое дело.

Большое вам спасибо, Мика, за сотрудничество.