Как я узнаю то, что кует мой SQL Server?
Firebase не имеет встроенного поискового запроса, похожего на SQL. Вы можете сортировать по значениям / ключам или равняться
https://firebase.google.com/docs/database/android / retrieve-data
Примеры можно найти по ссылке выше. Это последняя документация для FireBase.
Если вы ищете SQL как поиски. Тогда взгляните на упругий поиск. Но это увеличит сложность, так как вам нужна платформа для ее установки. Для этого я мог бы порекомендовать Heroku или, возможно, GoogleCloudServers
. Здесь есть запись в блоге о расширенном поиске с упругим поиском https://firebase.googleblog.com/2014/01/queries-part-2-advanced -searches-with.html
5 ответов
Я предполагаю, что при должной осмотрительности вы подтвердили, что ЦП действительно используется процессом SQL (счетчики категорий процессов perfmon подтвердят это). Обычно для таких случаев вы берете образец соответствующих счетчиков производительности и сравниваете их с базовыми показателями, установленными вами в условиях нормальной нагрузки. Как только вы решите эту проблему, я рекомендую вам установить такую основу для будущих сравнений.
Вы можете точно определить, на что SQL расходует каждый цикл ЦП. Но чтобы знать, где искать, нужно много знаний и опыта. Это SQL 2005/2008 или 2000? К счастью, для 2005 года и новее есть несколько готовых решений. У вас уже есть пара хороших указателей с ответом Джона Самсона. Я хотел бы добавить рекомендацию по загрузке и установке отчетов панели мониторинга производительности SQL Server . Некоторые из этих отчетов включают самые популярные запросы по времени или по вводу-выводу, наиболее часто используемые файлы данных и так далее, и вы можете быстро понять, в чем проблема. Вывод является как числовым, так и графическим, поэтому он более полезен для новичков.
Я бы также порекомендовал использовать сценарий Adam's Who is Active , хотя он немного более продвинутый.
И последнее, но не менее важное: я рекомендую вам загрузить и прочитать официальный документ группы поддержки клиентов MS SQL. по анализу производительности: Ожидания и очереди SQL 2005 .
Я также рекомендую обратить внимание на ввод-вывод. Если вы добавили нагрузку на сервер, которая уничтожает буферный пул (т. Е. Ему нужно столько данных, что он вытесняет кешированные страницы данных из памяти), результатом будет значительное увеличение ЦП (звучит удивительно, но это правда). Обычно виной всему новый запрос, который сканирует большую таблицу от начала до конца.
Вы можете запустить профилировщик SQL и отфильтровать по ЦП или продолжительности, чтобы исключить все "мелочи". Тогда будет намного проще определить, есть ли у вас проблема, например, конкретная хранимая процедура, которая работает намного дольше, чем должна (может быть отсутствующий индекс или что-то в этом роде).
Два предостережения:
- Если проблема в огромное количество крошечных транзакций, то описанный выше фильтр их исключит, и вы пропустите это.
- Кроме того, если проблема заключается в одной крупной работе (например, 8-часовое задание анализа или плохо спроектированный выбор, который должен перекрестно объединить миллиард строк), тогда вы можете не увидеть этого в профилировщике, пока оно не будет полностью выполнено, в зависимости от того, что события, которые вы профилируете (sp: completed vs sp: statementcompleted).
Но обычно я начинаю с монитора активности или sp_who2.
В этом запросе используются DMV для определения наиболее дорогостоящих запросов по ЦП
SELECT TOP 20
qs.sql_handle,
qs.execution_count,
qs.total_worker_time AS Total_CPU,
total_CPU_inSeconds = --Converted from microseconds
qs.total_worker_time/1000000,
average_CPU_inSeconds = --Converted from microseconds
(qs.total_worker_time/1000000) / qs.execution_count,
qs.total_elapsed_time,
total_elapsed_time_inSeconds = --Converted from microseconds
qs.total_elapsed_time/1000000,
st.text,
qp.query_plan
FROM
sys.dm_exec_query_stats AS qs
CROSS APPLY
sys.dm_exec_sql_text(qs.sql_handle) AS st
CROSS APPLY
sys.dm_exec_query_plan (qs.plan_handle) AS qp
ORDER BY
qs.total_worker_time DESC
Полное объяснение см .: Как определить самые дорогие запросы SQL Server по ЦП
Для подхода с графическим интерфейсом я бы взглянул на Activity Monitor в разделе Management и отсортировал по CPU.
Запустите любой из них с интервалом в несколько секунд. Вы обнаружите высокую скорость подключения ЦП. Или: сохранить ЦП в локальной переменной, WAITFOR DELAY, сравнить сохраненные и текущие значения ЦП
select * from master..sysprocesses
where status = 'runnable' --comment this out
order by CPU
desc
select * from master..sysprocesses
order by CPU
desc
Может быть не самым элегантным, но эффективным и быстрым.