Вызов хранимой процедуры SQL2005 Express

[Mirra88]

Да, я выполнила этот запрос "select ФИО from MyTable", спасибо, действительно, он меньше секунды выполняется, а до этого я просто имя поля забыла указать. На Менеджмент-студии я его и выполняла, профайлер я тоже какой-то скачивала, но он был не совсем полноценный, там куча функций была не доступна.

[x77]

Да, я выполнила этот запрос "select ФИО from MyTable", спасибо, действительно, он меньше секунды выполняется

при правильной организации логики работы с БД, проработанном интерфейсе и пр., все остальное будет также выполнятся. по крайней мере, можно к этому последовательно придти. думайте сами, надо оно вам, или нет

следующий этап - формулирование задачи. вы уже начали это делать: пациент пришел к врачу, врач ввел его фамилию, - увидел все его посещения. теперь надо это осмыслить в терминах SQL-запросов по вашей БД, и добиться максимально быстрого выполнения этой логики, пока просто "на пальцах" - т.е. в любом построителе запросов.

я пока попрощаюсь до завтра, может кто из ребят продолжит.

[Dimka]

Тут ещё важно, что такой запрос возвращает 700 тыс. записей. А зачем? Пора переходить к WHERE.

[x77]

Dimka, перечитай весь топик

[Dimka]

x77, топик я читал. Дело не в этом.

Дело в том, что существует система, и перенос данных в SQL Server был сделан как-то криво, или криво были реализованы операции над этими данными. Но это не решается программистскими средствами. Это решается с помощью программистских средств. Программирование - это ответ на вопрос "как?" А ещё есть вопросы "что?" и "зачем?" Ответы на эти два вопроса лежат в предметной области - в сфере, где люди вводят и запрашивают какую-то информацию для решения своих пользовательских задач.

Плясать нужно от предметной области, от того, что называется "бизнес-логикой". Тогда любая строчка кода обретёт смысл, и станет понятно, где нужно, а где лишнее, где неоптимальности.

Но это совсем другая тема и такое отвлечение от собственно баз данных, что я даже и не знаю, как бы подвести к этому Mirra88. А не подведя, нет большого смысла в том, что выборка по одному полю быстрее, чем по многим. Да, быстрее, но может полей нужно больше; да, медленнее, но может меньше полей нельзя. Самое грустное во всём этом то, что не только мы, но даже и сама Mirra88 не знает ответов на эти вопросы.

Но, естественно, я полностью согласен с тем, что 700 тыс. записей по 100 полей - это не те объёмы, на которых SQL Server тормозит на простых запросах. Сотни миллионов записей - вот тут уже могут быть проблемы при отсутствии индексов и при невдумчивых попытках выполнять JOIN нескольких таблиц в запросах. В данном случае тормозить могут лишь жёсткий диск и/или процесс передачи данных по сетям, если пытаться многим пользователям на любой чих передавать десятки, если не сотни Мб данных. Сам SQL Server на небольших объёмах может тормозить только в случае неграмотной организации транзакций или на очень навороченных запросах, включающих EXISTS и т.п. вещи, когда не справляется оптимизатор.

[Dale]

Я не могу привести пример запроса, потому что запросы скомпилированы в exe-файл разработчиков. Я не вижу текстов запросов, разработчики текстов своих программ нам не раздают.

Если программа обращается к MS SQL, то вы можете запустить утилиту SQL Server Profiler и перехватить все запросы к серверу, а заодно и увидеть основную статистику их выполнения.

Кстати, 700.000 записей - это совершенно несерьезный объем для MS SQL, такое количество данных не должно вызывать никаких особенных трудностей и задержек при правильной организации данных. У меня несколько таблиц имеют около 2.000.000.000 записей каждая, и это не вызывает больших проблем в работе (правда, на сервере инсталлирован MS SQL 2008, но он вряд ли в тысячу раз производительнее, чем 2005).

[Mirra88]

Я сильно сомневаюсь, что дело в жёстком диске или в загруженности сети. В своё время в момент пиковых загрузок работала нестабильно не только эта программка, использующая 2 базы, но и другие программки, установленные на сервере. Помогло увеличение памяти сервера до 4Г (в 2раза), теперь SQL-сервер в спокойном состоянии занимает 1.5Г оперативки и всё работает стабильно. Но тогда стабильность действительно зависела от загруженности сети. Скорость же открытия-закрытия той же формы посещений от этой загруженности не зависит совершенно, я пробовала и вечером, когда никто не работает, и после перезагрузки сервера и даже локально. Скорость такая же медленная, помогает только уменьшение самой базы, а вернее количества записей таблицы (сам-то размер базы на диске не меняется). Если удалить треть записей, вот тогда связанные с этими записями clarion-формы работают существенно быстрее. Причём, если бы дело было в жёстком диске (а сервер у нас отнюдь не самый старый ни морально, ни физически), то проблема, наверное была бы только наша, но на то же самое жалуются и другие больницы, пользующиеся данной программкой. Опять же скорость открытия формы посещения конкретного пациента сильно зависит ОТКУДА её открыть. Если не с общей формы посещений, а из формы списка пациентов, то она открывается-закрывается быстро. Но список пациентов имеет явно меньше записей, чем список всех посещений по больнице! Т. е. я опять же упираюсь в количество записей таблицы, чем оно больше, тем скорость работы медленнее, независимо от загруженности сети (работа в сети вообще организована в терминальном режиме). Я не знаю с чем связано вот такое замедление работы скорости с увеличением базы (тут, скорее формы ввода-вывода медленно открываются-закрываются, а с чем это связано - с запросами или с чем-то ещё я пока не понимаю), может быть причина состоит в необходимости дублировать всё в обе базы (но тогда непонятна зависимость скорости работы с формой того же посещения пациента от того, откуда её открывать), может быть в чём-то ещё, но если бы всё было просто и ясно, то разработчики бы так не сделали, не назло же сами себе они работают. Тут вот именно что-то не срабатывает, есть какая-то проблема

[Dale]

Я сильно сомневаюсь, что дело в жёстком диске или в загруженности сети.
...
Я не знаю с чем связано вот такое замедление работы скорости с увеличением базы

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

Если используете представления, может помочь переход к хранимым представлениям.

[Mirra88]

Разработчики представлений не используют, я же пока ещё даже толком не разобралась чем они могут быть полезны и как с ними работать. Я пока только начинаю со всем этим экспериментировать.

[Dale]

Тогда запускайте SQL Server Profiler и ищите операции, которые сильно нагружают процессор и дисковый тракт. Нередки случаи, когда правильно построенные индексы повышают производительность базы в 100 и более раз.

[baldr]

Mirra88, а индексы есть в таблицах?

[Mirra88]

Да вот я ещё не очень сильна в среде Менеджмент-студия и сейчас разбираюсь где всё это можно посмотреть. На это потребуется некоторое время. Мне и самой сразу стало интересно есть ли там индексы и могу ли я их создать и безопасно поменять..

[Dimka]

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

Главный вопрос - кому, зачем и в какие моменты времени нужны на форме все посещения по больнице (как я понимаю, за всю историю больницы)?

где всё это можно посмотреть.

Каждая таблица в обозревателе объектов раскрывается как дерево - внутри есть папки, в которых находятся описания полей, индексов, триггеров и т.п. вещи.

[Mirra88]

Главный вопрос - кому, зачем и в какие моменты времени нужны на форме все посещения по больнице (как я понимаю, за всю историю больницы)?

А в форме все посещения и не открываются, только за сегодняшнее число, плюс календарь и разные другие возможности вывода (например, по фамилии). Но открывается всё-равно долго. Может быть чтобы выйти на эти сегодняшние посещения просматривается вся база.. Не знаю..

[Dale]

открывается всё-равно долго. Может быть чтобы выйти на эти сегодняшние посещения просматривается вся база.. Не знаю..

Посмотрите планы выполнения своих запросов. Из них хорошо видно, какой механизм используется для выборки данных.

[Mirra88]

Запросы не мои. Они в ехе-файле разработчика и написаны не на SQL, а на Clarion. Следовательно я не имею возможности посмотреть их план.

[Dimka]

Mirra88, ты же говорила, что тормозит не Clarion, а SQL Server. На чём бы ни были написано приложение, оно всё равно генерирует запросы, которые посылаются на SQL Server из приложения. Про это и говорит Dale. Вместе с Management Studio у SQL Server есть другая программа - Profiler. Она перехватывает все запросы к серверу и собирает по ним статистику. С её помощью отследи, какие запросы идут к базе данных от клиентских приложений.

[Mirra88]

Я не знаю точно, что тормозит и почему. Однозначно могу сказать только то, что обращаясь к SQL-базе программа работает гораздо медленнее чем когда она же обращается к Clarion-базе. Это факт, с него я вчера начала. А всё остальное - это предположения и поиск истины. И мне уже тут такое море немеренное дали всяких хороших наводок к поиску этой истины (за что я очень благодарна участникам форума), что я её непременно должна найти! Например, сразу три человека посоверовали посмотреть индексы. Я их сейчас и изучала. По-правде говоря у меня сложилось впечатление, что с ними действительно что-то не то. Сама я построила бы их совсем по другому. Может быть это, наоборот, от моего незнания. Но ведь у меня же есть копия базы и возможность экспериментировать! Я думаю, что подсказки со стороны участников форума истину найти мне помогут. И вот тогда я смогу сделать утверждение в чём собственно было дело и что являлось причиной медленной работы, Clarion, SQL-сервер или что-то ещё. Пока же я могу только предполагать.

[x77]

Mirra88, ты же говорила, что тормозит не Clarion, а SQL Server. На чём бы ни были написано приложение, оно всё равно генерирует запросы, которые посылаются на SQL Server из приложения. Про это и говорит Dale. Вместе с Management Studio у SQL Server есть другая программа - Profiler. Она перехватывает все запросы к серверу и собирает по ним статистику. С её помощью отследи, какие запросы идут к базе данных от клиентских приложений.

по-моему, в Экспрессе нет родного профайлера.

[Mirra88]

Да, в нём действительно нет родного профайлера, как и многих других функций и программок про которые я читала (облизываясь) в книге про SQL2005. Там нет агента, планировщика и ещё много-много чего. Но я скачала какой-то профайлер, который работает и на express. Но от скачанного мною профайлера мало толку, там очень много функций недоступно.

[HandKot]

Да, в нём действительно нет родного профайлера, как и многих других функций и программок про которые я читала (облизываясь) в книге про SQL2005. Там нет агента, планировщика и ещё много-много чего. Но я скачала какой-то профайлер, который работает и на express. Но от скачанного мною профайлера мало толку, там очень много функций недоступно.

ничего страшного, хотя и странно, т.к профайлер никак не связан с редакцией сервера.
если нет профайлера, то используйте динамические представления
вот пример из БОЛ

Код:

--В следующем примере возвращаются сведения о пяти первых запросах, отсортированных по среднему времени ЦП. В этом примере объединяются запросы в 
--соответствии с хэшем запроса таким образом, чтобы обеспечить группировку логически эквивалентных запросов по их совокупному потреблению ресурсов
SELECT TOP 5 query_stats.query_hash AS "Query Hash", 
    SUM(query_stats.total_worker_time) / SUM(query_stats.execution_count) AS "Avg CPU Time",
    SUM(query_stats.total_elapsed_time ) / SUM(query_stats.execution_count) AS "Avg Duration",
    MIN(query_stats.statement_text) AS "Statement Text"
FROM 
    (SELECT QS.*, 
    SUBSTRING(ST.text, (QS.statement_start_offset/2) + 1,
    ((CASE statement_end_offset 
        WHEN -1 THEN DATALENGTH(st.text)
        ELSE QS.statement_end_offset END 
            - QS.statement_start_offset)/2) + 1) AS statement_text
     FROM sys.dm_exec_query_stats AS QS
     CROSS APPLY sys.dm_exec_sql_text(QS.sql_handle) as ST) as query_stats
GROUP BY query_stats.query_hash
ORDER BY 2 DESC;

только отберите запросы с максимальным Duration и минимальным CPU Time

так же смотрите в сторону других DMV
sys.dm_db_missing_index_details и sys.dm_db_missing_index_columns

[x77]

<..> нет большого смысла в том, что выборка по одному полю быстрее, чем по многим. Да, быстрее, но может полей нужно больше; да, медленнее, но может меньше полей нельзя.

я исходил из того, что человек пытается экспериментировать на копии боевой базы. т.е. саму базу трогать нельзя по условиям задачи, не факт, что 23-летней девушке возьмут и разрешат влепить нужные индексы, к примеру.

а тогда остаются только интерфейсные решения. выборка жесткого минимума полей и подгрузка остальных по мере надобности. при необходимости - отказ от двунаправленных датасетов.

я согласен, что пытаться программно компенсировать кривую архитектуру БД - в принципе неправильно, но на практике очень часто просто не остается другого выхода.

[Dimka]

x77, я в общем-то не про это говорил. Я говорил о том, что сначала нужно понять, что вообще происходит с данными с точки зрения предметной области. Индексы - это потом, после просветления.

Если "23-хлетняя девушка" представит достаточно рациональные обоснования, подверждённые экспериментальными замерами на копии боевой базы, то почему бы и нет? Если же отказ будет мотивирован ссылками исключительно на пол и возраст, то ничего не попишешь - гореть такой больнице в аду, а Mirra88 в таком случае можно с чистой совестью перестать волноваться за эту больницу.

[x77]

Dimka, дело не в поле и возрасте, а в том, что база боевая. я бы не дал у себя на проекте делать "лишний" индекс без соответствующего регрессионного тестирования.

[Mirra88]

Через 4 с лишним месяца после моего обращения на форум вопрос о причинах торможения базы с увеличением количества записей в ней неожиданно решился благодаря разработчикам базы данных. Причём решилось всё в точности как сказал Dale:
 

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

Так и получилось! Нам разослали письма как и какие 2 индекса надо добавить в базу на SQL-сервере и перестроить их. И теперь всё работает быстро. Ура!

[Dimka]

За ум взялись те разработчики.