ODAC для .NET работает медленно

У меня есть экземпляр Microsoft SQL Server 2008 и база данных Oracle 10g, установленные рядом на одном и том же удаленном сервере с одинаковыми точными данными, загруженными на каждый из них.

Я написал программу для простого запроса, который возвращает около 10 000 записей (SELECT * FROM TABLE WHERE X=X). Что я вижу в этом тесте, так это то, что Oracle возвращает где-то в 4-12 раз медленнее, чем MSSQL. Я протестировал соединение по локальной сети, удаленно через VPN, используя ODP.NET4, ODP.NET2, убедившись, что в 32-битной операционной системе установлена ​​правильная 32-битная версия, и то же самое для 64-битной.

Мои результаты всегда одинаковы в том, что Oracle всегда во много раз медленнее, чем экземпляр SQL Server.

Я также пробовал тот же запрос в SQL Developer, и этот инструмент извлекает тот же набор записей намного быстрее. Когда я заставляю инструмент извлекать все записи, он работает примерно на 20% медленнее, чем SQL Server, что, по крайней мере, было бы приемлемо в моем сценарии.

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

Спасибо

  • С сервера базы данных: 3 с (Oracle) против 0,6 с (SQL Server)
  • Откуда-то в локальной сети: 22 с (Oracle) против 4 с (SQL Server)
  • С удаленной машины через vpn: 54 с (Oracle) против 21 с (SQL Developer) против 13 с (SQL Server)

Дополнительный вопрос: это падение производительности, которое вы испытываете в своих приложениях, совместимых с ODP.NET + SQL Server, или я прав, предполагая, что что-то не так?


.net oracle odp.net
person user112799    schedule 14.11.2012    source источник
comment
Вы измеряете скорость на основе времени, необходимого для НАЧАЛА возврата записей, или времени, необходимого для ЗАВЕРШЕНИЯ возврата всех 10 000 записей?   -  person Derek Tomes    schedule 15.11.2012
comment
Время, необходимое для возврата всех записей и заполнения таблицы данных (с использованием DataAdapter)   -  person user112799    schedule 15.11.2012
comment
Продукт Microsoft -> Продукт Microsoft = быстро; Продукт Microsoft -> Другой продукт = медленно. Конечно, в продуктах, использующих одного и того же поставщика, будет оптимизация. Просто к вашему сведению, я видел именно то, что вы испытываете несколько раз в производстве.   -  person cillierscharl    schedule 15.11.2012
comment
Вам нужна таблица данных? Попробуйте DataReader в коллекцию (например, список).   -  person paparazzo    schedule 15.11.2012
comment
К сожалению, мне нужно, чтобы это был DataTable, что является совершенно другой проблемой. Слишком много кода зависит от него, чтобы изменить его.   -  person user112799    schedule 15.11.2012

Ответы (1)


arrow_upward
3
arrow_downward

Вы устанавливаете размер выборки в ваше приложение? Если да, пробовали ли вы устанавливать разные размеры выборки и измерять, как это влияет на прошедшее время? Я считаю, что SQL Developer по умолчанию использует размер выборки 500 (хотя я не гарантирую этого), поэтому вы можете использовать это в качестве отправной точки.

person Justin Cave    schedule 14.11.2012
comment
Джастин, спасибо, это действительно помогло. Знаете ли вы, есть ли какие-либо недостатки в использовании по умолчанию очень большого размера выборки? Настройка значения на 600 000 повысила производительность всего в 2 раза медленнее, чем SQL Server, что, безусловно, лучше, чем 15x, которые я испытал. - person user112799; 15.11.2012
comment
@ user112799 - В зависимости от сети я бы ожидал, по крайней мере, некоторого снижения, когда размер выборки стал слишком большим. И должно быть довольно быстро уменьшающееся преимущество по мере роста размера выборки — например, в официальном документе, на который я ссылался, переход от размера выборки 1 к размеру выборки 10 привел к сокращению затраченного времени примерно на 80%. в то время как переход от размера выборки с 1000 к 10000 привел к сокращению только на ~ 5%. Размер выборки в 600 000 довольно велик, но если это то, что вы считаете оптимальным для своего приложения, это не совсем выходит за рамки разумности. - person Justin Cave; 15.11.2012