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

Откуда: Издалека долго
Сообщений: 1205
Господа, добрый вечер. Прошу дать совет
Исходные данные
есть таблица с логами
create table dbo.tLogs
(id dsidentifier identity not null
,ObjType int not tull
,DateStart datetime not null
,DateEnd datetime 
,infoObj varchar(300)
,nameObj varchar(40)
,constraint pktLogs primary key (id))
пока в ней пара десятков тестовых дынных, на бою ожидается их большой прирост
есть запрос вида
select ObjType,  
         DateStart, 
         DateEnd, 
         infoObj 
 from tLogs 
where nameObj = @nameObj  /*уникальных значений не больше 10 000*/
  and ObjType = @ObjType      /*уникальных значений не больше 20*/
  and DateStart >= @DateStart  /*@DateStart всегда равна getdate() минус пара часов*/ 
  and DateEnd > @DateEnd /*@DateEnd всегда равна getdate() минус пара часов, но она больше @DateStart*/

Предикаты можно поменять местами, составной индекс на таблице пока один - на полях id, ObjType
Сторонние запросы к данной таблице используют лишь индекс описанный выше.
Верным ли будет создать такой составной индекс или есть более приемлемые вариации?
create index someindname
   on dbo.tLogs(nameObj, ObjType, DateStart, DateEnd) 
with (fillfactor = 80)
16 май 18, 17:10    [21414371]     Ответить | Цитировать Сообщить модератору
 Re: Правильное создание индекса  [new]
invm
Member

Откуда: Москва
Сообщений: 9345
шК0ДЕР,

create index someindname
   on dbo.tLogs(nameObj, ObjType, DateStart) include (DateEnd, infoObj);
16 май 18, 17:55    [21414519]     Ответить | Цитировать Сообщить модератору
 Re: Правильное создание индекса  [new]
шК0ДЕР
Member

Откуда: Издалека долго
Сообщений: 1205
invm, благодарю!
17 май 18, 08:01    [21415570]     Ответить | Цитировать Сообщить модератору
 Re: Правильное создание индекса  [new]
.Евгений
Member

Откуда:
Сообщений: 514
шК0ДЕР,

Также для большинства случаев рекомендую страничное сжатие, как индекса, так и самой таблицы (data_compression = page).
17 май 18, 12:57    [21416723]     Ответить | Цитировать Сообщить модератору
 Re: Правильное создание индекса  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6801
.Евгений
шК0ДЕР,

Также для большинства случаев рекомендую страничное сжатие, как индекса, так и самой таблицы (data_compression = page).

это кто такое рекомендует?
17 май 18, 13:02    [21416750]     Ответить | Цитировать Сообщить модератору
 Re: Правильное создание индекса  [new]
.Евгений
Member

Откуда:
Сообщений: 514
TaPaK
.Евгений
шК0ДЕР,

Также для большинства случаев рекомендую страничное сжатие, как индекса, так и самой таблицы (data_compression = page).

это кто такое рекомендует?

Это я такое рекомендую.
17 май 18, 13:29    [21416830]     Ответить | Цитировать Сообщить модератору
 Re: Правильное создание индекса  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7754
.Евгений,

нагруженные таблицы-то лучше не жать.
17 май 18, 13:32    [21416846]     Ответить | Цитировать Сообщить модератору
 Re: Правильное создание индекса  [new]
.Евгений
Member

Откуда:
Сообщений: 514
Владислав Колосов
.Евгений,
нагруженные таблицы-то лучше не жать.

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

Копать глубже и рассматривать прирост нагрузки в разрезе ресурсов мне сейчас лень. Может, TaPaK соберет стенд и статистику выполнения?
17 май 18, 13:53    [21416958]     Ответить | Цитировать Сообщить модератору
 Re: Правильное создание индекса  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6801
.Евгений
Владислав Колосов
.Евгений,
нагруженные таблицы-то лучше не жать.

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

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

зачем, я точно никому не рекомендую, никогда. Разве что с местом проблемы(в 2018 году :))
17 май 18, 14:12    [21417068]     Ответить | Цитировать Сообщить модератору
 Re: Правильное создание индекса  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 36968
TaPaK
зачем, я точно никому не рекомендую, никогда. Разве что с местом проблемы(в 2018 году :))
Выигрыш по месту -- это минимальное из преимуществ сжатия (хотя кому как -- место на производительных но маленьких SSD тоже важно не транжирить). При этом так же экономятся iops'ы и память.
17 май 18, 14:15    [21417083]     Ответить | Цитировать Сообщить модератору
 Re: Правильное создание индекса  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6801
Гавриленко Сергей Алексеевич
TaPaK
зачем, я точно никому не рекомендую, никогда. Разве что с местом проблемы(в 2018 году :))
Выигрыш по месту -- это минимальное из преимуществ сжатия (хотя кому как -- место на производительных но маленьких SSD тоже важно не транжирить). При этом так же экономятся iops'ы и память.

и платим за всё это cpu
17 май 18, 14:19    [21417097]     Ответить | Цитировать Сообщить модератору
 Re: Правильное создание индекса  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 36968
TaPaK
Гавриленко Сергей Алексеевич
пропущено...
Выигрыш по месту -- это минимальное из преимуществ сжатия (хотя кому как -- место на производительных но маленьких SSD тоже важно не транжирить). При этом так же экономятся iops'ы и память.

и платим за всё это cpu
Ну так не у всех же дефицит CPU, а всего остального навалом.
17 май 18, 14:37    [21417203]     Ответить | Цитировать Сообщить модератору
 Re: Правильное создание индекса  [new]
invm
Member

Откуда: Москва
Сообщений: 9345
.Евгений
В большинстве случаев нагрузка логирования не превышает считанных процентов от общей нагрузки на систему. Крохотное увеличение нагрузки при записи будет более чем компенсировано приростом скорости чтения лога.
Вы точно знаете как работает сжатие? Для чего предназначен лог и как он работает? Когда физически пишутся страницы данных/индексов в БД?
+
use msdb;
set xact_abort, nocount on;
go

print @@version;

create table dbo.tr (id tinyint, description varchar(30), elapsed_time int, log_bytes_used bigint);

create table dbo.t1 (id int identity, s varchar(50));
alter table dbo.t1 add constraint PK_t1 primary key clustered (id);

create table dbo.t2 (id int identity, s varchar(50));
alter table dbo.t2 add constraint PK_t2 primary key clustered (id) with (data_compression = page);

create table dbo.t3 (id int identity, s varchar(50));
alter table dbo.t3 add constraint PK_t3 primary key clustered (id) with (data_compression = row);
go

declare @dt datetime2 = sysdatetime(), @c int = 1000000;

begin tran;

while @c > 0
 begin
  insert into dbo.t1 values (cast(newid() as varchar(36)));
  select @c -= 1;
 end;

insert into dbo.tr
select
 1, 'data_compression = none', datediff(ms, @dt, sysdatetime()), sum(dbt.database_transaction_log_bytes_used + dbt.database_transaction_log_bytes_used_system)
from
 sys.dm_tran_current_transaction ct join
 sys.dm_tran_database_transactions dbt on dbt.transaction_id = ct.transaction_id

commit;
go

declare @dt datetime2 = sysdatetime(), @c int = 1000000;

begin tran;

while @c > 0
 begin
  insert into dbo.t2 values (cast(newid() as varchar(36)));
  select @c -= 1;
 end;

insert into dbo.tr
select
 2, 'data_compression = page', datediff(ms, @dt, sysdatetime()), sum(dbt.database_transaction_log_bytes_used + dbt.database_transaction_log_bytes_used_system)
from
 sys.dm_tran_current_transaction ct join
 sys.dm_tran_database_transactions dbt on dbt.transaction_id = ct.transaction_id

commit;
go


declare @dt datetime2 = sysdatetime(), @c int = 1000000;

begin tran;

while @c > 0
 begin
  insert into dbo.t3 values (cast(newid() as varchar(36)));
  select @c -= 1;
 end;

insert into dbo.tr
select
 3, 'data_compression = row', datediff(ms, @dt, sysdatetime()), sum(dbt.database_transaction_log_bytes_used + dbt.database_transaction_log_bytes_used_system)
from
 sys.dm_tran_current_transaction ct join
 sys.dm_tran_database_transactions dbt on dbt.transaction_id = ct.transaction_id

commit;
go

select
 tr.*,
 cast(tr.elapsed_time * 100. / a.min_elapsed_time - 100. as money) elapsed_time_impact_percent,
 cast(tr.log_bytes_used * 100. / a.max_log_bytes_used - 100. as money) log_bytes_used_impact_percent
from
 dbo.tr cross apply
 (select min(elapsed_time), min(log_bytes_used) from dbo.tr) a(min_elapsed_time, max_log_bytes_used)
order
 by id;
go

drop table dbo.tr, dbo.t1, dbo.t2, dbo.t3;
go

Microsoft SQL Server 2008 R2 (SP3) - 10.50.6220.0 (X64) 
Mar 19 2015 12:32:14
Copyright (c) Microsoft Corporation
Developer Edition (64-bit) on Windows NT 6.3 <X64> (Build 17134: ) (Hypervisor)
descriptionelapsed_timelog_bytes_usedelapsed_time_impact_percentlog_bytes_used_impact_percent
data_compression = none51901731167720,002,6408
data_compression = page727216866265640,11560,00
data_compression = row673216866265629,7110,00


Microsoft SQL Server 2017 (RTM-CU4) (KB4056498) - 14.0.3022.28 (X64) 
Feb 9 2018 19:39:09
Copyright (C) 2017 Microsoft Corporation
Developer Edition (64-bit) on Windows 10 Pro 10.0 <X64> (Build 17134: ) (Hypervisor)
descriptionelapsed_timelog_bytes_usedelapsed_time_impact_percentlog_bytes_used_impact_percent
data_compression = none68461767626640,002,7216
data_compression = page874017207964827,66580,0002
data_compression = row835017207930021,9690,00

17 май 18, 14:52    [21417278]     Ответить | Цитировать Сообщить модератору
 Re: Правильное создание индекса  [new]
.Евгений
Member

Откуда:
Сообщений: 514
invm
.Евгений
В большинстве случаев нагрузка логирования не превышает считанных процентов от общей нагрузки на систему. Крохотное увеличение нагрузки при записи будет более чем компенсировано приростом скорости чтения лога.
Вы точно знаете как работает сжатие? Для чего предназначен лог и как он работает?

Я говорил про пользовательское логирование (шК0ДЕР - "...есть таблица с логами..."). Либо вы несколько поспешили, либо я выразился недостаточно определенно - выбирайте любой вариант.
17 май 18, 15:06    [21417369]     Ответить | Цитировать Сообщить модератору
 Re: Правильное создание индекса  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31355
Гавриленко Сергей Алексеевич
TaPaK
зачем, я точно никому не рекомендую, никогда. Разве что с местом проблемы(в 2018 году :))
Выигрыш по месту -- это минимальное из преимуществ сжатия (хотя кому как -- место на производительных но маленьких SSD тоже важно не транжирить). При этом так же экономятся iops'ы и память.
Что то я тоже разочаровался в сжатии. Самое большое разочарование - вставка данных, там не то, что "требует CPU", а оно просто упирается в одно ядро, и производительность снижается катастрофически. Использую только ради места на дисках.
17 май 18, 15:36    [21417523]     Ответить | Цитировать Сообщить модератору
 Re: Правильное создание индекса  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31355
alexeyvg
Самое большое разочарование - вставка данных, там не то, что "требует CPU", а оно просто упирается в одно ядро, и производительность снижается катастрофически
Особенно BULK - получить вместо 500 гб/с только 5 - это само собой, бай дизайн.
17 май 18, 15:38    [21417528]     Ответить | Цитировать Сообщить модератору
 Re: Правильное создание индекса  [new]
invm
Member

Откуда: Москва
Сообщений: 9345
.Евгений
Я говорил про пользовательское логирование
Тем более.
А рекомендовать что-то, не зная как это работает и не сделав хотя бы раз нагрузочное тестирование на конкретной системе - удел бустобрехов, вроде некоторых самопровозглашенных "экспертов".
17 май 18, 17:07    [21417929]     Ответить | Цитировать Сообщить модератору
 Re: Правильное создание индекса  [new]
.Евгений
Member

Откуда:
Сообщений: 514
invm
.Евгений
Я говорил про пользовательское логирование
Тем более.
А рекомендовать что-то, не зная как это работает и не сделав хотя бы раз нагрузочное тестирование на конкретной системе - удел бустобрехов, вроде некоторых самопровозглашенных "экспертов".

Подчеркну специально для вас: моя рекомендация относилась к большинству случаев возможных вариантов использования логирования, описанного в первом сообщении. И добавлю: прежде всего к тем вариантам, которые мне кажутся естественными, типичными и ожидаемыми для пользовательского логирования.
Разумеется, можно придумать ситуации и наборы данных, когда сжатие практически не даст положительного эффекта, зато проявит все отрицательные. Например, когда вся деятельность системы шК0ДЕР-а будет заключаться в пакетной вставке почти не повторяющихся данных (в рамках страницы) в таблицу лога, запросам к ней, и ничего сверх того. Но я не ставил себе задачей подобное фантазирование и считаю свою оговорку про большинство случаев вполне достаточной.
Наконец, мне показалось, что вы захотели обосновать мою некомпетентность в теме сжатия данных MS SQL единственной, хотя и очень веской фразой "Тем более". Извините, но я не смог увидеть в ней ничего похожего на аргументацию даже при максимальной снисходительности. Я допускаю, что вы можете считать нецелесообразным сжатие таблицы логирования в большинстве типичных случаев, но мне это не мешает. Некоторые наши современники даже верят в плоскую Землю.
17 май 18, 18:58    [21418305]     Ответить | Цитировать Сообщить модератору
 Re: Правильное создание индекса  [new]
invm
Member

Откуда: Москва
Сообщений: 9345
.Евгений
Наконец, мне показалось, что вы захотели обосновать мою некомпетентность
Обычно собственную компетентность доказывают чем-то большим, чем словоизвержением ни о чем, в стиле "эффективных менеджеров" с "видением". А делать это, как вы честно написали, - лень.
17 май 18, 20:02    [21418505]     Ответить | Цитировать Сообщить модератору
 Re: Правильное создание индекса  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31355
.Евгений
считаю свою оговорку про большинство случаев вполне достаточной
Не знаю, как конкретно у ТС, но "в большинстве случаев" логирование предполагает запись, не предполагает частое чтение, и не предполагает хранение за большое время.
Соответственно, странно было прочитать ваше "Крохотное увеличение нагрузки при записи будет более чем компенсировано приростом скорости чтения лога."
17 май 18, 20:48    [21418575]     Ответить | Цитировать Сообщить модератору
 Re: Правильное создание индекса  [new]
.Евгений
Member

Откуда:
Сообщений: 514
invm
.Евгений
Наконец, мне показалось, что вы захотели обосновать мою некомпетентность
Обычно собственную компетентность доказывают чем-то большим, чем словоизвержением ни о чем, в стиле "эффективных менеджеров" с "видением". А делать это, как вы честно написали, - лень.

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

Я бы слегка поспорил с "большим временем хранения". Какое оно имеет отношение к теме? Важен объем данных, а он не мал: требуется не просто индекс, а оптимизированный индекс. Миллионы строк? Но главнее другое - отмечена важность быстрого чтения лога.

Теперь по записи. Характерным для логирования я бы назвал другие признаки: во-первых, оно вставляет в таблицу одну строку и bulk insert здесь не применяется. Во-вторых, оно неразрывно связано с действием, ресурсозатратным относительно логирования и не должно его значимо замедлять. Приняв это за норму, поставлю вопрос: какова доля операций вставки в таблицу логирования в общей нагрузке сервера? Какую разницу мы увидим между действиями с логированием в несжатую и сжатую таблицу? А примерно следующую: 1 секунда действия + 100 микросекунд логирования против 1 секунды действия + 200 микросекунд логирования. Другими словами, разницу малую и размазанную по времени, а потому малую пренебрежимо.
17 май 18, 21:34    [21418665]     Ответить | Цитировать Сообщить модератору
 Re: Правильное создание индекса  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31355
.Евгений
Я бы слегка поспорил с "большим временем хранения". Какое оно имеет отношение к теме? Важен объем данных, а он не мал
Важно, будет ли профит от использования сжатия в виде уменьшения стоимости хранилища. Если храним мало, то стоимость низкая, и этот + сжатия можно не учитывать.
.Евгений
Важен объем данных, а он не мал: требуется не просто индекс, а оптимизированный индекс.
Сжатие к оптимальному индексу не имеет отношения. Самый оптимальный индекс предложен invm в первом же ответе в теме.
.Евгений
Теперь по записи. Характерным для логирования я бы назвал другие признаки: во-первых, оно вставляет в таблицу одну строку и bulk insert здесь не применяется
Само собой, это был просто крик души про сжатие :-)
.Евгений
Приняв это за норму, поставлю вопрос: какова доля операций вставки в таблицу логирования в общей нагрузке сервера? Какую разницу мы увидим между действиями с логированием в несжатую и сжатую таблицу? А примерно следующую: 1 секунда действия + 100 микросекунд логирования против 1 секунды действия + 200 микросекунд логирования. Другими словами, разницу малую и размазанную по времени, а потому малую пренебрежимо.
Я лучше приму другую норму - 100 микросекунд действия + 100 микросекунд логирования.
.Евгений
Но главнее другое - отмечена важность быстрого чтения лога.
Отмечена необходимость быстрого выполнения запроса на выборку.
Про "соотношение чтения и записи" автор не говорил, возможно, оно такое же, как в типичных системах - на миллион запросов на вставку один запрос на чтение.
Вам "лень", вы советуете "собрать стенд", но даже не потрудились спросить у ТС об этом.
И тем более непонятно выглядит "в большинстве случаев".
Сколько видел систем, всегда чтение из логов происходит по письму больших начальников при разборках "кто виноват", "а я этого не вводила", "откуда тут НДС?", раз в месяц. А лог пишется 10 000 раз в секунду. Легко вычислить соотношение, типичное для "большинства систем".
17 май 18, 22:25    [21418817]     Ответить | Цитировать Сообщить модератору
 Re: Правильное создание индекса  [new]
.Евгений
Member

Откуда:
Сообщений: 514
alexeyvg
.Евгений
Важен объем данных, а он не мал: требуется не просто индекс, а оптимизированный индекс.
Сжатие к оптимальному индексу не имеет отношения. Самый оптимальный индекс предложен invm в первом же ответе в теме.

Да что вы говорите?! А затраты на чтение сжатого и несжатого индекса не имеют какого-либо отношения к оптимальности (в случае, когда он занимает несколько страниц)? Как же он оптимален, если его читать дольше?
alexeyvg
.Евгений
Но главнее другое - отмечена важность быстрого чтения лога.
Отмечена необходимость быстрого выполнения запроса на выборку.
Про "соотношение чтения и записи" автор не говорил...

Перечитайте мою фразу и заметьте - я тоже про него не говорил!
Возможно, что лог читается раз в сутки. Однако оптимизируют именно это единственное (или не единственное) чтение, а не запись. Отмечу, что шК0ДЕР не делал оговорки относительно границы допустимого торможения записи в лог. Ну и?
alexeyvg
Я лучше приму другую норму - 100 микросекунд действия + 100 микросекунд логирования.

Положа руку на сердце, вы всерьез считаете подобное соотношение действия и логирования типичным? Поскольку равное по времени логирование - это один insert, то вы постулируете логирование каждого отдельного оператора SQL.
alexeyvg
А лог пишется 10 000 раз в секунду. Легко вычислить соотношение, типичное для "большинства систем".

10 000 * 86 400 секунд = практически неуправляемая таблица, если не чистится каждые сутки. Извините, здесь я могу только процитировать великого поэта: "Печально я гляжу на наше поколенье! Его грядущее - иль пусто, иль темно..." В такой лог действительно смотрят исключительно из-под палки. Это действительно типично для большинства систем, с которыми вы имели дело? С моим профессиональным опытом это категорически расходится.
17 май 18, 23:18    [21418954]     Ответить | Цитировать Сообщить модератору
 Re: Правильное создание индекса  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31355
.Евгений
alexeyvg
Я лучше приму другую норму - 100 микросекунд действия + 100 микросекунд логирования.

Положа руку на сердце, вы всерьез считаете подобное соотношение действия и логирования типичным? Поскольку равное по времени логирование - это один insert, то вы постулируете логирование каждого отдельного оператора SQL.
Ок, логирование нескольких операций. Но часто бывало и один на один, и даже несколько записей в лог на одну запись в рабочие таблицы.
Однако соотношение всё таки не 20000:1, как у вас.

.Евгений
alexeyvg
А лог пишется 10 000 раз в секунду. Легко вычислить соотношение, типичное для "большинства систем".

10 000 * 86 400 секунд = практически неуправляемая таблица, если не чистится каждые сутки. Извините, здесь я могу только процитировать великого поэта: "Печально я гляжу на наше поколенье! Его грядущее - иль пусто, иль темно..." В такой лог действительно смотрят исключительно из-под палки. Это действительно типично для большинства систем, с которыми вы имели дело? С моим профессиональным опытом это категорически расходится.
Видимо да, расходимся, у меня системы были высоконагруженные, работали надёжно, так что читать из лога приходилось редко, причём, как вы говорите, "из-под палки", то есть выполняя запросы бизнеса по исследованию какого то редкого инцидента, а не просто из любопытства или хулиганства.
.Евгений
10 000 * 86 400 секунд = практически неуправляемая таблица
Да, интересно ваше замечание, что значит "неуправляемая"? Из неё запрос нельзя сделать, что ли?
Нормально всё "управляется", не такая большая таблица, хранить можно столько, сколько скажет бизнес, технических ограничений тут нет, соответственно, в таких случаях это решает бизнес, а не технический специалист. Впрочем, если хранить такой лог, например, год, тогда уже можно подумать о сжатии.
17 май 18, 23:36    [21418996]     Ответить | Цитировать Сообщить модератору
 Re: Правильное создание индекса  [new]
.Евгений
Member

Откуда:
Сообщений: 514
alexeyvg
Ок, логирование нескольких операций. Но часто бывало и один на один, и даже несколько записей в лог на одну запись в рабочие таблицы.
Однако соотношение всё таки не 20000:1, как у вас.

Тогда взгляните на это с другой стороны. Сопоставимая нагрузка действий и их логирования означает, что оптимизация последнего посредством исключения избыточных сведений означает соответствующий рост производительности системы. Утрируя, на одном и том же оборудовании одновременно обслуживается тысяча клиентов с полным логированием, или две тысячи - с сокращенным. А то и больше. Или бизнесу неведомо, что такое стоимость владения?
alexeyvg
Видимо да, расходимся, у меня системы были высоконагруженные, работали надёжно, так что читать из лога приходилось редко, причём, как вы говорите, "из-под палки", то есть выполняя запросы бизнеса по исследованию какого то редкого инцидента, а не просто из любопытства или хулиганства.

Любопытство или хулиганство здесь не при чем. Хороший лог обеспечивает легкую и удобную локализацию любой мнимой или реальной проблемы с данными или производительностью. Кому-то не нравится цифра, результат действий или время реакции - лог покажет, кем, какие и когда элементы системы (хп, задачи и т.п.) были запущены, с какими аргументами и в какой последовательности, свяжет их с интерфейсом или конкретными процессами. В подавляющем большинстве случаев этого достаточно для воспроизведения и дальнейшего анализа проблемы. Дальнейшая детализация в логе возможна только по отдельному запросу. Так я делал сам, такой же подход видел в чужих системах, с которыми приходилось работать.
alexeyvg
Да, интересно ваше замечание, что значит "неуправляемая"? Из неё запрос нельзя сделать, что ли?

Потому что с таблицей в миллиарды записей и более нельзя произвести ad-hoc действия за разумное время. Ходить можно только по дорожкам индексов, сошел с них - сиди и жди. Можешь час ждать, можешь более. Да и индексы не панацея - уровней больше, бегать дольше. Неуправляемую глыбу можно послать в оперативу, кубы или какую-нибудь бигдатую систему, но зачем? Надо просто взять и отсечь лишнее - 99 и 9 в периоде процентов.
18 май 18, 00:28    [21419089]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить