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

Откуда:
Сообщений: 15
Есть база 1С, есть SQL Server 2008

В базе 1С кроме обычной работы пользователей запускается процедура "перепроведения документов", которая даёт очень сильную нагрузку на дисковую систему (постоянная запись).

На сервере (Win2003) есть свободная память (10Гб) и хотелось бы отказаться от постоянной записи, так как записывается одно и то же - меняются остатки/итоги регистров, они пересчитываются и постоянно сбрасываются на хард. Чтения практически нет, так как всё в кэше SQL.

Есть ли возможность отключить запись на хард, т.е. производить её только (допустим) раз в 10 минут ?
18 дек 09, 14:04    [8086733]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли принудительный кэш записи SQL-Server ?  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
автор
так как записывается одно и то же - меняются остатки/итоги регистров, они пересчитываются и постоянно сбрасываются на хард.


Запись в лог транзакций не отключается, ибо именно он гарантирует восстановление бд в целостное состояние в случае сбоя.
18 дек 09, 14:45    [8087114]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли принудительный кэш записи SQL-Server ?  [new]
wwwolfy
Member

Откуда:
Сообщений: 15
Не в log-файле дело

Simple
18 дек 09, 15:01    [8087303]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли принудительный кэш записи SQL-Server ?  [new]
aleks2
Guest
wwwolfy
Не в log-файле дело

Simple


Лог он и в Африке лог, а уж в Simple и подавно.
18 дек 09, 15:04    [8087330]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли принудительный кэш записи SQL-Server ?  [new]
Glory
Member

Откуда:
Сообщений: 104751
wwwolfy
Не в log-файле дело

Simple

Тип модели не уменьшает число и объем транзакций, информацию о которых нужно записывать на диск
18 дек 09, 15:07    [8087356]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли принудительный кэш записи SQL-Server ?  [new]
Now password
Guest
Молодой человек, если у вас стоит модель recovery Simple, это не значит, что нет логирования событий, это значит что на каждый checkpoint происходит shrink лога. Совсем от записи данных на диск отказаться никак нельзя, ибо, как как правильно заметили выше, в случае сбоя вы не сможете восстановить БД.
18 дек 09, 15:16    [8087434]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли принудительный кэш записи SQL-Server ?  [new]
wwwolfy
Member

Откуда:
Сообщений: 15
Ладно, не буду спорить.

Но вопрос в (0) остаётся - как включить кэш SQL так, чтобы он не записывал, а держал в памяти ?
Точнее записывал бы раз в N минут.
18 дек 09, 15:19    [8087469]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли принудительный кэш записи SQL-Server ?  [new]
Now password
Guest
Вы сможете выставить интервал, с которым будет отрабатывать Checkpoint, который сбрасывает грязные страницы на диск, но совсем от записи вы не сможете отказаться. Если вы найдёте как это сделать, сообщите пожалуйста.
18 дек 09, 15:23    [8087502]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли принудительный кэш записи SQL-Server ?  [new]
max44
Member

Откуда: МОСКВА
Сообщений: 280
To wwwolfy А как Вы пришли к выводам, что идет постоянная запись? и нет чтений?
чем мониторили эту ситуацию?
есть небольшой опыт наблюдения за 1с, и там как раз соотношение запись\чтение наоборот (как в общем то и в любой ERP)
10 раз читаем 1 раз пишем....
Приведите пожалуйста методику как вы наблюдали ситуацию "постоянно записи"




автор
Вы сможете выставить интервал, с которым будет отрабатывать Checkpoint, который сбрасывает грязные страницы на диск, но совсем от записи вы не сможете отказаться. Если вы найдёте как это сделать, сообщите пожалуйста

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

Хотя я думаю это не Ваш случай... (не поможет:))

