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

Откуда: урал
Сообщений: 2846
Имеется сервер работающий медленно. Я запустил вот такой простой тест

create table Test(id int, descr varchar(100))

set nocount on

declare @i int
declare @d datetime
set @i = 0
set @d = getdate()

while @i < 500000
begin
insert into Test values(@i, 'xxx')
set @i = @i + 1
end

select datediff(ms, @d, getdate()) as InsertTime

select count(*) from Test
where id > 50000

select datediff(ms, @d, getdate()) as SelectTime



отрабатывает за 11 минут. На моем рабочем компьютере это занимает 3 минуты. Можно-ли сказать что именно тормозит и где?

Проблема сервера в том, что он на виртуальной машине, и узнать какие именно ресурсы ей выделены сложно т.к. это стоит у клиентов. Вот такой скрипт:

SELECT total_physical_memory_kb, available_physical_memory_kb, 
total_page_file_kb, available_page_file_kb, 
system_memory_state_desc
FROM sys.dm_os_sys_memory ;


показывает 30Гб общей памяти и 8 гиг свободной, т.е. вроде дело не в оперативке

Скрипт показывающий задержки чтения/записи (sys.dm_io_virtual_file_stats):

ReadLatency WriteLatency Latency
9 22 19
23 11 12
13 8 9
5 7 6
6 7 7


т.е. вроде диски работают быстро. В чем может быть еще проблема и как ее замерить?
19 авг 14, 10:10    [16460464]     Ответить | Цитировать Сообщить модератору
 Re: Тест на производительность  [new]
Crimean
Member

Откуда:
Сообщений: 13147
а процессы ждут чего? а то "медленно" - не совсем "показатель". вот, только что смотрел "зверушку" - тоже "все медленно" (ц), скуль при этом "курит" не затягиваясь, а интервалы между запросами - по 500 ms. теперь сетевик нервно икает :)
19 авг 14, 13:52    [16462373]     Ответить | Цитировать Сообщить модератору
 Re: Тест на производительность  [new]
gandjustas
Member

Откуда:
Сообщений: 857
Блог
stenford
т.е. вроде диски работают быстро. В чем может быть еще проблема и как ее замерить?

Берешь запрос отсюда: http://www.sqlskills.com/blogs/paul/wait-statistics-or-please-tell-me-where-it-hurts/
Запускаешь и показываешь результаты.
19 авг 14, 17:32    [16464093]     Ответить | Цитировать Сообщить модератору
 Re: Тест на производительность  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4823
Хорошо и как это интерпретировать?

CXPACKET38316228.2337996011.79320216.44115772670364.150.03310.03280.0003
PAGEIOLATCH_SH14460100.3714452402.327698.055117472124.210.28260.28240.0002
LATCH_EX1541756.701531287.8510468.85220765162.580.06980.06940.0005
TRACEWRITE706380.19706064.74315.458611901.180.82020.81990.0004
BACKUPIO689031.75688804.78226.9881893271.150.08410.08410.0000
PAGEIOLATCH_EX687707.03687489.49217.5451829041.150.13270.13260.0000
IO_COMPLETION684939.00684673.13265.8858149031.150.11780.11770.0000


IF OBJECT_ID ('tempdb..#T') IS NOT NULL 
DROP TABLE #T 
GO 

	SELECT
        [wait_type],
        [wait_time_ms] / 1000.0 AS [WaitS],
        ([wait_time_ms] - [signal_wait_time_ms]) / 1000.0 AS [ResourceS],
        [signal_wait_time_ms] / 1000.0 AS [SignalS],
        [waiting_tasks_count] AS [WaitCount],
        100.0 * [wait_time_ms] / SUM ([wait_time_ms]) OVER() AS [Percentage],
        ROW_NUMBER() OVER(ORDER BY [wait_time_ms] DESC) AS [RowNum]
  INTO #T
    FROM sys.dm_os_wait_stats
    WHERE [wait_type] NOT IN (
        N'BROKER_EVENTHANDLER',         N'BROKER_RECEIVE_WAITFOR',
        N'BROKER_TASK_STOP',            N'BROKER_TO_FLUSH',
        N'BROKER_TRANSMITTER',          N'CHECKPOINT_QUEUE',
        N'CHKPT',                       N'CLR_AUTO_EVENT',
        N'CLR_MANUAL_EVENT',            N'CLR_SEMAPHORE',
        N'DBMIRROR_DBM_EVENT',          N'DBMIRROR_EVENTS_QUEUE',
        N'DBMIRROR_WORKER_QUEUE',       N'DBMIRRORING_CMD',
        N'DIRTY_PAGE_POLL',             N'DISPATCHER_QUEUE_SEMAPHORE',
        N'EXECSYNC',                    N'FSAGENT',
        N'FT_IFTS_SCHEDULER_IDLE_WAIT', N'FT_IFTSHC_MUTEX',
        N'HADR_CLUSAPI_CALL',           N'HADR_FILESTREAM_IOMGR_IOCOMPLETION',
        N'HADR_LOGCAPTURE_WAIT',        N'HADR_NOTIFICATION_DEQUEUE',
        N'HADR_TIMER_TASK',             N'HADR_WORK_QUEUE',
        N'KSOURCE_WAKEUP',              N'LAZYWRITER_SLEEP',
        N'LOGMGR_QUEUE',                N'ONDEMAND_TASK_QUEUE',
        N'PWAIT_ALL_COMPONENTS_INITIALIZED',
        N'QDS_PERSIST_TASK_MAIN_LOOP_SLEEP',
        N'QDS_CLEANUP_STALE_QUERIES_TASK_MAIN_LOOP_SLEEP',
        N'REQUEST_FOR_DEADLOCK_SEARCH', N'RESOURCE_QUEUE',
        N'SERVER_IDLE_CHECK',           N'SLEEP_BPOOL_FLUSH',
        N'SLEEP_DBSTARTUP',             N'SLEEP_DCOMSTARTUP',
        N'SLEEP_MASTERDBREADY',         N'SLEEP_MASTERMDREADY',
        N'SLEEP_MASTERUPGRADED',        N'SLEEP_MSDBSTARTUP',
        N'SLEEP_SYSTEMTASK',            N'SLEEP_TASK',
        N'SLEEP_TEMPDBSTARTUP',         N'SNI_HTTP_ACCEPT',
        N'SP_SERVER_DIAGNOSTICS_SLEEP', N'SQLTRACE_BUFFER_FLUSH',
        N'SQLTRACE_INCREMENTAL_FLUSH_SLEEP',
        N'SQLTRACE_WAIT_ENTRIES',       N'WAIT_FOR_RESULTS',
        N'WAITFOR',                     N'WAITFOR_TASKSHUTDOWN',
        N'WAIT_XTP_HOST_WAIT',          N'WAIT_XTP_OFFLINE_CKPT_NEW_LOG',
        N'WAIT_XTP_CKPT_CLOSE',         N'XE_DISPATCHER_JOIN',
        N'XE_DISPATCHER_WAIT',          N'XE_TIMER_EVENT')
    ;

WITH [Waits] AS
    (SELECT * FROM #T)
SELECT
    [W1].[wait_type] AS [WaitType],
    CAST ([W1].[WaitS] AS DECIMAL (16, 2)) AS [Wait_S],
    CAST ([W1].[ResourceS] AS DECIMAL (16, 2)) AS [Resource_S],
    CAST ([W1].[SignalS] AS DECIMAL (16, 2)) AS [Signal_S],
    [W1].[WaitCount] AS [WaitCount],
    CAST ([W1].[Percentage] AS DECIMAL (5, 2)) AS [Percentage],
    CAST (([W1].[WaitS] / [W1].[WaitCount]) AS DECIMAL (16, 4)) AS [AvgWait_S],
    CAST (([W1].[ResourceS] / [W1].[WaitCount]) AS DECIMAL (16, 4)) AS [AvgRes_S],
    CAST (([W1].[SignalS] / [W1].[WaitCount]) AS DECIMAL (16, 4)) AS [AvgSig_S]
FROM [Waits] AS [W1]
INNER JOIN [Waits] AS [W2]
    ON [W2].[RowNum] <= [W1].[RowNum]
GROUP BY [W1].[RowNum], [W1].[wait_type], [W1].[WaitS],
    [W1].[ResourceS], [W1].[SignalS], [W1].[WaitCount], [W1].[Percentage]
HAVING SUM ([W2].[Percentage]) - [W1].[Percentage] < 95; -- percentage threshold
GO
19 авг 14, 17:44    [16464198]     Ответить | Цитировать Сообщить модератору
 Re: Тест на производительность  [new]
NickAlex66
Member

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

Вообще-то в статье довольно подробно описан ваш случай: If this (CXPACKET) is combined with a high number of PAGEIOLATCH_XX waits, it could be large parallel table scans going on because of incorrect non-clustered indexes, or a bad query plan.
19 авг 14, 21:52    [16465224]     Ответить | Цитировать Сообщить модератору
 Re: Тест на производительность  [new]
stenford
Member

Откуда: урал
Сообщений: 2846
gandjustas
Берешь запрос отсюда: http://www.sqlskills.com/blogs/paul/wait-statistics-or-please-tell-me-where-it-hurts/
Запускаешь и показываешь результаты.


Результаты ниже. Еще стоит сказать что проблема однозначно где-то в ресурсах, т.е. либо процессора нехватает, либо диски либо что-то еще из подобного. Можно что-то сказать по этим данным?

К сообщению приложен файл. Размер - 93Kb
20 авг 14, 09:38    [16466300]     Ответить | Цитировать Сообщить модератору
 Re: Тест на производительность  [new]
stenford
Member

Откуда: урал
Сообщений: 2846
Согласно гуглу:

PAGEIOLATCH_SH: Occurs when a task is waiting on a latch for a buffer that is in an I/O request. The latch request is in Shared mode. Long waits may indicate problems with the disk subsystem.
PAGEIOLATCH_EX: is a wait event often seen in SQL Server related to I/O, It actually corresponds to an "Exclusive I/O page latch".


т.е. типа дисковая система медленная? Но проблема в том, что вот такой запрос:

SELECT
    --virtual file latency
    [ReadLatency] =
        CASE WHEN [num_of_reads] = 0
            THEN 0 ELSE ([io_stall_read_ms] / [num_of_reads]) END,
    [WriteLatency] =
        CASE WHEN [num_of_writes] = 0
            THEN 0 ELSE ([io_stall_write_ms] / [num_of_writes]) END,
    [Latency] =
        CASE WHEN ([num_of_reads] = 0 AND [num_of_writes] = 0)
            THEN 0 ELSE ([io_stall] / ([num_of_reads] + [num_of_writes])) END,
    --avg bytes per IOP
    [AvgBPerRead] =
        CASE WHEN [num_of_reads] = 0
            THEN 0 ELSE ([num_of_bytes_read] / [num_of_reads]) END,
    [AvgBPerWrite] =
        CASE WHEN [num_of_writes] = 0
            THEN 0 ELSE ([num_of_bytes_written] / [num_of_writes]) END,
    [AvgBPerTransfer] =
        CASE WHEN ([num_of_reads] = 0 AND [num_of_writes] = 0)
            THEN 0 ELSE
                (([num_of_bytes_read] + [num_of_bytes_written]) /
                ([num_of_reads] + [num_of_writes])) END,
    LEFT ([mf].[physical_name], 2) AS [Drive],
    DB_NAME ([vfs].[database_id]) AS [DB],
    --[vfs].*,
    [mf].[physical_name]
FROM
    sys.dm_io_virtual_file_stats (NULL,NULL) AS [vfs]
JOIN sys.master_files AS [mf]
    ON [vfs].[database_id] = [mf].[database_id]
    AND [vfs].[file_id] = [mf].[file_id]
ORDER BY [WriteLatency] DESC;
GO


возвращает:


ReadLatency WriteLatency Latency
9 22 19
23 11 12
13 8 9
5 7 6
6 7 7



т.е. вроде диски не такие и медленные? Может процессор виноват? Можно как-то замерить нехватку процессорной мощности?
20 авг 14, 09:52    [16466347]     Ответить | Цитировать Сообщить модератору
 Re: Тест на производительность  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31823
stenford
отрабатывает за 11 минут. На моем рабочем компьютере это занимает 3 минуты. Можно-ли сказать что именно тормозит и где?
Для одного потока мелких транзакций часто десктопы быстрее сервера, из за более агрессивного кеширования записи.

Проверьте это, заключив тестовый скрипт в BEGIN TRANSACTION ... COMMIT TRANSACTION

Возможно, на сервере в рейд-контроллере нет батарейки для кеширования записи, или она разрядилась, или эта опция отключена.
20 авг 14, 10:41    [16466596]     Ответить | Цитировать Сообщить модератору
 Re: Тест на производительность  [new]
gandjustas
Member

Откуда:
Сообщений: 857
Блог
stenford,

Запросы не оптимизированные. Излишний параллелизм вызван отсутствием индексов\статистики или кривыми предикатами. Большой объем чтения и свободной оперативке - активная работа с tempdb, что скорее всего тоже следствие неэффективных запросов.
20 авг 14, 10:48    [16466651]     Ответить | Цитировать Сообщить модератору
 Re: Тест на производительность  [new]
stenford
Member

Откуда: урал
Сообщений: 2846
alexeyvg
Для одного потока мелких транзакций часто десктопы быстрее сервера, из за более агрессивного кеширования записи.

Проверьте это, заключив тестовый скрипт в BEGIN TRANSACTION ... COMMIT TRANSACTION

Возможно, на сервере в рейд-контроллере нет батарейки для кеширования записи, или она разрядилась, или эта опция отключена.


добалвление транзакции действительно увеличило скорость, на моем компе это стало несколько секунд, на сервере по прежнему несколько минут. Но какие выводы-то из этого? На тестовом сервере это все равно работает куда быстрее чем на кластере (5 мин против 11 минут), т.е. наш тестовый север получается в 2 раза быстрее производственного кластера?
20 авг 14, 11:02    [16466734]     Ответить | Цитировать Сообщить модератору
 Re: Тест на производительность  [new]
stenford
Member

Откуда: урал
Сообщений: 2846
gandjustas
stenford,

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


там работает типовая система, как-бы неоптимизированна она не была - на других серверах она работает куда быстрее. Отличие данного сервера - что это кластер (hyper-v), и сиквел работает на виртуальной машине. Соответственно есть подозрение что машине не дали достаточно ресурсов. Я и пытаюсь теперь определить каких ресурсов ей может нехватать. Вот например может процессора ей дали мало? Можно это как-нибудь поймать какими-нибудь запросами? Или все-таки дисковая система у кластера перегружена и он медленно обслуживает нашу машину?
20 авг 14, 11:02    [16466743]     Ответить | Цитировать Сообщить модератору
 Re: Тест на производительность  [new]
gandjustas
Member

Откуда:
Сообщений: 857
Блог
stenford,

Вывод такой - на кластере есть нагрузка, а на тестовом сервере нет.
20 авг 14, 11:04    [16466756]     Ответить | Цитировать Сообщить модератору
 Re: Тест на производительность  [new]
gandjustas
Member

Откуда:
Сообщений: 857
Блог
stenford
gandjustas
stenford,

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


там работает типовая система, как-бы неоптимизированна она не была - на других серверах она работает куда быстрее. Отличие данного сервера - что это кластер (hyper-v), и сиквел работает на виртуальной машине. Соответственно есть подозрение что машине не дали достаточно ресурсов. Я и пытаюсь теперь определить каких ресурсов ей может нехватать. Вот например может процессора ей дали мало? Можно это как-нибудь поймать какими-нибудь запросами? Или все-таки дисковая система у кластера перегружена и он медленно обслуживает нашу машину?


А с чего вы взяли что проблема в сервере вообще? У вас есть два сервера с этой системой, на них приходит одинаковая нагрузка и один работает заметно медленнее другого? Что с чем вы сравниваете?

Если вам кажется что ресурсов недостаточно, то надо начинать с Resource Monitor и Perforamce Monitor в Windows, это опять-таки нужно делать под реальной нагрузкой.
20 авг 14, 11:08    [16466785]     Ответить | Цитировать Сообщить модератору
 Re: Тест на производительность  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31823
stenford
добалвление транзакции действительно увеличило скорость, на моем компе это стало несколько секунд, на сервере по прежнему несколько минут.
Хм, странно, должны были по крайней мере сравняться.

А очереди к дискам какие?
NickAlex66
Вообще-то в статье довольно подробно описан ваш случай: If this (CXPACKET) is combined with a high number of PAGEIOLATCH_XX waits, it could be large parallel table scans going on because of incorrect non-clustered indexes, or a bad query plan.
Да какие там распараллеливания для такого теста... Разве что другая нагрузка ещё есть, от неё тормозит.
20 авг 14, 11:08    [16466789]     Ответить | Цитировать Сообщить модератору
 Re: Тест на производительность  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31823
stenford
Вот например может процессора ей дали мало?
Так надо посмотреть нагрузку на процессор.
20 авг 14, 11:09    [16466793]     Ответить | Цитировать Сообщить модератору
 Re: Тест на производительность  [new]
stenford
Member

Откуда: урал
Сообщений: 2846
gandjustas
stenford,

Вывод такой - на кластере есть нагрузка, а на тестовом сервере нет.


насколько я понимаю кластер (там выделены статические ресурсы для виртуальной машины) - не важно насколько он загружен, ресурсы всегда гарантированы. Следовательно, раз производительность низкая - ресурсов дали мало. Вот задача определить каких ресурсов недодали
20 авг 14, 11:09    [16466794]     Ответить | Цитировать Сообщить модератору
 Re: Тест на производительность  [new]
stenford
Member

Откуда: урал
Сообщений: 2846
gandjustas
А с чего вы взяли что проблема в сервере вообще? У вас есть два сервера с этой системой, на них приходит одинаковая нагрузка и один работает заметно медленнее другого? Что с чем вы сравниваете?

Если вам кажется что ресурсов недостаточно, то надо начинать с Resource Monitor и Perforamce Monitor в Windows, это опять-таки нужно делать под реальной нагрузкой.

типовая система стоит грубо говоря у десятков разных клиентов, и мы знаем что при указанных параметрах железа - она должна работать быстрее, грубо говоря у меня на лэптопе она отрабатывает быстрее чем производственный кластер. Т.е. проблема должна быть в выделенных ресурсах
20 авг 14, 11:16    [16466843]     Ответить | Цитировать Сообщить модератору
 Re: Тест на производительность  [new]
gandjustas
Member

Откуда:
Сообщений: 857
Блог
stenford,

Откуда вы знаете? Кому должна?

Обычно есть входные характеристики и выходные.

Входные - количество запросов, объем данных, количество соединений.
Выходные - потребление процессора, памяти, интенсивность работы с диском.

Чтобы не сравнивать яблоки с автомобилями надо чтобы входные характеристики на обоих системах (тестовой и продуктивной) были одинаковые. Или у вас должны быть замеры выходных параметров при варьировании входных в разных окружениях.
20 авг 14, 11:29    [16466925]     Ответить | Цитировать Сообщить модератору
 Re: Тест на производительность  [new]
gandjustas
Member

Откуда:
Сообщений: 857
Блог
stenford
gandjustas
stenford,

Вывод такой - на кластере есть нагрузка, а на тестовом сервере нет.


насколько я понимаю кластер (там выделены статические ресурсы для виртуальной машины) - не важно насколько он загружен, ресурсы всегда гарантированы. Следовательно, раз производительность низкая - ресурсов дали мало. Вот задача определить каких ресурсов недодали


При такой постановке вопроса можно было тему не начинать. Вы же сами в начале написали что памяти с головой хватает, поэтому надо увеличивать процессоры и диски. Но если процессоров можно просто добавить, то сделать диски в два раза быстрее нельзя. Кроме того неэффективные запросы могут съесть любой прирост мощностей без заметного увеличения производительности.
20 авг 14, 11:33    [16466963]     Ответить | Цитировать Сообщить модератору
 Re: Тест на производительность  [new]
stenford
Member

Откуда: урал
Сообщений: 2846
gandjustas
stenford,

Откуда вы знаете? Кому должна?

Обычно есть входные характеристики и выходные.

Входные - количество запросов, объем данных, количество соединений.
Выходные - потребление процессора, памяти, интенсивность работы с диском.

Чтобы не сравнивать яблоки с автомобилями надо чтобы входные характеристики на обоих системах (тестовой и продуктивной) были одинаковые. Или у вас должны быть замеры выходных параметров при варьировании входных в разных окружениях.


ну по опыту знаем. Сейчас например на кластере крутиться джоб по загрузке данных, он стандартный у всех киентов вообще, т.е. абсолютно одинаковая нагрузка с моим лэптопом, вообще один в один т.к. к кластеру пока никакие клиенты не присоединяются, а джоб одинаковый, и файлы грузит одинаковые по одинаковому алгоритму. Но работает медленно, причем в разы. Значит кластер виноват, ну не могу я больше никаких обьяснений этому придумать. А как именно настроена виртуалка - я не знаю т.к. у меня нет доступа к ихней админской консоли.
Остается только хитрыми запросами из-под самого сиквела выяснять где затык. Вот выяснил что оперативки достатотно, значит дело не в ней. Остается диск и процессор. Надо каким-то образом понять кто из них виноват, или оба сразу
20 авг 14, 11:36    [16466987]     Ответить | Цитировать Сообщить модератору
 Re: Тест на производительность  [new]
stenford
Member

Откуда: урал
Сообщений: 2846
gandjustas
При такой постановке вопроса можно было тему не начинать. Вы же сами в начале написали что памяти с головой хватает, поэтому надо увеличивать процессоры и диски. Но если процессоров можно просто добавить, то сделать диски в два раза быстрее нельзя. Кроме того неэффективные запросы могут съесть любой прирост мощностей без заметного увеличения производительности.


так вот я и пытаюсь понять кто именно - проц или диски. Вот по запросам которые приведены сверху вроде основное время ожидания - диски, но средняя скорость чтения/записи вроде нормальная - несколько миллисекунд.
А как можно из скуля выяснить что там с процессором?
20 авг 14, 11:39    [16467019]     Ответить | Цитировать Сообщить модератору
 Re: Тест на производительность  [new]
gandjustas
Member

Откуда:
Сообщений: 857
Блог
stenford,

wait stats недвусмысленно говорит нам, что там далеко не только загрузка файла работает. Так что или вы что-то не знаете и не договариваете.
20 авг 14, 11:39    [16467021]     Ответить | Цитировать Сообщить модератору
 Re: Тест на производительность  [new]
stenford
Member

Откуда: урал
Сообщений: 2846
gandjustas
stenford,

wait stats недвусмысленно говорит нам, что там далеко не только загрузка файла работает. Так что или вы что-то не знаете и не договариваете.

"загрузка файла" - означает что есть джоб, который последовательно читает текстовый файл и распихивает его по таблицам. Я не могу точно сказать какой там при этом процент селектов/инсертов, вродеинсертов длжно быть больше, но необязательно, т.к. там всякие расчеты этой информации ведуться перед тем как ее записать в таблицы
20 авг 14, 11:43    [16467058]     Ответить | Цитировать Сообщить модератору
 Re: Тест на производительность  [new]
stenford
Member

Откуда: урал
Сообщений: 2846
а все-таки, по этим данным, медленные диски или нет? Говорят-ли эти цифры что-нибудь про их производительность?
20 авг 14, 11:53    [16467161]     Ответить | Цитировать Сообщить модератору
 Re: Тест на производительность  [new]
gandjustas
Member

Откуда:
Сообщений: 857
Блог
stenford
а все-таки, по этим данным, медленные диски или нет? Говорят-ли эти цифры что-нибудь про их производительность?


Ничего не говорят, их только в сравнении можно оценивать.
На тестовом сервере какие цифры?
20 авг 14, 12:05    [16467286]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить