|
Действия ...
|
15.09.2005, 10:25:30
|
|||
|---|---|---|---|
|
|||
Fox + Oracle SQL server |
|||
|
|
|
15.09.2005, 10:28:06
|
|||
|---|---|---|---|
|
|||
Fox + Oracle SQL server |
|||
|
|
|
15.09.2005, 12:02:19
|
|||
|---|---|---|---|
|
|||
Fox + Oracle SQL server |
|||
|
|
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
14.09.2005, 09:29:50
|
|||
|---|---|---|---|
|
|||
Fox + Oracle SQL server |
|||
|
#18+
делаю связкеу фокса с Оракловым СКЛ но почему-то тормозит. на данном форуме прочел, что соединения держать долго нельзя поэтому сделал "короткие" соединения gnConnHandle = SQLCONNECT('bla','bla','bla') IF gnConnHandle <= 0 = MESSAGEBOX('Cannot make connection ' + lcConnString , 16, 'SQL Connect Error') ELSE = MESSAGEBOX('Connection made', 48, 'SQL Connect Message') cSP = "BEGIN Procedure() ; END;" k = SQLExec(gnConnHandle, cSP) IF K <> 1 = MESSAGEBOX('Xранимая процедура ' + cSP + ' по каким-то причинам не выполнилась!!!!', 48, 'Сообщение об ощибке') = SQLDISCONNECT(gnConnHandle) ENDIF endif вот из-за постоянного соединения-рассоединения сильно тормозит. может мне открыть соединение сразу и, потом закрывать его с выходом из программы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
14.09.2005, 09:57:19
|
|||
|---|---|---|---|
Fox + Oracle SQL server |
|||
|
#18+
Ну и насоветовали тебе - рвать соединение после выполнения команд, так конечно делать не стоит, подумай сам если использовать такую технологию, то сервер "запарится" отключать/подключать клиентов и на саму обработку данных у него времени не останется. Поэтому соединился и держи/используй своё соединение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
14.09.2005, 13:42:31
|
|||
|---|---|---|---|
Fox + Oracle SQL server |
|||
|
#18+
Все верно Вам посоветовали!!! ни в коем случае не держите коннект, падение БД при этом очень вероятно!!! А тормозит, если - тут ничего не поделаешь. если критично пишите под Oracle forms а если некритично, пусть операторы отдыхают изредка ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
14.09.2005, 14:11:21
|
|||
|---|---|---|---|
Fox + Oracle SQL server |
|||
|
#18+
Aki Что бы наити истину, предлагаю простой тест, возмите в цикле этак шагов на 1000 выполните SQLCONNECT, SQLDISCONNECT и посмотрите на время выполнения самого цикла. Aki падение БД при этом очень вероятно!!! Я не силен в ORACLE, но думаю, что если бы БД падала от открытого коннекта то врял ли с ней можно было бы в принципе работать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
14.09.2005, 15:11:25
|
|||
|---|---|---|---|
Fox + Oracle SQL server |
|||
|
#18+
PaulWist Aki Что бы наити истину, предлагаю простой тест, возмите в цикле этак шагов на 1000 выполните SQLCONNECT, SQLDISCONNECT и посмотрите на время выполнения самого цикла. ну провел.. правда надоело Copy-Paste делать поэтому в 1000 шагов не стал SQLCONNECT, SQLDISCONNECT писать, долго все же, а еще и работать приходится сделал 28 раз, получил время 3 секунды примерно. что дальше? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
14.09.2005, 22:02:04
|
|||
|---|---|---|---|
Fox + Oracle SQL server |
|||
|
#18+
Akiну провел.. правда надоело Copy-Paste делать поэтому в 1000 шагов не стал SQLCONNECT, SQLDISCONNECT писать, долго все же, а еще и работать приходится сделал 28 раз Лично мне просто в голову не пришло бы делать 1000 строк Connect - Disconnect. Такие вещи обычно делаются через циклы. Код: plaintext 1. 2. 3. 4. Разрывать соединение имеет смысл, если есть какие-то ограничение на количество одновременных коннектов. Тогда чем меньше время коннекта, тем больше человек может "одновременно" работать с базой. Если таких ограничений нет, то не вижу смысла "дергать" коннект. Какие проблемы могут быть, если коннект будет включен постоянно? Весь сеанс работы пользователя. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
15.09.2005, 03:42:38
|
|||
|---|---|---|---|
|
|||
Fox + Oracle SQL server |
|||
|
#18+
Hi All! Да уж, от таких "специалистов" как Aki (IMHO человеку не знающему что такое цикл не место на профессиональных форумах, ОСОБЕННО в роли эксперта) и стоит ожидать столь вредных советов. Я плакалъ прочитав про "падение БД при этом очень вероятно" Вообще есть несколько стратегий в плане количества (и времени удержания) соединений. Если в программе связь с сервером нужна в одной-двух формах, причём "раз в год, да и то если проверка нагрянула" - то смысла держать открытую конекцию конечно нет. Если же программа ПОСТОЯННО работает с сервером, то нету никакого смысла постоянно открывать/закрывать коннекции, надеясь на то что Connection Pooling спасёт - весьма наивно - да он повышает скорость "повторного" коннекта, но тем не менее затраты на этот процесс остаются весьма существенными... Есть более сложные схемы, например "1,5 коннекции" - это когда по одной коннекции идёт "текущая" работа - данные для интерфейса вынимаются, а по временно создающейся второй коннекции в асинхронном режиме выполняются какие-то "массивные" действия. И по завершении процесса вторая коннекция закрывается. Единственный случай когда приходится сразу же закрывать коннекцию - это WebService или DCOM компоненты - поскольку во-первых их реально может быть создано очень много экземпляров на сервере, а во-вторых потому что обычно они пишутся как stateless компоненты (и они кстати могут помещаться в пул объектов - т.е. один и тот-же экземпляр будет использован РАЗНЫМИ клиентами) - соответственно между вызовами их методов никакое "состояние" не должно сохраняться (в том числе и коннекция). Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
15.09.2005, 09:26:32
|
|||
|---|---|---|---|
Fox + Oracle SQL server |
|||
|
#18+
ВладимирМ Лично мне просто в голову не пришло бы делать 1000 строк Connect - Disconnect. Такие вещи обычно делаются через циклы. Код: plaintext 1. 2. 3. 4. тьфу - заработался! Максимов как всегда дает самые действенные советы. За что ему ОСОБОЕ уважение!!! Спасибо, что поправили! ВладимирМ Разрывать соединение имеет смысл, если есть какие-то ограничение на количество одновременных коннектов. Тогда чем меньше время коннекта, тем больше человек может "одновременно" работать с базой. . да в том, то и дело, что я НЕ знаю сколько людей будет работать. с моей программой от 3-х до 20-ти, человек, но база-то общая, к ней стучатся и другие пользователи!!!! вот так-то... 2 Igor Korolev Я вообще-то не позиционировал себя как эксперта. высказал свое мнение, и все, да вот Уважаемый Максимов меня поправил, и верно поправил! за что ему особое СПАСИБО ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
15.09.2005, 10:09:56
|
|||
|---|---|---|---|
Fox + Oracle SQL server |
|||
|
#18+
Aki да в том, то и дело, что я НЕ знаю сколько людей будет работать. с моей программой от 3-х до 20-ти, человек, но база-то общая, к ней стучатся и другие пользователи!!!! вот так-то... Названные цифры коннектов НИ КАК не повлияют на производительность сервера, обычно тормоза начинаются с цифры 200 открытых коннектов и то это лечится добавлением ОЗУ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
15.09.2005, 10:25:30
|
|||
|---|---|---|---|
Fox + Oracle SQL server |
|||
|
#18+
PaulWist Aki да в том, то и дело, что я НЕ знаю сколько людей будет работать. с моей программой от 3-х до 20-ти, человек, но база-то общая, к ней стучатся и другие пользователи!!!! вот так-то... Названные цифры коннектов НИ КАК не повлияют на производительность сервера, обычно тормоза начинаются с цифры 200 открытых коннектов и то это лечится добавлением ОЗУ. Я бы ввобще не стал привязываться к конкретным цифрам. Один коннект требует ресурса всего лишь в 12 килобайт. Можно подключить и десять тысяч пользователей, которые делать ничего не будут. Сколько для этого потребуется ОЗУ ? Совсем немного. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
15.09.2005, 10:28:06
|
|||
|---|---|---|---|
Fox + Oracle SQL server |
|||
|
#18+
Вообще я сторонник подхода, когда пользователь в начале сеанса работы устанавливает коннект к серверу и спокойно работает до выхода из программы. Не вижу абсолютно никакого смысла в том, чтобы создавать и рвать коннект при каждой манипуляции с данными. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
15.09.2005, 11:30:42
|
|||
|---|---|---|---|
Fox + Oracle SQL server |
|||
|
#18+
PaulWist Названные цифры коннектов НИ КАК не повлияют на производительность сервера, обычно тормоза начинаются с цифры 200 открытых коннектов и то это лечится добавлением ОЗУ. Эти цифры для MS SQL Server, но уж никак не для Оракла (Сама архитектура уж так устроена) "Тормоза" "обычно" связаны с неверной конфигурацией сервака. Оправданием "тормозов" не должно являться ни увеличение размера БД, ни постепенное увеличение количества пользователей. 2Диченка Можно узнать откуда взялась столь "магическая" цифра в 12 кило ? :) Если разовор б Оракле - возможно, вы слыхали о области PGA, которая (в зависимости от обьема переворачиваемых данных и - опять же - не всегда успешно построеной архитектуры самого приложения) может зашкаливаь и выше 500 метров на сессию :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
15.09.2005, 11:53:15
|
|||
|---|---|---|---|
|
|||
Fox + Oracle SQL server |
|||
|
#18+
о действительно убрал дисконнекты после каждой операции - все ускорилось значительно!! только вот Аки сказал, что база может упасть.. если такое случится меня админ убьет натуральным образом... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
15.09.2005, 12:02:19
|
|||
|---|---|---|---|
Fox + Oracle SQL server |
|||
|
#18+
Tamito2Диченка Можно узнать откуда взялась столь "магическая" цифра в 12 кило ? :) Пардон, господа, я проецировал свой ответ сквозь призму MSSQL, с которым работаю. В Оракле конечно все по своему устроено. Но как мне кажется серьезная СУБД, к которой и относится Оракл, не может тормозить и тем более падать от большого количества одновременно висящих коннектов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
15.09.2005, 12:17:30
|
|||
|---|---|---|---|
Fox + Oracle SQL server |
|||
|
#18+
TamitoЭти цифры для MS SQL Server, но уж никак не для Оракла Вы не очень внимательно читали пред посты PaulWistЯ не силен в ORACLE TamitoОправданием "тормозов" не должно являться ни увеличение размера БД, ни постепенное увеличение количества пользователей. Это вопрос филосовский, для его решения необходимо рассмотрение конкретной реализации. zeBeginnaтолько вот Аки сказал, что база может упасть.. Неужели Вы не обратили внимание на последующую критику участников форума поста Аки (особенно про Copy/Past для создания соединений), говорящую о многом. Поэтому пердупреждения надо читать, но и собственной головой думать, а насчет, что база может упасть - от этого никто не застрахован, на этот счет имеются средства архивирования и восстановления. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
15.09.2005, 12:29:46
|
|||
|---|---|---|---|
Fox + Oracle SQL server |
|||
|
#18+
PaulWist TamitoОправданием "тормозов" не должно являться ни увеличение размера БД, ни постепенное увеличение количества пользователей. Это вопрос филосовский .. состоящий в том насколько админ вследствие недостаточной своей квалификации как ДБА сможет убедить окружающих и руководство в том, что тормоза в данном случае допустимы, ибо они связаны с увеличением размера БД (если руководство развесит уши и утверждать подобные глупости с чрезвычайно самоуверенным видом - гляди, может и прокатить)... :) :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
15.09.2005, 12:33:35
|
|||
|---|---|---|---|
Fox + Oracle SQL server |
|||
|
#18+
Tamito Я не понял, что Вы хотели сказать своим постом (это была реплика-шутка или приглашение привести пример, когда размер БД, и как следствие выборок влияет на призводительность как сервера так и клиентов?) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
15.09.2005, 12:49:24
|
|||
|---|---|---|---|
Fox + Oracle SQL server |
|||
|
#18+
PaulWist Tamito Я не понял, что Вы хотели сказать своим постом (это была реплика-шутка или приглашение привести пример, когда размер БД, и как следствие выборок влияет на призводительность как сервера так и клиентов?) Вероятно я оказался не совсем понятым. Размер и количество сессий не должно влиять на производительность (Разовор об Оракле, в сиквеле все иначе, там - не уверен). Если производительность падает при увеличении размера базы или при увеличении количества пользовательских сессий - это вопросы к месному ДБА по настройе производительности (Ессно если при проектировании изначально не допущены грубые ошибки (Например - запросы выгребают все данные и фльтруют уже на клиенте, такого рода)). Если же данный ДБА не в состоянии обеспечить должное решение задач - тогда это уж другое дело - сможет другой - более квалифицированный. Сама СУБД позволяет делать все , насколько конкретные субьекты умеют пользоваться ее возможностями - это вопрос субьективной квалификации, насколько могут свой недостаок владения спихнуть на внешние обьективные причины (мол - база выросла, ничего тут не поделаешь) -это вероятно уже из софистики - способность убедить в заведомо ошибочных утверждениях... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
15.09.2005, 13:08:11
|
|||
|---|---|---|---|
Fox + Oracle SQL server |
|||
|
#18+
Tamito "Раз пошла такая пьянка" (с) Исходя из ваших слов - пример: выборка/поиск одной записи из индексированной таблицы с 10 записями и с 1 млн должна быть одинакова - обьясните тогда механизм за счет чего это достигается, как это реализуется в Oracle, насколько я помню ВСЕ численные методы поиска очень чуствительны к количеству реперных точек. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
15.09.2005, 13:35:00
|
|||
|---|---|---|---|
Fox + Oracle SQL server |
|||
|
#18+
PaulWist Tamito "Раз пошла такая пьянка" (с) Исходя из ваших слов - пример: выборка/поиск одной записи из индексированной таблицы с 10 записями и с 1 млн должна быть одинакова Совершенно верно. Даже если не углубляться в различные типы таблиц и индексов - и пользовать к примеру наиболее распостраненный из индексов - уровень вложенности В-дерева всегда не глубже 4. Критерием и целью должно являться общее снижение кличества операций логического и физического ввода-вывода, а из миллиона или из 10 строчек извлекать одну - уже не столь существенно. Производительность - как и везде - достигается за счет правильной работы оптимизатора. А вот исходную статистику и параметры конфигурации для него правильно ли предоставили - уже забота ДБА (Можно и на пятерых пользователях на десяти строчках обесечить жуткие тормоза ) :) Мы углубляемся в особенности архитектуры и работы, в которых Оракл и МС СКЛ неописуемо далеки. Думаю, резонно было бы прекратить полемику. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
15.09.2005, 13:39:50
|
|||
|---|---|---|---|
Fox + Oracle SQL server |
|||
|
#18+
TamitoМы углубляемся в особенности архитектуры и работы, в которых Оракл и МС СКЛ неописуемо далеки. Думаю, резонно было бы прекратить полемику. Боже упаси, никакой полемики, мне просто интересен сам механизм, рассказанный доходчиво - "для дураков". Раз вы считаете, что лучше прекратить, то я не возражаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
15.09.2005, 14:09:58
|
|||
|---|---|---|---|
Fox + Oracle SQL server |
|||
|
#18+
Освежил в памяти теорию В-дерева - не убедительно. Основной постулат этого графа говорит, что доступ (путь) к данным одинаков , НО не говорится о накладных расходах поиска следующего ключа (хотя вариаций много для ускорения этого поиска), а вот это как раз и является важным так, что время поиска одной записи для разных таблиц будет разное, либо одинаковое, но равное поиску в большей таблице - никуда не денешься от теории численных методов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
16.09.2005, 03:39:31
|
|||
|---|---|---|---|
|
|||
Fox + Oracle SQL server |
|||
|
#18+
Hi PaulWist! Не надо далеко ходить - создай в фоксе табличку из пары миллионов записей, создай индекс по полю поиска, и засеки время выборки той самой пресловутой "одной записи". Я так понимаю что именно про это пытается говорить Tamito. Правда есть одно НО - далеко не вся обработка связана с "извлечением одной записи" - есть масса случаев когда нужно "перетрясать" практически весь объём хранимой информации - тут конечно против фактов не попрёшь - тут размер базы имеет большое значение. Иногда правда необходимость в таких действиях вытекает не из сути задачи, а из неверного подхода, применённого прикладным программистом - о чём тоже намекал Tamito - да, от "безумного" кода не спасёт ни супер-профессиональный DBA, ни сверхмощный кластер ;) Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
16.09.2005, 09:06:23
|
|||
|---|---|---|---|
Fox + Oracle SQL server |
|||
|
#18+
Igor Korolyov Igor Korolyov Не надо далеко ходить - создай в фоксе табличку из пары миллионов записей, создай индекс по полю поиска, и засеки время выборки той самой пресловутой "одной записи". Надо ли это понимать, что организация индексов в Фоксе и Oracle одинаковы? Если "Да" - то такие манипуляции я проводил много раз, если "Нет" - то для чего эта реплика? Посто сравнить "сапоги с километрами"? Igor KorolyovПравда есть одно НО - далеко не вся обработка связана с "извлечением одной записи" - есть масса случаев когда нужно "перетрясать" практически весь объём хранимой информации - тут конечно против фактов не попрёшь - тут размер базы имеет большое значение. Ну в общем я об этом и говорил, задавая "провокационный" вопрос насчет утверждения, что от размера таблички не зависит скорость получения данных. Тем более, была ссылка на организацию индекса в Oracle в виде В-дерева, которое имеет очевидные плюсы (независимо от кол-ва записей путь к данным одинаков) и очевидные минусы (время поиска в таблице с 10 записями имеющий индекс В-дерева с 1 млн записей бедет "чуть меньше" или таким же что и из таблички с 1млн. записей). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
16.09.2005, 09:25:58
|
|||
|---|---|---|---|
Fox + Oracle SQL server |
|||
|
#18+
ДиченкаПардон, господа, я проецировал свой ответ сквозь призму MSSQL, с которым работаю. В Оракле конечно все по своему устроено. Но как мне кажется серьезная СУБД, к которой и относится Оракл, не может тормозить и тем более падать от большого количества одновременно висящих коннектов. Отличная шутка дня Перенесем данный топик в "Сравнение СУБД" или ПТ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=41&mobile=1&tid=1593460]: |
0ms |
get settings: |
7ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
210ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
51ms |
get tp. blocked users: |
1ms |
| others: | 195ms |
| total: | 492ms |
| 0 / 0 |
