ref-14882 (663315), страница 15
Текст из файла (страница 15)
* READONLY. При указании этого значения группа файлов переводится в режим «только для чтения». В этом режиме запрещается выполнение любых модификаций данных в файлах, принадлежащих соответствующей группе. Переключение группы файлов в режим «только для чтения» могут выполнять только пользователи, имеющие монопольный доступ к базе данных. Нельзя устанавливать в режим «только для чтения» первичную группу файлов, так как в этом случае системные таблицы будут заблокированы и выполнение любых изменений в базе данных (в том числе и отмена для группы файлов режима «только для чтения») станет невозможным.
* READWRITE. Действие этого значения обратно предыдущему. Используется для разрешения изменений в группе файлов, установленной в режим «только для чтения». Работа с этим значением, как и с предыдущим, разрешена только пользователям, имеющим монопольный доступ к базе данных.
* DEFAULT. Используется для маркировки указанной группы файлов как группы файлов по умолчанию (default filegroup). В эту группу файлов будут включаться все файлы данных, которые явно не включены ни в какую другую группу файлов. Более того, все объекты (индексы, таблицы и их столбцы), для которых явно не указано, в какой группе файлов они должны располагаться, будут размещены в группе файлов по умолчанию. Группа файлов, которая до этого была группой файлов по умолчанию, становится обычной группой.
О WITH . Вполне возможна ситуация, когда попытка изменения базы данных происходит при выполнении какой-либо транзакции. Как уже говорилось, эти две операции несовместимы и одна из них должна быть отложена до окончания другой. То есть администратор должен либо подождать завершения всех активных транзакций, либо принудительно прервать их выполнение. В первом случае администратор может довольно долго ждать завершения всех транзакций. Более того, ничто не помешает пользователям начинать новые транзакции. В предыдущих версиях, в том числе и в SQL Server 7.0, это было единственным решением. К счастью, в SQL Server 2000 появилась возможность принудительного прерывания всех пользовательских транзакций. Именно для этого и используется аргумент WITH , который определяет метод прерывания транзакций. Синтаксис конструкции следующий:
< termination > ::= ROLLBACK AFTER integer [ SECONDS ] | ROLLBACK IMMEDIATE | NO WAIT
» ROLLBACK AFTER num_second [SECONDS] — в этом случае сервер будет ожидать указанное количество секунд, прежде чем прервет все активные и обслуживание баз данных транзакции. Предварительно можно отправить пользователям сообщение по сети, что через столько-то секунд все транзакции будут принудительно откачены. За это время пользователи должны либо зафиксировать, либо откатить свои транзакции. * ROLLBACK IMMEDIATE — в этом случае откат пользовательских транзакций
выполняется немедленно без каких-либо пауз.
» NO WAIT— как и в предыдущем случае, откат происходит сразу же. О COLLATE < conation_name >. С помощью этого аргумента указывается сопоставление по умолчанию для всех объектов, создаваемых в базе данных. Изменение сопоставления по умолчанию не влияет на сопоставления, используемыми уже созданными объектами базы данных. Разрешается указываться как сопоставления Windows, так и сопоставления SQL Server. Определяет сопоставление для базы данных. По умолчанию задается сопоставление SQL Server.
О SET [ , . . . n ]. С помощью аргумента SET пользователь может управлять различными свойствами базы данных. Свойства указываются с помощью конструкции , которая имеет довольно объемную структуру. Более подробно управление свойствами базы данных будет рассмотрено далее в этой главе в разделе «Управление свойствами базы данных».
В предыдущих версиях SQL Server, включая и SQL Server 7.0, не поддерживалась
возможность изменения свойств базы данных с помощью команды ALTER DATABASE.
Уменьшение размера базы данных
В одном из предыдущих разделов этой главы было рассказано о возможности SQL Server 2000 автоматически увеличивать размер баз данных. Однако нередко требуется выполнить и обратный процесс — уменьшение размера базы данных. Действительно, если из базы данных удаляется значительная часть данных или после нескольких дней напряженной работы пользователи существенно снижают нагрузку на сервер и в журнале транзакций образуется много свободного пространства, часто возникает необходимость вернуть неиспользуемое дисковое пространство в операционную систему. Как и увеличение базы данных, процесс уменьшения размера базы данных, называемый также сжатием базы данных (shrinking database), представляет собой уменьшение размера отдельных файлов, из которых состоит база данных.
Операции сжатия базы данных по возможности должны выполняться в период наименьшей активности пользователей, чтобы доставлять им как можно меньше неудобств.
Как и увеличение, сжатие базы данных может выполняться автоматически. Однако при автоматическом сжатии нет возможности контролировать размер, на который необходимо уменьшить размер файлов базы данных. Сервер пытается освободить как можно большую, но не всю свободную часть базы данных. То есть в некоторых случаях сервер может оставить в файле лишнее свободное пространство, тогда как в других свести его к минимуму. Такое неконтролируемое сведение к минимуму свободного пространства очень скоро приводит к необходимости нового увеличения размера файла. Конечно, разумнее было бы оставить в файле какой-то процент свободного пространства, но, к сожалению, сервер этого не делает.
Автоматическое уменьшение размера базы данных происходит в том случае, когда сервер обнаруживает в базе данных слишком много неиспользуемого пространства.
Несмотря на некоторые недостатки автоматического уменьшения размера базы данных, нельзя не отметить и неоспоримое преимущество — администратор освобождается от необходимости следить за размером базы данных, а также за объемом используемого и свободного пространства, переложив эту обязанность на сервер.
Для разрешения или запрещения автоматического уменьшения базы данных используется хранимая процедура sp_dboption:
sp_dboption "database_name", "autoshrink". ("true" | "false")
С помощью первого аргумента указывается имя базы данных, свойства которой предполагается изменять. Второй аргумент должен оставаться таким, как он приведен выше. Указывая значение "true" или " f al se", можно соответственно разрешать и запрещать автоматическое уменьшение файлов базы данных.
Автоматическое уменьшение размера базы данных можно разрешить и с помощью команды ALTER DATABASE, воспользовавшись аргументом SET. Более подробно управление свойствами базы данных будет рассмотрено в следующем разделе.
Помимо автоматического можно также выполнять ручное уменьшение размера базы данных. Это делается с помощью команды контроля согласованности (или целостности) базы данных (database consistency check, DBCC):
DBCC SHRINKDATABASE
( databasejname [ , target_percent ]
[ , { NOTRUNCATE | TRUNCATEONLY } ]
)
Рассмотрим назначение аргументов.
О database_name. Имя базы данных, которую необходимо сжать.
О target_percent. Количество процентов свободного пространства, которое желательно оставить в базе данных после выполнения ее сжатия. Говоря точнее, с помощью рассматриваемого аргумента указывается процент от общего объема файлов базы данных, который должен быть незаполненным. Например, если в файле размером 10 Мбайт имеется 4 Мбайта свободного пространства, то для уменьшения количества неиспользуемого пространства до 2 Мбайт необходимо указать значение аргумента target_percent равным 25. Сначала сервер вычисляет объем свободного и занятого пространства (соответственно 4 и 6 Мбайт). Чтобы получить искомые 25 процентов, соотношение свободного и занятого пространства должно быть 3 к 1. Путем нехитрых вычислений сервер приходит к выводу, что нужный результат будет получен при размере файла, равном 8 Мбайт. После этого сервер переносит все данные из последних 2 Мбайт файла в первые 8 Мбайт, помещая их в любое незанятое место на странице. После того как все данные будут перенесены, выполняется уменьшение размера файла. Заметим, что в аргументе target_percent нельзя указывать размер, превышающий текущий процент свободного пространства. В противном случае уменьшение размера файла выполнено не будет. Таким образом, выполняя команду DBCC SHRINKDATABASE
г со слишком большим значением аргумента target_percent, можно получить ситуацию, когда уменьшения размера базы данных вообще не происходит.
О NOTRUNCATE. При задании этого аргумента свободное пространство не возвращается операционной системе, а резервируется в файлах для будущего использования, то есть физически уменьшения размера базы данных не происходит. Тем не менее, сервер все же выполняет перенос данных в начало файла, как это было описано для предыдущего аргумента.
О TRUNCATEONLY. При задании этого аргумента сервер удаляет все свободное пространство в файле за последним используемым экстентом. Значение аргумента target_percent при этом игнорируется. Не предпринимается никакой попытки перемещения данных для более эффективного их распределения в файле. Если в файле размером 2 Мбайт выделено всего два экстента в начале и в середине файла, то при использовании команды DBCC SHRINKDATABASE будет освобождена только половина файла, начиная от второго экстента и до конца файла. Размер файла будет составлять около 1 Мбайт, хотя в принципе он мог быть уменьшен до 128 Кбайт.
Права на сжатие базы данных с помощью команды DBCC SHRINKDATABASE выданы только членам фиксированной роли сервера sysadmin и фиксированной роли базы данных dbowner. Эти права не могут быть переданы пользователю никаким другим способом, кроме как включением его в одну из этих ролей. Чтобы уменьшить количество свободного пространства в базе данных pubs до 15% с резервированием освобожденного пространства для дальнейшего использования, необходимо выполнить следующую команду: DBCC SHRINKDATABASE (pubs. 15. NOTRUNCATE)
He имеет значения, в контексте какой базы данных выполняется команда DBCC SHRINKDATABASE, так как при ее вызове явно указывается имя нужной базы данных.
После выполнения команды сервер выдаст примерно следующее сообщение:
Dbld Fileld CurrentSize MinSize UsedPages EstimatedPages
5 2 96 63 96 56
(1 row(s) affected)
DBCC execution completed. If DBCC printed error messages, contact your system
administrator.
Рассмотрим назначение столбцов в полученном результате. О Dbld — идентификационный номер базы данных. Этот номер-будет одинаков
для всех отображаемых строк.
О Fileld— идентификационный номер файла базы данных, размер которого был уменьшен в процессе сжатия базы данных. Если некоторые файлы не были сжаты, то информация о них не выводится.
О CurrentSize— количество страниц, которое имеется в файле, причем учитываются как заполненные, так и свободные страницы.
О MinimumSize— минимальное количество страниц, до которого может быть уменьшен файл. Это значение может ограничиваться начальным размером файла, установленным при его создании. В ином случае оно равно значению в столбце EstimatedPages.
О UsedPages— количество страниц, содержащих данные.
О EstimatedPages— количество страниц, до которого может быть сжат файл. Однако не всегда файл может быть сжат до указанного размера, так как нельзя установить размер файла меньше первоначального.
Список баз данных и соответствующих идентификационных номеров хранится в таблице sysdatabases системной базы данных master. Для получения идентификационного номера базы данных можно использовать команду DB_ID ("databasename"). Если же необходимо определить имя базы данных по идентификационному номеру, то можно воспользоваться командой DB_NAME(database_id).
Команда DBCC SHRINKDATABASE работает с целой базой данных. Если же необходимо уменьшить размер конкретного файла базы данных, то для этого следует использовать команду DBCC SHRINKFILE, имеющую следующий синтаксис:
DBCC SHRINKFILE
( { filejname | fllejd }
{ [ . target_size ]
j [ . { EMPTYFILE | NOTRUNCATE | TRUNCATEONLY } ]
Выполнение этой команды, в отличие от команды DBCC SHRINKDATABASE, должно производиться в контексте той базы данных, файл которой предполагается уменьшить. Напомним, что для переключения баз данных используется команда USE. Рассмотрим назначение аргументов команды DBCC SHRINKFILE. О f i 1 e_name | f i 1 e_i d. Имя файла, который необходимо сжать, или его иден-
тификационный номер. Для получения идентификационного номера файла
базы данных можно использовать команду FILE_ID: FILE ID ("filename")
ПРИМЕЧАНИЕ
Список файлов базы данных, их идентификационных номеров, логических и физических имен хранится в таблице sysfiles каждой базы данных.
О target_size. Желательный размер (целое число в мегабайтах), который должен иметь файл после выполнения сжатия. Если размер не указывается, то файл сжимается до минимально возможного размера. При выполнении команды DBCC SHRINKFILE сервер при необходимости выполняет перемещение данных из части файла, которая должны быть удалена, в ту часть, которая будет оставлена. Если размер target_size меньше, чем минимально возможный размер файла, то сжатие файла будет выполняться только до минимально возможного размера. Например, если файл размером 20 Мбайт содержит 14 Мбайт данных, а пользователь пытается сжать его до 10 Мбайт, то файл будет сжат только до 14 Мбайт. Если размер файла после сжатия становится
меньше первоначального размера, то новый размер становится минимальным размером файла.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
