wwwoldi.ru

About Me

Dashy

Hello word I am dashy Guy

Разное

Ms sql история запросов: Как просмотреть историю запросов mssql. — adminbd

alexxlab
No Comments

Как просмотреть историю запросов mssql. — adminbd

/************************************************************
 *  * k.moskvichev ©
 * Time: 27.06.2019 13:13:52
 ************************************************************/

SELECT 		
      creation_time
           ,last_execution_time
           ,execution_count
           ,total_worker_time / 1000      AS CPU
           ,CONVERT(MONEY ,(total_worker_time)) / (execution_count * 1000) AS [AvgCPUTime]
           ,qs.total_elapsed_time / 1000  AS TotDuration
           ,CONVERT(MONEY ,(qs.total_elapsed_time)) / (execution_count * 1000) AS [AvgDur]
           ,total_logical_reads           AS [Reads]
           ,total_logical_writes          AS [Writes]
           ,total_logical_reads + total_logical_writes AS [AggIO]
           ,CONVERT(
                MONEY
               ,(total_logical_reads + total_logical_writes) / (execution_count + 0.0)
            )                             AS [AvgIO]
           ,CASE 
                 WHEN sql_handle IS NULL THEN ' '
                 ELSE (
                          SUBSTRING(
                              st.text
                             ,(qs.statement_start_offset + 2) / 2
                             ,(
                                  CASE 
                                       WHEN qs.statement_end_offset = -1 THEN LEN(CONVERT(NVARCHAR(MAX) ,st.text)) * 2
                                       ELSE qs.statement_end_offset
                                  END - qs.statement_start_offset
                              ) / 2
                          )
                      )
            END                           AS query_text
           ,DB_NAME(st.dbid)              AS database_name
           ,object_schema_name(st.objectid ,st.dbid) + '.' + OBJECT_NAME(st.objectid ,st.dbid) AS OBJECT_NAME
           ,qp.query_plan
FROM   
      sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(sql_handle) st CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp --WHERE --creation_time > '2018-12-14 08:00:00.000' --object_schema_name(st.objectid, st.dbid)+'.'+object_name(st.objectid, st.dbid) = 'dbo.ChequeExciseInsert' ORDER BY creation_time DESC

 

Similar Posts:

Как просмотреть историю запросов в SQL Server Management Studio

Вопрос:

Сохранена ли история запросов в некоторых файлах журнала? Если да, можете ли вы сказать мне, как найти их местоположение? Если нет, можете ли вы дать мне совет о том, как его увидеть?

Ответ №1

[Поскольку этот вопрос, скорее всего, будет закрыт как дубликат.]

Если SQL Server не был перезапущен (и план не был выведен и т.д.), вы можете найти запрос в кеше плана.

SELECT t.[text]
FROM sys.dm_exec_cached_plans AS p
CROSS APPLY sys.dm_exec_sql_text(p.plan_handle) AS t
WHERE t.[text] LIKE N'%something unique about your query%';

Если вы потеряли файл из-за сбоя Management Studio, вы можете найти здесь файлы восстановления:

C:\Users\<you>\Documents\SQL Server Management Studio\Backup Files\

В противном случае вам нужно будет использовать что-то еще, чтобы помочь вам сохранить историю запросов, например SSMS Tools Pack, как указано в Ed Harper answer — хотя это не ‘t бесплатно в SQL Server 2012+. Или вы можете настроить небольшую трассировку, отфильтрованную по имени входа или имени хоста (но для этого используйте для этого трассировку на стороне сервера, а не Profiler).

Как отметил @Ненад-Живкович, может быть полезно присоединиться к sys.dm_exec_query_stats и упорядочить на last_execution_time:

SELECT t.[text], s.last_execution_time
FROM sys.dm_exec_cached_plans AS p
INNER JOIN sys.dm_exec_query_stats AS s
ON p.plan_handle = s.plan_handle
CROSS APPLY sys.dm_exec_sql_text(p.plan_handle) AS t
WHERE t.[text] LIKE N'%something unique about your query%'
ORDER BY s.last_execution_time DESC;