К сообщению приложен файл. Размер - 0Kb
21 дек 09, 18:17    [8097699]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли принудительный кэш записи SQL-Server ?  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 3422
max44
автор
Вы сможете выставить интервал, с которым будет отрабатывать Checkpoint, который сбрасывает грязные страницы на диск, но совсем от записи вы не сможете отказаться. Если вы найдёте как это сделать, сообщите пожалуйста
Это делаеться так см. картинку
Да что вы говорите
recovery interval Option
The frequency of checkpoints in each database depends on the amount of data modifications made, not on any time-based measure. A database used primarily for read-only operations will not have many checkpoints. A transaction database will have frequent checkpoints.
Эта опция, безусловно, влияет на частоту чекпойнтов, но явно ее не задает. Слишком важный параметр, чтобы позволять пользователям рулить его значением напрямую.
21 дек 09, 23:50    [8098765]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли принудительный кэш записи SQL-Server ?  [new]
max44
Member

Откуда: МОСКВА
Сообщений: 280
To Ennor Tiegael
Я и не утверждаю, что Recovery Interval=10 минутам говорит о том что сервер будет делать чекпоинт раз в 10 минут:) но чем он больше тем реже SQL пишет данные в файл(ы) БД...

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

и еще интересует вот это нюанс "На сервере (Win2003) есть свободная память (10Гб)" она точно SQL не отдана? если нет то можно помочь настроить сервер так что бы он кушал эту память (если редакции windows и SQL позволят:))
22 дек 09, 08:14    [8099094]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли принудительный кэш записи SQL-Server ?  [new]
Денис Ильин
Member

Откуда: Железнодорожный
Сообщений: 242
может дешевле купить новый диск, а то "10 гигабайт свободного места" по нынешним временам звучит как "места на диске катастрофически не хватает". Кстати, для ntfs разделов неплохо, если у них 30..40% свободного места - они от этого меньше фрагментируются.
22 дек 09, 09:10    [8099177]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли принудительный кэш записи SQL-Server ?  [new]
vino
Member

Откуда:
Сообщений: 1191
wwwolfy
Есть база 1С, есть SQL Server 2008

В базе 1С кроме обычной работы пользователей запускается процедура "перепроведения документов", которая даёт очень сильную нагрузку на дисковую систему (постоянная запись).

На сервере (Win2003) есть свободная память (10Гб) и хотелось бы отказаться от постоянной записи,...
Исследуйте нагрузку на TempDB во время "перепроведения документов": если она большая, а память действительно свободна, и TempDB не растет более 9Гб, то создайте "виртуальный" раздел и разместите там TempDB.
Запись лога во время операций при работе SQL - нормальное явление (при любой модели восстановления). Тем более на Simple нужно иметь быстрый диск для лог-файла

Сообщение было отредактировано: 22 дек 09, 11:40
22 дек 09, 11:05    [8099907]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли принудительный кэш записи SQL-Server ?  [new]
wwwolfy
Member

Откуда:
Сообщений: 15
Спасибо всем за внимание к вопросу.
Всё это время разбирались с сервером (он новый). Оказалась проблема в RAID-5, который на сервере IBM почему-то даёт скорость всего 4Мб/с
Поставили "зеркало" и получили 80Мб/с, RAID-6 - 70Мб/с, разбираемся с тех.поддержкой IBM.

2(max44) Скорость записи/чтения мониторили по Perfomance счётчикам (Администрирование / Производительность), загрузка жёсткого диска в процентах

2(Денис Ильин) 10Гб свободно в ОПЕРАТИВКЕ !
23 дек 09, 17:07    [8109094]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли принудительный кэш записи SQL-Server ?  [new]
ziktuw
Member

Откуда:
Сообщений: 3552
wwwolfy
Есть база 1С, есть SQL Server 2008

В базе 1С кроме обычной работы пользователей запускается процедура "перепроведения документов", которая даёт очень сильную нагрузку на дисковую систему (постоянная запись).

На сервере (Win2003) есть свободная память (10Гб) и хотелось бы отказаться от постоянной записи, так как записывается одно и то же - меняются остатки/итоги регистров, они пересчитываются и постоянно сбрасываются на хард. Чтения практически нет, так как всё в кэше SQL.

Есть ли возможность отключить запись на хард, т.е. производить её только (допустим) раз в 10 минут ?


