selis76To Alexey Sh и витёкша
Access 97, гонял эту прогу и на Access 2000.
Однако вот что беспокоит
Процессор клиента загружен не более чем на 30% (я еще Access давал High priority в Windows.) По моему разумению вычислительные ресурсы используются не полностью как же Recordset access и прочие навороты могут мешать? Да они не забивают проц.
Более того я сознательно ввел в процедуру FillCache думал что она сразу будет группой считывать строки, а видно нет, не делает
Таблица большая 3 милиона записей, каждая запись в oracle гдето 990 байт
Такое впечатление что гдето в ODBC сидит timeout например опрашивает чередь поступивших данных

все он делает (в смысле филлкеш)
с арифметикой у меня всегда проблемы - на вскидку
размер выходной строки = 2.5 гигабайта - если "все за раз"
не может такого быть, чтобы вы всю таблу за раз обрабатывали.
если циферки не враки - ты должен отчетливо наблюдать, как с течением времени все реже и реже обращения к серверу идут.
Да и сервер напрягать держать невыбранных буферов и/или открытых курсоров такого размера - не почеловечески.

Ох, НЕ ВЕРЮ, что вы весь набор за раз обрабатываете.

СКОЛЬКО ВРЕМЕНИ ЗАНИМАЕТ В ЧАСАХ РАБОТА?
железка-то какая?


Сегодня вечером - без всякого рекордсета проделай фокус

Sub Test

Dim s1 as String
dim FStr as String
dim iNdex as long

s1 = String(999,0)

For index = 1 to 3000000
Fstr = FStr & s1
NExt

и оставь на ночь считаться. Завтра посмотри, где там индекс болтается, на каком миллионе.
Производительность у тебя выше 30% и не поднимется.
Ос очень быстро своп начнет и будешь ты работать с диском. А процессор ждать, пока дисковые операции будут выполняться.

Во первых, использовать Mid= - бегом марш.
Во вторых, тут что-то с размером думать надо. Нафига и кому така строка/файл размера не дочитать до конца жизни?


ЗЫ0
ох, так и просится вынос в ActiveX DLL...

ЗЫ1
строка ведь дальше в файло превращается?
Дальнейшая оптимизация - писать напрямую в файл. Лучше отображенный на память. В принципе, можно изобразИть с ним как со строкой обращение.
Правда чуть покодировать придется.

да вот еще подумал -
1) момент вставки подстроки - было бы удачно, если бы размер вставляемой подстроки всегда был кратен четырем (8 байт).

по сравнению с временем формирования выходной строки все остальное не так критично, но все же

2) обращение к полям при рекордсетах такого размера - тоже становится важным. Перепиши через RS.Collect.
Поиграйся с настройками рекордсета. Говорят для MS SQL, в смысле скорости, лучше, когда CursorLoaction = adUseServer (в терминах АДО), курсор для рекордсета заказан forwardonly, cashsize=1.
для Оракл - не знаю.

извини - невнимателен и не обновляю ранее прочитанное - не пересматриваю. виноват.

если это не универсальная процедура - попробуй явно прокешировать каждый Field. или попробуй Collect. здесь я не могу внятного совета дать - что лучше - не знаю.

50*990 - это конечно не гигабайты, а всего 49 килобайт. Попробовать все же стоит. Примерно так

2 selis76

Ау, есть ли новости с фронта?

все-таки не ясно, какие именно проводся замеры.
ИМНО - догнать SQL Plus на Акцесс - задача неосуществимая.
По двум причинам

1) как помню, SQL Plus обращается к Oracle.Net напрямую, минуя ОДБС.
Трудно предствить, чтобы драйвер выиграл. Когда-то их было как минимум 3 от Оракл от Майкрософт и от Мерант. Производительность их может отличаться. У тебя чей?
2) У тебя происходит обработка в p-Коде, исполнитель которого работает как один из потоков Акцесс. Увеличить скорость собственно обработки плученных от ДАО строк в 20-40 раз можно, перенеся код как есть в native-компилированную ActiveX dll.

А сравнивать с SQL Plus разумно можно просто пустой цикл перебора строк для приложения, обращающегося к ОДБС напрямую. У тебя все-таки даже в случае ODBCWorkspace есть посредник.


У тебя должна бы быть под рукой подходящая АДО библиотека.
Я бы все-таки советовал попробовать. Может все-таки получиться выигрыш на твоем рекордсете заметный. если бы это был MS SQL Server - точно получил бы.

Оптимизировать скорость перебора рекордсета и скорость его обработки хорошо в двух независимых процедурах. Ты ведь так и делаешь?

Пока что понял следующее.
Манипуляции с параметрами рекордсета дают 60% прирост скорости.
Попытка ускорить формирование строки - еще 10%
Почему бы их не скомбинировать?

Еще что-то можно выиграть на доступе к полям.

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

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

Если есть желание "продолжать" (а мне - так интересно было бы увидеть, на чем сердце успокоилось), может выложишь последние фрагменты получившегося?
любобытно увидеть абсолютное время работы процедуры до оптимизации и после.

selis76To Victosha
Замеры проводятся простые. Логика такова есть более мощный ПК PiV 2Gg и менее мощный P633 и сервер 2 проца по 933 + Oracle + сеть 100 мегабит. Есть приложение на Access которое использует курсор. Использую ODBC драйвер от Oracle
...
По идее проц быстро делает запрос отправляет серверу, периодически опрашивается очередь полученных данных, и как только они есть они забираются. Т.е. чем мощнее проц клиента тем короче промежуток на обработку данных.

Глупый вопрос. Почему скорость копирования файлов с сервера в 50 раз выше сканирования таблицы?
...
Но почему тогда более мощная машина не дает сокращения времени на выборку данных в случае Access ODBC но дает это в случае SQLPlus???


Предварительно
Я не знаю ответа на Ваш вопрос. Просто изложу свое представление.
------------
1) ПРЕЖДЕ ВСЕГО НЕОБХОДИМО ПРИНЯТЬ ВО ВНИМАНИЕ, ЧТО SQL PLUS НЕ РАБОТАЕТ ЧЕРЕЗ ОДБС. (буду сильно удивлен, если это не так) Поэтому сравнение с ним не вполне корректно. ОДБС как правило работает медленнее.
Просто потому, что с курсором работает существенно менее эффективно, прокручивая их построчно, да и заказывать норовит, как подозреваю глобальные курсоры. Подозреваю, что SQL Plus может обойтись с курсором более эффективно - как с потоком данных.

2) Рост производительности приложения работающего через ОДБС, вообще говоря не обязано быть таким же, как и у SQL Plus. Ниже я постараюсь высказать свое представление - почему.

Вы замеряли, на сколько проц PIV 2 Gg быстрее чем проц P633 ?
На сколько другие приложения (в частности офисные, и в любом случае без учета графических пакетов) считаются быстрее на 2Гц, чем на P633?

Было бы несправделиво, если бы Акцесс ускорился больше, чем Ексель, например.
Сильно сомнительно, чтобы офис (и прочие приложения) в среднем ускорились бы на вашем 2 Гц на столько же, на сколько ускорился SQl Plus.

Применительно к сетевому обмену - На PIV - быстрее системная шина, и он гораздо с большей эффективностью использует (может использовать на специально для этого написанных задачах) 100 мб сетевую карту. Практически полностью выбирая ее производительность. Для P633 это по существу за рамками архитектуры - он просто не может толком нагрузить сетевую карту.

При смене машинки, например, должно ускориться, например копирование файла по сети.
SQL Plus должен ускориться примерно в той же пропорции, или больше.

Ускорение SQL Plus легко объяснить - его ускорение в существенной степени предопределено прямизной обращения к сетевому уровню Оракл и эффективностью написания этого уровня. И выигрыш этот определен тем, что карта начинает работать.

А считать на процессоре SQL Plus почти нечего в тот момент, кода он прием данных осуществляет.

Акцесс работает через ДАО, которое транслирует его вызовы к ОДБС, оно транслирует к Оракловому драйверу, который уже начинает работать с сетевым уровнем Оракл. При этом Акцессу нужно еще исполнять код ВБА и еще малость чего пытаться делать.

При таком подходе приложению НЕКОГДА к сетевой карте обращаться, ему бы успеть перемолотить весь код между Акцессом и Оракл.нет. Верхняя граница здесь проходит по линии производительность процессора-шины памяти-модулей памяти + задержки на перевод процессора в работу в режиме ядра при обращении к системным (в т.ч. сетевым функциям). +вероятные доп потери при наличии подкачки. (памяти хватает акцессу?) По этой верхней границе насколько PIV 2ГЦ быстрее?

Само по себе использование ОДБС от Оракл - может быть не очень удачное в смысле именно производительности. ОДБС, вообще говоря, чуждая для Оракл технология, хотя и одна из самых быстрых среди "не родных".
Может для смеху драйвер от MS попробовать?

Хотя я еще раз посоветовал бы на АДО обратить внимание.

Если у вас на входе файл, то, вслед за kedzo, повторю - все на сервер.