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

Откуда: Ярославль
Сообщений: 211
Владислав Колосов, нет - первая строчка это как раз диск G с файлами баз данных (mdf).
/
28 ноя 18, 14:16    [21747398]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение хранимых процедур  [new]
invm
Member

Откуда: Москва
Сообщений: 8218
Владислав Колосов
PLE 1300+ как укладывается в Ваше предположение?
Еще раз - ознакомьтесь со статьей и посчитайте рекомендуемый минимальный PLE для условий ТС'а.
28 ноя 18, 14:23    [21747406]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение хранимых процедур  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 5671
Владислав Колосов
invm,

PLE 1300+ как укладывается в Ваше предположение?

значение PLE "просто на сейчас" не имеет никакой ценности
28 ноя 18, 14:33    [21747423]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение хранимых процедур  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 5671
gepard1980,

Покажите содержание пула, чем то типа 21525605
28 ноя 18, 14:40    [21747430]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение хранимых процедур  [new]
gepard1980
Member

Откуда: Ярославль
Сообщений: 211
TaPaK, вот:

К сообщению приложен файл. Размер - 27Kb
28 ноя 18, 14:55    [21747451]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение хранимых процедур  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 5671
gepard1980,

Ну, имхо очередь к диску конечно не маленькая, но и не ужас. Судя по тому что у вас резултаты по "одной" строке возвращают, значить получаете сканы, не попадаете в индексы, всё это таскается между диском и памятью, тут и очередь и низкий ple. Разбирайте конкретные запросы
28 ноя 18, 15:04    [21747472]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение хранимых процедур  [new]
invm
Member

Откуда: Москва
Сообщений: 8218
a_voronin
А вы бекапы вообще делаете?
Даже стало любопытно: бекап чего надо сделать, что бы прекратить рост ЖТ при простой модели восстановления?

ЗЫ: Не надоело бред генерировать?
28 ноя 18, 15:07    [21747484]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение хранимых процедур  [new]
Yasha123
Member

Откуда:
Сообщений: 1148
на картинке товарища на первой странице читаются поля с названиями file_word_upd, keyfilebody.
вопрос: какого типа эти поля?
если это блобы, то поздравимся: они не кэшируются, т.е. каждый раз начитываются заново с диска
28 ноя 18, 15:54    [21747555]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение хранимых процедур  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 5977
При такой очереди диска может и не катастрофа, когда запросы "висят" мертво, но нельзя сказать, что работа комфортна.

Есть же резервы памяти, верхнюю границу можно увеличить до 60Гб для SQL?
28 ноя 18, 16:20    [21747594]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение хранимых процедур  [new]
Yasha123
Member

Откуда:
Сообщений: 1148
Владислав Колосов
При такой очереди диска может и не катастрофа, когда запросы "висят" мертво, но нельзя сказать, что работа комфортна.

Есть же резервы памяти, верхнюю границу можно увеличить до 60Гб для SQL?

если это блобы, то хоть терабайт памяти зафигачь,
будет их читать с диска каждый раз заново
28 ноя 18, 16:25    [21747600]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение хранимых процедур  [new]
gepard1980
Member

Откуда: Ярославль
Сообщений: 211
Владислав Колосов, это я оставил для запуска студий и других программ. тоже кушать хотят. думаю увеличение с 45 до 55 например (а всего 58) ничего не даст. сиквел сожрет и эту десятку.
28 ноя 18, 16:29    [21747608]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение хранимых процедур  [new]
Владислав Колосов
Member

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

там, похоже, комплексная проблема... Блобы -то да, но они разве повлияли бы на PLE?
28 ноя 18, 16:29    [21747609]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение хранимых процедур  [new]
gepard1980
Member

Откуда: Ярославль
Сообщений: 211
Yasha123, спасибо, уберу их из запроса.
28 ноя 18, 16:30    [21747612]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение хранимых процедур  [new]
Владислав Колосов
Member

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

Ну, знаете ли... Тогда Вам следовало очень хорошо запастись памятью, студия может и 16 Гб скушать. А Вы такую нагрузку дали серверу.
28 ноя 18, 16:31    [21747613]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение хранимых процедур  [new]
gepard1980
Member

Откуда: Ярославль
Сообщений: 211
Владислав Колосов, ищу какой-то баланс. сиквелу - 45. 10 - приложениям.
28 ноя 18, 16:37    [21747624]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение хранимых процедур  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2116
gepard1980,

Есть вероятность что у вас там много сканов и память постоянно вытесняется сначала одними таблицами потом другими. Базы большие?
Покажите распределение памяти по базам:

+ Buffer By Database
/* Generated in SQL Explorer v.1.6.4.31586 */
SET NOCOUNT ON
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
SET LOCK_TIMEOUT 10000

SELECT 
  CASE WHEN database_id = 32767 THEN 'ResourceDB' ELSE DB_NAME(database_id) END  as DatabaseName, 
  CAST(COUNT(*)/128. AS NUMERIC(20,2)) AS [BufferSize MB], 
  CAST(SUM(CAST(free_space_in_bytes AS BIGINT)) / (1024. * 1024) AS NUMERIC(20,2)) AS [EmptySize MB], 
  CAST(SUM(is_modified/128.) AS NUMERIC(20,2)) AS [DirtySize MB], 
  CAST(AVG(100.*(free_space_in_bytes/ (1024. * 1024))/(1/128.)) AS NUMERIC(8,2)) AS [EmptySize %], 
  COUNT(*) AS PagesInCache
FROM sys.dm_os_buffer_descriptors
GROUP BY database_id
ORDER BY PagesInCache desc
OPTION(MAXDOP 1)

Ну и потом для той базы что которая больше всего памяти использует запустите

+ Buffer By Object
/* Generated in SQL Explorer v.1.6.4.31586 */
SET NOCOUNT ON
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
SET LOCK_TIMEOUT 10000

SELECT 
  CASE WHEN ISNULL(RES.container_id, 0) = 0 
    THEN '<<<Marked for deferred drop>>>'
  ELSE
    OBJECT_SCHEMA_NAME(p.[object_id]) + '.' + OBJECT_NAME(p.[object_id]) 
  END AS [TableName],
  p.index_id, 
  CASE WHEN i.index_id IS NOT NULL THEN ISNULL(i.name, '<<<HEAP>>>') ELSE NULL END AS [IndexName], 
  RES.type_desc,
  CAST(RES.buffers/128. AS NUMERIC(20,2)) AS [BufferSize MB],  
  CAST(RES.buffers_modified/128. AS NUMERIC(20,2)) AS [DirtySize MB],
  CAST(ROUND(CASE WHEN RES.used_pages < RES.buffers THEN 100. ELSE ISNULL(100.0 * RES.buffers / NULLIF(RES.used_pages,0),0) END, 4) AS DECIMAL(8,4)) AS [PagesCached %],
  CAST(RES.free_space_in_mb AS NUMERIC(20,2)) AS [EmptySize MB]
FROM
  (
    SELECT  -- Get allocation units + buffer descriptors grouped by container_id
      AU.container_id,
      AU.type_desc,
      SUM(BUF_GP.buffers) AS buffers,
      SUM(AU.used_pages) AS used_pages,
      SUM(BUF_GP.free_space_in_mb) AS free_space_in_mb,
      SUM(buffers_modified) AS buffers_modified,
      SUM(CASE WHEN AU.type = 1 THEN BUF_GP.RowCountLeaf ELSE 0 END) AS RowCountLeaf,
      SUM(CASE WHEN AU.type = 1 THEN BUF_GP.RowCountNonLeaf ELSE 0 END) AS RowCountNonLeaf
    FROM
    (
      SELECT  -- Get buffer descriptors grouped by allocation_unit_id
        BUF.allocation_unit_id,
        COUNT(*) AS buffers,
        SUM(CAST(BUF.free_space_in_bytes AS BIGINT)) / (1024. * 1024) AS free_space_in_mb, 
        SUM(CASE WHEN BUF.is_modified = 1 THEN 1 ELSE 0 END) AS buffers_modified,
        SUM(CASE WHEN BUF.page_level =  0 and BUF.page_type IN ('INDEX_PAGE','DATA_PAGE') THEN BUF.row_count ELSE 0 END ) AS RowCountLeaf,
        SUM(CASE WHEN BUF.page_level <> 0 and BUF.page_type IN ('INDEX_PAGE','DATA_PAGE') THEN BUF.row_count ELSE 0 END ) AS RowCountNonLeaf
      FROM sys.dm_os_buffer_descriptors AS BUF
      WHERE BUF.database_id = DB_ID()
      GROUP BY BUF.allocation_unit_id
    ) BUF_GP
    LEFT JOIN sys.allocation_units AS AU ON AU.allocation_unit_id = BUF_GP.allocation_unit_id
    GROUP BY AU.container_id, AU.type_desc
  ) RES
  LEFT JOIN sys.partitions AS p ON RES.container_id = p.hobt_id 
  LEFT JOIN sys.indexes AS i ON i.object_id = p.object_id AND i.index_id = p.index_id
WHERE ABS(ISNULL(p.[object_id],101)) > 100
ORDER BY RES.buffers DESC
OPTION(MAXDOP 1);

и
+ Index Usage Statistics
/* Generated in SQL Explorer v.1.6.4.31586 */
SET NOCOUNT ON
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
SET LOCK_TIMEOUT 10000

SELECT 
  OBJECT_SCHEMA_NAME(i.[object_id]) + '.' + OBJECT_NAME(i.[object_id]) AS TableName,
  ISNULL(REPLACE(i.name, NCHAR(31), ''), '<<<HEAP>>>') AS IndexName,
  i.is_primary_key AS PK,
  i.is_unique_constraint AS UQ,
  CAST(CASE WHEN i.index_id = 1 THEN 1 ELSE 0 END AS BIT) AS Clust,
  CAST(p2.SizeMB AS DECIMAL(20, 2)) AS SizeMB,
  s.user_seeks,
  s.user_scans,
  s.user_lookups,
  s.user_seeks + s.user_scans + s.user_lookups AS total_user_reads,
  CAST(s.user_scans*SizeMB/1024. AS DECIMAL(30, 2)) AS TotalScanGB,
  CASE WHEN i.index_id IN (0,1) THEN mi.MissingIndexes ELSE NULL END AS MissingIndexes
FROM sys.indexes AS i
LEFT JOIN
    (
      select p2.object_id, p2.index_id, SUM(au.used_pages) / 128.AS SizeMB
      from sys.partitions AS p2
        INNER JOIN sys.allocation_units AS au ON p2.partition_id = au.container_id
      where au.type <> 2-- LOB_DATA
      group by p2.object_id, p2.index_id
    ) p2 ON p2.object_id = i.object_id AND p2.index_id = i.index_id
LEFT JOIN 
  (
    SELECT mid.object_id, MissingIndexes = COUNT(*)
    FROM sys.dm_db_missing_index_group_stats AS migs
      INNER JOIN sys.dm_db_missing_index_groups AS mig ON migs.group_handle = mig.index_group_handle
      INNER JOIN sys.dm_db_missing_index_details AS mid ON mig.index_handle = mid.index_handle
    WHERE mid.database_id = DB_ID()
    GROUP BY mid.object_id
  ) mi ON mi.object_id = i.object_id
LEFT JOIN sys.dm_db_index_usage_stats AS s
  ON s.[object_id] = i.[object_id] AND s.index_id = i.index_id
  AND s.database_id = DB_ID()
WHERE ((OBJECTPROPERTY(i.[object_id],'IsUserTable') = 1) OR (OBJECTPROPERTY(i.[object_id],'IsView') = 1))
ORDER BY TotalScanGB DESC
OPTION(MAXDOP 1)
28 ноя 18, 22:31    [21747923]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение хранимых процедур  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2116
gepard1980
Владислав Колосов, ищу какой-то баланс. сиквелу - 45. 10 - приложениям.
На сервере БД не должно быть других приложений! Сколько у вас свободной памяти на сервере?
28 ноя 18, 22:34    [21747925]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение хранимых процедур  [new]
gepard1980
Member

Откуда: Ярославль
Сообщений: 211
Mind, первое выполнил. А в двух других скриптах не понял, где указывать самую большую БД (в моем случае это lion_data)?

К сообщению приложен файл. Размер - 31Kb
28 ноя 18, 23:03    [21747939]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение хранимых процедур  [new]
gepard1980
Member

Откуда: Ярославль
Сообщений: 211
Mind, размер базы lion_data 110 Гб. Базы WebLeader 75 Гб. На сервере всего 58 Гб ОЗУ. 45 Гб выделил сиквелу. Остальное про запас оставил. Виндовый процесс-менеджер показывает 7 Гб свободно.

К сообщению приложен файл. Размер - 66Kb
28 ноя 18, 23:06    [21747940]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение хранимых процедур  [new]
gepard1980
Member

Откуда: Ярославль
Сообщений: 211
Mind, из приложений только SSMS и DBForge. Естественно никаких FTP, NoSQL и т.д. на этом сервере нет. Они на другом.
28 ноя 18, 23:13    [21747942]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение хранимых процедур  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2116
gepard1980,

Просто перейдите в нужную базу перед запуском скрипта.

USE lion_data
28 ноя 18, 23:59    [21747954]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение хранимых процедур  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2116
gepard1980
Mind, первое выполнил. А в двух других скриптах не понял, где указывать самую большую БД (в моем случае это lion_data)?
У вас 37% (16Гб) пустого места внутри индексов. Вы rebuild/reorginize индексов хоть раз делали?
Хотя это конечно могут быть блобы, но все равно вряд ли так много.
29 ноя 18, 00:02    [21747957]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение хранимых процедур  [new]
gepard1980
Member

Откуда: Ярославль
Сообщений: 211
Mind, есть job который сначала проверку на целостность делает, а потом ребилд индексов. посмотрел сейчас лог - он всегда останавливался на ошибке при DBCC CHECKDB на базе WebLeader и дальше соответственно не шел. надо будет ночью сегодня запустить джоб на ребилд индексов. а ошибка такая:

Executing the query "DBCC CHECKDB(N'WebLeader') WITH NO_INFOMSGS
" failed with the following error: "Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 0 (type Unknown), page ID (1:9380353) contains an incorrect page ID in its page header. The PageId in the page header = (0:0).
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 0 (type Unknown), page ID (1:9380354) contains an incorrect page ID in its page header. The PageId in the page header = (0:0).
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 0 (type Unknown), page ID (1:9451372) contains an incorrect page ID in its page header. The PageId in the page header = (0:0).
Object ID 367395005, index ID 1, partition ID 72058363036303360, alloc unit ID 72058364643835904 (type In-row data): Page (1:9451372) could not be processed. See other errors for details.
Table error: Object ID 367395005, index ID 1, partition ID 72058363036303360, alloc unit ID 72058364643835904 (type In-row data). Index node page (0:0), slot 0 refers to child page (1:9451372) and previous child (0:0), but they were not encountered.
Object ID 624671800, index ID 1, partition ID 72058362590003200, alloc unit ID 72058364196487168 (type In-row data): Page (1:9380354) could not be processed. See other errors for details.
Table error: Object ID 624671800, index ID 1, partition ID 72058362590003200, alloc unit ID 72058364196487168 (type In-row data). Index node page (0:0), slot 0 refers to child page (1:9380354) and previous child (0:0), but they were not encountered.
Object ID 640671857, index ID 1, partition ID 72058362590068736, alloc unit ID 72058364196552704 (type In-row data): Page (1:9380353) could not be processed. See other errors for details.
Table error: Object ID 640671857, index ID 1, partition ID 72058362590068736, alloc unit ID 72058364196552704 (type In-row data). Index node page (0:0), slot 0 refers to child page (1:9380353) and previous child (0:0), but they were not encountered.
Table error: page (1:22851) allocated to object ID 1627561255, index ID 1, partition ID 72058340014751744, alloc unit ID 72058341621170176 (type In-row data) was not seen. The page may be invalid or may have an incorrect alloc unit ID in its header.
Table error: Object ID 1627561255, index ID 1, partition ID 72058340014751744, alloc unit ID 72058341621170176 (type In-row data). Index node page (0:0), slot 0 refers to child page (1:22851) and previous child (0:0), but they were not encountered.
Table error: page (1:22848) allocated to object ID 1643561312, index ID 1, partition ID 72058340014817280, alloc unit ID 72058341621235712 (type In-row data) was not seen. The page may be invalid or may have an incorrect alloc unit ID in its header.
Table error: Object ID 1643561312, index ID 1, partition ID 72058340014817280, alloc unit ID 72058341621235712 (type In-row data). Index node page (0:0), slot 0 refers to child page (1:22848) and previous child (0:0), but they were not encountered.
CHECKDB found 0 allocation errors and 3 consistency errors not associated with any single object.
CHECKDB found 0 allocation errors and 2 consistency errors in table 'sys.ifts_comp_fragment_1166627199_1279643' (object ID 367395005).
CHECKDB found 0 allocation errors and 2 consistency errors in table 'sys.ifts_comp_fragment_1166627199_1279308' (object ID 624671800).
CHECKDB found 0 allocation errors and 2 consistency errors in table 'sys.ifts_comp_fragment_4649743_10289803' (object ID 640671857).
CHECKDB found 0 allocation errors and 2 consistency errors in table 'sys.ifts_comp_fragment_4649743_9953028' (object ID 1627561255).
CHECKDB found 0 allocation errors and 2 consistency errors in table 'sys.ifts_comp_fragment_4649743_9953029' (object ID 1643561312).
CHECKDB found 0 allocation errors and 13 consistency errors in database 'WebLeader'.
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (WebLeader).". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
29 ноя 18, 08:52    [21748036]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение хранимых процедур  [new]
gepard1980
Member

Откуда: Ярославль
Сообщений: 211
Mind, по второму скрипту относительно базы lion_data результаты такие:

К сообщению приложен файл. Размер - 80Kb
29 ноя 18, 08:55    [21748039]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение хранимых процедур  [new]
gepard1980
Member

Откуда: Ярославль
Сообщений: 211
Mind, по третьему скрипту относительно базы lion_data результаты такие. На что обратить внимание?
29 ноя 18, 08:56    [21748040]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить