Производительность таблицы доступа Microsoft Access с сквозным запросом

Question

Вопрос для вас. Гуру доступа там:

У меня есть Oracle сквозной запрос, который возвращает набор результатов примерно за 2 секунды в программе Access. Однако, когда я пытаюсь использовать этот сквозной запрос внутри запроса make-таблицы, он тянется примерно на 7 минут. (Файл в настоящее время находится на моем рабочем столе, и все таблицы являются локальными (не связаны)).

В целях повышения производительности я создал запросы на удаление / добавление и запустил его с VBA. Затем я попробовал DAO db.Execute с явными строковыми SQL запросами, ссылающимися на сквозной запрос (INSERT / SELECT). Все методы очень медленные! Я хотел бы приблизить его к фактическому времени выполнения передачи (опять же, 2 секунды).

Любое понимание?

Answer 1

Скорее всего, нет большой разницы в производительности между make-таблицей и сквозным запросом. На самом деле выполнение запроса занимает несколько минут, а некоторые результаты можно просмотреть за считанные секунды. Прокрутка вниз окна запроса может показать, что запрос все еще выполняется.

Поскольку транзитные запросы взаимодействуют с ODB C драйвером / поставщиком OLEDB для анализа SQL операторов между клиентом (то есть MS Access) и базой данных. (т. е. Oracle) по сети, факторы могут быть связаны с несколькими средами или программным обеспечением.

1. Сетевой трафик c между клиентским компьютером и сервером. Избегайте WAN для проводных соединений LAN . Никогда не используйте inte rnet папки и не запускайте Access на дисках fla sh или дисках с ограниченным дисковым пространством.
2. ODB C драйвер / поставщик OLEDB, который может быть устаревшим. Попробуйте найти самую последнюю версию совместимую с вашей Oracle версией и версией MS Office. И попробуйте запустить на 64-разрядных архитектурах.
3. Сложные или большие Oracle типы данных, которые не могут быть сопоставлены с типами данных JET / ACE, такими как числовые типы высокой точности или большие двоичные типы объектов. См. Это Oracle do c.
4. Приложение с раздутым доступом, которое должно быть сжатым и даже декомпилированным .
5. База данных без разделенной архитектуры , где объект приложения (запросы, формы, отчеты, макросы, модули) отделены от таблиц.

Answer 2

Является ли таблица доступа для доступа локальной? Я имею в виду собаку и говорю, что шина - это ОЧЕНЬ разные вещи.

Делает ли таблица локальную для oracle, или вы рассматриваете использование PT-запроса в качестве make-таблицы для LOCAL-таблицы в Доступ? Таким образом, ваше сравнение - это гора Эвереста.

Я подозреваю, что таблица привязки плоскости jane к Oracle против таблицы запросов PT, скорее всего, выполнит то же самое, если целевая таблица будет "локальной". Это потому, что вы перетаскиваете всю таблицу вниз по сетевому каналу к локальной таблице.

Если запрос PT является таблицей make на 100% к другой таблице на сервере Oracle? Тогда запрос PT должен выполняться так же быстро, как если бы вы вводили эту команду в консоли Oracle - различий не должно быть.

Вы не упоминаете счетчик строк (РЕДАКТИРОВАТЬ - я вижу только примечание 16 000 рядов - это довольно мало). Таким образом, проблема заключается в сетевом подключении. это локальная сеть (LAN) или вы используете VPN и inte rnet, который будет примерно в 100 раз медленнее. Я имею в виду, что соединение, которое в 100 раз медленнее, чем обычная локальная сеть, будет в 100 раз медленнее - здесь нет ничего удивительного.

Итак, подробности относительно типа используемого соединения и количества строк потеряют значительную часть. зажечь здесь Но если здесь задействованы VPN и соединение через inte rnet, то такие соединения примерно в 50 раз медленнее, чем ваша сверхдешевая локальная офисная сеть. Вы можете прочитать эту мою статью, которая объясняет эту проблему скорости: http://www.kallal.ca//Wan/Wans.html

Я не понимаю, почему 16 000 строк заняли бы так много времени - это займет меньше секунды в самой дешевой офисной сети. Использование любого другого клиента для извлечения этих данных не должно выполняться или работать быстрее, чем запрос PT. Я имею в виду, ado. net, ODB C или oleDB не заставляют сервер говорить: гуд, гы - давайте отправляем данные медленнее. Все эти клиенты должны получать данные с одинаковой скоростью.