На дисковом контролере есть кэш. Для СУБД он обычно выключается на запись (настройка WRITE THRU). Но вы его можете включить - настройка WRITE BACK. Это делается вендорской утилитой конфигурации контролера (или RAID-массива). При включении WRITE BACK вы берете на себя всю ответственность за повреждение БД при сбое питания или оборудования.
24 дек 09, 09:43    [8111162]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли принудительный кэш записи SQL-Server ?  [new]
wwwolfy
Member

Откуда:
Сообщений: 15
Глеб

На дисковом контролере есть кэш. Для СУБД он обычно выключается на запись (настройка WRITE THRU). Но вы его можете включить - настройка WRITE BACK. Это делается вендорской утилитой конфигурации контролера (или RAID-массива). При включении WRITE BACK вы берете на себя всю ответственность за повреждение БД при сбое питания или оборудования.


проблема не тока в СУБД, при обычном копировании тоже
Короче ждём ответа от суппорта ИБМ
24 дек 09, 12:42    [8112521]     Ответить | Цитировать Сообщить модератору
Между сообщениями интервал более 1 года.
 Re: Существует ли принудительный кэш записи SQL-Server ?  [new]
Valerii79
Member

Откуда: Кишинев, Молдавия
Сообщений: 395
vino
wwwolfy
Есть база 1С, есть SQL Server 2008

В базе 1С кроме обычной работы пользователей запускается процедура "перепроведения документов", которая даёт очень сильную нагрузку на дисковую систему (постоянная запись).

На сервере (Win2003) есть свободная память (10Гб) и хотелось бы отказаться от постоянной записи,...
Исследуйте нагрузку на TempDB во время "перепроведения документов": если она большая, а память действительно свободна, и TempDB не растет более 9Гб, то создайте "виртуальный" раздел и разместите там TempDB.
Запись лога во время операций при работе SQL - нормальное явление (при любой модели восстановления). Тем более на Simple нужно иметь быстрый диск для лог-файла


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

1. Как узнать находятся ли обычная таблица (порядка 20-30 строк) с редко изменяемыми данными в буферном кэше после упреждающего чтения? Из нее постоянно читаются данные.

2. Т.к. есть обычные таблицы с постоянно изменяющимися данными, то есть ли смысл вместо создания виртуального диска для tempdb скидывать все данные из этих таблиц в соответствующие глобальные временные таблицы, которые, как я понял из BOL, будут постоянно находиться в кэше (памяти) из-за педполагаемого небольшого размера (порядка 20-30 строк), и т.о. создание виртуального диска для tempdb не нужно?
23 фев 12, 23:15    [12144175]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли принудительный кэш записи SQL-Server ?  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
Valerii79
Также есть задача ускорения обработки данных!
Всвязи с этим есть вопросы к более опытным участникам форума.

1. Как узнать находятся ли обычная таблица (порядка 20-30 строк) с редко изменяемыми данными в буферном кэше после упреждающего чтения? Из нее постоянно читаются данные.

Почти наверняка она будет в буферном кэше. Если нет, то у вас явно memory pressure.
Проверить находится ли таблица в кэше можно так:
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

SELECT 
  OBJECT_SCHEMA_NAME(p.[object_id]) + '.' + OBJECT_NAME(p.[object_id]) AS [TableName],
  p.index_id, 
  CASE WHEN i.index_id IS NOT NULL THEN ISNULL(i.name, '<<<HEAP>>>') ELSE NULL END AS [IndexName], 
  CAST(a.CNT/128. AS NUMERIC(20,2))  AS [BufferSize MB],  
  CAST(CASE WHEN p.object_id IS NULL THEN NULL ELSE a.free_space_in_mb END AS NUMERIC(20,2)) AS [EmptySize MB], 
  CAST(CASE WHEN p.object_id IS NULL THEN NULL ELSE a.cnt_is_modified/128. END AS NUMERIC(20,2)) AS [DirtySize MB],
  CAST(CASE WHEN p.object_id IS NULL THEN NULL ELSE a.free_space_in_mb/(a.CNT/128.)*100 END AS NUMERIC(20,2)) AS [EmptySize %], 
  a.RowCountLeaf AS CachedRowCountLeaf,
  p.rows AS TotalRowCount,
  CAST(ROUND(CASE WHEN p.rows < a.RowCountLeaf THEN 100. ELSE ISNULL(100.0 * a.RowCountLeaf / NULLIF(p.rows,0),0) END, 4)  AS DECIMAL(8,4)) AS [Cached %],
  p.partition_number,
  a.CNT AS BufferCount,
  a.cnt_is_modified AS DirtyBufferCount
FROM
  (
    SELECT 
      a.container_id,
      COUNT(*) AS CNT,
      SUM(CAST(free_space_in_bytes AS BIGINT)) / (1024. * 1024) AS free_space_in_mb, 
      SUM(CASE WHEN b.is_modified = 1 THEN 1 ELSE 0 END) AS cnt_is_modified,
      SUM(CASE WHEN a.type = 1 and page_level = 0 and page_type IN ('INDEX_PAGE','DATA_PAGE') THEN b.row_count ELSE 0 END ) AS RowCountLeaf
    FROM sys.dm_os_buffer_descriptors AS b
      LEFT JOIN sys.allocation_units AS a ON a.allocation_unit_id = b.allocation_unit_id
    WHERE b.database_id = DB_ID()
    GROUP BY a.container_id
  ) a
  LEFT JOIN sys.partitions AS p ON a.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 BufferCount DESC;


Valerii79
2. Т.к. есть обычные таблицы с постоянно изменяющимися данными, то есть ли смысл вместо создания виртуального диска для tempdb скидывать все данные из этих таблиц в соответствующие глобальные временные таблицы, которые, как я понял из BOL, будут постоянно находиться в кэше (памяти) из-за педполагаемого небольшого размера (порядка 20-30 строк), и т.о. создание виртуального диска для tempdb не нужно?

К чему все эти приседания и манипуляции? У вас проблемы с производительностью? Вы уже нашли их причину?
Про виртуальный диск для tempdb вообще пока забудьте.
24 фев 12, 00:59    [12144492]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли принудительный кэш записи SQL-Server ?  [new]
Valerii79
Member

Откуда: Кишинев, Молдавия
Сообщений: 395
Mind,

благодарю за ответ!

Проблем с производительностью нет! Но есть задача уменьшить количество обращений к дисковой подсистеме. И поэтому попробую таблицы с небольшим кол-вом часто изменяемых данных (20-30 строк) копировать в глобальные временные таблицы и обрабатывать данные, обращаясь уже к временным таблицам.
24 фев 12, 10:34    [12145304]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли принудительный кэш записи SQL-Server ?  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
Valerii79
Mind,
Проблем с производительностью нет! Но есть задача уменьшить количество обращений к дисковой подсистеме. И поэтому попробую таблицы с небольшим кол-вом часто изменяемых данных (20-30 строк) копировать в глобальные временные таблицы и обрабатывать данные, обращаясь уже к временным таблицам.

Oh my God! Зачем? Зачем это делать, объясните мне? Чтобы усложнить код и логику? Не пытайтесь придумать себе проблем там где их нет. Все что должно быть закэшировано будет закэшировано, главное не мешайте SQL Server-у работать. Временные таблицы ничем не отличаются от обыкновенных по части кэширования.
24 фев 12, 10:57    [12145456]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли принудительный кэш записи SQL-Server ?  [new]
SanyL
Member

Откуда: Москва
Сообщений: 4540
Valerii79
Проблем с производительностью нет! Но есть задача уменьшить количество обращений к дисковой подсистеме.


Класс! Хорошая задача...


ps Когда солдату нечем заняться - всегда выручает куча песка. Сегодня перекидываем кучу на 5 метров в право, а завтра обратно!
24 фев 12, 11:23    [12145608]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли принудительный кэш записи SQL-Server ?  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
SanyL
Valerii79
Проблем с производительностью нет! Но есть задача уменьшить количество обращений к дисковой подсистеме.


Класс! Хорошая задача...


ps Когда солдату нечем заняться - всегда выручает куча песка. Сегодня перекидываем кучу на 5 метров в право, а завтра обратно!

Да ладно вам стебаться, может у них тарификация по IO. 100 IO операций стоит 3 бакса :)
24 фев 12, 11:29    [12145642]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли принудительный кэш записи SQL-Server ?  [new]
Valerii79
Member

Откуда: Кишинев, Молдавия
Сообщений: 395
Mind
Valerii79
Mind,
Проблем с производительностью нет! Но есть задача уменьшить количество обращений к дисковой подсистеме. И поэтому попробую таблицы с небольшим кол-вом часто изменяемых данных (20-30 строк) копировать в глобальные временные таблицы и обрабатывать данные, обращаясь уже к временным таблицам.

Oh my God! Зачем? Зачем это делать, объясните мне? Чтобы усложнить код и логику? Не пытайтесь придумать себе проблем там где их нет. Все что должно быть закэшировано будет закэшировано, главное не мешайте SQL Server-у работать. Временные таблицы ничем не отличаются от обыкновенных по части кэширования.


Еще раз спасибо за ответ! Читал и похожие темы, и Ваш пост также прочитал, и статью Майкрософт tempdb на RAM-диске
Может я не совсем точно высказался: данные не просто копируются, а постоянно пересчитываются и должны храниться где-нибудь, до следующего обновления данных. Пока что в начальной разработке это обычные пользовательские таблицы, так что перенос временных данных в tempdb уже почти решен положительно (у пользовательских таблиц вижу только одно преимущество - они не исчезнут после разрыва соединения, что хоть и не часто, но может произойти).
24 фев 12, 11:30    [12145654]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли принудительный кэш записи SQL-Server ?  [new]
Valerii79
Member

Откуда: Кишинев, Молдавия
Сообщений: 395
SanyL
Valerii79
Проблем с производительностью нет! Но есть задача уменьшить количество обращений к дисковой подсистеме.


Класс! Хорошая задача...


ps Когда солдату нечем заняться - всегда выручает куча песка. Сегодня перекидываем кучу на 5 метров в право, а завтра обратно!


Скорость обращения к дисковой подсистеме как минимум на порядок медленнее, чем к памяти.
24 фев 12, 11:36    [12145687]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли принудительный кэш записи SQL-Server ?  [new]
SanyL
Member

Откуда: Москва
Сообщений: 4540
Valerii79
Mind
пропущено...

Oh my God! Зачем? Зачем это делать, объясните мне? Чтобы усложнить код и логику? Не пытайтесь придумать себе проблем там где их нет. Все что должно быть закэшировано будет закэшировано, главное не мешайте SQL Server-у работать. Временные таблицы ничем не отличаются от обыкновенных по части кэширования.


Еще раз спасибо за ответ! Читал и похожие темы, и Ваш пост также прочитал, и статью Майкрософт tempdb на RAM-диске
Может я не совсем точно высказался: данные не просто копируются, а постоянно пересчитываются и должны храниться где-нибудь, до следующего обновления данных. Пока что в начальной разработке это обычные пользовательские таблицы, так что перенос временных данных в tempdb уже почти решен положительно (у пользовательских таблиц вижу только одно преимущество - они не исчезнут после разрыва соединения, что хоть и не часто, но может произойти).


Забудьте про RAM диски, вот будто ни когда о них не слышали! Не надо этого делать!

И не стоит решать проблему там где ее нет.
т.е. оптимизация дисковой подсистемы на которую нет нагрузки безполезна! Если Вы думаете что поставив железо в 100раз мощнее вы получите в 100 раз больше производительности = ошибаетесь. Если Вы не могли загрузить слабое железо - то мощное не сможете загрузить точно, и прироста производительности ожидать особого смысла нет.


>Пока что в начальной разработке это обычные пользовательские таблицы, так что перенос временных данных в tempdb уже почти решен положительно (у пользовательских таблиц вижу только одно преимущество - они не исчезнут после разрыва соединения, что хоть и не часто, но может произойти).

Это вообще сложно комментировать... Есть общие принципы и подходы к разработке, есть вещи где применимы и неприменимы временные таблицы. Это компетенция разработчика, а не руководства "которое рассматривает и принимает решение".
24 фев 12, 11:39    [12145714]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить