» Microsoft SQL SERVER

люди подскажите что сделать, вот такая ситуация:
есть сервер 2008 х32, на нем стоит скуль 2008 и 1с, перекинули базу 1с с файла в базу теперь наблюдаю что скуль есть полтора гига памяти

Добавлено:
может где то что то нужно оптимизировать в скуле?((((

kot488
Вообще первый вопрос будет - а что он так мало жреть
А если спрашивать правильно - то 1. размер бызы?
2. сколько польователей
3. какой режим востановления

BigBear

Цитата:

3. какой режим востановления

А что от режима востановления размер пожираемой памяти зависит?

Цитата:

А что от режима востановления размер пожираемой памяти зависит

да

Цитата:

да

Вот это новость! А в чем различие для режимов full, simple и bulk-logged?

kazavo4ka

Цитата:

А что от режима востановления размер пожираемой памяти зависит
да

как это так?

я наверное не правильно выразился
третий вопрос имел отношение к
Цитата:

может где то что то нужно оптимизировать в скуле?((((

а не к потреблению памяти
человек спросил что можно настроить
после его ответов можно давать какие- то советы по настройки сиквела
а я просто поразился что sql так мало памяти сьел

Цитата:

А в чем различие для режимов full, simple и bulk-logged?

в механизме их работы


Цитата:

как это так?

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

то, что пришло в голову лично мне:
- разный программный код требует различного объема оперативной памяти
- при модели full, файл лога будет иметь больший чем при simple размер = увеличению затрат на "обслуживание" этого файла

Цитата:

в механизме их работы

Я спрашивал про память. Разница в механизме работы минимальна - в симпл при чекпойнте неактивные vlf'ы метятся как свободные, а в фулл\балк-логгед - нет. Рост файла журнала транзакций связан как раз с этим. А вот про память, увы, ничего не знаю.

Цитата:

при модели full, файл лога будет иметь больший чем при simple размер = увеличению затрат на "обслуживание" этого файла

"обслуживание" лога, фактически, производится только при старте сервера - когда накатываются\откатываются незавершенные транзакции. В остальное время - тупо дописывание в конец последнего активного vlf. К памяти это, можно сказать, не относится.

Цитата:

Я спрашивал про память.

я понял


Цитата:

в симпл при чекпойнте неактивные vlf'ы метятся как свободные, а в фулл\балк-логгед - нет. Рост файла журнала транзакций связан как раз с этим.

спасибо за объяснение принципов работы этого механизма, но я и так в курсе


Цитата:

Разница в механизме работы минимальна

разница минимальна != отсутствию разницы
Это если опустить контекст в котором задавался вопрос kot488. Если же смотреть относительно этого вопроса, то да, согласен что скорее всего разница будет минимальной, но без конкретики - точных замеров не производил


Цитата:

К памяти это, можно сказать, не относится.

а я бы так сказать не смог - это относится ко всем ресурсам + бэкапы и шринки

Цитата:

это относится ко всем ресурсам + бэкапы и шринки

можете немного развернуть мысль? Каким образом на память влияет модель восстановления? Или, даже, уточняя - Как именно размер лог-файла влияет на использование памяти SQL Server'ом? Какие затраты и на какое "обслуживание" этого файла повлияют на память?

Цитата:

Как именно размер лог-файла влияет на использование памяти SQL Server'ом?

вы не так давно сами предложили один из вариантов ответа

Цитата:

"обслуживание" лога, фактически, производится только при старте сервера - когда накатываются\откатываются незавершенные транзакции.

это один пункт

вот навскидку второй -

Цитата:

The overhead of reading/writing to VLFs by the LogReader and LogWriter processes is affected by the sheer quantity and size of them, and can affect the servers performance on a number of operations, like the discovery of VLFs when starting up a Database, or when scanning every VLF for transactions that are marked for replication.

такой ответ устроит?

Цитата:

вы не так давно сами предложили один из вариантов ответа

Цитата: "обслуживание" лога, фактически, производится только при старте сервера - когда накатываются\откатываются незавершенные транзакции.

и как это зависит от модели восстановления О_О? Активная часть в любой модели одинакова (если в ней было BULK-операций, а если были - то база в простой модели просто не поднимется).


Цитата:

вот навскидку второй -

Дак ведь и тут речь про активную часть - которая будет одинакова при любой модели восстановления. Более того, по ссылке речь идет не про размер самого файла, а про количество VLF в нем.

Цитата:

That is why these operations can take a long time when there is a large TLog made up of a big number of VLFs.

следующее предложение после процитированного вами.

bigsloth

Цитата:

Разница в механизме работы минимальна - в симпл при чекпойнте неактивные vlf'ы метятся как свободные, а в фулл\балк-логгед - нет. Рост файла журнала транзакций связан как раз с этим.

Про память замнем для ясности - сколько ни дай - SQL все сожрет... А вот про журнал транзакций, подробней можно (по понятней, не только sa)? То он неделями держится в нормальных рамках (~ равен данным), то разрастается в разы... что это значит?

Цитата:

То он неделями держится в нормальных рамках (~ равен данным), то разрастается в разы... что это значит?

Зависит от. Какая у вас модель восстановления? Как часто делается резервное копирование журнала транзакций (если модель полная)? За какое время журнал разрастается (ночью, или непрерывно в течении нескольких дней растет)? Репликация/зеркалирование/лог-шиппинг используется? Дефрагментация/перестройка индексов когда и как делается?

bigsloth

Цитата:

Какая у вас модель восстановления?

По умолчанию - полная. Думаю переключить на простую... но не знаю чем это грозит в плане производительности. Сисадмин, который занимался SQL, уволился, а нового нет пока... Полный бэкап делается только ночью. Бэкап транзакций делаю только когда базу надо сжать - обычно утром проверяю.
Цитата:

Репликация/зеркалирование/лог-шиппинг используется? Дефрагментация/перестройка индексов когда и как делается?

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

Цитата:

Бэкап транзакций делаю только когда базу надо сжать - обычно утром проверяю.

поэтому у вас лог и растет. В простой модели восстановления SQL Server периодически (это зависит от нескольких факторов - значение recovery interval, заполненность журанал транзакций) делает чекпойнт - скидывает "грязные" (измененные) страницы в кэше SQL Server на диск и проверяет - если какие-то записи в журнале транзакций уже не понадобятся для приведения базы в целостное состояние (все транзакции, связанные с ними завершены и все данные, измененные этими транзакциями уже записаны на диск) при перезапуске сервера, то он их "удаляет" и то место которое было занято этими записями сразу же может использоваться повторно. "Удаляет" в кавычках, т.к. фактически не удаляет, а просто отмечает это место как свободное.
В вашем случае (т.е. при полной модели восстановления), чекпойнт тоже периодически выполняется, но разница в том, что записи из журнала транзакций не удаляются, а просто помечаются как "неактивные" - т.е. не нужные для приведения базы в целостное состояние. И все эти записи остаются в вашем журнале транзакций до тех пор, пока вы не сделаете бэкап журнала транзакций - вот он ваш рост лога. Учтите, что когда вы делаете бэкап с ключевым словом TRUNCATE_ONLY, фактически, никакого бэкапа не делается, а из журнала просто удаляются неактивные записи. Т.е. вы вручную делаете практически тоже самое, что sql server автоматически делает в простой модели восстановления.


Цитата:

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

Смотрите job'ы (ветка SQL Server Agent в SSMS) и maintenance plan'ы (ветка Management). Раз вырастает за ночь - скорее всего ночью что-то выполняется. Утром вы лог чистите, а следующей ночью все повторяется.


Цитата:

Думаю переключить на простую... но не знаю чем это грозит в плане производительности.

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

Цитата:

и как это зависит от модели восстановления О_О? Активная часть в любой модели одинакова

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


Цитата:

Дак ведь и тут речь про активную часть - которая будет одинакова при любой модели восстановления.

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

Цитата:

Более того, по ссылке речь идет не про размер самого файла, а про количество VLF в нем.

ок, больше "логических" данных в одном файле тоже, как видно из примера, влияют на ситуацию с производительностью (в свое время читал блог одного мужика - он даже замеры делал, зависимость производительности от количества vlf'ов при определенных ситуациях существует существует)
Понятно что это можно настроить, но тем не менее разница с simple будет

Цитата:

больше "логических" данных в одном файле

vlf - это не логические данные. Это вполне себе физические куски, на которые делится кусок файла, добавляемый к логу. И именно этими кусками оперирует sql server - их отмечает как активные/неактивные/свободные.
Количество vlf не зависит напрямую от модели восстановления. Если выбрана правильная частота создания резервных копий журнала транзакций, размер журнала и, соответственно, количество vlf в нем НЕ БУДЕТ отличаться от количиства vlf в журнале при простой модели восстановления.
Вы, конечно, можете сказать, что выбор правильной частоты создания резернвых копий журнала - это и есть правильная настройка, но это не так - это требование. Как требование заправлять машину 98-м, а не 72-м бензином. На первом она едет нормально, на втором не едет совсем.
И разницы - не будет.

Цитата:

зависимость производительности от количества vlf'ов при определенных ситуациях существует

Да, существует. НО количество vlf не зависит от модели восстновления.
Например - у базы в простой модели восстановления стоит прирост в 10 мегабайт для журнала транзакций. И его размер сейчас 4 гигабайта. Количество vlf у вас будет - больше 1500! И каждый по 2,5 мегабайта.
А у базы в полной модели восстановления стоит прирост в 1 гигабай. И размер лога пусть даже 16 гигабайт - в результате вы будете иметь всего 256 vlf.

bigsloth

Цитата:

при перезапуске сервера, то он их "удаляет"

Если сервер работает постоянно, то переходить на простую схему смысла нет?

Цитата:

лог набирает "нужный" размер, т.е. такой, что в него помещается вся активная часть, и останавливается в росте.

"нужный" размер - это сколько, ~ размер данных?

Цитата:

Если сервер работает постоянно, то переходить на простую схему смысла нет?

Не понял как вы сделали такой вывод. Я вам просто рассказал как SQL Server работает с журналом транзакций и почему он растет в полной модели восстановления и, обычно, не растет в простой. Перезапуск сервера - это только один из случаев, когда sql server "шерстит" лог. Тоже самое происходит, например, при аттаче базы.
Контрольные точки и активная часть журнала
Выбор модели восстановления должен основываться на требованиях к БД по возможности восстановления после сбоев. Если вас устроит, что после повреждения вы сможете восстановиться из последнего полного бэкапа+ последнего диф. бэкапа (который мог быть сделан за 12 часов до сбоя, например) - ваш выбор простая модель. Если вам нужно восстановить БД на момент непосредственно перед сбоем - ваш выбор полная модель восстановления и регулярные бэкапы журнала транзакций.

Цитата:

"нужный" размер - это сколько, ~ размер данных?

it depends. Для полной модели восстановления - это объем записей в журнале транзакций между двумя бэкапами журнала транзакций, умноженный на два. Для простой модели восстановления - объем записей в журнале транзакций между двумя чекпойнтами, умноженный на два. И это ооочень примерно - зеркалирование, репликация, длительные транзакции запросто могут привести к увеличению размера файла журнала транзакций.

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

Установится ли SQL Server 2005 на Windows 7 Ultimate x64???

Kerstraff

Цитата:

Установится ли SQL Server 2005 на Windows 7 Ultimate x64

http://forum.oszone.net/post-1326352.html

opt_step
Спс,просто уже сто раз ставил 2008 и никак не хочет работать...

Есть скуль 2008 в нем база 1С, делается резервное копирование на другой диск, как можно реализовать на другой ПК в сети?

Убедиться что у учеток под которыми запущны sql server agent и sql server есть права на запись на этой шаре и переделать скрипт - указать путь в UNC-формате (\\mycomp\sharename\backupname.bak)

Цитата:

Убедиться что у учеток под которыми запущны sql server agent и sql server есть права на запись на этой шаре и переделать скрипт - указать путь в UNC-формате (\\mycomp\sharename\backupname.bak)

Тобесть такого вида путь должен быть

с:\1c\*****.bak;\\test\test\*****.bak ?

Чтобы сделать бэкап на удаленный компьютер, путь должен бытьпрописан так: \\имя_компьютера_на_который_делается_бэкап\имя_шары_для_бэкапа\имя_бэкапа
Если вам надо делать и на локальный компьютер, и на удаленный, то надо исопльзовать параметр, ЕМНИП, MIRROR TO. Это возможно только в Enterprise редакции.

bigsloth

Цитата:

Если вам надо делать и на локальный компьютер, и на удаленный, то надо исопльзовать параметр, ЕМНИП, MIRROR TO. Это возможно только в Enterprise редакции.

Никакого MIRROR TO нет ни в Enterprise, ни в любой другой редакции SQL Server.

Если надо делать бекапы на локальный и на удаленный - можно делать на локальный и удаленный по UNC пути последовательно; можно делать на локальный, а потом одним из бесчисленных способов (например запуском копирования через xp_cmdshell) копировать файл бэкапа на удаленный сервер.

Если же говорить о зеркалировании AKA Database Mirroring (одном из средств обеспечения высокой доступности) - это не имеет никакого отношения к "путям на шаре". И да, Database Mirroring с некоторыми ограничениями, но доступно на SQL Server Standard Edition.