Ответ №2

В конце, но, надеюсь, полезно, поскольку он добавляет больше деталей…

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

Чтение журнала транзакций — это не простая вещь, потому что она в проприетарном формате. Однако, если вам нужно просмотреть запросы, которые выполнялись исторически (кроме SELECT), это единственный способ.

Для этого вы можете использовать сторонние инструменты, такие как ApexSQL Log и SQL Log Rescue (бесплатно, но только для SQL 2000). Проверьте эту тему для получения более подробной информации здесь SQL Server Transaction Log Explorer/Analyzer

Профилировщик SQL Server — лучше всего подходит, если вы просто хотите начать аудит и вас не интересует, что произошло раньше. Убедитесь, что вы используете фильтры, чтобы выбрать только те транзакции, которые вам нужны. В противном случае вы получите очень много данных очень быстро.

Трассировка SQL Server — лучше всего подходит, если вы хотите захватить все или большинство команд и сохранить их в файле трассировки, который может быть проанализирован позже.

Триггеры — лучше всего подходят, если вы хотите захватить DML (кроме select) и сохранить их где-нибудь в базе данных

Ответ №3

Ответ №4

Как уже отмечали другие, вы можете использовать SQL Profiler, но вы также можете использовать его функциональность через системные хранимые процедуры sp_trace_ *. Например, этот фрагмент SQL будет (по крайней мере, в 2000 году; я думаю, что то же самое для SQL 2008, но вам придется перепроверить) перехватывает события RPC:Completed и SQL:BatchCompleted для всех запросов, выполнение которых занимает более 10 секунд и сохраните вывод в файл трассировки, который вы можете открыть в профилировщике SQL позже:

DECLARE @TraceID INT
DECLARE @ON BIT
DECLARE @RetVal INT
SET @ON = 1

exec @RetVal = sp_trace_create @TraceID OUTPUT, 2, N'Y:\TraceFile.trc'
print 'This trace is Trace ID = ' + CAST(@TraceID AS NVARCHAR)
print 'Return value = ' + CAST(@RetVal AS NVARCHAR)
-- 10 = RPC:Completed
exec sp_trace_setevent @TraceID, 10, 1, @ON     -- Textdata
exec sp_trace_setevent @TraceID, 10, 3, @ON     -- DatabaseID
exec sp_trace_setevent @TraceID, 10, 12, @ON        -- SPID
exec sp_trace_setevent @TraceID, 10, 13, @ON        -- Duration
exec sp_trace_setevent @TraceID, 10, 14, @ON        -- StartTime
exec sp_trace_setevent @TraceID, 10, 15, @ON        -- EndTime

-- 12 = SQL:BatchCompleted
exec sp_trace_setevent @TraceID, 12, 1, @ON     -- Textdata
exec sp_trace_setevent @TraceID, 12, 3, @ON     -- DatabaseID
exec sp_trace_setevent @TraceID, 12, 12, @ON        -- SPID
exec sp_trace_setevent @TraceID, 12, 13, @ON        -- Duration
exec sp_trace_setevent @TraceID, 12, 14, @ON        -- StartTime
exec sp_trace_setevent @TraceID, 12, 15, @ON        -- EndTime

-- Filter for duration [column 13] greater than [operation 2] 10 seconds (= 10,000ms)
declare @duration bigint
set @duration = 10000
exec sp_trace_setfilter @TraceID, 13, 0, 2, @duration

Вы можете найти идентификатор для каждого события трассировки, столбцов и т.д. В Books Online; просто искать sp_trace_create, sp_trace_setevent и sp_trace_setfiler sprocs. Затем вы можете управлять трассировкой следующим образом:

