Форум: "Базы";
Текущий архив: 2005.02.06;
Скачать: [xml.tar.bz2];
Вниз
Скорость выборки Найти похожие ветки
← →
Piter © (2004-12-18 18:50) [0]Есть такое выражение:
"SELECT Count(n) From MyTable Where n=0"
Выборка длится около 4 секунд :(
Всего записей в базе 4700.
Почему так медленно? Правда, стоит заметить, что это только первый раз так долго. Потом такие выражения выполняются не более 100 мс, но все равно - загрузка программы происходит очень долго из-за этого.
Такое ощущение, что это как бы инициализация работы с таблицей. То есть, при первой выборке из этой таблице что-то там делается долго, после чего последующие выборки из этой таблицы отрабатывают оперативно. Ну это мне так кажется.
Можно как-нибудь ускорить процесс? А то 4 секунды - это перебор все таки, имхо, на Athlon 1800. Не понимаю, как тогда работают базы с миллионами записей...
Использую базу Firebird Embedded
← →
Anatoly Podgoretsky © (2004-12-18 18:53) [1]Индекс по полю N и добавить памяти в компьютер.
← →
AlterEgo of WondeRu © (2004-12-18 18:57) [2]{+оффтоп}
Piter © (18.12.04 18:50)
Использую базу Firebird Embedded
испоьзуй нормальный Firebird, с ним у меня никогда проблем не возникало
{-оффтоп}
← →
Piter © (2004-12-18 19:12) [3]Anatoly Podgoretsky © (18.12.04 18:53) [1]
Индекс по полю N
индекс по полю N есть. Причем что он есть, что его нету - пофигу.
и добавить памяти в компьютер.
а причем здесь память? Потом ведь выборки нормально осуществляются... Просто какое-то ненормально долгая инициализация на мой взгляд...
← →
Piter © (2004-12-18 19:13) [4]AlterEgo of WondeRu © (18.12.04 18:57) [2]
испоьзуй нормальный Firebird, с ним у меня никогда проблем не возникало
а почему бы Oracle не посоветовать?
Если я использую Firebird Embedded, то значит это чем-то обоснованно.
Да и на обычном Firebird тоже самое
← →
AlterEgo of WondeRu © (2004-12-18 19:20) [5]Piter © (18.12.04 19:13) [4]
совет. а попробуй инициализацию проводить на другой таблице! т.е. хотя бы на анкетах, она же пустая!
← →
Sergey_Masloff (2004-12-18 20:17) [6]Piter © (18.12.04 18:50)
А не сборка ли энто мусора? 4 сек на 5000 записей многовато конечно но - точно не оно?
← →
Piter © (2004-12-18 20:38) [7]AlterEgo of WondeRu © (18.12.04 19:20) [5]
совет. а попробуй инициализацию проводить на другой таблице
Хм, инциализацию данной таблицы проводить на другой таблице? Как ты себе это представляешь...
← →
Piter © (2004-12-18 20:39) [8]Sergey_Masloff (18.12.04 20:17) [6]
А не сборка ли энто мусора?
в смысле?
← →
DrPass © (2004-12-18 20:42) [9]Транзакции убирают мусор, который оставили их предшественники. Если до этого у тебя проводились масштабные операции удаления/обновления, сборка мусора займет заметное время.
← →
Sergey_Masloff (2004-12-18 20:47) [10]Piter © (18.12.04 20:39) [8]
>в смысле?
В прямом. Во время работы много DELETE и UPDATE?
Мое предположение такое (если тормоз на 1 выборке):
1) Во время работы программы идет много апдейтов и удалений
2) При каждом изменении-удалении IB создает "версии" записей. Рано или поздно версии становятся "мусором" и помечаются соответствующим флагом. При следующем обращении к записи IB видит последнюю и старые мусорные версии и удаляет мусор. Это занимает время.
Эксперимент:
1) СОздаешь таблицу с 100000 записей
2) Делаешь DELETE FROM YOURTABLE
3) Делаешь COMMIT
4) Делаешь SELECT COUNT(*) FROM YOURTABLE
5) Наслаждаешься наблюдением диких тормозов N времени при приличной загрузке процессора интербейзом.
← →
Sergey_Masloff (2004-12-18 20:49) [11]Ну в смысле 100000 тебя притормозит значительно дольше чем на 4 секунды, возможно успеешь кофе сходить попить ;-) А твои 5000 если из них апдейтилось процентов 30 пару-тройку секунд могут дать.
← →
Piter © (2004-12-18 22:47) [12]Piter © (18.12.04 18:50)
Правда, стоит заметить, что это только первый раз так долго. Потом такие выражения выполняются не более 100 мс, но все равно - загрузка программы происходит очень долго из-за этого
То есть, данная выборка делается в начале работы программы. И делается она очень долго почему-то.
А так как firebird embedded, то наверное никакого там мусора не остается.
Если закрыть программу, а потом опять открыть - то все будет быстро отрабатывать. Если перезагрузиться, то опять в первый раз будут тормоза.
P.S. Page Size = 4096, если это важно...
← →
DrPass © (2004-12-18 22:58) [13]Подозреваю, что проблема в таком случае кроется не в СУБД, а в операционке. Win9x?
Возможно, просто файл БД хочет дефрагментации. Попробуй сначала backup-restore, потом дефрагментацию
← →
Sergey_Masloff (2004-12-18 23:30) [14]Piter © (18.12.04 22:47) [12]
>То есть, данная выборка делается в начале работы программы. И >делается она очень долго почему-то.
Никакого противоречия. До закрытия программы у тебя висит заинтересованная транзакция и мусора нет. В момент закрытия происходит автокоммит и все ненужное становится мусором.
>А так как firebird embedded, то наверное никакого там мусора не >остается.
А что ембеддед запрещает параллельные транзакции одного приложения? И они механизм версионности переписали специально для emb? Сомневаюсь (уверен что это не так).
Вобщем, экспериментируй. Уверен что это именно выборка тормозит? Если сделаешь select first(1) from MyTable Where n=0 тормозит также? A select * from MyTable Where ID = 0? Если да то это не сборщик мусора а иначе проверяй дальше. Отключи допустим сборку мусора. Или перед запуском программы сделай базе бэкап-рестор. При этом гарантировано в базе мусора нет - те же тормоза?
← →
Nikolay M. © (2004-12-18 23:31) [15]А какие еще есть значения, кроме 0? Если только 0/1, то, конечно, индекс при выборке не будет использоваться, будет тупой scan table.
← →
Piter © (2004-12-19 00:36) [16]DrPass © (18.12.04 22:58) [13]
Win9x?
win2000
Возможно, просто файл БД хочет дефрагментации
а почему повторно запрос отрабатывает очень быстро, да и впоследствии все работает хорошо?
← →
Piter © (2004-12-19 00:48) [17]Sergey_Masloff (18.12.04 23:30) [14]
Никакого противоречия. До закрытия программы у тебя висит заинтересованная транзакция и мусора нет. В момент закрытия происходит автокоммит и все ненужное становится мусором
НУ хорошо, хорошо. А как ты объяснишь:
Piter © (18.12.04 22:47) [12]
Если закрыть программу, а потом опять открыть - то все будет быстро отрабатывать. Если перезагрузиться, то опять в первый раз будут тормоза.
Nikolay M. © (18.12.04 23:31) [15]
А какие еще есть значения, кроме 0?
0-15 где-то...
Если только 0/1, то, конечно, индекс при выборке не будет использоваться
а почему?
← →
SergP © (2004-12-19 01:50) [18]Хм... У меня с access"ом аналогичная ситуация...
Да и ранее наблюдал такое и с MySQL и с Oracle.
Первый запрос после подключения к базе всегда долго отрабатывается...
А что касается акцесса, то первый запуск проги долго отрабатывается (там призапуске идет подключение к базе и несколько запросов), при следующих запусках все сравнительно быстро. Но если почистить память, то следующий запуск снова долго происходит.
ИМХО то что в твоем случае - вполне нормально.
← →
Piter © (2004-12-19 03:20) [19]SergP © (19.12.04 1:50) [18]
Первый запрос после подключения к базе всегда долго отрабатывается
ну не 4 секунды же...
← →
Sergey_Masloff (2004-12-19 09:11) [20]Piter © (19.12.04 00:48) [17]
>НУ хорошо, хорошо. А как ты объяснишь:
>Piter © (18.12.04 22:47) [12]
>Если закрыть программу, а потом опять открыть
см. [14] 3 абзац. Если сделано то опиши результаты. Если нет то не вижу базы для дальнейших теоретических рассуждений. Причин может быть миллион и если просто в уме их перебирать - не хватит жизни. Знаешь же метод двоичного спуска? Так чтобы отсекать половинки нужны эксперименты, без этого никак.
← →
AlterEgo of WondeRu © (2004-12-19 13:13) [21]Piter © (18.12.04 20:38) [7]
Хм, инциализацию данной таблицы проводить на другой таблице? Как ты себе это представляешь...
у тебя данный запрос первый идет? или до него еще есть какие-либо запросы? как быстро они выполняются?
поробуй выполнить свой запрос в IBExpert"e
← →
Nikolay M. © (2004-12-19 14:02) [22]
> Piter © (19.12.04 00:48) [17]
> А какие еще есть значения, кроме 0?
>
> 0-15 где-то...
>
> Если только 0/1, то, конечно, индекс при выборке не будет
> использоваться
>
> а почему?
Тогда похоже на то. Посмотри план своего запроса, подозреваю, что индекс в нем не используется.
А как ты представляешь себе грамотную индексацию поля, в котором есть, скажем, только значения 0/1?
← →
Piter © (2004-12-19 14:56) [23]Nikolay M. © (19.12.04 14:02) [22]
Тогда похоже на то
что тогда похоже на то? :)
Я просто спросил - почему. Реально значения не только 0-1
А как ты представляешь себе грамотную индексацию поля, в котором есть, скажем, только значения 0/1?
а я вообще себе индексацию не представляю :(
или до него еще есть какие-либо запросы?
есть, но из других таблиц
← →
DrPass © (2004-12-19 14:59) [24]
> Возможно, просто файл БД хочет дефрагментации
>
> а почему повторно запрос отрабатывает очень быстро, да и
> впоследствии все работает хорошо?
Потому что кешируется операционкой. Подозреваю, что файл не слишком большой. Кроме того, 4700 записей - это ничтожный размер даже для тупого перебора без индексов, 4 сек. тут многовато
← →
Sergey_Masloff (2004-12-19 15:01) [25]Nikolay M. © (19.12.04 14:02) [22]
В таблице 4000 записей. Есть индекс, нет индекса, используется он или нет - на современном компьютере и интербейзе он все равно 4 секунды не будет выполняться.
← →
Anatoly Podgoretsky © (2004-12-19 15:05) [26]Памяти добавь, винчестера побыстрее.
Если хватает, то учти следующее, что в первый раз данные берутся из диска в кэш, п последующии операции уже из кэша.
Это при условии, что все остальное ты сделал правильно и все нам рассказал, в чем сомневаюсь, поскольку за тобой замечена выдача не полной информации по проблеме.
← →
Nikolay M. © (2004-12-19 15:06) [27]
> Sergey_Masloff (19.12.04 15:01) [25]
А где написано про современный компьютер? Атлон 1800? Дык может у автора памяти 64 и винт на 2?
Тут еще встречал советы по поводу расширения у файла БД - какие-то расширения винда считает своими (слышал звон...). Точнее не скажу, т.к. с ИБ не работаю.
← →
Sergey_Masloff (2004-12-19 15:12) [28]Nikolay M. © (19.12.04 15:06) [27]
>А где написано про современный компьютер?
Я имею в виду начиная с DX4-100 c 32Mb RAM.
У меня есть система работающая уже скоро 8 лет, из них 6 я к ней не прикасался. Сервер IBM PC/2 DX2-66 16 Mb RAM (вернее на моей памяти доставляли до 32 Mb) 6 пользователей в одноранговой сети. Таблица из 4000 записей - это семечки даже для такой "системы".
← →
Piter © (2004-12-19 15:34) [29]Итак, опыты провожу в IBConsole (ну нету у меня IBExpert и трафика нет, чтобы скачать):
1)SELECT count(n) FROM Tree WHERE n=3
Execution Time: 3:0297
Prepare Time: 0
Starting Memory: 9141244
Current Memory: 9180156
Delta Memory: 38912
Number of buffers: 2048
Reads: 752
Writes: 5
Plan: PLAN(TREE INDEX(TREE_ID))
Запрос вернул Count=2206
При повторном запуске числа практически теже, только:
Execution Time: 0:0016
2)select first(1) from Tree Where n=3
Token unknown - line 1, char 17
from
3)select * from Tree Where n=3
Execution Time: 0:0094
Prepare Time: 0:0031
Starting Memory: 9151480
Current Memory: 9195512
Delta Memory: 44032
Number of buffers: 2048
Reads: 74
Writes: 9
Plan: PLAN(TREE INDEX(TREE_ID))
Повторный запрос выполняется вообще за время ноль :)
Если послеselect * from Tree Where n=3
выполнитьSELECT count(n) FROM Tree WHERE n=3
- то последний все равно выполняется больше 3-х секунд.
← →
Nikolay M. © (2004-12-19 15:44) [30]
> PLAN(TREE INDEX(TREE_ID))
Какие поля входят в этот индекс? И как называется индекс по полю n? Не знаю точно, как это будет у ИБ, но, имхо, индекс по n тут не используется. ы?
Кстати, могу еще предположить, что у ИБ count() работает как-то хитро, попробуй удалить индекс на n и повторить эксперимент?
← →
Sergey_Masloff (2004-12-19 15:55) [31]Piter © (19.12.04 15:34) [29]
Да интересная ситуация. Уж и так и сяк гоняю никак больше 16 мс не могу заставить выполняться. Ни о каких секундах речи нет... :(
Ну еще напрягись сделай не count(n) a count(*) тем более в твоем контексте это одно и то же.
Ну а так все же может фича ембеддеда - ведь это dll-ка которая загружается только при запуске твоей программы. Ей свой кэш тоже надо распределять и так далее - может поэтому первый запрос с интенсивным подъемом страниц в память так тормозит?
← →
Sergey_Masloff (2004-12-19 15:56) [32]Nikolay M. © (19.12.04 15:44) [30]
>попробуй удалить индекс на n и повторить эксперимент?
Кстати очень хорошая мысль!
← →
Piter © (2004-12-19 16:02) [33]Anatoly Podgoretsky © (19.12.04 15:05) [26]
в чем сомневаюсь
извините, но можете сомневаться дальше
DrPass © (19.12.04 14:59) [24]
Подозреваю, что файл не слишком большой
28 Мб.
Nikolay M. © (19.12.04 15:06) [27]
Атлон 1800? Дык может у автора памяти 64 и винт на 2?
80 Gb барракуда + 256 Mb DDR 2100
Sergey_Masloff (19.12.04 15:12) [28]
Таблица из 4000 записей - это семечки даже для такой "системы".
Сергей, а вы учитываете что я говорю про ПЕРВЫЙ ЗАПУСК. У вас там думаю крутится сервер базы данных и крутится. Повторные запросы и у меня отрабатываются очень быстро. Можете посмотреть выше - я привел статистику. Но вот САМЫЙ ПЕРВЫЙ ЗАПРОС после перезагрузки - очень медленно работает.
Вы проведите эксперимент - вырубите базу данных на вашем DX2-66 сервере, перезагрузите компьютер, запустите сервер - и посмотрите сколько будет выполняться хотя бы первый count(*) по любой таблице, где записей хотя бы пару тысяч.
← →
Piter © (2004-12-19 16:04) [34]Nikolay M. © (19.12.04 15:44) [30]
Какие поля входят в этот индекс?
CREATE INDEX TREE_ID ON TREE (n)
Просто название неудачное, остался от прежнего:
CREATE INDEX TREE_ID ON TREE (n, ID);
← →
Piter © (2004-12-19 16:04) [35]Sergey_Masloff (19.12.04 15:55) [31]
Уж и так и сяк гоняю никак больше 16 мс не могу заставить выполняться
бли-и-ин. А вы перезагружались??!?!?!
← →
Nikolay M. © (2004-12-19 16:14) [36]
> CREATE INDEX TREE_ID ON TREE (n)
>
> Просто название неудачное, остался от прежнего:
>
> CREATE INDEX TREE_ID ON TREE (n, ID);
Тогда, скорее всего, остался мусор в страницах от предыдущего индекса. Удали и создай заново.
← →
Nikolay M. © (2004-12-19 16:16) [37]
> Sergey_Masloff (19.12.04 15:55) [31]
> Ну а так все же может фича ембеддеда - ведь это dll-ка которая
> загружается только при запуске твоей программы. Ей свой
> кэш тоже надо распределять и так далее - может поэтому первый
> запрос с интенсивным подъемом страниц в память так тормозит?
И из-за этого план запроса требует кол-во чтений на порядок больше, судя по [29]?
← →
Sergey_Masloff (2004-12-19 16:18) [38]Piter © (19.12.04 16:04) [35]
>бли-и-ин. А вы перезагружались??!?!?!
Да, и сервис перестартовывал и даже (хотя это уже не играет роли) компьютер перезагружал. Одно и то же.
← →
Sergey_Masloff (2004-12-19 16:20) [39]Ну вобщем COUNT(*) по 50 000 000 записей 52 секунды без индексов. После перезагрузки компьютера ;-)
← →
Piter © (2004-12-19 16:25) [40]Sergey_Masloff (19.12.04 15:55) [31]
ведь это dll-ка которая загружается только при запуске твоей программы. Ей свой кэш тоже надо распределять и так далее - может поэтому первый запрос с интенсивным подъемом страниц в память так тормозит
а серверу Interbase не надо в первый раз поднимать страницы в память?
К тому же - приведенные мной опыты я делал уже на сервере Firebird (использовал IBConsole) - никакой разницы между Embedded и сервером не замечено
Nikolay M. © (19.12.04 15:44) [30]
попробуй удалить индекс на n и повторить эксперимент?
Дропнул индекс по N. Запрос выполняется еще дольше:SELECT count(n) FROM Tree WHERE n=3
:
Execution Time: 4:0672 - время увеличилось
Prepare Time: 0:0000
Delta Memory: 6144 - маленькой какой-то стала
Number of buffers: 2048
Reads: 1118 - увеличилось
Writes: 6
Plan: PLAN(TREE NATURAL)
← →
Sergey_Masloff (2004-12-19 16:25) [41]Nikolay M. © (19.12.04 16:16) [37]
>И из-за этого план запроса требует кол-во чтений на порядок >больше
Упс... проглядел.
← →
Piter © (2004-12-19 16:28) [42]Nikolay M. © (19.12.04 16:14) [36]
Тогда, скорее всего, остался мусор в страницах от предыдущего индекса. Удали и создай заново.
нет! Не в этом дело...
Sergey_Masloff (19.12.04 16:18) [38]
>бли-и-ин. А вы перезагружались??!?!?!
Да, и сервис перестартовывал
как вас понимать?! Что значит "И"? Как можно перезагрузить сервер и в тоже время не перестартовать сервис IB?
Sergey_Masloff (19.12.04 16:18) [38]
(хотя это уже не играет роли) компьютер перезагружал
как это не играет? Я говорю, что именно после перезагрузки первый раз тормоза, а потом уже нормально - а вы говорите не играет роли!
Sergey_Masloff (19.12.04 16:20) [39]
Ну вобщем COUNT(*) по 50 000 000 записей 52 секунды без индексов. После перезагрузки компьютера ;-)
после перезагрузки какого компьютера? Сервера надеюсь?! Или вы клиента перегружаете?!?!?!?
← →
Sergey_Masloff (2004-12-19 16:32) [43]Piter © (19.12.04 16:25) [40]
>а серверу Interbase не надо в первый раз поднимать страницы в >память?
Надо но выделить под них место он может (и делает это) раньше - при старте.
Но неважно - сам говоришь не влияет.
Честно говоря- заинтриговал. Уже по свякому перепробовал - ну никак не влияет на результат и перегрузки компьютера, и индекс ненужный создавал, и дропал его - ну никак никакого торможения не добъюсь. Все эксперименты на таблице 6500 записей - подобрал максимально похожую.
← →
Piter © (2004-12-19 16:33) [44]А вот на SQL.ru - хотя Николай и говорил, что там просто фантастический уровень находящегося там народа так вообще ничего путного не сказали - http://www.sql.ru/forum/actualthread.aspx?bid=2&tid=146762&pg=-1
← →
Piter © (2004-12-19 16:35) [45]Sergey_Masloff (19.12.04 16:32) [43]
ну никак не влияет на результат и перегрузки компьютера
какого компьютера? Сервера?
Sergey_Masloff (19.12.04 16:32) [43]
Надо но выделить под них место он может (и делает это) раньше - при старте
как при старте? Имхо, при старте IB сервер вообще к таблицам не обращается. Запускается он мгновенно. И только при первом запросе из таблицы начинает ее читать. имхо.
← →
sniknik © (2004-12-19 16:38) [46]еще пара предположений (вернее одно ;) но разные причины)
1 файл на изменениях кэшируется системой (полностью копируется весь *.gdb), в какойто из виндов такое есть, поищи на http://ibase.ru (помню чтото такое читал, не помню где. главное зависит от расширения, если поменять на *.fdb (так вроде? для фаребирда) или из системы каширований прежнее удалить, то проходит)
2 файл базы блокируется антивирусом при первом обращении (открытии).
в обшем неважно чем но блокировка, и от файрбирда она не зависит...
← →
sniknik © (2004-12-19 16:41) [47]впрочем, у меня антивирус стоит и никаких задержек с тем же фаребирдом...
может всетаки код виноват?
выслать тестовую прогу? провериш в ней, если будет тоже самое... ну в общем любой результат показатель.
← →
Sergey_Masloff (2004-12-19 16:46) [48]Piter © (19.12.04 16:35) [45]
>какого компьютера? Сервера?
Уже хотел ругаться что ответы не читаешь но понял что из-за глюков сервера мое огромное сообщение сюда не попало.
Придется заново. Но кратко :(
Сервер и клиент у меня один физический компьютер. После перегрузки СЕРВИСА IB его (а не операционки) кэш не существует как класс поэтому дальнейшие перезагрузки СЕРВЕРА по идее безразличны. В качестве эксперимента производилось и то и другое - то есть перестарт службы и перестарт компьютера на котором она запущена (а заодно и клиент). Все без разницы - результаты абсолютно одинаковые
>как при старте? Имхо, при старте IB сервер вообще к таблицам не >обращается. Запускается он мгновенно. И только при первом >запросе из таблицы начинает ее читать. имхо.
При старте сервер выделяет немного памяти под эти страницы. Конечно к базе он не обращается - он же не знает с какой базой будут работать клиенты. Хотя скорее вего не выделяет а просто резервирует так что на скорость это влиять не должно...
← →
Sergey_Masloff (2004-12-19 16:48) [49]sniknik © (19.12.04 16:38) [46]
>1 файл на изменениях кэшируется системой (полностью копируется >весь *.gdb),
Это в XP только. Я сначала тоже подумал но у Питера 2000.
← →
Nikolay M. © (2004-12-19 16:50) [50]
> sniknik © (19.12.04 16:38) [46]
Я это уже в [27] предлагал...
> Piter © (19.12.04 16:28) [42]
> Nikolay M. © (19.12.04 16:14) [36]
> Тогда, скорее всего, остался мусор в страницах от предыдущего
> индекса. Удали и создай заново.
>
> нет! Не в этом дело...
А сделать базе сжатие-восстановление, если такое есть у ИБ? Или нет, сначала рядом завести тестовую таблицу аналогичной структуры и залить туда все данные из таблички? Если не поможет, создать новую базу. ы?
← →
Anatoly Podgoretsky © (2004-12-19 17:03) [51]Piter © (19.12.04 16:02) [33]
А чего тут сомневаться, вот сейчас по немногу начинаешь рассказывать подробности и то по немногу.
Например до сих пор неизвестно имя файла сервера, например .fdb это одно, а .gdb совсем другое тут и система восстонавления может оказаться задействованой.
Например использование памяти в первом приближении можно посмотреть с помощью диспетчера задач, до запуска, дп первого запроса и после, после второго запроса и так далее. Эту информацию по использованию памяти ты не давал, и очень долго пришлось ждать прежде чем ты выдал информацию по объему памяти и винчестерам, а это все важная информация, которая может помочь в диагнозе.
По внешнем признакам или это кэш, или антивирус первый раз проверяет или система восстановления.
← →
Anatoly Podgoretsky © (2004-12-19 17:07) [52]Piter © (19.12.04 16:33) [44]
На sql.ru хорошии специалисты, но по MS SQL
а по интербейсу и клонам лучшии на ibase.ru, но и там тоже будут гадать при такой подаче материала, хотя может быть и догадаются, попробовать то стоит?
← →
Piter © (2004-12-19 18:55) [53]Антивируса (монитора) - нет
sniknik © (19.12.04 16:41) [47]
может всетаки код виноват?
какой код? :)
Я эксперименты проводил в IBConsole - выполнял выборки. Какой тут код?
Sergey_Masloff (19.12.04 16:46) [48]
Уже хотел ругаться что ответы не читаешь но понял что из-за глюков сервера мое огромное сообщение сюда не попало
используй мой клиент Magic Forum :)
Тогда твои посты пропадать не будут.
Sergey_Masloff (19.12.04 16:46) [48]
Сервер и клиент у меня один физический компьютер
хорошо. У меня тоже
Sergey_Masloff (19.12.04 16:46) [48]
После перегрузки СЕРВИСА IB его (а не операционки) кэш не существует как класс поэтому дальнейшие перезагрузки СЕРВЕРА по идее безразличны
Сергей! Ну что значит безразличны? Я ведь который пост говорю, что РАЗЛИЧНЫ!
Если компьютер не перезагружать - то вторичная выборка происходит за миллисекунды! При этом можно стартовать сервис IB, можно отключать его.
И с FB Embedded тоже само! По идее, он ведь при запуске каждый раз стартует? Ан нет, при повторном запуске программы все отлично, работает быстро. Тут видимо, кеширование операционки сказывается.
И только после перезагрузки в первый раз опять все медленно. Или можно не после перезагрузки - а например после интенсивной игры в какой-нибудь Call Of Duty. Тогда после выхода из игры опять выборка будет медленной в первый раз (видимо, ОС из-за игры убирает из кеша данные сервера).
Я когда проводил опыты - КАЖДЫЙ РАЗ ПЕРЕГРУЖАЛСЯ. Иначе экспериментировать не имеет смысла - время выборки при вторичных запросах очень маленькое. При этом можно хоть перегружать IB сервис, хоть нет. Да и вообще, это ведь справедливо и для FB Embedded, а там ведь при каждом запуске программы серверкак бы перезагружается.
В общем, похожая тема есть здесь - http://www.sql.ru/forum/actualthread.aspx?bid=2&tid=144344&pg=1
Nikolay M. © (19.12.04 16:50) [50]
А сделать базе сжатие-восстановление, если такое есть у ИБ?
Backup-Restore что ли? Есть такое у FB...
Sergey_Masloff (19.12.04 16:48) [49]
предлагаю провести эксперимент. Итак, делаем новую таблицу:Create Table TestTable ( n integer not null, TestI integer not null, TestI2 integer not null, TestBlob blob not null, TestDE DOUBLE PRECISION not null, TestSI smallint, TestVC varchar(100), TestVC2 varchar (50) )
Заполняем ее рандомными значениями. Я написал программу, вот ее исходники:
http://www.newmail.ru/messages/file.dhtml?file=www.piter007.newmail.ru/other/test_fill.zip
Листинг:function RandomString(MaxCount: integer): string;
var
i: integer;
begin
Randomize;
SetLength( Result, Random(MaxCount) + 1 );
for i := 1 to Length(Result) do
Result[i] := chr( Random(30) + 60 ) ;
end;
procedure TForm1.Button1Click(Sender: TObject);
var
i: integer;
begin
IBDatabase1.DatabaseName := EditBaseName.Text ;
IBDatabase1.Open ;
with IBQuery1 do
begin
SQL.Clear ;
SQL.Add( "INSERT INTO " + EditTableName.Text
+ " (n, TestI, TestI2, TestBlob, TestDE, TestSI, TestVC, TestVC2) VALUES"
+ " (:pn, :pTestI, :pTestI2, :pTestBlob, :PTestDE, :pTestSI, :pTestVC, :pTestVC2)" );
Randomize ;
for i := 1 to StrToInt( EditInsertCount.Text ) do
begin
ParamByName("pn").AsInteger := Random(4);
ParamByName("pTestI").AsInteger := Random(999999);
ParamByName("pTestI2").AsInteger := Random(50);
ParamByName("pTestBlob").AsBlob := RandomString(700);
ParamByName("pTestDE").AsInteger := Random(9999999);
ParamByName("pTestSI").AsInteger := Random(100);
ParamByName("pTestVC").AsString := RandomString(90);
ParamByName("pTestVC2").AsString := RandomString(40);
ExecSQL ;
end;
IBTransaction1.Commit ;
end;
end;
После заполнения таблицы 10000 записями - ПЕРЕЗАГРУЖАЕМ компьютер-сервер.
После чего, у меня выполнениеSELECT Count(n) FROM TestTable WHERE n=3
происходит чуть более секунды.
И это немного странно. С одной стороны, это явно меньше 3-4-х секунд в моем реальном примере, а с другой стороны здесь и общее, и при условии n=3 число записей больше. Число записей больше, а отрабатывает быстрее...
Новую таблицу я создавал прямо в своей реальной рабочей базе.
Но зато в реальной таблице число полей больше - может, в этом дело? Интересно...
← →
Piter © (2004-12-19 18:59) [54]Anatoly Podgoretsky © (19.12.04 17:03) [51]
вот сейчас по немногу начинаешь рассказывать подробности и то по немногу
я рассказал все, что считал нужным. Откуда я знаю что рассказывать? Может быть, имеет значение положение каталога с windows? Откуда я знаю? Вы справшивайте - я отвечаю.
Anatoly Podgoretsky © (19.12.04 17:03) [51]
Например до сих пор неизвестно имя файла сервера, например .fdb это одно, а .gdb
.gdb
Anatoly Podgoretsky © (19.12.04 17:03) [51]
тут и система восстонавления может оказаться задействованой.
в win2000?
Anatoly Podgoretsky © (19.12.04 17:03) [51]
По внешнем признакам или это кэш, или антивирус первый раз проверяет или система восстановления.
как я понял, это будет наблюдаться у любых систем. Можете проверить - тестовый пример я выложил.
← →
Sergey_Masloff (2004-12-19 21:12) [55]Piter © (19.12.04 18:55) [53]
Частично мне удалось повторить твой эксперимент. После перезагрузки компьютера первая выборка из твоей таблицы идет медленнее - почти в 6 раз но конечно даже о секунде речи не идет:
------ Performance info ------
Prepare time = 0ms
Execute time = 94ms
Avg fetch time = 94.00 ms
Current memory = 669 216
Max memory = 701 848
Memory buffers = 2 048
Reads from disk to cache = 848
Writes from cache to disk = 6
Fetches from cache = 15 431
В таблице 6500 записей сейчас проверяю одну идею.
← →
Anatoly Podgoretsky © (2004-12-19 21:19) [56]Piter © (19.12.04 18:59) [54]
Вы справшивайте - я отвечаю.
Это твоя задача задавать вопросы :-)
.gdb
В этом и может быть проблема, по рекомендация от производителей серверов этого типа, рекомендуется сменить расширение на .fdb, поскольку может быть снижение производительности именно того типа, которое ты и описываешь. Файлы .gdb являются системными и поэтому система их может (с делает) сохранять для восстановления.
в win2000?
Я не знаю если в в win2000 система восстановления или нет, но она есть даже на WinMe.
← →
Sergey_Masloff (2004-12-19 21:21) [57]Piter © (19.12.04 18:55) [53]
>предлагаю провести эксперимент. Итак, делаем новую таблицу:
Секундочку! У тебя что Primary Key в таблице нет? И в той на которой экспериментируешь ты - тоже? ;-)
Отвечай срочно ;-)
← →
AlterEgo of WondeRu © (2004-12-19 23:47) [58]Sergey_Masloff (19.12.04 21:21) [57]
Отвечай срочно ;-)
отвечу за него: нет!!! причем PK нет ни в одной таблице его базы!
← →
Piter © (2004-12-20 00:15) [59]Anatoly Podgoretsky © (19.12.04 21:19) [56]
не знаю если в в win2000 система восстановления или нет
по-моему, нет
Sergey_Masloff (19.12.04 21:21) [57]
У тебя что Primary Key в таблице нет? И в той на которой экспериментируешь ты - тоже?
видимо, нету :( Я привел SQL выражения для создания чистой таблицы. Привел программу заполнения этой таблицы. Больше ничего не делал...
А-а-а, чувствую меня сейчас будут бить... ногами...
Sergey_Masloff (19.12.04 21:12) [55]
но конечно даже о секунде речи не идет
а ты count делал? Или просто выборку select * ?
А то просто второй вариант и у меня быстро отрабатывает. А вот count...
← →
AlterEgo of WondeRu © (2004-12-20 00:25) [60]Piter © (20.12.04 0:15) [59]
а ты count делал? Или просто выборку select * ?
А то просто второй вариант и у меня быстро отрабатывает. А вот count...
чего голову морочишь? делай просто селект и проверяй Query1.RecordCount! и делай PK!
← →
Anatoly Podgoretsky © (2004-12-20 00:43) [61]Piter © (20.12.04 00:15) [59]
Срочно убегай :-)
← →
Anatoly Podgoretsky © (2004-12-20 00:47) [62]Кстати для подоьного запроса сервер может посчитать необходимым построить временный индекс или что ни будь другое сделать.
SELECT Count(n) From MyTable Where n=0
← →
sniknik © (2004-12-20 01:12) [63]> А то просто второй вариант и у меня быстро отрабатывает. А вот count...
странно, у меня count работает на порядок быстрее чем полный селект. (так и должно в приципе)
задержка на первом есть, но не 4 сек, это точно... повторил предложенный код (чуть переделал под ADO. привычнее)
первый запуск предложенного селекта с count(*) около сек. (0,73 показало) второй 0,06.
в принципе логично, у меня не сервер, embeded, значит время на подгрузку dll, чтение страниц базы. нормально в общем...
при добавленом индексе время меньше но не намного, гдето 0,6 и 0,04 (всетаки влияет)
а вот простой селект с выборкой всех записей гдето 4 сек и даже немного больше получается (с ограничением n=3 0.66)
кстати интересно если сделать такую же таблицу в другой базе, и по ходу переключится с базы на базу то время первого селекта на ней сокращается с 0,6 (это уже с индексом) до 0,4сек. (меньше на время подгрузки dll ?)
← →
Sergey_Masloff (2004-12-20 08:28) [64]Anatoly Podgoretsky © (20.12.04 00:47) [62]
>Кстати для подоьного запроса сервер может посчитать необходимым >построить временный индекс или что ни будь другое сделать.
Да временный индекс строится (потому что если в такую таблицу, уже заполненую, добавлять полный дубликат записи она скажет - как минимум одна запись с такими полями есть. И скажет не задумываясь). Правда мне не хватает знаний чтобы понять как этот индекс может оставаться доступным после перестарта сервиса IB и использующего его приложения. Нет, что страницы в кеше ОС невытеснены это понятно. Но что они доступны приложению...
← →
ЗВМ (2004-12-20 08:57) [65]А ты пускай выборку в потоке, программа запуститься сразу. А эти 4 секунды показывай заставку :)). Это на тот случай если ты не решишь данную проблему :)
← →
Sergey_Masloff (2004-12-20 09:19) [66]Итак предварительное резюме.
testtable
testtable2
две одинаковые по структуре таблицы (то что привел Piter и добавлено поле ID заполненое уникальными значениями). В таблице testtable2 объявлен первичный ключ по полю ID. Больше НИЧЕМ таблицы не отличаются.
Результаты ПЕРВОГО селекта после перестарта КОМПЬЮТЕРА
TESTTABLE2
Plan
PLAN (TESTTABLE2 NATURAL)
Adapted Plan
PLAN (TESTTABLE2 NATURAL)
------ Performance info ------
Prepare time = 0ms
Execute time = 68ms
Avg fetch time = 68.00 ms
Current memory = 674 260
Max memory = 758 924
Memory buffers = 2 048
Reads from disk to cache = 944
Writes from cache to disk = 6
Fetches from cache = 15 586
Таблица без ПК (в 2 раза дольше)
Plan
PLAN (TESTTABLE NATURAL)
Adapted Plan
PLAN (TESTTABLE NATURAL)
------ Performance info ------
Prepare time = 0ms
Execute time = 125ms
Avg fetch time = 125.00 ms
Current memory = 674 448
Max memory = 758 924
Memory buffers = 2 048
Reads from disk to cache = 920
Writes from cache to disk = 6
Fetches from cache = 16 359
То есть 3 секунды все равно не получаем то таблица с PK все равно стабильно обрабатывается БЫСТРЕЕ. Причем статистика примерно одинаковая так что потери времени скорее всего не на запросе а именно на чем-то типа построения индекса.
← →
Sergey_Masloff (2004-12-20 09:28) [67]Да результат воспроизводимый - с PK всегда ощутимо быстрее при похожей статистике.
← →
jack128 © (2004-12-20 11:48) [68]Нефига не понимаю. PLAN (TESTTABLE2 NATURAL) С какого боку тут влияет наличие или отсутствие ПК?
← →
Anatoly Podgoretsky © (2004-12-20 11:50) [69]jack128 © (20.12.04 11:48) [68]
Почему бы и нет, ведь идентифицировать записи как то нужно, а его нетути.
← →
Nexel (2004-12-20 12:01) [70]Тэкс есть у меня инфа но это только для BDE! Вообщето когда работаем через жоп.. простите BDE то вначале (при ПЕРВОМ обращении) опрашивается структура и прочая "нужная" информация и кешируется далее пока TDatabase.Connected:=True то обращение идет просто мгновенно, чтобы юзать этот кэш повторно нужно в жоп... простите BDE указать следующее
SHEMA CACHE=True
CACHE DIR=Bla..bla..bla...
НО ПРИ ЛЮБОМ ИЗМЕНЕНИИ СТРУКУРЫ ТАБЛИЦ ВСЕ СОДЕРЖИМОЕ CACHE DIR надо удалять к ЕДРЕНИ ФЕНИ!
← →
Sergey_Masloff (2004-12-20 15:51) [71]jack128 © (20.12.04 11:48) [68]
>Нефига не понимаю. PLAN (
Нам надо перебрать всю таблицу. Ее записи разбросаны по разным (непоследовательным) страницам IB. Теоретически серверу нужно было бы перебрать ВСЕ страницы данных и смотреть по каждой записи не из нужной ли она таблицы. Это небыстро если в базе не одна таблица.
Поэтому NATURAL это проход по индексу первичного ключа с последующими быстрыми обращениями к уже известным страницам данных с нужными записями.
Так как тут ПК нет IB наверняка сроит индекс и боюсь что по всем полям сразу что конечно тоже скорости не добавляет. Конечно на 100% я это не знаю но предположение это с высокой степенью достоверности.
Кстати смотри - у Piter база около 25 мег у меня едва 3 (тольк тестовые таблицы в основном). У него первая выборка 3-4 секунды у меня гораздо меньше но все же больше последующих. Тоже ведь укладывается в теорию.
← →
msguns © (2004-12-20 16:30) [72]Вопрос к Piter: а что там у нас с антивирусниками ? Какой (какие) стоЯт ?
У меня стоИт Касперский. Так к тормозам при первом обращении к серверу я привык в общем-то..;(
← →
Alexander Panov © (2004-12-20 16:52) [73]Не хотел говорить свое мнение, но думаю, что здесь не последнюю роль играет системный файловый кэш.
При первом чтении начитывается в кэш - поэтому долго.
При следующих обращениях работа идет уже с данными в памяти+отложенная запись на диск.
Это же может происходить при
Piter © (19.12.04 18:55) [53]
...И только после перезагрузки в первый раз опять все медленно. Или можно не после перезагрузки - а например после интенсивной игры в какой-нибудь Call Of Duty. Тогда после выхода из игры опять выборка будет медленной в первый раз (видимо, ОС из-за игры убирает из кеша данные сервера)...
Мое мнение такое...
← →
Sergey_Masloff (2004-12-20 17:03) [74]Alexander Panov © (20.12.04 16:52) [73]
>Не хотел говорить свое мнение, но думаю, что здесь не последнюю >роль играет системный файловый кэш.
Возможно, но тут вопрос почему такое поведение не удается повторить на других машинах? Файловый кэш ИМХО примерно одинаково работает везде. Заявляемых пациентом ;-) 3-4 секунд повторить не удалось. Причем не поднимается же весь файл в кеш - только определенные страницы. А вот почему при такой же таблице у Piter нужно больше страниц в памяти - мы и обсуждаем.
Сам Piter молчит. Заведение PK помогло или нет - вот в чем вопрос! ;-)
← →
Alexander Panov © (2004-12-20 19:26) [75]Sergey_Masloff (20.12.04 17:03) [74]
Файловый кэш ИМХО примерно одинаково работает везде.
В разных системах по-разному, все-таки.
Еще надо учесть наличие других работающих программ в данный момент, использование ими памяти. от настроек системы тоже зависит.
Т.е. в точности повторить эксперимент не удастся.
Если только на голой системе.
← →
Piter © (2004-12-20 20:07) [76]AlterEgo of WondeRu © (20.12.04 0:25) [60]
чего голову морочишь? делай просто селект и проверяй Query1.RecordCount!
типа это быстрей отработает? Фигня, не может быть такого...
← →
AlterEgo of WondeRu © (2004-12-20 20:22) [77]Piter © (20.12.04 20:07) [76]
типа это быстрей отработает? Фигня, не может быть такого...
не я же сказал: "А то просто второй вариант и у меня быстро отрабатывает. А вот count...
"
← →
Sergey_Masloff (2004-12-20 20:56) [78]Piter ©
Создать первичный ключ пробовал? Как результат?
← →
Anatoly Podgoretsky © (2004-12-20 21:04) [79]Допрос продолжается :-)
← →
Piter © (2004-12-20 21:08) [80]sniknik © (20.12.04 1:12) [63]
задержка на первом есть, но не 4 сек, это точно
ну на тестовой таблице у меня тоже не 4 секунды, а меньше, около секунды. На реальной 4 секунды, но там полей больше.
sniknik © (20.12.04 1:12) [63]
первый запуск предложенного селекта с count(*) около сек. (0,73 показало) второй 0,06.
и у меня тоже самое. Только не 0,73 - а ближе к секунде
при добавленом индексе время меньше но не намного
аналогично
Sergey_Masloff (20.12.04 9:19) [66]
Prepare time = 0ms
Execute time = 125ms
даже учитывая, что таблицы без ПК - поразительные результаты... Может, у тебя таблица не как у меня? Сделай таблицу точно такой структуры как я написал. И заполни ее 10.000 записями по алгоритму программы, которую я выложил.
Sergey_Masloff (20.12.04 17:03) [74]
Возможно, но тут вопрос почему такое поведение не удается повторить на других машинах?
почему же? У Sniknik очень похожие результаты. А вот твои результаты мне нравятся гораздо больше, если бы у меня так было... но мне просто кажется, что ты экспериментируешь на другой таблице, более простой для подсчета. Попробуй таблицу, которую использовал Sniknik и я.
Alexander Panov © (20.12.04 16:52) [73]
При первом чтении начитывается в кэш - поэтому долго.
При следующих обращениях работа идет уже с данными в памяти+отложенная запись на диск
несомненно. Вопрос в другом - почему первый раз так долго?
sniknik © (20.12.04 1:12) [63]
странно, у меня count работает на порядок быстрее чем полный селект. (так и должно в приципе)
а попробуй еще раз - мне кажется ты ошибся. Ибо даже на SQL.ru писали, что count(*) поднимает всю таблицу и кеширует ее.
По крайней мере, у меня первый count(*) на тестовой таблице длится секунду. На реально - четыре секунды.
А вот SELECT * происходит практически мгновенно.
← →
Piter © (2004-12-20 21:16) [81]Sergey_Masloff (20.12.04 20:56) [78]
Создать первичный ключ пробовал? Как результат?
да, создавал. Ускорение, конечно, есть, но хочется еще быстрее...
А можно как-нибудь добавить к существующей базе поле с Primary Key?
Неужели придется переносить записи...
← →
Sergey_Masloff (2004-12-20 21:19) [82]Piter © (20.12.04 21:08) [80]
>Попробуй таблицу, которую использовал Sniknik и я.
Мои сообщения Sergey_Masloff (20.12.04 09:19) [66]
относятся К ТВОЕЙ структуре таблицы. В одном случае я добавил к ней еще одно поле и заполнил его уникальными значениями пометив как PK. В таблице 6700 записей, до 10 тыс могу конечно набросить но сначала
СДЕЛАЙ PK И НАПИШИ РЕЗУЛЬТАТ ТЕСТА!!!! ;-)))
← →
AlterEgo of WondeRu © (2004-12-20 21:21) [83]Piter © (20.12.04 21:08) [80]
А вот SELECT * происходит практически мгновенно.
это первый селект из таблицы?
← →
AlterEgo of WondeRu © (2004-12-20 21:24) [84]Anatoly Podgoretsky © (20.12.04 21:04) [79]
теперь я допрашиваю)
← →
Sergey_Masloff (2004-12-20 21:26) [85]Когда писал не видел
Piter © (20.12.04 21:16) [81]
К существующей базе добавить можно но чревато опасностями. Прще так: берешь скрипт таблицы и создаешь вторую такую же по структуре.
1) Делаешь INSERT INTO TABLE2 SELECT * FROM TABLE
2) Делаешь DELETE FROM TABLE
3) Добавляешь 1 поле ID INTEGER NOT NULL
4) Добавляешь триггер бифор инсерт
IF (NEW.ID IS NULL) THEN NEW.ID = GEN_ID(YOURGENERATORNAME,1);
5) Объявляешь PRIMARY KEY(ID);
6) Делаешь INSERT INTO TABLE(FIELD1,...FIELDN)
SELECT FIELD1,...FIELDN FROM TABLE2
7) Делаешь DROP TABLE2
Все в твоей TABLE есть ПК.
← →
Sergey_Masloff (2004-12-20 21:29) [86]Стоп... у тебя есть BLOB-ы. Не катит
Тогда так: добавляешь поле, заполняешь уникальными значениями, делаешь по нему уникальный индекс, делаешь поле NOT NULL поправляя запись домена и потом объявляешь что это поле PK. Должно прокатить.
← →
Piter © (2004-12-20 22:59) [87]AlterEgo of WondeRu © (20.12.04 21:21) [83]
это первый селект из таблицы?
естественно! Я что, такой дурак, чтобы всем талдычить про первый запуск, а самому делать по другому?
Более того, я это уже писал в самом начале, так что вместо того, чтобы допрашивать можно хотя бы чуть чуть почитать, что я пишу. Я писал, что SELECT * выполняется очень быстро. И если даже выполнить Count * ПОСЛЕ Select * - то все равно 4 секунды...
У вас не так?
Sergey_Masloff (20.12.04 21:29) [86]
поле NOT NULL поправляя запись домена
а в этом месте можно поподробнее?
Sergey_Masloff (20.12.04 21:29) [86]
и потом объявляешь что это поле PK
а как объявить существующие поле, что оно PK?
← →
AlterEgo of WondeRu © (2004-12-20 23:39) [88]Piter © (20.12.04 22:59) [87]
Более того, я это уже писал в самом начале, так что вместо того, чтобы допрашивать можно хотя бы чуть чуть почитать, что я пишу. Я писал, что SELECT * выполняется очень быстро. И если даже выполнить Count * ПОСЛЕ Select * - то все равно 4 секунды...
У вас не так?
как ни странно... читал каждый пост!
может я не понимаю тебя, но не нада искать причину, делай так как работает!
нефиг делать count(*), делай select * from answers where n=0, а затем в Query (если конечно его используешь) проверяй свойство RecordCount!!!
← →
AlterEgo of WondeRu © (2004-12-20 23:47) [89]AlterEgo of WondeRu © (20.12.04 23:39) [88]
with Query2 do
begin
Close;
SQL.Clear;
SQL.Add("select * from answers where n=0");
Open;
RCount := RecordCount; //то что нада
end;
← →
Piter © (2004-12-21 00:11) [90]AlterEgo of WondeRu © (20.12.04 23:47) [89]
with Query2 do
begin
Close;
SQL.Clear;
SQL.Add("select * from answers where n=0");
Open;
RCount := RecordCount; //то что нада
end;
и типа сам то как думаешь - какой ответ получится если проверять RecordCount?
← →
AlterEgo of WondeRu © (2004-12-21 00:17) [91]Piter © (21.12.04 0:11) [90]
какой ответ получится если проверять RecordCount?
думаю тоже самое что и при count(*)! или я не прав?
← →
AlterEgo of WondeRu © (2004-12-21 00:22) [92]попробуй... хотя справка говорит:
Generally, an application should only use RecordCount with Paradox and dBASE tables.
← →
Piter © (2004-12-21 00:39) [93]AlterEgo of WondeRu © (21.12.04 0:17) [91]
или я не прав?
не прав
← →
Piter © (2004-12-21 00:40) [94]она у тебя ноль выдаст
← →
WondeRu © (2004-12-21 09:00) [95]Piter © (21.12.04 0:40) [94]
она у тебя ноль выдаст
ты пробовал?????
← →
WondeRu © (2004-12-21 09:00) [96]Piter © (21.12.04 0:40) [94]
она у тебя ноль выдаст
ты пробовал?????
← →
jack128 © (2004-12-21 11:13) [97]WondeRu © (21.12.04 9:00) [96]
для IBX RecordCount - это кол-во отфетчиных записей. Для коректной работы нужно в [89] после Open добавить FetchAll. Только вот бредовый это способ...
← →
WondeRu © (2004-12-21 11:27) [98]jack128 © (21.12.04 11:13) [97]
Только вот бредовый это способ...
если он быстрее будет работать, тогда чего мучаться??
← →
sniknik © (2004-12-21 11:49) [99]> а попробуй еще раз - мне кажется ты ошибся. Ибо даже на SQL.ru писали, что count(*) поднимает всю таблицу и кеширует ее.
сколько ж еще пробовать? ;о) я себе доверяю. хотя проверил еще раз, на работе. то же самое (методов не менял)
зависит от компонентов/движка? я же писал использовал ADO для теста.
может я тебе всетаки вышлю прогу (если адрес даш ;)
надо будет скачать OLEDB провайдера (установка элементарная, регистрация dll там bat файл есть для этого)
http://zstyle.dp.ua/rus/iboledb_prod.htm
строка подключения будет примерно такая
Provider=IBOLE.Provider.v4;Password=masterkey;Persist Security Info=True;Data Source=D:\CONMAN.GDB
и вот на нем и пробуй с count(*) и простой запрос. все адекватно работает (небольшая задержка тоже понятна, в прежнем посте писал предполагаемые причины, непонятна была большая задержка).
(здесь я просто представляю как все работает, а в твоих компонентах х.з. ощущение такое что у тебя для каунта действительно полная выборка используется и проверка recordcount а вот простой селект открывается с серверным курсором... вот кстати проверь, померь время не после Query.Open; а после Query.Open; Query.Last; (закачки на клиента))
← →
Zacho © (2004-12-21 11:53) [100]WondeRu © (21.12.04 11:27) [98]
Не будет он быстрее работать. Ну, разве что, в каких-либо совсем экзотических случаях.
Кстати, я регулярно использую FetchAll и RecordCount для отчетов. Все равно весь резалтсет фетчить, так заче ещё один запрос ?
← →
Anatoly Podgoretsky © (2004-12-21 13:13) [101]Имено так, плюс сумма выполнения обеих запросов, плюс возможное расхождения количества, по первому и второму запросу (для embeded неважно). И насчет скорости select я думаю тоже лукавит, наверняка серверный курсор и эта скорость только скорость выборки очень небольшой части данных, а не всего запроса.
← →
Piter © (2004-12-21 21:42) [102]Anatoly Podgoretsky © (21.12.04 13:13) [101]
И насчет скорости select я думаю тоже лукавит, наверняка серверный курсор и эта скорость только скорость выборки очень небольшой части данных
вполне может быть. Я четко писал что делал - выполнял выражение "SELECT * FROM TestTable" из IBConsole и приводил его статистику.
← →
Piter © (2005-01-03 15:43) [103]up
← →
DrPass © (2005-01-03 19:32) [104]Ты все ж таки попробуй поработать с файловой системой - сперва выполни дефрагментацию диска, на котором лежит база, а после этого - backup-restore самой базы.
← →
Zacho © (2005-01-03 21:05) [105]Piter © (03.01.05 15:43) [103]
И ащё - ПК сделай наконец, да ?
Sorry, Миша, пьян я счас...
А воообще, зачем up ? Усё уже разжевали...
← →
Sergey_Masloff (2005-01-03 21:07) [106]Zacho © (03.01.05 21:05) [105]
>И ащё - ПК сделай наконец, да ?
Уже сделал он же ж ;-). Ускорение было но недостаточное. Хотя в цифрах бы... Желательно на таблице тысяч 500 записей.
← →
Zacho © (2005-01-03 21:35) [107]Sergey_Masloff (03.01.05 21:07) [106]
Я действительно счас пьян, но как не пытался, такого получить не смог. И в трезвом виде тоже не смог :)
← →
Sergey_Masloff (2005-01-03 21:56) [108]Zacho © (03.01.05 21:35) [107]
>И в трезвом виде тоже не смог :)
Я тоже не смог хотя вообще практически не пью. Но пациент упорствует в ереси. Может какой-то редкий случай?
← →
Zacho © (2005-01-03 22:13) [109]Sergey_Masloff (03.01.05 21:56) [108]
Мне это тоже крайне любопытно :)
← →
DrPass © (2005-01-04 00:19) [110]Если бы оный пациент покромсал свою прогу и базу, да выложил ее для тестов, все бы решилось в момент. А вообще - побить его да выгнать, дабы не мешал людям новогодние праздники ощущать
Страницы: 1 2 3 вся ветка
Форум: "Базы";
Текущий архив: 2005.02.06;
Скачать: [xml.tar.bz2];
Память: 0.81 MB
Время: 0.041 c