Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 На что обратить внимание при иследовании SQL?  [new]
dark_DBa_dmin
Member

Откуда:
Сообщений: 105
В общем скоро необходимо будет исследовать SQL в сторонней конторе (т.е. в качестве приглашенного специалиста) и выдать рекомендации (по оптимизации, расположению файлов, планов обслуживания и т.д.), не разу не работал в таком ключе, вопрос к тем у кого есть опыт, на что в первую очередь обратить внимание?
6 ноя 15, 05:21    [18376286]     Ответить | Цитировать Сообщить модератору
 Re: На что обратить внимание при иследовании SQL?  [new]
Jaffar
Member

Откуда:
Сообщений: 633
dark_DBa_dmin,

поговори с заказчиком, узнай что его беспокоит?
начни с того что запусти профайлер который отловит тяжелые запросы.
потом отлови самые критичные запросы и попытайся их оптимизировать.
6 ноя 15, 06:12    [18376302]     Ответить | Цитировать Сообщить модератору
 Re: На что обратить внимание при иследовании SQL?  [new]
dark_DBa_dmin
Member

Откуда:
Сообщений: 105
Jaffar
dark_DBa_dmin,

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



Спасибо. Благо мне не надо будет оптимизировать, мне надо будет показать на их косяки и проблемы, а дальше они как-нибудь сами.
Кстати, по поводу тяжелых запросов, допустим есть долгий запрос который выполняется раз в месяц (допустим отчет какой нибудь), так как он выполняется редко план может быть удален из кеша и с помощью того же sys.dm_exec_query_stats посмотреть данные не выйдет (а заказчик молчит, может их устраивает что отчет формируется несколько часов и они просто привыкли.) вопрос: можно ли как нибудь отловить тяжелые но редкие запросы, если план был удален из кеша?
6 ноя 15, 06:33    [18376311]     Ответить | Цитировать Сообщить модератору
 Re: На что обратить внимание при иследовании SQL?  [new]
Jaffar
Member

Откуда:
Сообщений: 633
dark_DBa_dmin,

нужно выполнять.

можно заранее попросить их запустить профайлер в табличку - и потом посмотреть.
Про большой отчет: Главное не объем данных а правильно построенный план - для этого нужно знать бизнес логику отчета.
Если не разбираться а дать какие-то общие рекомендации - это не особо поможет если случай не совсем запущенный.

Хотя если в качестве эксперта приглашают человека который этого ни разу не делал - значит общие рекомендации все таки могут помочь.
6 ноя 15, 08:19    [18376414]     Ответить | Цитировать Сообщить модератору
 Re: На что обратить внимание при иследовании SQL?  [new]
o-o
Guest
Jaffar
можно заранее попросить их запустить профайлер в табличку - и потом посмотреть

Из всех возможных вариантов выбрал с максимальной нагрузкой
Это в книгу вредных советов надо
А если товарищам дорога производительность,
после такого совета не только рекомендацию лесом пошлют, но и советчика тоже
sql-server-profiler-or-server-side-trace
Never trace directly to a table
6 ноя 15, 09:05    [18376520]     Ответить | Цитировать Сообщить модератору
 Re: На что обратить внимание при иследовании SQL?  [new]
dark_DBa_dmin
Member

Откуда:
Сообщений: 105
Jaffar
dark_DBa_dmin,

нужно выполнять.

можно заранее попросить их запустить профайлер в табличку - и потом посмотреть.
Про большой отчет: Главное не объем данных а правильно построенный план - для этого нужно знать бизнес логику отчета.
Если не разбираться а дать какие-то общие рекомендации - это не особо поможет если случай не совсем запущенный.

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


По поводу отчета, это был вопрос на отвлеченную тему, что называется для себя.
Просто они могут и не знать что отчет может выполняться быстрее и их все устраивает (я как то был в конторе и у них в условии использовалась функция, запрос выполнялся недолго и всех все устраивало, естественно когда поменяли условие чтобы можно было использовать индексы стало намного быстрее).
Им и нужны общие рекомендации, допустим у них бекапы на одном серваке с базой лежат и другие очевидные моменты.
Если лезть в отчеты, разбираться с бизнес логикой, это уже совсем другая работа.
6 ноя 15, 09:14    [18376570]     Ответить | Цитировать Сообщить модератору
 Re: На что обратить внимание при иследовании SQL?  [new]