exec sp_trace_setstatus 15, 0       -- Stop the trace
exec sp_trace_setstatus 15, 1       -- Start the trace
exec sp_trace_setstatus 15, 2       -- Close the trace file and delete the trace settings

… где ’15’ — это идентификатор трассировки (как сообщается в sp_trace_create, который первый скрипт выкинул выше).

Вы можете проверить, с какими трассировками работают:

select * from ::fn_trace_getinfo(default)

Единственное, что я скажу с осторожностью — я не знаю, какую нагрузку это окажет на вашу систему; это добавит некоторые, но насколько велико это «некоторые», вероятно, зависит от того, насколько занят ваш сервер.

Ответ №5

Система не записывает запросы таким образом. Если вы знаете, что хотите сделать это раньше времени, вы можете использовать SQL Profiler для записи того, что входит и отслеживать запросы во время работы Профайлера.

Ответ №6

Вы можете отслеживать SQL-запросы SQL Profiler, если вам это нужно

Ответ №7

Я использую приведенный ниже запрос для отслеживания активности приложения на SQL-сервере, у которого нет профилировщика трассировки.
Метод использует Query Store (SQL Server 2016+) вместо DMV. Это дает лучшую возможность просматривать исторические данные, а также более быстрый поиск.
Очень эффективно записывать короткие запросы, которые невозможно захватить sp_who/sp_whoisactive.

/* Adjust script to your needs.
Run full script (F5) -> Interact with UI -> Run full script again (F5)
Output will contain the queries completed in that timeframe.
*/

/* Requires Query Store to be enabled:
ALTER DATABASE <db> SET QUERY_STORE = ON
ALTER DATABASE <db> SET QUERY_STORE (OPERATION_MODE = READ_WRITE, MAX_STORAGE_SIZE_MB = 100000)
*/

USE <db> /* Select your DB */

IF OBJECT_ID('tempdb..#lastendtime') IS NULL
SELECT GETUTCDATE() AS dt INTO #lastendtime
ELSE IF NOT EXISTS (SELECT * FROM #lastendtime)
INSERT INTO #lastendtime VALUES (GETUTCDATE())

;WITH T AS (
SELECT
DB_NAME() AS DBName
, s.name + '.' + o.name AS ObjectName
, qt.query_sql_text
, rs.runtime_stats_id
, p.query_id
, p.plan_id
, CAST(p.last_execution_time AS DATETIME) AS last_execution_time
, CASE WHEN p.last_execution_time > #lastendtime.dt THEN 'X' ELSE '' END AS New
, CAST(rs.last_duration / 1.0e6 AS DECIMAL(9,3)) last_duration_s
, rs.count_executions
, rs.last_rowcount
, rs.last_logical_io_reads
, rs.last_physical_io_reads
, q.query_parameterization_type_desc
FROM (
SELECT *, ROW_NUMBER() OVER (PARTITION BY plan_id, runtime_stats_id ORDER BY runtime_stats_id DESC) AS recent_stats_in_current_priod
FROM sys.query_store_runtime_stats
) AS rs
INNER JOIN sys.query_store_runtime_stats_interval AS rsi ON rsi.runtime_stats_interval_id = rs.runtime_stats_interval_id
INNER JOIN sys.query_store_plan AS p ON p.plan_id = rs.plan_id
INNER JOIN sys.query_store_query AS q ON q.query_id = p.query_id
INNER JOIN sys.query_store_query_text AS qt ON qt.query_text_id = q.query_text_id
LEFT OUTER JOIN sys.objects AS o ON o.object_id = q.object_id
LEFT OUTER JOIN sys.schemas AS s ON s.schema_id = o.schema_id
CROSS APPLY #lastendtime
WHERE rsi.start_time <= GETUTCDATE() AND GETUTCDATE() < rsi.end_time
AND recent_stats_in_current_priod = 1
/* Adjust your filters: */
-- AND (s.name IN ('<myschema>') OR s.name IS NULL)
UNION
SELECT NULL,NULL,NULL,NULL,NULL,NULL,dt,NULL,NULL,NULL,NULL,NULL,NULL, NULL
FROM #lastendtime
)
SELECT * FROM T
WHERE T.query_sql_text IS NULL OR T.query_sql_text NOT LIKE '%#lastendtime%' -- do not show myself
ORDER BY last_execution_time DESC

TRUNCATE TABLE #lastendtime
INSERT INTO #lastendtime VALUES (GETUTCDATE())

Ответ №8

вы можете использовать «Автоматически генерировать script при каждом сохранении», если вы используете студию управления.
Это, конечно, не журнал.
Проверьте, полезны ли вам..;)

Ответ №9

Если интересующие вас запросы — это динамические запросы, которые прерываются с перерывами, вы можете записывать SQL и datetime и пользователя в таблицу во время создания динамического оператора. Это будет сделано в каждом конкретном случае, хотя для этого требуется определенное программирование, и для этого требуется дополнительное время обработки, поэтому сделайте это только для тех немногих запросов, которые вас больше всего волнуют. Но наличие журнала выполняемых конкретных операторов может действительно помочь, когда вы пытаетесь выяснить, почему он терпит неудачу один раз в месяц. Динамические запросы трудно проверить, и иногда вы получаете одно конкретное входное значение, которое просто не будет работать, и выполнение этого ведения журнала во время создания SQL часто является лучшим способом увидеть, что конкретно было в sql, который был построен.

Ответ №10

Немного нестандартным методом было бы написать решение в AutoHotKey. Я использую это, и это не идеально, но работает и бесплатно. По сути, этот сценарий назначает горячую клавишу для CTRL + SHIFT + R, которая скопирует выбранный SQL в SSMS (CTRL + C), сохранит файл SQL с меткой даты и затем выполнит выделенный запрос. (F5). Если вы не привыкли к сценариям AHK, начальная точка с запятой — это комментарий.

;CTRL+SHIFT+R to run a query that is first saved off
^+r::
;Copy
Send, ^c
; Set variables
EnvGet, HomeDir, USERPROFILE
FormatTime, DateString,,yyyyMMdd
FormatTime, TimeString,,hhmmss
; Make a spot to save the clipboard
FileCreateDir %HomeDir%\Documents\sqlhist\%DateString%
FileAppend, %Clipboard%, %HomeDir%\Documents\sqlhist\%DateString%\%TimeString%.sql
; execute the query
Send, {f5}
Return

Самым большим ограничением является то, что этот сценарий не будет работать, если вы нажмете «Выполнить» вместо использования сочетания клавиш, и этот сценарий не сохранит весь файл — только выделенный текст. Но вы всегда можете изменить скрипт для выполнения запроса, а затем выбрать все (CTRL + A) перед копированием/сохранением.

Использование современного редактора с функциями поиска в файлах позволит вам осуществлять поиск в истории SQL. Вы можете даже прихотить и скопировать свои файлы в базу данных SQLite3 для запроса ваших запросов.

Ответ №11

SELECT deqs.last_execution_time AS [Time], dest.text AS [Query], dest.*
FROM sys.dm_exec_query_stats AS deqs
CROSS APPLY sys.dm_exec_sql_text(deqs.sql_handle) AS dest
WHERE dest.dbid = DB_ID('msdb')
ORDER BY deqs.last_execution_time DESC

Это должно показать вам время и дату, когда был выполнен запрос

История оптимизации одного большого запроса средствами MSSQL Profiler и 1С


КОГДА ЗначенияПоказателейСхемМотивации.Показатель.ВидПоказателя =ЗНАЧЕНИЕ(Перечисление.ВидыПоказателейСхемМотивации.ПоПодразделению)


ТОГДА ДвиженияРаботников.Подразделение = ЗначенияПоказателейСхемМотивации.Подразделение


КОГДА ЗначенияПоказателейСхемМотивации.Показатель.ВидПоказателя =ЗНАЧЕНИЕ(Перечисление.ВидыПоказателейСхемМотивации.ПоПодразделениюИСотруднику)


ТОГДА ДвиженияРаботников.Физлицо = ЗначенияПоказателейСхемМотивации.Сотрудник.Физлицо


И ДвиженияРаботников.Подразделение = ЗначенияПоказателейСхемМотивации.Подразделение


ИНАЧЕ ИСТИНА


КОНЕЦ)


ВНУТРЕННЕЕ СОЕДИНЕНИЕ Справочник.ПоказателиСхемМотивации КАК ПоказателиСхемМотивации


ПО ЗначенияПоказателейСхемМотивации.Показатель = ПоказателиСхемМотивации.ПоказательПредыдущегоПериода


И (ПоказателиСхемМотивации.ПредыдущийПериод)


При заполнении временной  таблицы ЗначенияЕжемесячныхПоказателей идет соединение Движений иЗначенийПоказателей в условии соединения идет ВЫБОР КОГДА с различными вариантами по ВидамПоказателей


Были указаны виды:


  • Индивидуальный

  • ПоПодразделению

  • ПоПодразделениюИСотруднику


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

Причина ошибки — в программу предыдущими разработчиками было добавлено новое значение перечисления показателя «ПоКадровымДаннымСотрудника», который заполняется по подразделению и должности и который не был описан в условии соединения.

Решение – добавить новое условие в ВЫБОР КОГДА по новому виду показателя.


Скорректированный код запроса приводить не буду – логика понятна.


Время выполнения текущего запроса снизилось с 2 секунд до 0.2 секунд и снизилось количество записей до 300. 


IV часть – Заключительная и опять короткая 🙂


Результаты оптимизации стали видны сразу:


  • Невооруженным взглядом – время заполнения документа изменилось с «очень долго» на «практически мгновенно».

  • Вооруженным – APDEX изменился с «неприемлимо» до «отлично».


 


 Замеры выполнения ДО и ПОСЛЕ оптимизации разделены красным маркером.


Вывод


  1. План выполнения запросов MSSQL из SQL Profiler удобно использовать для анализа и оптимизации «узких мест» в больших «многоэтажных» запросах и либо находить, либо сужать область поиска неоптимального или некорректного кода, особенно когда проводить рефакторинг кода запроса крайне затруднительно или невозможно.

  2. Анализ планов выполнения запроса так же помогает выявить запросы, которые сами по себе выполняются достаточно быстро по отношению к общему времени выполнения запроса, но которые критическим образом сказываются на общем времени выполнения. Такие «некорректные» запросы очень тяжело выявить используя только стандартные средства 1С без визуализации плана выполнения.

  3. Когда у тебя руки чешутся, чтобы сделать что-нибудь полезное – проверь не сделал ли это кто-нибудь до тебя (с) Здесь я имею ввиду – Консоль запросов 1С с одновременной возможностью просмотра плана выполнения запроса из SQL Profiler. Такая обработка уже есть – http://infostart.ru/public/56973/ — автор Ararat. Пока, к сожалению, воспользоваться ей не довелось, но судя по отзывам и рекомендациям – там все нормально, и она отработает так как надо. Думаю, что с такой обработкой я бы решил задачу быстрее, так как с Profiler’ом было бы поменьше работы. Так что думаю обработка из разряда — must have.

  4. Начинать любую оптимизацию лучше всего с внедрения подсистемы «Оценка производительности» и установки замеров времени выполнения, чтобы четко отслеживать результаты оптимизации. 

  5. На производительности могут сказываться неочевидные и труднонаходимые ошибки в коде. (с) Капитан Очевидность

  6. Очередное подтверждение правила, если что-то стало медленно работать – 90% что надо искать «кривой» код


В качестве P.S., крайне рекомендую к прочтению статью Славы Гилева «Влияние оптимизатора запросов на производительность 1С» — в ней очень хорошо показана вся внутренняя кухня оптимизатора СУБД, плана выполнения запроса и всего остального. Статья из разряда «must read», особенно тем, кто готовится к Эксперту по ТВ или просто хочет чуть лучше понимать как оно «ТАМ» работает

Как просмотреть историю запросов в среде SQL Server Management Studio — sql-server

Как уже отмечали другие, вы можете использовать SQL Profiler, но вы также можете использовать его функциональность с помощью sp_trace_* системных хранимых процедур. Например, этот фрагмент SQL будет (по крайней мере, в 2000 году; я думаю, что это то же самое для SQL 2008, но вам придется дважды проверить) перехватывать события RPC:Completed и SQL:BatchCompleted для всех запросов, выполнение которых занимает более 10 секунд, и сохранять выходные данные в файл трассировки, который вы можете открыть в SQL profiler позже:

DECLARE @TraceID INT
DECLARE @ON BIT
DECLARE @RetVal INT
SET @ON = 1

exec @RetVal = sp_trace_create @TraceID OUTPUT, 2, N'Y:\TraceFile.trc'
print 'This trace is Trace ID = ' + CAST(@TraceID AS NVARCHAR)
print 'Return value = ' + CAST(@RetVal AS NVARCHAR)
-- 10 = RPC:Completed
exec sp_trace_setevent @TraceID, 10, 1, @ON     -- Textdata
exec sp_trace_setevent @TraceID, 10, 3, @ON     -- DatabaseID
exec sp_trace_setevent @TraceID, 10, 12, @ON        -- SPID
exec sp_trace_setevent @TraceID, 10, 13, @ON        -- Duration
exec sp_trace_setevent @TraceID, 10, 14, @ON        -- StartTime
exec sp_trace_setevent @TraceID, 10, 15, @ON        -- EndTime

-- 12 = SQL:BatchCompleted
exec sp_trace_setevent @TraceID, 12, 1, @ON     -- Textdata
exec sp_trace_setevent @TraceID, 12, 3, @ON     -- DatabaseID
exec sp_trace_setevent @TraceID, 12, 12, @ON        -- SPID
exec sp_trace_setevent @TraceID, 12, 13, @ON        -- Duration
exec sp_trace_setevent @TraceID, 12, 14, @ON        -- StartTime
exec sp_trace_setevent @TraceID, 12, 15, @ON        -- EndTime

-- Filter for duration [column 13] greater than [operation 2] 10 seconds (= 10,000ms)
declare @duration bigint
set @duration = 10000
exec sp_trace_setfilter @TraceID, 13, 0, 2, @duration

Вы можете найти ID для каждого trace-события, столбцов и т. д. Из книг в интернете; просто найдите sp_trace_create, sp_trace_setevent и sp_trace_setfiler sprocs. Затем вы можете управлять trace следующим образом:

exec sp_trace_setstatus 15, 0       -- Stop the trace
exec sp_trace_setstatus 15, 1       -- Start the trace
exec sp_trace_setstatus 15, 2       -- Close the trace file and delete the trace settings

…

где ’15’ — это trace ID (как сообщает sp_trace_create, который запускает первый скрипт, выше).

Вы можете проверить, чтобы увидеть, какие трассировки работают с:

select * from ::fn_trace_getinfo(default)

Единственное, что я скажу с осторожностью — я не знаю, сколько нагрузки это поставит на вашу систему; это добавит немного, но насколько велик этот «some», вероятно, зависит от того, насколько занят ваш сервер.

Немного о том где хранить sql запросы в программах.

Многие начинающие разработчики при проектировании очередного ПО задумываются, куда разместить такой объект как текст SQL запроса. Очевидное решение: в исходном коде программы (а то и в виде статических полей какогонить объекта), видится наиболее простым, особенно в купе с поддержкой со стороны некоторых IDE, множество недостатков такого подхода даже обсуждать не стоит, ибо там всего одно достоинство — макароны SQL кода перемешан с макаронами кода программы, блюда на любителя. Другой более продуманный подход: хранить в файлах, порождает вопрос «в каких?», на что просвещенный интернет заявляет «в XML». Казалось бы что ту можно обсуждать?
Но, тем не мене, предлагаю хранить запросы там где им самое место… в SQL файлах:

/*#secondTestQuery*/ --название запроса
select 
 now(), /*@date title=Дата, javaType=java.util.Date*/ -- тут определяется тип и аттрибуты поля
 17843,  --@weight title=Вес, javaType=float
--тут определеяется параметр запроса id с типом INT, строка `123` для использования в SQL редакторе, т.е. только для тестирования и отладки
        /*$id, type=INT {*/123/*}*/
 ;
/*#secondTestQuery end*/

/*#getAlarmButtonEvents */
select t.*, 
       (select tc.comment from telemetrycomments tc where tc.id = t.uid) as comment
  from telemetry t
 where t.eventtime >= /*$startDate, type=timestamp {*/to_timestamp('20121206000000','YYYYMMDDHh34MISS')/*}*/
   and t.eventtime <= /*$endDate, type=timestamp {*/to_timestamp('20121206235959','YYYYMMDDHh34MISS')/*}*/
   and (t.provider || ':' || t.deviceid) = any (/*$devices {*/'{"test:test"}'/*}*/::varchar[])
   and t.eventtype = 'ALARM_BUTTON'
/*#getAlarmButtonEvents end*/
/*   После парсинга шаблоны запросов будут преобразованы в код пригодный для выполнения:   */
-- secondTestQuery
select 
 now(),
 17843,
 ?
 ;
-- getAlarmButtonEvents 
select t.*, 
       (select tc.comment from telemetrycomments tc where tc.id = t.uid) as comment
  from telemetry t
 where t.eventtime >= ?
   and t.eventtime <= ?
   and (t.provider || ':' || t.deviceid) = any (?::varchar[])
   and t.eventtype = 'ALARM_BUTTON'

Да, да я храню SQL запросы в SQL файлах, чего и вам советую.  Информация о имени запроса, список возвращаемых запросом колонок (необязательно), а также список параметров запроса (с произвольным набором аттрибутов) хранитса прямо тут в виде особых комментариев.
Такой простой подход оценят не столько разработчки на какойнить Java, сколько авторы этих самых запросов, зачастую нетривиальных, а также те кто это все будет поддерживать, ведь для того чтобы выполнить запрос достаточно открыть файл в SQL редакторе и, собственно, его выполнить, так как даже тестовые параметры уже подставленны (кто не заметил, между символами {*/<тестовый параметр>/*}, при парсинге запроса, эти параметры естествено удаляются).
Стоит заметить что эта идея уже скоро как пять лет успешно применяется на практитке. К сожалению реализация не является open source, но набросать парсер не такая уж сложная задача.

История запросов пользователей SQL Server

Переполнение стека

  1. Около

  2. Продукты

  3. Для команд

  1. Переполнение стека
    Общественные вопросы и ответы

  2. Переполнение стека для команд
    Где разработчики и технологи делятся частными знаниями с коллегами

  3. Вакансии
    Программирование и связанные с ним технические возможности карьерного роста

  4. Талант
    Нанимайте технических специалистов и создавайте свой бренд работодателя

  5. Реклама
    Обратитесь к разработчикам и технологам со всего мира

  6. О компании

.

oracle — узнать историю SQL-запросов

Переполнение стека

  1. Около

  2. Продукты

  3. Для команд

  1. Переполнение стека
    Общественные вопросы и ответы

  2. Переполнение стека для команд
    Где разработчики и технологи делятся частными знаниями с коллегами

  3. Вакансии
    Программирование и связанные с ним технические возможности карьерного роста

  4. Талант
    Нанимайте технических специалистов и создавайте свой бренд работодателя

  5. Реклама
    Обратитесь к разработчикам и технологам со всего мира

.

История запросов рабочей среды MySql (последний выполненный запрос / запросы), т.е. создание / изменение таблицы, выбор, вставка запросов на обновление

Переполнение стека

  1. Около

  2. Продукты

  3. Для команд

  1. Переполнение стека
    Общественные вопросы и ответы

  2. Переполнение стека для команд
    Где разработчики и технологи делятся частными знаниями с коллегами

  3. Вакансии
    Программирование и связанные с ним технические возможности карьерного роста

  4. Талант
    Нанимайте технических специалистов и создавайте свой бренд работодателя

  5. Реклама
    Обратитесь к разработчикам и технологам со всего мира

  6. О компании

Загрузка…

  2. Авторизоваться
    зарегистрироваться

.

Как найти несколько последних выполненных запросов в SQL Server?

Как администратору баз данных, вам часто может потребоваться проверить последних выполненных запросов на сервере SQL или в конкретной базе данных. Использование DMV (Dynamaic Management Views) — один из самых простых способов найти недавно выполненные запросы. Конечно, использование DMV не является на 100% надежным, но оно даст вам быстрое представление о запросах, выполненных в недавнем прошлом.

Здесь я перечислю несколько операторов DMV, которые будут полезны при поиске исторических запросов SQL для различных сценариев.

Поиск нескольких последних выполненных запросов ко всем базам данных в SQL Server 

ВЫБРАТЬ
txt.TEXT AS [оператор SQL],
qs.EXECUTION_COUNT [Нет. Раз казнено],
qs.LAST_EXECUTION_TIME AS [последнее выполнение],
DB_NAME (txt.dbid) AS [База данных]
ИЗ SYS.DM_EXEC_QUERY_STATS КАК qs
CROSS APPLY SYS.DM_EXEC_SQL_TEXT (qs.SQL_HANDLE) AS txt
ЗАКАЗАТЬ ПО qs.LAST_EXECUTION_TIME DESC

Против определенной базы данных

Чтобы отфильтровать вышеуказанный запрос для конкретной базы данных, используйте столбец DBID в представлении DM_EXEC_SQL_TEXT.Ниже приведен образец заявления. Остерегайтесь, столбец DBID не всегда будет содержать данные. Существует вероятность того, что DBID столбца имеет нулевое значение, и вы можете пропустить некоторые недавно выполненные операторы для базы данных.

ВЫБРАТЬ
txt.TEXT AS [оператор SQL],
qs.EXECUTION_COUNT [Нет. Раз казнено],
qs.LAST_EXECUTION_TIME AS [последнее выполнение],
DB_NAME (txt.dbid) AS [База данных]
ОТ
SYS.DM_EXEC_QUERY_STATS как qs
CROSS APPLY SYS.DM_EXEC_SQL_TEXT (qs.SQL_HANDLE) AS txt
ГДЕ
txt.dbid = DB_ID ('WideWorldImporters')
ЗАКАЗАТЬ ПО qs.LAST_EXECUTION_TIME DESC

Недостатки

  1. DMV sys.dm_exec_query_stats работает на основе плана запроса в кэше. После того, как план каким-либо образом будет удален из кеша, представление не вернет запрос. Так что этот метод ненадежный.
  2. Столбец dbid в sysdm_exec_sql_text может содержать нулевое значение. Поэтому использование его для подачи запросов, выполняемых к конкретной базе данных, ненадежно.

Другие параметры

  • Один из способов найти несколько последних выполненных запросов — это использовать трассировку на стороне сервера в течение короткого времени и собрать выполненные операторы SQL.
  • Самый лучший и надежный метод — использовать расширенные события.

Ссылка:

  • Подробная информация о dmv в Microsoft docs.

.

No related posts.

Share :

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *