[Busla]

Если серьезно - учите матчасть. Могу привести два аргумента, теоретический и практический: 1) В 32х битной системе процессу больше двух гигабайт памяти не выделяется. Потоки делят память внутри процесса. Идеальный случай: - у вас много памяти, по крайней мере достаточно для безпроблемного кеширования всего и вся, или размер данных не велик и полностью влезает в память. - один файл данных обслуживает один процесс кэширования операций чтения/записи. - Файлов много, процессов кеширования тоже. Так вот, дорогой друг, при размере файла данных более 2 гигабайт, даже при наличии свободной памяти, один процесc не сможет обслужить файл данных, дабы тот целиком влез в кэш. А при не равном соотношении количестве процессов - файлов это уже конкуренция за ресурсы. Естественно на это имеет смысл обращать внимание лишь в высоконагруженных системах. »

Матчасть я, как раз, знаю, спасибо:
1) ключ 3gb файла boot.ini позволяет перераспредилить адресное пространство, и пользовательским процессам будет отведено до 3Гб
2) памяти у нас всё же меньше чем объём данных, и для чтения-записи какой-то части файла его ОС целиком в память не грузит
3) ОС работает с дисковой системой не на уровне байтов, а на уровне секторов (512 байт); кластеров (как правило больше секторов); SQL Server на уровне - страниц (8Кб) и групп страниц (extent - 64Кб). Соответственно и чтение-запись осуществляется блоками по 8-64 Кб, а не массивами "сколько в память влезет".
4) У нас речь и о величине прироста файла или об абсолютном размере файла? Прирост я как раз рекомендовал делать меньше 2Гб. А разбивать БД на множество мелких файлов в большинстве случаев неэффективно.

[Busla]

если хотите разобраться с моделями архивирования в MS SQL изучите команду DUMP »

нету больше DUMP - в 2k это уже нерекомендуемая операция, которая оставлена исключительно для совместимости (как и LOAD). Нужно пользоваться BACKUP и RESTORE.

Если в системе появились "нетипичные операции", то нужно убивать либо программистов (обычно они первые гадят), либо пользователя, либо администратора. »

Операции/мероприятия проводимые раз в квартал, год - можно назвать типичными? - Сомневаюсь. Тем не менее, они очень даже присутствуют в бухгалтерской деятельности (раз уж речь про 1С). Открытие нового филиала, какая-нибудь ревизия-инвентаризация - вообще непериодические операции - вряд ли о каждом подобном действе будут сообщать администратору

[kim-aa]

Busla,
Типичные-типичные.
Любой стандартный отчет типичный. Главное период наблюдения.

и пользовательским процессам будет отведено до 3Гб »

Да. Вы правы. Но это не изменит win32. Это изменит выделение памяти нескольким процессам.

ОС работает с дисковой системой не на уровне байтов, а на уровне секторов (512 байт); кластеров (как правило больше секторов); SQL Server на уровне - страниц (8Кб) и групп страниц (extent - 64Кб). Соответственно и чтение-запись осуществляется блоками по 8-64 Кб, а не массивами "сколько в память влезет" »

Честно говоря не понял аргумента. Какая разница в страницах или секторах, 2 ГБ будет всегда.

У нас речь и о величине прироста файла или об абсолютном размере файла? Прирост я как раз рекомендовал делать меньше 2Гб. А разбивать БД на множество мелких файлов в большинстве случаев неэффективно. »

Значитсо мы говорим об одном и том же. Я уже поправился.
На счет разового выделения 2ГБ - Вы правы. Не хилая операция. Но в тех же рекомендациях MS, рекомендуется выделять пространство заранее.
---------------------------------

Busla,
На самом деле, тут у нас эстетский тред, вызванный кривостью реализации 1C.

[DoublE_zone]

По умолчанию архивирование журнала транзакций (Transaction Log) осуществляет и его усечение »

А насколько происходит усечение файла журнала транзакций при бэкапе (в процентах, примерно, если не существует точных данных)? Отобразится ли это на его фактическом размере (он станет меньше в GB) или просто файл останется таким же по размеру (но освободится зарезервированное пространство внутри самого файла под новые логи)?
И сколько может весить такой бэкап, опять же в процентах от файла транзакций логов?

[kim-aa]

или просто файл останется таким же по размеру (но освободится зарезервированное пространство внутри самого файла под новые логи)? »

Да

[DoublE_zone]

kim-aa, при резервировании файла транзакций логов на тестовой базе (файл равнялся 612MB), урезка файла получилась (если получилась) совсем крошечной... Смотрел через "Свойства базы - Задачи - Сжать - Файлы", там четко видно, сколько реально занято пространства из файла. То есть, ощутимой выгоды по урезке файла логов резервирование оного не дает.

[kim-aa]

То есть, ощутимой выгоды по урезке файла логов резервирование оного не дает. »

Вы не поняли. Очищает файл логов не сама процедура архивирования.
Просто при архивировании файла логов есть опция очищать его.
Вы можете сделать то же самое написав SQL-скриптик который будет просто очищать файл логов.

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

[DoublE_zone]

kim-aa, извиняюсь, видимо, галка эта по умолчанию не стояла, а так я ее не заметил.
В понедельник попробую.
А вот скрипт, который позволяет очистить журнал транзакций без проведения резервного копирования (еще не проверял, нашел в умной книге): BACKUP LOG имя базы TRUNCATE_ONLY.

Нашел хорошую книгу... Ростислав Михеев. "MS SQL Server 2005 для администраторов". Рассмотрены многие важные моменты, которые упущены в других изданиях. Очень рекомендую.

[Busla]

(еще не проверял, нашел в умной книге): BACKUP LOG имя базы TRUNCATE_ONLY »

это можно было найти и в "умном хэлпе". Формально:
BACKUP LOG имя_БД WITH TRUNCATE_ONLY
хотя мне тоже попадались примеры без with

[kim-aa]

К вопросу об "автоинременциях" и прочем автоматизме