dark_DBa_dmin
Member

Откуда:
Сообщений: 105
o-o
Jaffar
можно заранее попросить их запустить профайлер в табличку - и потом посмотреть

Из всех возможных вариантов выбрал с максимальной нагрузкой
Это в книгу вредных советов надо
А если товарищам дорога производительность,
после такого совета не только рекомендацию лесом пошлют, но и советчика тоже
sql-server-profiler-or-server-side-trace
Never trace directly to a table


Эт понятно, но у них вроде 2012, там есть более "легкий вариант" (расширенные события).
6 ноя 15, 09:17    [18376580]     Ответить | Цитировать Сообщить модератору
 Re: На что обратить внимание при иследовании SQL?  [new]
o-o
Guest
Так это вам понятно.
Но вы же на форуме, а не в личной переписке это обсуждаете.
Тему будут и другие читать.
Поэтому на подобные советы надо писать опровержение
6 ноя 15, 09:26    [18376608]     Ответить | Цитировать Сообщить модератору
 Re: На что обратить внимание при иследовании SQL?  [new]
churupaha
Member

Откуда: Краснодар
Сообщений: 1015
dark_DBa_dmin,

автор
на что в первую очередь обратить внимание?


спросите это у сервера

Wait statistics, or please tell me where it hurts - SQLskills.com

оттуда и пляшите.
6 ноя 15, 10:05    [18376773]     Ответить | Цитировать Сообщить модератору
 Re: На что обратить внимание при иследовании SQL?  [new]
churupaha
Member

Откуда: Краснодар
Сообщений: 1015
В дополнению к куче инфе из интернетов (все в одном месте).

SQL Server 2005 Waits and Queues - Microsoft
Pro SQL Server Wait Statistics
SQL Server: Performance Troubleshooting Using Wait Statistics

Иначе будет похоже на наши больницы, пришел с прибитым пальцем - послали к проктологу.
6 ноя 15, 10:10    [18376799]     Ответить | Цитировать Сообщить модератору
 Re: На что обратить внимание при иследовании SQL?  [new]
dark_DBa_dmin
Member

Откуда:
Сообщений: 105
churupaha
В дополнению к куче инфе из интернетов (все в одном месте).

SQL Server 2005 Waits and Queues - Microsoft
Pro SQL Server Wait Statistics
SQL Server: Performance Troubleshooting Using Wait Statistics

Иначе будет похоже на наши больницы, пришел с прибитым пальцем - послали к проктологу.


Спасибо!
6 ноя 15, 10:15    [18376814]     Ответить | Цитировать Сообщить модератору
 Re: На что обратить внимание при иследовании SQL?  [new]
Winnipuh
Member [заблокирован]

Откуда: Київ
Сообщений: 10428
churupaha
В дополнению к куче инфе из интернетов (все в одном месте).

SQL Server 2005 Waits and Queues - Microsoft
Pro SQL Server Wait Statistics
SQL Server: Performance Troubleshooting Using Wait Statistics

Иначе будет похоже на наши больницы, пришел с прибитым пальцем - послали к проктологу.


зы. он точно определит почему палец поврежден
6 ноя 15, 12:34    [18377618]     Ответить | Цитировать Сообщить модератору
 Re: На что обратить внимание при иследовании SQL?  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 8807
Я знаю, что у MS есть набор средств для исследований сервера, в том числе они используют счетчики производительности, проверяют систему безопасности, индексы в базах, флаги трассировки и много еще чего. Но где их взять - не знаю.
6 ноя 15, 12:50    [18377723]     Ответить | Цитировать Сообщить модератору
 Re: На что обратить внимание при иследовании SQL?  [new]
Minamoto
Member

Откуда: Москва
Сообщений: 1162
dark_DBa_dmin,

1) Модели восстановления баз и историю создания бэкапов.
Как часто делаются, какие делаются, не вылезают ли за пределы технологических перерывов (к полным относится). Проверяете - все ли настроено корректно (нет ли базовых ошибок типа полной модели и отсутствия бэкапа лога) и на основании истории вычисляете RPO и RTO и спрашиваете - действительно ли бизнесу подходят такие значения
2) Смотрите наличие планов обслуживания на перестройку индексов, на пересчет статистик - смотрите, насколько "умные" эти планы, вовремя ли выполняются (не вылезают ли за пределы технологических перерывов).
3) как выше уже сказали - статистику ожиданий посмотреть
4) посмотреть статистику по дискам - как там с временем ожидания
+
-- Плохо: Ср.задержка одной операции > 20 мсек
USE master
GO
SELECT cast(db_name(a.database_id) AS VARCHAR) AS Database_Name
	 , b.physical_name
	 --, a.io_stall
	 , a.size_on_disk_bytes
	 , a.io_stall_read_ms / a.num_of_reads 'Ср.задержка одной операции чтения'
	 , a.io_stall_write_ms / a.num_of_writes 'Ср.задержка одной операции записи'
	 --, *
FROM
	sys.dm_io_virtual_file_stats(NULL, NULL) a
	INNER JOIN sys.master_files b
		ON a.database_id = b.database_id AND a.file_id = b.file_id
where num_of_writes > 0 and num_of_reads > 0
ORDER BY
	Database_Name
  , a.io_stall DESC

5) Недостающие индексы - рекомендации от базы данных
+
SELECT 
  migs.avg_total_user_cost * (migs.avg_user_impact / 100.0) * (migs.user_seeks + migs.user_scans) AS improvement_measure, 
  'CREATE INDEX [missing_index_' + CONVERT (varchar, mig.index_group_handle) + '_' + CONVERT (varchar, mid.index_handle) 
  + '_' + LEFT (PARSENAME(mid.statement, 1), 32) + ']'
  + ' ON ' + mid.statement 
  + ' (' + ISNULL (mid.equality_columns,'') 
    + CASE WHEN mid.equality_columns IS NOT NULL AND mid.inequality_columns IS NOT NULL THEN ',' ELSE '' END 
    + ISNULL (mid.inequality_columns, '')
  + ')' 
  + ISNULL (' INCLUDE (' + mid.included_columns + ')', '') AS create_index_statement, 
  migs.*, mid.database_id, mid.[object_id]
FROM sys.dm_db_missing_index_groups mig
INNER JOIN sys.dm_db_missing_index_group_stats migs ON migs.group_handle = mig.index_group_handle
INNER JOIN sys.dm_db_missing_index_details mid ON mig.index_handle = mid.index_handle
WHERE migs.avg_total_user_cost * (migs.avg_user_impact / 100.0) * (migs.user_seeks + migs.user_scans) > 10
  and database_id = DB_ID()
ORDER BY migs.avg_total_user_cost * migs.avg_user_impact * (migs.user_seeks + migs.user_scans) DESC

6) Лишние индексы - в которые пишут, но из которых не читают:
+
SELECT   OBJECT_NAME(i.object_id) AS [Table Name],
         i.name AS [Not Used Index Name],
         case when i.is_unique = 1 then 'UNIQUE ' else '' end + i.type_desc,
         s.last_user_update AS [Last Update Time],
         s.user_updates AS [Updates]--, i.*
FROM     sys.dm_db_index_usage_stats AS s
JOIN     sys.indexes AS i
ON       i.object_id = s.object_id
AND      i.index_id = s.index_id
JOIN     sys.objects AS o
ON       o.object_id = s.object_id
WHERE    s.database_id = DB_ID()
AND      (    user_scans   = 0
          AND user_seeks   = 0
          AND user_lookups = 0
          AND last_user_scan   IS NULL
          AND last_user_seek   IS NULL
          AND last_user_lookup IS NULL 
         )
AND      OBJECTPROPERTY(i.[object_id],         'IsSystemTable'   ) = 0
AND      INDEXPROPERTY (i.[object_id], i.name, 'IsAutoStatistics') = 0
AND      INDEXPROPERTY (i.[object_id], i.name, 'IsHypothetical'  ) = 0
AND      INDEXPROPERTY (i.[object_id], i.name, 'IsStatistics'    ) = 0
AND      INDEXPROPERTY (i.[object_id], i.name, 'IsFulltextKey'   ) = 0
AND		 i.is_primary_key = 0
AND      (i.index_id between 2 AND 250 OR (i.index_id=1 AND OBJECTPROPERTY(i.[object_id],'IsView')=1))
AND      o.type <> 'IT'
ORDER BY Updates desc , OBJECT_NAME(i.object_id) 


Ну и дальше по ситуации - трассировку по проблемным местам, и т.д.
6 ноя 15, 14:09    [18378466]     Ответить | Цитировать Сообщить модератору
 Re: На что обратить внимание при иследовании SQL?  [new]
o-o
Guest
Minamoto,
по пункту 4) пожелание: убрать sys.master_files.
для sys.dm_io_virtual_file_stats хватит VIEW SERVER STATE,
в то время как sys.master_files:
The minimum permissions that are required to see the corresponding row are CREATE DATABASE, ALTER ANY DATABASE, or VIEW ANY DEFINITION.
т.е. имеющий лишь VIEW SERVER STATE получит пустой набор
6 ноя 15, 14:20    [18378582]     Ответить | Цитировать Сообщить модератору
 Re: На что обратить внимание при иследовании SQL?  [new]
o-o
Guest
трындец, товарищи,
наше темпдб -- чемпион в запросе 4).
наверное, его сглазили.
"заблокировали"!!!
я даже знаю, кто
Лунтик, аууу!!!
---
теперь я в нерешительности.
какую икону должно показывать tempdb в OE?
по запросу "blocked" гугл выдал много картинок,
например, вот
+

Картинка с другого сайта.

+
Картинка с другого сайта.

обе подходят по смыслу, я аж разрываюсь
(а диски у них и правда стремные)

К сообщению приложен файл. Размер - 53Kb
6 ноя 15, 14:54    [18378834]     Ответить | Цитировать Сообщить модератору
 Re: На что обратить внимание при иследовании SQL?  [new]
Minamoto
Member

Откуда: Москва
Сообщений: 1162
o-o
Minamoto,
по пункту 4) пожелание: убрать sys.master_files.
для sys.dm_io_virtual_file_stats хватит VIEW SERVER STATE,
в то время как sys.master_files:
The minimum permissions that are required to see the corresponding row are CREATE DATABASE, ALTER ANY DATABASE, or VIEW ANY DEFINITION.
т.е. имеющий лишь VIEW SERVER STATE получит пустой набор

Если человека приглашают провести аудит, наверное, дадут ему прав достаточно? :)
А так - согласен -если прав не хватает - можно закомментировать, как вы сделали.
6 ноя 15, 16:00    [18379424]     Ответить | Цитировать Сообщить модератору
 Re: На что обратить внимание при иследовании SQL?  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4893
o-o
Jaffar
можно заранее попросить их запустить профайлер в табличку - и потом посмотреть

Из всех возможных вариантов выбрал с максимальной нагрузкой
Это в книгу вредных советов надо
А если товарищам дорога производительность,
после такого совета не только рекомендацию лесом пошлют, но и советчика тоже
sql-server-profiler-or-server-side-trace
Never trace directly to a table


+1

Я очень большой любитель профайлера. Прямо сейчас у меня их 5 штук запущено на разных серверах. Но никогда я не сохраняю трассу напрямую в таблицу.
6 ноя 15, 16:26    [18379640]     Ответить | Цитировать Сообщить модератору
 Re: На что обратить внимание при иследовании SQL?  [new]
o-o
Guest
ой, тут в соседней теме права дают вообще всем,
так что я ничему не удивляюсь.
IMHO: все равно лучше писать запросы под минимальные права
вот, например, тоже хотят, чтобы мониторили, но без админских прав
Activity monitor - можно ли настроить просмотр CPU, I\O без админских прав?
и это правильно.
название-то какое говорящее, VIEW SERVER STATE.
для мониторинга и придумали
6 ноя 15, 16:32    [18379684]     Ответить | Цитировать Сообщить модератору
 Re: На что обратить внимание при иследовании SQL?  [new]
komrad
Member

Откуда:
Сообщений: 5736
dark_DBa_dmin
В общем скоро необходимо будет исследовать SQL в сторонней конторе (т.е. в качестве приглашенного специалиста) и выдать рекомендации (по оптимизации, расположению файлов, планов обслуживания и т.д.), не разу не работал в таком ключе, вопрос к тем у кого есть опыт, на что в первую очередь обратить внимание?


для начала можно запустить Microsoft Best Practices Analyzer
http://sqlmag.com/blog/microsoft-sql-server-2012-best-practices-analyzer-bpa
6 ноя 15, 17:41    [18380168]     Ответить | Цитировать Сообщить модератору
 Re: На что обратить внимание при иследовании SQL?  [new]
Ant76
Member

Откуда: Санкт-Петербург
Сообщений: 37
dark_DBa_dmin,
попробуйте поработать с рекомендациями вот этого господина
http://www.brentozar.com/first-aid/sql-server-downloads/
6 ноя 15, 18:54    [18380522]     Ответить | Цитировать Сообщить модератору
 Re: На что обратить внимание при иследовании SQL?  [new]
Eleanor
Member

Откуда:
Сообщений: 3420
Еще можно заглянуть в error log. Иногда там встречаются интересные вещи типа:

- * BEGIN STACK DUMP
- Autogrow of file 'ххх' in database 'ххх' took 171531 milliseconds
- 40 occurrence(s) of I/O requests taking longer than 15 seconds to complete
7 ноя 15, 00:19    [18381912]     Ответить | Цитировать Сообщить модератору
 Re: На что обратить внимание при иследовании SQL?  [new]
dark_DBa_dmin
Member

Откуда:
Сообщений: 105
Minamoto
dark_DBa_dmin,

1) Модели восстановления баз и историю создания бэкапов.
Как часто делаются, какие делаются, не вылезают ли за пределы технологических перерывов (к полным относится). Проверяете - все ли настроено корректно (нет ли базовых ошибок типа полной модели и отсутствия бэкапа лога) и на основании истории вычисляете RPO и RTO и спрашиваете - действительно ли бизнесу подходят такие значения
2) Смотрите наличие планов обслуживания на перестройку индексов, на пересчет статистик - смотрите, насколько "умные" эти планы, вовремя ли выполняются (не вылезают ли за пределы технологических перерывов).
3) как выше уже сказали - статистику ожиданий посмотреть
4) посмотреть статистику по дискам - как там с временем ожидания
+
-- Плохо: Ср.задержка одной операции > 20 мсек
USE master
GO
SELECT cast(db_name(a.database_id) AS VARCHAR) AS Database_Name
	 , b.physical_name
	 --, a.io_stall
	 , a.size_on_disk_bytes
	 , a.io_stall_read_ms / a.num_of_reads 'Ср.задержка одной операции чтения'
	 , a.io_stall_write_ms / a.num_of_writes 'Ср.задержка одной операции записи'
	 --, *
FROM
	sys.dm_io_virtual_file_stats(NULL, NULL) a
	INNER JOIN sys.master_files b
		ON a.database_id = b.database_id AND a.file_id = b.file_id
where num_of_writes > 0 and num_of_reads > 0
ORDER BY
	Database_Name
  , a.io_stall DESC

5) Недостающие индексы - рекомендации от базы данных
+
SELECT 
  migs.avg_total_user_cost * (migs.avg_user_impact / 100.0) * (migs.user_seeks + migs.user_scans) AS improvement_measure, 
  'CREATE INDEX [missing_index_' + CONVERT (varchar, mig.index_group_handle) + '_' + CONVERT (varchar, mid.index_handle) 
  + '_' + LEFT (PARSENAME(mid.statement, 1), 32) + ']'
  + ' ON ' + mid.statement 
  + ' (' + ISNULL (mid.equality_columns,'') 
    + CASE WHEN mid.equality_columns IS NOT NULL AND mid.inequality_columns IS NOT NULL THEN ',' ELSE '' END 
    + ISNULL (mid.inequality_columns, '')
  + ')' 
  + ISNULL (' INCLUDE (' + mid.included_columns + ')', '') AS create_index_statement, 
  migs.*, mid.database_id, mid.[object_id]
FROM sys.dm_db_missing_index_groups mig
INNER JOIN sys.dm_db_missing_index_group_stats migs ON migs.group_handle = mig.index_group_handle
INNER JOIN sys.dm_db_missing_index_details mid ON mig.index_handle = mid.index_handle
WHERE migs.avg_total_user_cost * (migs.avg_user_impact / 100.0) * (migs.user_seeks + migs.user_scans) > 10
  and database_id = DB_ID()
ORDER BY migs.avg_total_user_cost * migs.avg_user_impact * (migs.user_seeks + migs.user_scans) DESC

6) Лишние индексы - в которые пишут, но из которых не читают:
+
SELECT   OBJECT_NAME(i.object_id) AS [Table Name],
         i.name AS [Not Used Index Name],
         case when i.is_unique = 1 then 'UNIQUE ' else '' end + i.type_desc,
         s.last_user_update AS [Last Update Time],
         s.user_updates AS [Updates]--, i.*
FROM     sys.dm_db_index_usage_stats AS s
JOIN     sys.indexes AS i
ON       i.object_id = s.object_id
AND      i.index_id = s.index_id
JOIN     sys.objects AS o
ON       o.object_id = s.object_id
WHERE    s.database_id = DB_ID()
AND      (    user_scans   = 0
          AND user_seeks   = 0
          AND user_lookups = 0
          AND last_user_scan   IS NULL
          AND last_user_seek   IS NULL
          AND last_user_lookup IS NULL 
         )
AND      OBJECTPROPERTY(i.[object_id],         'IsSystemTable'   ) = 0
AND      INDEXPROPERTY (i.[object_id], i.name, 'IsAutoStatistics') = 0
AND      INDEXPROPERTY (i.[object_id], i.name, 'IsHypothetical'  ) = 0
AND      INDEXPROPERTY (i.[object_id], i.name, 'IsStatistics'    ) = 0
AND      INDEXPROPERTY (i.[object_id], i.name, 'IsFulltextKey'   ) = 0
AND		 i.is_primary_key = 0
AND      (i.index_id between 2 AND 250 OR (i.index_id=1 AND OBJECTPROPERTY(i.[object_id],'IsView')=1))
AND      o.type <> 'IT'
ORDER BY Updates desc , OBJECT_NAME(i.object_id) 


Ну и дальше по ситуации - трассировку по проблемным местам, и т.д.


Спасибо. По поводу индексов, я тут как то поднимал тему, какой индекс считать лишним, если в него 100000 раз пишут и 1-5 читают, он лишний или нет? Конечно, если эти 1-5 это какой нибудь отчет, то он будет делаться намного медленее без индекса, но тут вопрос что важнее, несколько раз в месяц подольше подождать отчет или что запись может идти чуть дольше. Очень часто встречал БД где индексы были добавлены везде где их можно добавить, на вопрос зачем обычно отвечают: а че, так быстрее же.
9 ноя 15, 07:57    [18387183]     Ответить | Цитировать Сообщить модератору
 Re: На что обратить внимание при иследовании SQL?  [new]
o-o
Guest
dark_DBa_dmin,

Если это отчет, выполняющийся раз в месяц,
можно ровно под него и создавать индекс,
дропая его после отчета
9 ноя 15, 09:14    [18387299]     Ответить | Цитировать Сообщить модератору
 Re: На что обратить внимание при иследовании SQL?  [new]
dark_DBa_dmin
Member

Откуда:
Сообщений: 105
o-o
dark_DBa_dmin,

Если это отчет, выполняющийся раз в месяц,
можно ровно под него и создавать индекс,
дропая его после отчета


В принципе как вариант. Еще вопрос когда индекс можно удалять, т.е. какой период можно считать для индекса грубо говоря критичным чтобы удалить его. Допустим у нас есть статистика по исп. индексов за 3 месяца и за это время есть индексы которые не разу не использовались, то скорее всего их можно удалять или подождать еще, или его можно было удалить раньше?
С базами с которыми сейчас работаю я такие индексы есть и их довольно много, но их не дают удалять разработчики, а руки чешутся.
9 ноя 15, 09:47    [18387447]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить