Перейти из форума на сайт.

Новости • Файловые архивы
Поиск • Активные темы • Топ лист
Правила • Кто в on-line?
Вход • Забыли пароль? • Первый раз на этом сайте? • Регистрация
Компьютерный форум Ru.Board » Компьютеры » Прикладное программирование » SQL запрос
помогите создать запрос

Модерирует : ShIvADeSt

 Версия для печати • Подписаться • Добавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46

Открыть новую тему     Написать ответ в эту тему

Mavrikii

Platinum Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
ArkadyKiller

Цитата:
Однако в данной таблице уже существует некластеризованный индекс

индекс индексу - рознь. обычно зависит от того, какие столбцы, в каком порядке.
Всего записей: 16875 | Зарегистр. 20-09-2014 | Отправлено: 07:33 17-12-2025
ArkadyKiller



Advanced Member		Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Mavrikii
а что сделать? какой дать ему индекс?
Всего записей: 899 | Зарегистр. 28-09-2006 | Отправлено: 10:59 17-12-2025
Mavrikii

Platinum Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
ArkadyKiller

Цитата:
какой дать ему индекс?

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

Цитата:
USE [KA2]
GO
CREATE NONCLUSTERED INDEX [<Name of Missing Index, sysname,>]
ON [dbo].[_AccumRg89653] ([_RecorderTRef],[_RecorderRRef],[_Fld3201],[_LineNo])

Всего записей: 16875 | Зарегистр. 20-09-2014 | Отправлено: 11:21 17-12-2025
ArkadyKiller



Advanced Member		Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Mavrikii
бро, индекс уже создан _AccumRg89653, там в запрос вместо <Name of Missing Index, sysname,> пишем _AccumRg89653 тот который нужен. то есть, почему скуль не видит его
Всего записей: 899 | Зарегистр. 28-09-2006 | Отправлено: 11:31 17-12-2025 | Исправлено: ArkadyKiller, 11:32 17-12-2025
Mavrikii

Platinum Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
ArkadyKiller

Цитата:
то есть, почему скуль не видит его

возможно в запросе фильтрация по стобцам идет не в том порядке.
я не пользуюсь mssql, но в mysql может быть и так.
Всего записей: 16875 | Зарегистр. 20-09-2014 | Отправлено: 20:21 17-12-2025
CWolfy

Junior Member		Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
ArkadyKiller
Судя по названию - вы пытаетесь вкрячить индекс в БД 1С. ЕМНИП там куча своих особенностей,и сами индексы, опять же ЕМНИМС задаются в ейном конфигураторе.
Навскидку - на инфостарте пишут такое Самые распространенные заблуждения об индексах в мире 1С
Всего записей: 76 | Зарегистр. 15-01-2008 | Отправлено: 10:16 01-01-2026 | Исправлено: CWolfy, 10:17 01-01-2026
ArkadyKiller



Advanced Member		Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
contrafack
Короче вот видео, странное поведение запроса, перевалил за 100%, это что вообще такое?, можэет кэш сервера MSSQL очистить? ибо кэш 1с сервера чистил.
 
Ссылка на видео
Всего записей: 899 | Зарегистр. 28-09-2006 | Отправлено: 10:34 29-01-2026
contrafack

Silver Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
ArkadyKiller
 
Вот рекомендации от GPT:

Как правильно поймать проблему
 
Смотреть в момент нагрузки:
 
В пиковое время, когда пользователи жалуются.
Или запустить тестовую нагрузку, которая повторяет проблему.
Использовать динамические представления:
 

Код:
-- Статистика latch за всё время
SELECT wait_type, waiting_tasks_count, wait_time_ms, max_wait_time_ms
FROM sys.dm_os_wait_stats
WHERE wait_type LIKE 'PAGELATCH%'
ORDER BY wait_time_ms DESC;
 

 
Здесь видно, какой тип latch и сколько миллисекунд накоплено.
 
Мониторинг с 1С / SQL Profiler / Extended Events:
 
Настроить XE-сессию на wait_info или sql_statement_completed.
Сохранять запросы, которые вызывают latch.
 
Вывод:
 
Пусто в sys.dm_os_waiting_tasks — это нормально, если сейчас нет нагрузки.
 
Проблему нужно ловить в момент, когда реально тормозит сервер.
 
Альтернатива: смотреть накопленные wait_stats для анализа тенденции.
 
Если хочешь, я могу написать готовый скрипт Extended Events, который будет ловить PAGELATCH для базы 1С, чтобы не пропустить момент, когда сервер «зависает». Это прям в стиле «ловим проблему на лету».
 
Хочешь такой скрипт?
Всего записей: 3528 | Зарегистр. 21-04-2008 | Отправлено: 10:34 29-01-2026
ArkadyKiller



Advanced Member		Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
contrafack
сейчас не пиковое время, сейчас вяло вяло работают, а этот запрос висит с 9-10 часов
 

 
суть тет не в пайдж латч, а то что запрос этот как-то странно выполняется, прям ваще я хз, такого не было, только вот сегодня заметил.
 
у меня сегодня засирался Buffer Latch, однако когда я рестартанул агента сервера 1с и очистил его кэш, стало работать нормально, а вот этот запрос который в видео, прям странный он, мне он не нравится совсем
Всего записей: 899 | Зарегистр. 28-09-2006 | Отправлено: 10:35 29-01-2026 | Исправлено: ArkadyKiller, 10:42 29-01-2026
contrafack

Silver Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
ArkadyKiller
 
То, что на первом месте PAGELATCH_EX с waiting_tasks_count = 80 532 и суммарным временем ожидания 348 050 ms (~5,8 минут), а максимальное ожидание 231 568 ms (~3,8 минуты), говорит о том, что на сервере действительно была сильная конкуренция за страницы в буфере.

Что это значит:
 
PAGELATCH_EX — это эксклюзивный latch, который возникает при модификации страниц в памяти (например, при вставках/обновлениях в таблицах или индексах).
Высокий waiting_tasks_count &#8594; много сессий пытались одновременно писать в одни и те же страницы.
Высокий max_wait_time_ms &#8594; были запросы, которые реально зависали почти на 4 минуты.
 
Где копать
 
Определяем проблемные таблицы/индексы
Чаще всего это:
 
"горячие" таблицы 1С с большим числом одновременных обновлений.
Индексы, которые узкие и «плотно упакованы» &#8594; блокировка страниц.
Скрипт, чтобы найти, на какие объекты лочатся PAGELATCH_EX:

Код:
 
SELECT  
    t.name AS TableName,
    i.name AS IndexName,
    p.partition_id,
    p.page_id,
    COUNT(*) AS LatchCount
FROM sys.dm_os_buffer_descriptors bd
JOIN sys.allocation_units au ON bd.allocation_unit_id = au.allocation_unit_id
JOIN sys.partitions p ON au.container_id = p.hobt_id
JOIN sys.tables t ON p.object_id = t.object_id
LEFT JOIN sys.indexes i ON p.object_id = i.object_id AND p.index_id = i.index_id
WHERE bd.database_id = DB_ID('ИмяВашейБазы')
GROUP BY t.name, i.name, p.partition_id, p.page_id
ORDER BY LatchCount DESC;
 

 
Это покажет «горячие» страницы, по которым идёт конкуренция.
 
Посмотреть текущие тяжелые запросы 1С
 

Код:
SELECT  
    r.session_id,
    r.status,
    r.blocking_session_id,
    r.wait_type,
    r.wait_time,
    r.cpu_time,
    r.total_elapsed_time,
    t.text AS QueryText
FROM sys.dm_exec_requests r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t
WHERE r.database_id = DB_ID('ИмяВашейБазы')
ORDER BY r.cpu_time DESC;

 
 
С помощью этого можно увидеть, какой конкретно SELECT / UPDATE / INSERT вызывает нагрузку.
Часто это именно запросы 1С типа «распределение» или массовые операции по бухгалтерским регистрам.
 
Профилирование с Extended Events
 
Ловим wait_info и sql_statement_completed с фильтром по вашей базе.
Сохраняем в файл и анализируем позже, чтобы понять: какие запросы реально «подвешивают» сервер.
 
 
Вывод / рекомендации на основе этих цифр:
 
Проблема не в дисках и не в памяти, а именно в конкуренции за страницы в буфере.
Основные точки оптимизации:
Разделение «горячих» таблиц или индексов (например, на более узкие индексы, меньше блокировки страниц).
Оптимизация тяжелых запросов 1С (ограничение выборок, использование индексов).
Возможно, увеличение MAXDOP или настройка параллелизма для распределения нагрузки.
Всего записей: 3528 | Зарегистр. 21-04-2008 | Отправлено: 10:50 29-01-2026
ArkadyKiller



Advanced Member		Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
contrafack
вот результат запроса, там как раз этот ИД77 тяжелый запрос и светитсмя
 

 
максдоп стоит 1
 
 
в 1с вот это задание выполняется
 
Всего записей: 899 | Зарегистр. 28-09-2006 | Отправлено: 10:58 29-01-2026 | Исправлено: ArkadyKiller, 11:17 29-01-2026
contrafack

Silver Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
ArkadyKiller
 
 
Скинь, пожалуйста, чтобы было видно:
 
session_id
 
status
 
blocking_session_id
 
wait_type
 
wait_time
 
cpu_time
 
total_elapsed_time
 
QueryText
 
Главное, чтобы видно было какие запросы 1С «тормозят» сервер и на какие объекты они работают.
 
P.S. текстом или файлом скинь, чтоб я смог отправить в чат.
Всего записей: 3528 | Зарегистр. 21-04-2008 | Отправлено: 11:14 29-01-2026
ArkadyKiller



Advanced Member		Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
contrafack

Код:
77    running    0    NULL    0    15699911    15700205    (@P1 numeric(10),@P2 numeric(10),@P3 numeric(10))SELECT T1._Q_000_F_002RRef, T1._Q_000_F_003RRef, T1._Q_000_F_004RRef, ISNULL(T3._Fld13651RRef,0x00000000000000000000000000000000), CASE WHEN (ISNULL(T3._Fld13651RRef,0x00000000000000000000000000000000) = 0x8F411131DFD4B8184305C1582EFEFC30) THEN 0x01 ELSE 0x00 END, ISNULL(T3._Fld13650_TYPE,0x01), ISNULL(T3._Fld13650_RTRef,0x00000000), ISNULL(T3._Fld13650_RRRef,0x00000000000000000000000000000000), 0x00000000000000000000000000000000, 0x00000000000000000000000000000000, 0x00000000000000000000000000000000, T2._Fld123660_TYPE, T2._Fld123660_RTRef, T2._Fld123660_RRRef, MIN(T2._Fld123654), MIN(T2._Fld123654), MIN(T2._Fld123664), @P1, 0x00 FROM #tt82 T1 WITH(NOLOCK) INNER JOIN dbo._InfoRg123653X1 T2 ON (T1._Q_000_F_002RRef = T2._Fld123657RRef) AND (T1._Q_000_F_003RRef = T2._Fld123658RRef) AND (T1._Q_000_F_004RRef = T2._Fld123659RRef) LEFT OUTER JOIN dbo._Reference498 T3 ON ((T1._Q_000_F_003RRef = T3._IDRRef)) AND (T3._Fld3201 = @P2) WHERE (T2._Fld3201 = @P3) GROUP BY T1._Q_000_F_002RRef, T1._Q_000_F_003RRef, T1._Q_000_F_004RRef, ISNULL(T3._Fld13651RRef,0x00000000000000000000000000000000), CASE WHEN (ISNULL(T3._Fld13651RRef,0x00000000000000000000000000000000) = 0x8F411131DFD4B8184305C1582EFEFC30) THEN 0x01 ELSE 0x00 END, ISNULL(T3._Fld13650_TYPE,0x01), ISNULL(T3._Fld13650_RTRef,0x00000000), ISNULL(T3._Fld13650_RRRef,0x00000000000000000000000000000000), T2._Fld123660_TYPE, T2._Fld123660_RTRef, T2._Fld123660_RRRef
 

 
 
вижу что выборка из какой-то таблицы #tt это типа временная таблица где-то, и из нее что-то выбирается постоянно. Где она лежит? В памяти?, в базе такой таблы нет. Или в кэшэ.
 
уже перевалило за 306%! Это как?
 
 
из плана выполнения запроса

Код:
SELECT T1._Q_000_F_002RRef, T1._Q_000_F_003RRef, T1._Q_000_F_004RRef, ISNULL(T3._Fld13651RRef,0x00000000000000000000000000000000), CASE WHEN (ISNULL(T3._Fld13651RRef,0x00000000000000000000000000000000) = 0x8F411131DFD4B8184305C1582EFEFC30) THEN 0x01 ELSE 0x00 END, ISNULL(T3._Fld13650_TYPE,0x01), ISNULL(T3._Fld13650_RTRef,0x00000000), ISNULL(T3._Fld13650_RRRef,0x00000000000000000000000000000000), 0x00000000000000000000000000000000, 0x00000000000000000000000000000000, 0x00000000000000000000000000000000, T2._Fld123660_TYPE, T2._Fld123660_RTRef, T2._Fld123660_RRRef, MIN(T2._Fld123654), MIN(T2._Fld123654), MIN(T2._Fld123664), @P1, 0x00 FROM #tt82 T1 WITH(NOLOCK) INNER JOIN dbo._InfoRg123653X1 T2 ON (T1._Q_000_F_002RRef = T2._Fld123657RRef) AND (T1._Q_000_F_003RRef = T2._Fld123658RRef) AND (T1._Q_000_F_004RRef = T2._Fld123659RRef) LEFT OUTER JOIN dbo._Reference498 T3 ON ((T1._Q_000_F_003RRef = T3._IDRRef)) AND (T3._Fld3201 = @P2) WHERE (T2._Fld3201 = @P3) GROUP BY T1._Q_000_F_002RRef, T1._Q_000_F_003RRef, T1._Q_000_F_004RRef, ISNULL(T3._Fld13651RRef,0x00000000000000000000000000000000), CASE WHEN (ISNULL(T3._Fld13651RRef,0x00000000000000000000000000000000) = 0x8F411131DFD4B8184305C1582EFEFC30) THEN 0x01 ELSE 0x00 END, ISNULL(T3._Fld13650_TYPE,0x01), ISNULL(T3._Fld13650_RTRef,0x00000000), ISNULL(T3._Fld13650_RRRef,0x00000000000000000000000000000000), T2._Fld123660_TYPE, T2._Fld123660_RTRef, T2._Fld123660_RRRef

 
в удобочитаемом виде

Код:
SELECT
T1._Q_000_F_002RRef,
T1._Q_000_F_003RRef,
T1._Q_000_F_004RRef,
ISNULL(T3._Fld13651RRef,0x00000000000000000000000000000000),
CASE WHEN (ISNULL(T3._Fld13651RRef,0x00000000000000000000000000000000) = 0x8F411131DFD4B8184305C1582EFEFC30) THEN 0x01 ELSE 0x00 END,
ISNULL(T3._Fld13650_TYPE,0x01),
ISNULL(T3._Fld13650_RTRef,0x00000000),
ISNULL(T3._Fld13650_RRRef,0x00000000000000000000000000000000),
0x00000000000000000000000000000000,
0x00000000000000000000000000000000,
0x00000000000000000000000000000000,
T2._Fld123660_TYPE,
T2._Fld123660_RTRef,
T2._Fld123660_RRRef,
MIN(T2._Fld123654),
MIN(T2._Fld123654),
MIN(T2._Fld123664),
@P1,
0x00
FROM #tt82 T1 WITH(NOLOCK)
INNER JOIN dbo._InfoRg123653X1 T2
ON (T1._Q_000_F_002RRef = T2._Fld123657RRef) AND (T1._Q_000_F_003RRef = T2._Fld123658RRef) AND (T1._Q_000_F_004RRef = T2._Fld123659RRef)
LEFT OUTER JOIN dbo._Reference498 T3
ON ((T1._Q_000_F_003RRef = T3._IDRRef)) AND (T3._Fld3201 = @P2)
WHERE (T2._Fld3201 = @P3)
GROUP BY T1._Q_000_F_002RRef,
T1._Q_000_F_003RRef,
T1._Q_000_F_004RRef,
ISNULL(T3._Fld13651RRef,0x00000000000000000000000000000000),
CASE WHEN (ISNULL(T3._Fld13651RRef,0x00000000000000000000000000000000) = 0x8F411131DFD4B8184305C1582EFEFC30) THEN 0x01 ELSE 0x00 END,
ISNULL(T3._Fld13650_TYPE,0x01),
ISNULL(T3._Fld13650_RTRef,0x00000000),
ISNULL(T3._Fld13650_RRRef,0x00000000000000000000000000000000),
T2._Fld123660_TYPE,
T2._Fld123660_RTRef,
T2._Fld123660_RRRef
 
Всего записей: 899 | Зарегистр. 28-09-2006 | Отправлено: 11:19 29-01-2026 | Исправлено: ArkadyKiller, 11:31 29-01-2026
contrafack

Silver Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
ArkadyKiller
 
по поводу первого запроса:  
   

Код:
 
SET STATISTICS XML ON;
-- выполнить ваш SELECT
SET STATISTICS XML OFF;
 

 
   

Код:
 
SELECT  
    wait_type, waiting_tasks_count, wait_time_ms
FROM sys.dm_os_wait_stats
WHERE wait_type LIKE 'PAGELATCH%';

 
Если растёт очень быстро — значит процесс активно бьёт по одним страницам.
 
Проверить TempDB:
Часто временные таблицы (#tt82) используют TempDB.
Убедитесь, что она на быстром диске, с достаточным размером и несколькими файлами (1 per CPU).
 
 
 
 
Добавлено:

Цитата:
вижу что выборка из какой-то таблицы #tt это типа временная таблица где-то, и из нее что-то выбирается постоянно. Где она лежит? В памяти?, в базе такой таблы нет. Или в кэшэ.
 
уже перевалило за 306%! Это как?  

 
   

3. Где именно лежит #tt82
 
Физически: TempDB
 
В памяти: SQL Server пытается держать страницы в Buffer Pool TempDB
Если памяти мало или TempDB маленький &#8594; SQL Server пишет/читает с диска TempDB
Индексов на #tt82 почти всегда нет &#8594; каждый join = scan &#8594; много latch EX
 
4. Что с этим делать
 
Посмотреть размер TempDB:

Код:
SELECT
    name,  
    size/128.0 AS SizeMB,
    max_size/128.0 AS MaxSizeMB,
    growth/128.0 AS GrowthMB
FROM tempdb.sys.database_files;

 
   
 
 

Код:
SELECT wait_type, waiting_tasks_count, wait_time_ms
FROM sys.dm_os_wait_stats
WHERE wait_type LIKE 'PAGELATCH%';
 
Всего записей: 3528 | Зарегистр. 21-04-2008 | Отправлено: 12:04 29-01-2026
ArkadyKiller



Advanced Member		Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
contrafack
теперь по порядку:
1 - TempDB у меня один. Сколько нужно сделать файлов по количеству? 2 сокета, то есть 2 физических проца, 20 ядер в сумме, 40 логических в сумме, сколько файлов TempDB мне нужно сделать? Сам файл лежит на быстром диске Samsung 1.6 Tb HHHL
 
2 - размер темпДБ сейчас 75 гиг
 
3 - batch проессинг я хз что это такое и как его делать.
 
4 - Реиндексация была сделана на прошлой неделе, раз в неделю у меня работает расписание задачи.
 
Сейчас сервер не тормозит, графики ровные низкие, но запрос еще выполняется, как бы не мешает, но что-то слишком долго он там что-то считает.
 
6 - так же настроен на диск серверный пул на 128 гигов, оперативки 128 гигов
Всего записей: 899 | Зарегистр. 28-09-2006 | Отправлено: 12:24 29-01-2026 | Исправлено: ArkadyKiller, 12:28 29-01-2026
contrafack

Silver Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
1 - TempDB у меня один. Сколько нужно сделать файлов по количеству? 2 сокета, то есть 2 физических проца, 20 ядер в сумме, 40 логических в сумме, сколько файлов TempDB мне нужно сделать? Сам файл лежит на быстром диске Samsung 1.6 Tb HHHL  

   
код отдельно: Под себя пути можешь прописать

Код:
USE master;
GO
 
ALTER DATABASE tempdb  
ADD FILE (NAME = tempdev2, FILENAME = 'D:\TempDB\tempdev2.ndf', SIZE = 1024MB, FILEGROWTH = 256MB),
         (NAME = tempdev3, FILENAME = 'D:\TempDB\tempdev3.ndf', SIZE = 1024MB, FILEGROWTH = 256MB),
         (NAME = tempdev4, FILENAME = 'D:\TempDB\tempdev4.ndf', SIZE = 1024MB, FILEGROWTH = 256MB),
         (NAME = tempdev5, FILENAME = 'D:\TempDB\tempdev5.ndf', SIZE = 1024MB, FILEGROWTH = 256MB),
         (NAME = tempdev6, FILENAME = 'D:\TempDB\tempdev6.ndf', SIZE = 1024MB, FILEGROWTH = 256MB),
         (NAME = tempdev7, FILENAME = 'D:\TempDB\tempdev7.ndf', SIZE = 1024MB, FILEGROWTH = 256MB),
         (NAME = tempdev8, FILENAME = 'D:\TempDB\tempdev8.ndf', SIZE = 1024MB, FILEGROWTH = 256MB);
GO
 

 

Цитата:
2 - размер темпДБ сейчас 75 гиг  

 
Для твоего объёма памяти 128 ГБ и серверного пула дисков &#8594; размер TempDB в 75 ГБ нормальный, но если таблицы #tt огромные &#8594; возможно, будет ещё расти.
 
Добавление файлов даст параллельное распределение latch, поэтому Buffer Latch EX станет меньше.
 

Цитата:
3 - batch проессинг я хз что это такое и как его делать.  

Batch Processing
 
Это когда большой запрос делим на порции, чтобы не гонять все данные за один проход.
В твоем случае #tt82 очень большая &#8594; TempDB перегружается.
В 1С это может быть реализовано через разбивку выборки на, например, 1000–5000 записей за раз, а не всё сразу.
 
Конкретная реализация зависит от 1С-объектов и регистров, но принцип простой: меньше данных за один проход &#8594; меньше contention.
 

Цитата:
4 - Реиндексация была сделана на прошлой неделе, раз в неделю у меня работает расписание задачи.  

Раз в неделю &#8594; ок.
 
Для Join #tt82 INNER JOIN _InfoRg123653X1 важно, чтобы поля _Fld123657RRef, _Fld123658RRef, _Fld123659RRef имели покрывающие индексы &#8594; уменьшает Scan &#8594; меньше latch.
 
 

Цитата:
6 - так же настроен на диск серверный пул на 128 гигов, оперативки 128 гигов

Samsung HHHL 1.6 ТБ &#8594; быстрые NVMe &#8594; диски не узкое место.
 
Pool на 128 ГБ &#8594; хорошо, TempDB спокойно растёт, но важно не делать автогров маленьким (иначе много аллокаций &#8594; latch).
 

Резюме действий
 
Добавить 8–12 файлов TempDB одинакового размера.
Перезапустить SQL Server после добавления файлов.
Проверить индексы на _InfoRg123653X1 и _Reference498.
Если возможно, внедрить batch processing на стороне 1С, чтобы #tt82 не был огромным за один проход.
Мониторить PAGELATCH_EX после добавления файлов:

Код:
 
SELECT wait_type, waiting_tasks_count, wait_time_ms
FROM sys.dm_os_wait_stats
WHERE wait_type LIKE 'PAGELATCH%'
ORDER BY wait_time_ms DESC;
 

 
Всего записей: 3528 | Зарегистр. 21-04-2008 | Отправлено: 13:09 29-01-2026
ArkadyKiller



Advanced Member		Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
contrafack
бро, создал файлы, однако как был tempdb.mdf 75 гигов, так и остался, твои файлы tempdev#.ndf так и остались начального размера, перезапуск сервера ничего не изменил в размерах файлов. И почему *.ndf а не *.mdf? И как мне заставить чтобы файлы равномерно работали? или указать им размер? Чтот я тут совсем не понял как он работает. Или он сначала всю начальную кашу скинул в первый файл, а в процессе работы будет юзать другие? я тут в ступоре.
 
Короче ночью остановил все службы, вычистил все кэши сервера 1с, очистил статистику и буферы сервера СКЛ. Сегодня вроде бы полет нормальный. Чуть позже проверим ту операцию из 1с которая порождала этот чудовищный запрос. будем его отлавливать и смотреть что же 1с посылает серверу,
 
Почитал про MDF и NDF, и получается что эти вторичные NDF в моем случае совсем не используются.
 
Разбить tempdb на несколько файлов по количеству процессоров — миф
 
в тырнете полно про это например тут
Всего записей: 899 | Зарегистр. 28-09-2006 | Отправлено: 19:13 29-01-2026 | Исправлено: ArkadyKiller, 06:10 30-01-2026
katamoto

Newbie		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
бро, создал файлы, однако как был tempdb.mdf 75 гигов, так и остался, твои файлы tempdev#.ndf так и остались начального размера, перезапуск сервера ничего не изменил в размерах файлов.

 
В свойствах базы выставь одинаковый размер у всех файлов. Возможно сперва нужен будет рестарт сервиса.  
 

Цитата:
Разбить tempdb на несколько файлов по количеству процессоров — миф  

 
Настолько не миф, что с SQL2016 они по умолчанию в процессе установки создаются
Всего записей: 14 | Зарегистр. 17-12-2015 | Отправлено: 07:32 30-01-2026
ArkadyKiller



Advanced Member		Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
katamoto
и как мне это сделать массово по всем файлам?
Всего записей: 899 | Зарегистр. 28-09-2006 | Отправлено: 08:33 30-01-2026
contrafack

Silver Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
бро, создал файлы, однако как был tempdb.mdf 75 гигов, так и остался, твои файлы tempdev#.ndf так и остались начального размера, перезапуск сервера ничего не изменил в размерах файлов. И почему *.ndf а не *.mdf? И как мне заставить чтобы файлы равномерно работали? или указать им размер? Чтот я тут совсем не понял как он работает. Или он сначала всю начальную кашу скинул в первый файл, а в процессе работы будет юзать другие? я тут в ступоре.  

Вот полный текст отдельно пастил , много там вариантов:
https://ideone.com/15o7hO
 

Цитата:
Почитал про MDF и NDF, и получается что эти вторичные NDF в моем случае совсем не используются.
 
Разбить tempdb на несколько файлов по количеству процессоров — миф  

Тут с тобой не согласны.  
Вот подробно почему:  
https://ideone.com/YjTkU1
Всего записей: 3528 | Зарегистр. 21-04-2008 | Отправлено: 08:38 30-01-2026
Открыть новую тему     Написать ответ в эту тему

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46

Компьютерный форум Ru.Board » Компьютеры » Прикладное программирование » SQL запрос


Реклама на форуме Ru.Board.

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.Board
© Ru.B0ard 2000-2026

LiteCoin: LgY72v35StJhV2xbt8CpxbQ9gFY6jwZ67r

Рейтинг.ru