авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:     | 1 |   ...   | 22 | 23 || 25 | 26 |   ...   | 33 |

«Е.Мамаев MS SQL SERVER 2000 Книга посвящена одной из самых мощных и популярных современных систем управления базами данных - Microsoft SQL Server 2000. ...»

-- [ Страница 24 ] --

• READ UNCOMMITED Этот уровень обеспечивает решение проблемы последнего изменения (The lost update problem) и соответствует уровню блокирования 0 стандарта ANSI SQL-92. Это минимальный уровень изоляции SQL Server 2000. При его ис пользовании накладывается только блокировка, запрещающая изменение од них и тех же данных разными транзакциями. Однако данные, измененные транзакцией, могут быть прочитаны другой транзакцией. То есть не решается проблема грязного (dirty) и неповторяемого (unrepeatable) чтения. Кроме того, в наборе данных, используемых транзакцией, возможно удаление и появле ние новых строк — проблема чтения фантомов.

О READ COMMITTED Помимо решения проблемы последнего изменения на этом уровне решается проблема грязного чтения (The uncommitted dependency problem), что соответ ствует уровню блокирования 1 стандарта ANSI SQL-92. На изменяемые дан ные налагается блокировка, запрещающая не только модификацию, но и чтение данных другой транзакцией. Тем не менее, если транзакция не изме няет, а только читает данные, может сложиться ситуация, когда при повтор ном чтении она будет работать с иными данными, чем при предыдущем чте нии. Это так называемая проблема неповторяемого чтения. Также не решается и проблема чтения фантомов. Уровень изоляции READ COMMITTED использует ся в SQL Server 2000 по умолчанию.

П REPEATABLE READ При использовании этого уровня устанавливается режим изоляции, соответ ствующий уровню блокирования 2 стандарта ANSI SQL-92. Это обеспечивает решение проблемы неповторяемого чтения (The inconsistent analysis problem).

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

О SERIALIZABLE Это высший уровень изоляции, обеспечивающий полную независимость транзакций друг от друга. На этом уровне решается проблема чтения фанто мов (The phantom read problem). Отличительной особенностью реализации данного уровня изоляции является то, что на нем используется блокировка индекса. Это гарантирует, что в таблицу не могут быть вставлены или удале ны из нее строки, которые соответствуют логическому условию, используе мому для выборки данных.

Управление блокировками на уровне команд После открытия нового соединения устанавливается уровень изоляции READ COMMITED. При необходимости пользователь может задать любой другой уровень.

Кроме того, можно управлять уровнем изоляции не только на уровне соедине Глава 19. Транзакции и блокировки ния, но и на уровне отдельного запроса. Для этого в SQL Server 2000 существу ют специальные ключевые слова — xunrrtu (hint), которые указываются при вы полнении запроса. В предыдущих версиях SQL Server применение хинтов до пускалось только при выборке данных с помощью команды SELECT. В SQL Server 2000 разрешается использовать хинты также и для команд UPDATE, INSERT И DELETE.

При выполнении команд работы с данными хинты указываются с помощью ключевого слова WITH, после которого в круглых скобках пишется название хинта. Например, приведенная ниже команда производит выборку из таблицы t i t l e s всех названий книг, цена которых выше 15 условных единиц. При этом устанавливается блокировка на уровне строк.

SELECT title FROM titles WITH (ROWLOCK) WHERE price Рассмотрим хинты, которые используются в SQL Server 2000 для управления уровнем блокирования на уровне запроса:

• ROWLOCK. Блокировка устанавливается на уровне конкретной строки таблицы.

Рекомендуется указывать в случаях, когда необходимо блокировать всего не сколько строк.

П PAGLOCK. При использовании этого хинта взамен установки блокировки на уровне таблицы будет осуществляться блокировка на уровне страницы.

• TABLOCK. Блокировка устанавливается целиком на таблицу и удерживается только до конца выполнения команды. Тем не менее, если хинт TABLOCK применяется совместно с хинтом HOLDLOCK, TO блокировка будет удерживать ся до завершения всей транзакции. Если хинт TABLOCK используется в ко манде SELECT, то другие транзакции могут читать блокированные данные.

П TABLOCKX. Указание этого хинта позволяет блокировать таблицу полностью таким образом, что другие транзакции не смогут работать с данными до за вершения команды или транзакции. В отличие от хинта TABLOCK происходит полное блокирование таблицы, запрещающее даже чтение данных.

П HOLDLOCK. Этот хинт позволяет блокировать строку, страницу или таблицу целиком до конца транзакции, а не разблокировать их после завершения ко манды. Использование хинта HOLDLOCK позволяет применять в транзакции уровень изолированности SERIALIZABLE, даже если в соединении установлен другой уровень изолированности.

• UPDLOCK. При помощи этого хинта на ресурсы можно устанавливать так на зываемые блокировки обновления (update locks) взамен использования коллек тивных блокировок (shared locks). При этом блокировка сохраняется до конца команды или транзакции. Особенностью блокировок обновления является то, что они позволяют другим транзакциям читать данные, но запрещают из менять их. Когда необходимо выполнить изменение данных, блокировка об новления повышается до монопольной блокировки. После этого другие транзакции уже не смогут читать данные.

872 Часть IV. Разработка и сопровождение баз данных (~ Замечание } Типы блокировок и поведение сервера при использовании конкретного типа будет рассмотрено в следующем разделе.

• При указании этого хинта во время выполнения команды не уста NOLOCK.

навливается никакая блокировка. Это соответствует низшему (нулевому) уровню изоляции. Таким образом, другие транзакции могут изменять дан ные, которые читаются с помощью команды, использующей хинт NOLOCK. TO есть присутствуют проблемы грязного чтения, неповторяемого чтения и чте ния фантомов. Разрешается использовать только для команды SELECT.

• Использование этого хинта имеет тот же эффект, что и READUNCOMMITTED.

использование хинта NOLOCK. ДЛЯ команды устанавливается уровень изоля ции READ UNCOMMITTED.

О READCOMMITTED. При указании данного хинта для конкретной команды или транзакции устанавливается уровень изоляции READ COMMITTED. ПО умолча нию в SQL Server 2000 все команды выполняются с этим уровнем изоляции.

О REPEATABLEREAD. При указании этого хинта для конкретной команды или транзакции устанавливается уровень изоляции REPEATABLE READ.

• SERIALIZABLE. В данном случае система ведет себя так же, как и при исполь зовании хинта HOLDLOCK. Для конкретной команды или транзакции устанав ливается уровень изоляции SERIALIZABLE.

• READPAST. Когда в команде указывается этот хинт, то при выборке данных система будет пропускать строки, блокированные другими транзакциями, а не ожидать их завершения и разблокирования ресурсов. Использование этого хинта допускается только для команды SELECT. Кроме того, в соединении должен быть установлен уровень изоляции READ COMMITTED.

Типы блокировок Все действия пользователей по работе с данными можно разбить на две катего рии: чтения и изменения. К последним относится не только изменение собст венно данных, но и изменение таблиц и баз данных в целом — в том числе уда ление и вставка строк в таблицы. Как уже говорилось ранее в этой главе, в SQL Server 2000 имеется несколько различных типов блокировок, которые позволяют наиболее эффективно организовать работу с одними и теми же данными мно жеству пользователей. Тип блокировки либо выбирается сервером автоматиче ски в зависимости от выполняемых действий, либо самим пользователем при выполнении конкретной команды с помощью хинтов.

Основные типы блокировок В SQL Server 2000 существуют четыре основных типа блокировок:

• Коллективная блокировка (S, Shared). Коллективные блокировки являются наименее жестким типом блокировок SQL Server 2000. Обычно этот тип бло Глава 19. Транзакции и блокировки кировок используется при выполнении операций чтения (read only operation) данных. Типичным примером таких операций является команда SELECT. Ос новное достоинство коллективной блокировки в том, что она позволяет множеству транзакций читать одни и те же данные. При этом система гаран тирует, что если транзакция установила коллективную блокировку, то ни од на другая транзакция не сможет изменить эти данные. Тем самым решается проблема неповторяемого чтения.

П Блокировка обновления (U, Update). Этот тип блокировок, как следует из названия, используется при изменении данных. Блокировка обновления мо жет быть установлена непосредственно или коллективная блокировка может быть повышена до блокировки обновления. Блокировка обновления рас сматривается как подготовительный этап к собственно изменению данных.

Чтобы изменить данные, необходимо сначала установить монопольную бло кировку. Однако для непосредственной установки монопольной блокировки требуется, чтобы ни одна другая транзакция не читала данных. То есть моно польная блокировка несовместима с коллективными блокировками. Чтобы установить монопольную блокировку, транзакция должна поймать момент снятия всех блокировок со всех необходимых ресурсов. Однако это не всегда удается, особенно при работе с большим количеством данных. Для решения этой проблемы предназначена блокировка обновления. Когда транзакция хо чет изменить данные, она сначала устанавливает блокировку обновления.

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

• Монопольная блокировка (Е, Exclusive). Этот тип блокировок применяется при изменении данных. Установка этого типа блокировок возможна только в том случае, если на необходимые ресурсы не установлена никакая другая блоки ровка. Монопольная блокировка может быть установлена как непосредствен но, так и после повышения блокировки обновления. Если на ресурс установ лена монопольная блокировка, то ни одна другая транзакция не сможет никаким образом обратиться к данным. Это решает проблему грязного чтения.

• Блокировка массивного обновления (BU, Bulk Update). Данный тип блокиро вок используется при выполнении операций массивной вставки данных в таблицу с указанием хинта TABLOCK. Кроме того, блокировка массивного об новления может устанавливаться автоматически, если для таблицы с помо щью хранимой процедуры sp_tabieoption установлен параметр table lock on bulk load. Блокировка массивного обновления запрещает обращение к /Таблице любым процессам, не участвующим в операциях массивной вставки данных. Однако система не запрещает вставку новых строк в одну и ту же таблицу различным процессам массивного копирования.

874 Часть IV. Разработка и сопровождение баз данных С Замечание ) К операциям массивного копирования относится выполнение утилиты bcp.exe, ко манды BULK INSERT и вставка данных с помощью механизмов DTS.

Замечание Не всегда тип устанавливаемой блокировки может соответствовать типу выполняе мых операций. Например, при чтении данных командой SELECT пользователь может установить не только коллективную блокировку или блокировку обновления, но и монопольную блокировку. С другой стороны, при изменении данных пользователь может вообще не устанавливать никакой блокировки. Для этого достаточно исполь зовать соответствующие хинты или установить нужный уровень изоляции.

Специальные типы блокировок В предыдущем разделе были рассмотрены четыре основных типа блокировок, используемых не только в SQL Server 2000, но и во многих других системах управления базами данных. Описанные блокировки обеспечивают базовую функциональность СУБД. Однако в SQL Server 2000 помимо уже перечисленных типов блокировок имеются три специальных типа блокировок:

П блокировка намерений (Intent Lock);

О блокировка диапазона ключа (Key Lock);

О блокировка схемы (Schema Lock).

Блокировка намерений обеспечивает пользователей дополнительными возмож ностями для управления ресурсами. Она предназначена для блокирования ре сурсов вниз по иерархии объекта. Например, если предполагается, что хранимая процедура будет сканировать большую часть таблицы, то для снижения затрат на захват ресурсов и снижения времени ожидания снятия ранее наложенных блокировок в начале хранимой процедуры можно установить коллективную блокировку намерений на уровне таблицы. Любая другая транзакция сможет читать данные в таблице, но не сможет установить монопольную блокировку.

При этом хранимая процедура способна беспрепятственно обращаться к любым строкам таблицы. Установка блокировок на конкретные строки или страницы не требуется, т. к. блокировка относится ко всей таблице.

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

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

Если такая блокировка установлена, и она конфликтует с типом запрашиваемой блокировки, то установка новой блокировки запрещается. Если блокировка на мерений не установлена или ее тип не конфликтует с типом запрашиваемой блокировки, то менеджер блокировок проверяет, не существует ли конфлик Глава 19. Транзакции и блокировки тующая блокировка на уровне группы страниц, отдельной страницы или строки.

Такой конфликтующей блокировкой может быть как одна из основных блоки ровок, так и блокировка намерений.

(~ Замечание J Хотя использование блокировок намерений обеспечивает увеличение производи тельности работы с блокировками в целом, платой за это является снижение воз можности коллективной работы множества пользователей.

В SQL Server 2000 существует три типа блокировок намерений:

П Коллективная блокировка намерений (IS, Intend Shared). Этот тип блокиров ки намерений применяется в случае, когда предполагается читать данные вниз по иерархии объекта. Вместо установки множества коллективных бло кировок на уровне страницы или строки непосредственно в момент выпол нения команды чтения данных, можно установить коллективную блокировку намерений на уровне таблицы в начале транзакций и тем самым избежать ожидания разблокирования используемых другими транзакциями ресурсов. С другой стороны, при попытке некоторой транзакции установить монополь ную блокировку на множество ресурсов, достаточно выполнить лишь одну проверку на наличие блокировки намерений на уровне таблицы, чтобы уви деть, что в настоящий момент наложение такой блокировки невозможно и необходимо ожидать снятия блокировки намерения.

• Монопольная блокировка намерений (IE, Intent Exclusive). Данный тип бло кировок намерений предназначен для блокирования объектов, в которых предполагается выполнить множество изменений. На объект в целом уста навливается монопольная блокировка, так что никакая другая транзакция никак не сможет обратиться к данным блокированного объекта. Например, если предполагается изменить более 70% строк в таблице в середине длин ной транзакции и необходимо свести к минимуму период ожидания установ ки монопольной блокировки на все необходимые ресурсы, то в начале тран закции можно указать монопольную блокировку намерений, и менеджер блокировок не установит ни одной блокировки на запрашиваемые ресурсы.

П Коллективно-монопольная блокировка намерений (SIX, Shared with Intent Ex clusive). Этот тип блокировок намерений используется, когда транзакция вы полняет чтение большей части данных и частично изменяет их. Основное от личие данного типа блокировок от монопольной блокировки намерений в том, что первая изменяет лишь небольшую часть данных. При этом обеспе чивается возможность чтения неизменяемых данных другими транзакциями.

Например, транзакция устанавливает коллективно-монопольную блокировку намерений на уровне таблицы. На каком-то этапе транзакция начинает из менение данных. При этом менеджер блокировок устанавливает монополь ную блокировку намерений на уровне группы страниц или конкретной стра ницы и выполняет изменение данных. В то же время другие транзакции могут использовать для таблицы коллективные блокировки намерений на уровне таблицы и читать любые данные, для которых не используется моно 876 Часть IV. Разработка и сопровождение баз данных польная блокировка (Е или IE). Также разрешается наличие обычных кол лективных блокировок на ресурсы, на которые не установлена монопольная блокировка. Тем не менее, ни одна транзакция не может применить блоки ровку обновления (U) или монопольную блокировку (Е), если ранее к таб лице была применена коллективно-монопольная блокировка намерений.

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

Приведенные ранее типы блокировок, несмотря на их разнообразие, все же можно рассматривать как один тип блокировок — блокировка данных. Однако в SQL Server 2000 имеется возможность блокирования не только конкретного на бора страниц, строк, таблиц или группы страниц, но и захвата ресурсов на ос нове логического условия. Блокировки на основе логического условия называ ются блокировками ключа (Key Locks). Этот тип блокировок решает проблемы чтения фантомов (The phantom read problem) и обеспечивает реализацию выс шего уровня изолированности — сериализуемости транзакций (Serializable).

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

Замечание Операции обработки блокировок диапазона ключа являются довольно ресуроемки ми, хотя удаление и вставка строк в таблицу выполняются нечасто. Тем не менее, блокировка диапазона ключа осуществляется только в том случае, если установлен ;

уровень ИЗОЛЯЦИИ SERIALIZABLE.

Последний тип блокировок — это блокировка схемы (Shm, Schema Locks). Этот тип блокировок используется при выполнении команд языка модификации объ ектов баз данных (DDL, Data Definition Language). Типичным примером таких команд является команда ALTER. Блокировка схемы — это новый тип блокиро Глава 19. Транзакции и блокировки вок, который не существовал в предыдущих версиях SQL Server, т. к. только SQL Server 2000 позволяет выполнять изменение структуры объектов базы дан ных, таких, например, как таблицы и представления. Блокировка схемы предна значена для захвата метаданных объектов базы данных. Все объекты, созданные в базе данных, описываются в системных таблицах этой базы данных. Напри мер, информация о пользовательских таблицах хранится в системной таблице systabies, т. е. данные таблицы systabies являются метаданными, содержа щими сведения о структуре пользовательских таблиц. Любые другие объекты базы данных, такие как роли, пользователи, ограничения целостности, индексы, правила, умолчания и т. д. также описываются с помощью метаданных в сис темных таблицах.

В SQL Server 2000 реализовано два типа блокировок схемы:

П Блокировка стабильности схемы (Sch-S, Stability Lock). Этот тип блокировок служит для обеспечения неизменности метаданных объектов на время вы полнения транзакции. Система должна гарантировать, что во время работы транзакции объекты не будут изменены. Например, нельзя допустить, что за время выполнения транзакции один из пользователей изменит структуру таблицы таким образом, что она не будет содержать столбцов, которые чита ла транзакция, или что вследствие изменения структуры таблицы в ней будут содержаться иные данные, чем в начале транзакции. Блокировка стабильно сти схемы автоматически устанавливается менеджером блокировок, как только некоторая транзакция устанавливает любой тип блокировки на дан ные таблицы. Когда все блокировки в таблице снимаются, автоматически анулируется и блокировка стабильности схемы. Только после этого разреша ется изменение структуры таблицы.

П Блокировка изменения схемы (Sch-M, Modification Lock). Блокировки этого типа применяются непосредственно при изменении объекта базы данных.

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

Конфликты блокировок В предыдущих разделах были рассмотрены типы блокировок, используемых в SQL Server 2000 для выполнения требований ACID и реализации различных уровней изолированности. В зависимости от типа блокировки, уже установлен ной транзакцией на ресурс, запрещается или разрешается создание новых бло кировок другими транзакциями. Например, если к странице применена коллек тивная блокировка, то допускается установка только дополнительной коллек тивной блокировки или блокировки обновления. Образование монопольной Часть IV. Разработка и сопровождение баз данных блокировки не разрешается. В табл. 19.1 приведена сводная информация о со вместимости различных типов блокировок SQL Server 2000.

Таблица 19.1. Совместимость блокировок Тип наложенной блокировки Тип запрашиваемой блокировки и IX X IS SIX S * * Коллективная блокировка (S) * * Блокировка изменений (U) Монопольная блокировка (X) * * * * * Коллективная блокировка намерений (IS) * * Монопольная блокировка намерений (IX) Коллективно-монопольная блокировка наме рений (SIX) с Замечание Хотя монопольная блокировка не совместима ни с одним типом блокировок, вклю чая саму себя, тем не менее, монопольная блокировка намерений совместима сама с собой и с коллективной блокировкой намерений. Это связано с тем, что блокиров ка намерений говорит о том, что транзакция собирается изменить лишь часть бло кируемых данных, но не все. Если в момент установки монопольной блокировки на мерений на уровне таблицы уже существовала монопольная или коллективная блокировка намерений на уровне страницы или строки, то создание этой блокировки разрешается.

с Замечание Как уже говорилось ранее, блокировка стабильности схемы совместима со всеми типами блокировок, исключая блокировку модификации схемы. В свою очередь, блокировка модификации схемы несовместима ни с одним типом блокировки, вклю чая саму себя. Блокировка массивного обновления совместима только с другими блокировками массивного обновления и с блокировкой стабильности схемы.

Мертвые блокировки При одновременной работе с данными множества пользователей возможна си туация, когда две или более транзакций обращаются к одному и тому же набору данных. Если последовательность обращения к ресурсам у всех транзакций оди накова, то особых проблем не возникает — транзакция, обратившаяся к ресурсу позднее других транзакций, должна будет просто дождаться разблокирования нужных ресурсов. После этого она сможет нормально продолжить работу. Те перь предположим, что имеются две транзакции (назовем их А и в), обращаю щиеся к двум ресурсам (1 и 2). При запуске транзакция А обращается сначала к ресурсу 1, а транзакция в — к ресурсу 2. При этом каждая из транзакций уста Глава 19. Транзакции и блокировки навливает блокировку на используемый ресурс. На следующем этапе транзакция А обращается к ресурсу 2. Однако ресурс 2 уже блокирован транзакцией в. Та ким образом, транзакция А приостанавливается и ожидает снятия блокировки. В свою очередь транзакция в обращается к ресурсу 1, который блокирован тран закцией А. Это приводит к тому, что транзакция в станет ожидать снятия бло кировки с ресурса 1. Таким образом, каждая из транзакций ожидает разблоки рования ресурсов, используемых противоположной транзакцией. Однако ни одна из транзакций не может быть продолжена, т. к. для ее завершения необхо димо разблокирование ресурсов, используемых другой транзакцией. Описанная ситуация является типичным примером мертвой, или, как ее еще называют, ту пиковой блокировки.

(~ Замечание ^ Возникновение мертвой блокировки невозможно при выполнении операций чтения данных, т. к. допускается установка на один и тот же ресурс более одной коллектив ной блокировки. Обычно мертвые блокировки возникают при попытке изменения од них и тех же данных несколькими транзакциями.

Мертвая блокировка (deadlock) возникает, когда две или более транзакций пыта ются обратиться к ресурсам, блокированным ранее другими транзакциями — участницами мертвой блокировки. Описанный выше пример является простей шим вариантом мертвой блокировки, в которую вовлечены всего две транзакции и два ресурса. Однако на практике возможно образование мертвых блокировок, в которые втянуто множество транзакций, блокирующих десятки и сотни ресурсов.

Мертвая блокировка не может разрешиться сама собой. Если не предпринимать никаких дополнительных действий, мертвая блокировка способна существовать бесконечно долго. В системе управления базами данных должны быть преду смотрены механизмы, позволяющие решать конфликты мертвых блокировок.

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

Для установки времени ожидания разблокирования ресурсов используется сле дующая команда:

SET LOCKJHMEOUT t i m e o u t _ p e r i o d Время ожидания задается с помощью аргумента t i m e o u t p e r i o d в миллисекун дах. Период ожидания разблокирования ресурсов задается на уровне соедине ния. По умолчанию в соединении устанавливается период ожидания, равный — 1, что соответствует бесконечному ожиданию разблокирования ресурса.

Задание максимального значения для срока ожидания установки блокировки — это лишь механизм, позволяющий на уровне соединения избежать возникнове-/ ния мертвых блокировок. Тем не менее, на уровне сервера остается высока* 29 Зыс.1207 / 880 Часть IV. Разработка и сопровождение баз данных вероятность возникновения мертвых блокировок, т. к. нет гарантии, что для всех соединений будет назначен период ожидания разблокирования ресурса.

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

После обнаружения существования в системе мертвой блокировки менеджер бло кировок должен разрешить конфликт. Единственный способ разрешения кон фликта мертвой блокировки — это принудительное снятие одной из блокировок.

При этом происходит автоматический откат транзакции, блокировка которой бы ла снята. Соединение, инициировавшее транзакцию, получает сообщение об ошибке 1205 (откат транзакции вследствие возникновения мертвой блокировки).

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

SET DEADLOCK_PRIORITY {LOW | NORMAL I @ d e a d l o c k _ v a r } Использование аргумента LOW необходимо в тех ситуациях, когда транзакцией можно пожертвовать в случае возникновения мертвой блокировки. Аргумент NORMAL определяет стандартную цену транзакции. С помощью аргумента Sdeadiockvar можно указать цену транзакции с помощью переменной. Значение 3 соответствует использованию аргумента LOW, а значение 6 — аргументу NORMAL.

( Замечание ^ Установка цены транзакции возможна только на уровне соединения. То есть нельзя определить стоимость соединения по умолчанию на уровне сервера или базы данных, которые будут автоматически возникать для всех вновь устанавливаемых соединений.

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

В приложении должны быть реализованы механизмы отслеживания отката тран закции, а при необходимости, и повторного ее запуска.

Глава Работа с базой данных База данных является базовым элементом SQL Server 2000 и своего рода кон тейнером, в котором располагаются объекты и данные. Любой объект должен принадлежать базе данных. Каждая база данных имеет свою систему безопасно сти, связанную с системой безопасности SQL Server 2000. Любой пользователь при обращении к серверу работает в контексте какой-то базы данных. Каждой базе данных сопоставлен пользователь, который является ее владельцем (database owner);

Этот пользователь имеет имя dbo и ему предоставлены макси мальные права в базе данных.

В главе 18 была рассмотрена физическая и логическая архитектура баз данных SQL Server 2000. В этой же главе основное внимание будет отдано рассмотре нию практической работы с базой данных:

• планирование конфигурации базы данных;

О создание базы данных;

• управление свойствами базы данных;

• отсоединение и присоединение базы данных;

• внесение изменений в базу данных;

• удаление базы данных.

Будет обсуждаться выполнение указанных задач с использованием всех стан дартных средств, имеющихся в распоряжении пользователей — Transact-SQL, Enterprise Manager и мастера.

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

Планирование размещения файлов Возможность хранения информации базы данных в разных файлах открывает администратору большие возможности по управлению производительностью Часть IV. Разработка и сопровождение баз данных операций ввода/вывода. Основная задача планирования использования файлов сводится к оценке "тяжести" тех или иных данных, интенсивности обращения к ним, частоте обновления и изменения.

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

( Замечание ) Выбирая диск, на котором будут располагаться файлы базы данных, следует обра тить внимание на количество свободного пространства на диске. Необходимо учесть возможность увеличения в будущем файлов базы данных. Кроме того, для достижения максимальной производительности следует размещать файлы базы данных на логических дисках, принадлежащих разным физическим дискам. Допол нительное повышение производительности возможно за счет подключения дисков к разным контроллерам.

Например, если в таблице имеется столбец типа t e x t, n t e x t или image, то хра нение столбцов этого типа в отдельном файле может существенно повысить производительность. Поля типа text, ntext и image занимают много места, и хранение их вместе с основными данными может заметно снизить производи тельность операций выборки и сканирования данных. По возможности следует выносить столбцы типа t e x t, ntext и image на отдельные физические диски.

Также следует внимательно отнестись к индексам, созданным в базе данных.

Если индексы сложные и требуют частого перестроения, то также по возможно сти следует приписать их отдельному файлу или даже группе. Индексы можно хранить на отдельном жестком диске, на котором нет данных, но можно хра нить их и вместе с данными. В последнем случае нужно лишь располагать ин дексы и индексируемые данные на разных жестких дисках. Это позволит повы сить производительность обновления данных.

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

Если на компьютере с SQL Server 2000 установлено множество жестких дисков, то следует расположить на каждом из них как минимум по одному файлу базы данных. В сложных базах данных на каждом физическом диске можно разме щать несколько файлов. Для получения максимальной производительности сле дует выделить группы операций работы с данными. Для каждой группы опера ций следует проанализировать, к каким данным выполняются обращения, какие индексы используются, какова интенсивность чтения и изменения данных. На основе полученной информации следует разместить данные таким образом, что бы при выполнении каждой группы операций можно было добиться макси мальной производительности.

Глава 20. Работа с базой данных При работе на одном компьютере с SQL Server 2000 со множеством баз данных можно использовать для расположения файлов каждой из них отдельные диски или размешать файлы баз данных на всех доступных дисках. Выбор той или иной стратегии зависит от конкретной ситуации.

Использование групп файлов Строго говоря, SQL Server 2000 позволяет приписывать данные только к груп пе файлов. Для того чтобы сохранить данные таблицы или отдельной колонки в конкретном файле, необходимо создать новую группу, содержащую только этот файл. Как ясно из вышесказанного, группы файлов создаются для повы шения производительности операций ввода/вывода и облегчения управления размещением данных. Хранение данных в конкретных файлах было бы связа но с определенными трудностями, поэтому эта возможность в SQL Server не реализована.

Предположим, что на компьютер с SQL Server 2000 был добавлен новый жест кий диск и на нем был создан дополнительный файл данных. Данные таблиц были приписаны к конкретным файлам. Чтобы разрешить сохранение данных в новом файле, следует изменить свойства всех таблиц, данные из которых жела тельно хранить в новом файле. Если количество таблиц невелико, то такой под ход вполне допустим. Если же таблиц в базе данных несколько сотен, то изме нение места хранения данных может занять довольно много времени.

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

Планирование групп файлов напрямую связано с планированием файлов. Груп пы файлов, создаваемые в базе данных, обычно разделяются по их назначению.

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

Например, если в одной группе расположить сами данные и их индексы, то при внесении изменений в данные необходимо обновить как данные, так и их ин дексы. При этом длительность процесса изменения увеличивается. Конечно, если обновляется всего несколько строк, то ничего страшного в этом нет, но если необходимо обновить несколько сотен тысяч записей, то потери времени становятся весьма заметными.

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

( Замечание ^ Итак, группы файлов можно использовать для облегчения управления местом хра нения данных или для повышения производительности операций дискового вво да/вывода. Можно решать только одну из этих задач или обе вместе.

884 Часть IV. Разработка и сопровождение баз данных Возможность автоматического роста файлов Количество информации в базах данных имеет тенденцию со временем увели чиваться. При работе с SQL Server 6.x администратор должен был постоянно следить за размером баз данных. Если свободное пространство в базе данных кончалось, то администратор должен был вручную увеличивать размер базы данных за счет устройств, сконфигурированных на сервере. Если свободное пространство на устройствах заканчивалось, то необходимо было предваритель но увеличить размер устройств. Как видим, увеличение размера базы данных было довольно хлопотным занятием.

Начиная с версии 7.0, в SQL Server реализована возможность автоматического увеличения размера базы данных. При создании базы для каждого ее файла (данных и журнала транзакций) необходимо указать первоначальный размер файла и шаг приращения. Шаг приращения можно указывать как в абсолютных единицах, так и в процентах от первоначального размера.

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

Администратор может очень гибко настраивать автоматический рост базы дан ных. Устанавливая индивидуальные параметры для каждого файла базы данных, можно оптимальным образом контролировать количество свободного простран ства на диске. Перед тем как выбрать первоначальный размер и шаг прироста файла, необходимо оценить, какое количество данных будет добавляться. Если данные практически не добавляются, то можно установить небольшой шаг при роста. Если же ожидается постоянное добавление большого количества данных, то лучше установить шаг прироста побольше. Увеличение размера файла зани мает довольно много времени и не стоит выполнять его слишком часто.

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

Предположим, что группа состоит из трех файлов. Группа была заполнена, и осуществляется автоматическое увеличение файлов. Сначала SQL Server увеличивает размер первого файла в группе. Когда добавленное пространство будет исчерпано, увеличится размер второго файла, затем — третьего. Когда и третий файл будет заполнен, то весь процесс повторится. Будет увеличен пер вый файл в группе, затем второй и т. д. Планируя шаг прироста каждого файла, следует учитывать эту особенность.

Поочередное, а не одновременное увеличение размера файлов группы позволяет более эффективно расходовать дисковое пространство. Если на одном диске рас Глава 20. Работа с базой данных положены несколько групп файлов, то одновременное увеличение всех файлов одной группы может лишить файлы других групп возможности расти. Вышеска занное относится только к файлам данных. Напомним, что для файлов журнала транзакций создание групп файлов не поддерживается. Однако файлы журнала транзакций также могут автоматически увеличиваться при полном их заполнении.

Использование неформатированных разделов До сих пор мы рассматривали файлы базы данных, физически реализованные как обычные файлы операционной системы. Однако помимо таких файлов в SQL Server 2000 можно использовать так называемые сырые разделы (raw partition), ко торые представляют собой логические диски, созданные утилитой конфигуриро вания диска (fdisk.exe для Windows 98, Disk Administrator для Windows NT 4.0 или Computer Management для Windows 2000), но не отформатированные. Таким обра зом, сырой раздел не имеет никакой файловой системы и на нем нельзя разме щать обычные файлы операционной системы. Чтобы использовать такой раздел в операционной системе, его необходимо предварительно отформатировать.

SQL Server 2000 может использовать сырой раздел в качестве одного из файлов операционной системы. При этом для файла отводится полностью все доступ ное пространство в разделе и для него нельзя конфигурировать автоматическое увеличение размера. Использование неформатированных разделов позволяет повысить безопасность информации, хранящейся в базе данных, т. к. доступ к неформатированному разделу не может быть получен стандартными средствами операционной системы, которая продолжает рассматривать раздел как неформа тированный, а следовательно не имеющий никаких данных. При работе с обыч ными файлами пользователь имеет возможность скопировать файлы на другой компьютер и присоединить (attach) их в качестве базы данных. Скопировать же сырой раздел не удастся, т. к. доступ к нему может быть получен только средст вами ядра SQL Server 2000. Однако это же является и недостатком. Администра тор не может выполнять резервное копирование базы данных путем копирова ния файлов базы данных.

Выбор сопоставления При работе с базами данных SQL Server 2000 администратор должен помимо всего прочего выбрать сопоставление (collation), которое будет использовать база данных. При работе с более ранними версиями SQL Server, в т. ч. и с SQL Server 7.0, сопоставление (точнее его аналоги) определялось на уровне сервера, и его действие распространялось на все аспекты работы сервера, в т. ч. базы данных, индексы, таблицы и их столбцы. Таким образом, не было возможности использовать различные сопоставления в пределах одного сервера.

( Замечание ^ Напомним, что сопоставление определяет правила хранения, сравнения и сорти ровки символьных данных. Подробно сопоставления рассматривались в главе 4.

886 Часть IV. Разработка и сопровождение баз данных В SQL Server 2000 такая возможность появилась. Теперь сопоставление, кон фигурируемое на уровне сервера, рассматривается как сопоставление по умол чанию, которое автоматически используется в тех случаях, когда при создании базы данных явно не указывается какое-либо сопоставление. Определяемое на уровне сервера сопоставление также применяется для всех баз данных, созда ваемых в процессе инсталляции SQL Server 2000 — системных баз данных, а также баз данных pubs и Northwind.

Сопоставление, указываемое на уровне базы данных при ее создании, использу ется для всех системных таблиц. Это напрямую отражается на правилах имено вания объектов базы данных и выборе имен пользователей. Например, при вы боре сопоставления, нечувствительного к регистру (case insensitive), сервер не будет делать различия между символами, набранными в верхнем и нижнем ре гистре. То есть имена AUTHORS и Authors будут считаться именем одного и того же объекта. Так же нельзя будет создавать в таблицах столбцы с одинако выми именами, но набранными в разных регистрах. Если же для базы данных существует сопоставление, чувствительное к регистру (case insensitive), то сервер будет проверять уникальность имен объектов с учетом регистра.

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

Установленное на уровне базы данных сопоставление не является обязательным для таблиц, создаваемых в базе данных, а также столбцов этих таблиц. Пользо ватель может при создании таблицы явно определить сопоставление, которое должно использоваться для этой таблицы. Более того, SQL Server 2000 позволяет указывать сопоставление и на уровне отдельного столбца таблицы.

С Замечание ) При определении локальных переменных, меток перехода (для команды GOTO), временных хранимых процедур и временных таблиц применяется сопоставление, определенное на уровне сервера. Это позволяет обеспечить однотипное поведение указанных объектов при переключении между различными базами данных. В про тивном случае нельзя гарантировать верного выполнения запросов. Например, если пользователь создает две переменные с одинаковыми именами, но набранными в разных регистрах, то необходимо гарантировать, что они будут различаться незави симо от того, в контексте какой базы данных будут использоваться.

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

CREATE TABLE tbll ( Coll nvarchar(lO) COLLATE Latinl_General_CI_AS, Col2 nvarchar(lO) COLLATE L a t i n l G e n e r a l C S A S Глава 20. Работа с базой данных С помощью данного кода организуется таблица t b i i, имеющая два столбца — c o l l и Со12. Первый из них имеет сопоставление, чувствительное к регистру, а второй — нет. Теперь вставим в таблицу новую строку:

INSERT INTO tbll VALUES (N'Aaa1, N'AAa') Как видно, для столбцов были выбраны значения, отличающиеся только реги стром второго символа. Однако даже такие небольшие различия приводят к конфликту сопоставлений. Убедимся в этом:

SELECT * FROM tbll WHERE Coll=Col В ответ будет выдано следующее сообщение об ошибке:

Server: Msg 446, Level 16, State 9, Line Cannot resolve collation conflict for equal tc operation.

Данное сообщение свидетельствует о наличии конфликта сопоставлений. То есть сервер не знает, по каким правилам должно выполняться сравнение значе ний. Разрешить конфликт достаточно легко. Для этого нужно явно указать, ка кое сопоставление, а соответственно и правила сравнения символов, должны использоваться при выполнении запроса. Для этого после выражения необхо димо указать ключевое слово COLLATE, после которого и приводится имя сопос тавления. Попробуем выполнить тот же запрос с указанием сопоставления, чув ствительного к регистру:

SELECT * FROM tbll WHERE Coll=Col2 COLLATE Latinl_General_CS_AS В ответ будет получен результат:

Coll CO Часть IV. Разработка и сопровождение баз данных ний. Список сопоставлений, имеющихся в SQL Server 2000, можно получить с помощью функции fnheipcoiiations, выполнив следующий запрос:

SELECT * F O R M ::fn_helpcollations() В ответ сервер возвратит более семисот строк, каждая из которых описывает отдельное сопоставление. Однако это довольно значительный объем. Сопостав ления можно систематизировать, что позволит легко различать их. Выведем только список сопоставлений, относящихся к кириллице:

SELECT name FROM ::fn_helpcollations() WHERE name LIKE 'Cyrillic%' Будет получен результат:

Cyrillic_General_BIN Cyrillic_General_CI_AI Cyrillic_General_CI_AI_WS Cyrillic_General_CI_AI_KS Cyrillic_General_CI_AI_KS_WS Cyrillic_General_CI_AS Cyrillic_General_CI_AS_WS Cyrillic_General_CI_AS_KS Cyrillic_General_CI_AS_KS_WS Cyrillic_General_CS_AI Cyrillic_General_CS_AI_WS Cyrillic_General_CS_AI_KS Cyrillic_General_CS_AI_KS_WS Cyrillic_General_CS_AS Cyrillic_General_CS_AS_WS Cyrillic_General_CS_AS_KS Cyr i11i c_Gene ra1_CS_AS_KS_WS (11 row(s) affected) В общем виде имя сопоставления представляет собой описание свойств, которое оно имеет. Типичным примером названия сопоставления является имя cyriiiicj3enerai_cs_AS. Первая часть имени описывает национальный набор символов, с которым работает сопоставление. В данном случае это кириллица.


Дополнительно может указываться подвид национальных символов (например, Danish_Norwegian_cs_Ai). Эта возможность используется для национальных алфавитов, имеющих несколько вариантов. Значение General соответствует наиболее распространенному варианту. В принципе, данный вариант может быть вообще единственным. Далее в имени представления следует набор сокра щений, описывающих конкретные свойства сопоставления в отношении срав нения символов. Первая буква сокращения означает контролируемое свойство, тогда как вторая — поведение сервера в отношении соответствующего свойства.

Рассмотрим, какое же значение имеет первая буква сопоставления:

• с — чувствительность к регистру;

• А — чувствительность к акценту;

Глава 20. Работа с базой данных О w — чувствительность к ширине символа. Определяет, будет ли сервер разли чать один и тот же символ, представленный одним (не Unicode) и двумя бай тами (Unicode);

• к — определяет, будет ли сервер делать различие между двумя наборами японских символов — Hiragana и Katakana.

С Замечание ^ На первый взгляд непонятно, какое отношение к кириллице имеют японские симво лы. Дело в том, что выражение может включать не только значения кириллицы, но и японские значения. При этом пользователь может явно указать, будут ли различать ся символы Hiragana и Katakana.

Теперь же рассмотрим назначение второго символа:

• s — сервер будет чувствителен к соответствующему свойству;

О i — сервер будет нечувствителен к соответствующему свойству.

( Замечание ^ Естественно, сервер может быть либо чувствителен к свойству, либо не чувствите лен. То есть одновременно в имени сопоставления не могут присутствовать значе ния CS И CI, AS И AI, W И WI, KS И KI.

S Помимо рассмотренных двухбуквенных сокращений, в именах сопоставлений также встречается значение BIN, ЧТО свидетельствует о том, что сравнение сим волов будет производиться на основе их порядкового номера в наборе символов (characters set), известного также как кодовая страница (code page). Такой тип сравнения символов известен как бинарная сортировка (binary sort order). Естест венно, для этого типа сортировок не допускается указание двухбуквенных со кращений.

( Замечание } Достоинством бинарной сортировки является высокая скорость сравнения симво лов, т. к. не требуется выполнять дополнительных операций работы с данными.

Иногда бывает полезно узнать, какой набор символов использует то или иное сопоставление или какому сопоставлению Windows соответствует то или иное сопоставление. Для получения этой информации используется функция COLLATIONPROPERTY, имеющая следующий синтаксис:

COLLATIONPROPERTY (collatlon_name, property) Первый параметр функции задает имя сопоставления, о котором необходимо получить информацию, тогда как второй параметр — собственно свойство. Па раметр property может принимать следующие значения:

О 'CodePage' — номер кодовой страницы данных не Unicode, соответствую щей указанному сопоставлению.

890 Часть IV. Разработка и сопровождение баз данных П 'LCID' — возвращает идентификационный номер локализации операционной системы (LCID, locale ID), соответствующей указанному сопоставлению. Ес ли указано сопоставление SQL Server, то будет возвращено значение NULL.

П 'Comparisonstyle' — возвращает, какой стиль сравнения Windows соответ ствует указанному сопоставлению.

В качестве примера рассмотрим получение информации о всех трех свойствах ДЛЯ сопоставления Cyrillic_General_CS_Ai:

SELECT COLLATIONPROPERTY('Cyrillic_General_CS_AI', 'CodePage') SELECT COLIATIONPROPERTY('Cyrillic_General_CS_AI', 'LCID') SELECT COLLATIONPROPERTY('Cyrillic_General_CS_AI', 'ComparisonStyle') Будет возвращен следующий результат:

(1 row(s) affected) (1 row(s) affected) (1 row(s) affected) Ранее в этом разделе был приведен список всех сопоставлений, соответствую щих кириллице. Однако довольно часто вместо кириллицы используется одно из сопоставлений Latinl_General. Хотя это сопоставление соответствует кодо вой странице 1252, однако оно с успехом может быть использовано и при рабо те с русским текстом. Выберем список всех сопоставлений Latinl_Generai:

SELECT name F O R M ::fn_helpcollations() WHERE name LIKE 'Latinl_General%'.

Будет возвращен результат:

Глава 20. Работа с базой данных Latinl_General_CS_AS_WS Latinl_General_CS_AS_KS Latlnl_General_CS_AS_KS_WS (17 row(s) affected) 892 Часть IV. Разработка и сопровождение баз данных но в ней имеется набор системных объектов, необходимых для функционирования базы данных. Например, в каждой базе данных существует набор системных таб лиц, которые содержат информацию обо всех объектах базы данных, а также о самой базе данных. Кроме того, в только что созданной базе данных образуются два представления, набор фиксированных ролей и пользователь dbo.

Однако в SQL Server 2000 имеется возможность создавать базы данных, содер жащие дополнительные объекты. Дело в том, что сервер не выполняет генери рования создаваемой базы данных с нуля, а использует в качестве шаблона базу данных Model. Она состоит всего из двух файлов — одного файла данных и од ного файла журнала транзакций. При создании новой базы данных сервер ко пирует эти файлы и присваивает им указанное имя. Если нужно, то размер фай лов изменяется, а также создаются дополнительные файлы.

( Замечание ") Описанный алгоритм создания базы данных используется всегда, независимо от то го, какой инструмент применялся для создания базы данных.

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

Изменяя размер файлов базы данных, можно управлять размером по умолча нию, который будут иметь файлы базы данных, а следовательно и сама база данных. Необходимо отметить, что для базы данных Model, как и для базы дан ных Master, не разрешается определять дополнительные файлы (данных или журнала транзакций). По умолчанию размер файла данных базы данных Model равен 768 Кбайт, а размер файла журнала транзакций — 512 Кбайт.

Использование Transact-SQL Создание базы данных средствами Transact-SQL предоставляет администратору максимальные возможности. Конечно, Enterprise Manager также предоставляет довольно широкие возможности по созданию баз данных, тем не менее, с по мощью этого инструмента нельзя выполнить присоединение базы данных как разновидность создания новой базы данных. Тем не менее, Enterprise Manager все же позволяет осуществлять присоединение базы данных. Выполнение при соединения и отсоединения базы данных будет рассмотрено далее в этой главе.

Для создания базы данных существует следующая команда Transact-SQL:

CREATE DATABASE database_name 4, [ON [ filespec [,...n]] [, filegroup [,...n]]] " • " " '''" [LOG ON { filespec [,...n ]}) [COLLATE-collation_name] [FOR LOAD I FOR ATTACH] Глава 20. Работа с базой данных С Замечание } Правом создания баз данных, точнее выполнением команды C R E A T E D A T A B A S E, ПО умолчанию обладают только члены фиксированных ролей сервера s y s a d m i n и d b c r e a t o r. Тем не менее, право создания базы данных может быть предоставлено не только включением учетной записи в одну из указанных ролей сервера, но и пу тем предоставления учетной записи права CREATE DATABASE. Отметим, что это право не выдается при выполнении для учетной записи команды GRANT ALL. Пре доставить учетной записи право CREATE DATABASE могут только члены фиксиро ванной роли сервера sysadmin или securityadmin. Подробно система безопас ности, а в частности и права, были рассмотрены в главе 9.

Рассмотрим назначение параметров команды:

П database_name Этот параметр определяет имя, которое будет присвоено базе данных. Имя базы данных указывается в формате Unicode и может быть длиной до 128 символов. Это единственный обязательный параметр команды CREATE DATABASE. Однако для создания базы данных необходимо определить имена файлов данных и журнала транзакций, из которых будет состоять база дан ных. Когда же команда CREATE DATABASE выполняется только с указанием параметра database_name, то сервер создаст один файл данных и один файл журнала транзакций. Генерирование имен этих файлов будет выполняться на основе имени базы данных, к которому будет добавлен суффикс Data для файла данных и суффикс Log для файла журнала транзакций. Так как длина имен файлов также ограничивается 128 символами, то длина имени базы данных в случае указания только параметра databasename (точнее, не указа ния имен файлов) ограничивается 123 символами.

П ON Присутствие этого ключевого слова свидетельствует о том, что далее следует определение файлов данных, а также групп файлов, из которых будет состо ять база данных. Если параметр ON опускается, то для базы данных будет соз дан единственный файл данных. По умолчанию размер этого файла равен 768 Кбайт (0,75 Мбайт). Однако этот размер может быть изменен путем вне сения соответствующих изменений в базу Данных Model.

П LOG ON После этого ключевого слова указывается набор файлов, из которых будет со стоять журнал транзакций базы данных. Если приводится более одного файла, то они должны быть разделены запятой. Как видно из синтаксиса, параметр LOG ON может не указываться. В этом случае журнал транзакций будет состоять из единственного файла, размер которого будет составлять 25% от общего объ ема всех файлов данных, но не менее 512 Кбайт, и иметь имя, генерируемое на основе имени базы данных, к которому добавляется суффикс Log.


QQ4 Часть IV. Разработка и сопровождение баз данных О COLLATE collation_name С помощью этого параметра указывается сопоставление, которое будет иметь база данных. Подробно выбор сопоставления был рассмотрено в разд. "Выбор сопоставления" ранее в этой главе. Если параметр опускается, то будет ис пользоваться сопоставление, определенное на уровне сервера при установке SQL Server 2000.

• FOR LOAD Этот параметр используется для совместимости с предыдущими версиями SQL Server (до SQL Server 7.0). Параметр FOR LOAD применялся для создания базы данных в состоянии, необходимом для восстановления резервной копии базы данных. При этом создание базы данных заканчивалось выделением для нее дискового пространства (в специальных устройствах) и внесением соот ветствующей записи в таблицу sysdatabases. Набор же объектов, пользова тели и т. д. создавались в результате восстановления резервной копии. Такой подход являлся следствием особенностей работы подсистемы резервного ко пирования, требующей предварительного создания каркаса базы данных. На чиная с SQL Server 7.0, база данных может быть создана непосредственно в ходе восстановления резервной копии (с помощью команды RESTORE DATABASE), поэтому использование параметра FOR LOAD не требуется. Тем не менее, база данных при указании параметра FOR LOAD переводится в состоя ние Loading и доступ к ней разрешается только владельцу базы данных (режим dbo use only).

• FOR ATTACH Параметр FOR ATTACH позволяет не создавать новой базы данных в полном смысле, а выполнить присоединение существующей базы данных. Подробно присоединение и отсоединение баз данных будут рассмотрены в следующих разделах этой главы. Сейчас же скажем, что применение параметра FOR ATTACH требует наличия файлов данных и журнала транзакций, полный путь к кото рым, а также их имя и необходимо указать. Результатом выполнения команды CREATE DATABASE с использованием параметра будет лишь создание в таблице sysdatabases новой строки со ссылкой на первичный файл присоединяемой базы данных. Собственно же создание файлов выполняться не будет.

В двух следующих разделах будет рассмотрено описание файлов базы данных, а также групп файлов.

Описание файлов В соответствии с названием в этом разделе рассмотрим, каким образом описы ваются файлы базы данных. Как уже было сказано, и файлы данных, и файлы журнала транзакций определяются одинаково — с помощью конструкции f i i e s p e o. Однако при описании файлов журнала транзакций не применяются параметры, связанные с группами файлов, т. к. для журнала транзакций группы файлов не поддерживаются. Напомним, что каждая база данных может иметь множество файлов данных и журнала транзакций.

Глава 20. Работа с базой данных Конструкция f i l e s p e o имеет следующий синтаксис:

f i l e s p e c : : = [ PRIMARY ] ( [NAME = l o g i c a l _ f i l e _ n a m e, ] FILENAME = ' o s _ f i l e _ n a m e ' [, SIZE = s i z e ] [, MAXSIZE = { m a x _ s i z e I UNLIMITED}] [, FILEGROWTH = g r o w t h _ i n c r e m e n t ] ) [,... n ] Рассмотрим назначение и использование приведенных параметров:

• PRIMARY С помощью данного параметра указывается файл, который будет первичным.

В первичном файле располагаются все системные объекты, а следовательно и описание структуры все базы данных. Напомним, что первичный файл сущест вует только для файлов данных, поэтому указание параметра PRIMARY при опи сании файлов журнала транзакций не разрешается. Наличие в группе файлов первичного файла определяет группу файлов как первичную. Только один файл может быть указан как первичный. Если параметр PRIMARY не указан ни для одного файла, то первичным файлом будет являться самый первый файл в списке, т. е. указанный непосредственно после ключевого слова ON.

П NAME = logical_file_name Посредством данного параметра указывается логическое имя файла базы дан ных. Именно с помощью этого имени пользователи будут ссылаться на опи сываемый файл базы данных. Логическое имя можно рассматривать как сво его рода псевдоним, позволяющий избавиться от физических имен, которые обычно довольно длинные. При выборе логического имени следует придер живаться стандартных правил именования объектов. При необходимости раз решается заключать имена в ограничители. Логическое имя файла должно быть уникальным в пределах базы данных.

• FILENAME = 'os_file_name' Этот параметр предназначен для определения физического имени файла. Если логическое имя используется при работе с файлом на уровне SQL Server 2000, то физическое имя предназначено для работы на уровне опера ционной системы и представляет собой совокупность собственно имени файла и полного пути к нему. Разрешается размещение файла в любом ката логе любого локального диска. Однако не допускается размещение файлов на сетевых ресурсах и сжатых (compressed) дисках. Если предполагается исполь зовать для создания файла сырой раздел, то нужно привести только букву соответствующего диска. При этом для файла не разрешается указание на чального (параметр S I Z E ) И максимального размера файла (параметр MAXSIZE), а также шага прироста (параметр FILEGROWTH).

896 Часть IV. Разработка и сопровождение баз данных граммных средств, таких как, например dblspace или drvspace (в операционной системе Windows 95/98).

( Замечание ) Напомним, что по умолчанию первичному файлу данных присваивается расширение mdf, вторичному — ndf, а файлам журнала транзакций — расширение Idf. Тем не менее, разрешается указание любых других расширений. Однако не стоит злоупот реблять этим, т. к. это может затруднить работу с файлами.

• SIZE = s i z e Данный параметр позволяет указывать размер, который будет иметь описы ваемый файл базы данных сразу же после создания. Если данный параметр опускается, то при создании вторичного файла (secondary file) данных он бу дет иметь размер 1 Мбайт. Для первичного файла данных по умолчанию ис пользуется тот же размер, который имеет первичный файл системной базы данных Model. Минимальный размер, который может иметь файл базы дан ных (как данных, так и журнала транзакций), составляет 512 Кбайт. Размер файла может задаваться как целое число. Тем не менее, допускается исполь зование различных суффиксов, означающих различную величину — кв для килобайт, мв для мегабайт, GB ДЛЯ гигабайт и тв для терабайт. Таким обра зом, вместо указания значения 0,5 мв необходимо указывать 512 кв. Если никакой суффикс не указан, то по умолчанию используется мв.

d MAXSIZE = { max_size I UNLIMITED } Если с помощью предыдущего параметра указывается первоначальный размер файла, то рассматриваемый параметр предназначен для определения макси мального размера, до которого будет разрешено автоматическое увеличение файла. Конечно, данная опция имеет смысл только в том случае, если вообще разрешено автоматическое увеличение размера файла. Если параметр MAXSIZE опускается, то файл будет увеличиваться до тех пор, пока не заполнит все дос тупное пространство на диске. К аналогичному результату приведет указание значения UNLIMITED. ДЛЯ указания максимального размера файла (параметр maxsize) используется тот же синтаксис, что и для параметра SIZE.

( Замечание ) Автоматическое увеличение размера файла не выполняется, если оценочный раз мер файла после увеличения будет превышать максимальный размер.

• FILEGROWTH = growth_increment Используя данный параметр, можно указать шаг приращения (growth incre ment), в соответствии с которым сервер будет автоматически увеличивать размер файла. Шаг приращения может быть задан либо как абсолютное, ли бо как относительное значение. Разрешается применение суффиксов кв, мв, GB, тв и %. Указание любого из первых четырех суффиксов рассматривается как указание абсолютного шага приращения, тогда как суффикса % — как Глава 20. Работа с базой данных относительное. Если шаг приращения приводится без суффикса, то автома тически используется суффикс мв. Шаг приращения может указываться толь ко как целое число. При конфигурировании относительного шага прираще ния следует учитывать, что собственно шаг приращения (в абсолютном выражении) вычисляется относительно первоначального размера файла (указанного с помощью параметра SIZE), а не относительно текущего разме ра файла, но округляется в ближайшую сторону до 64 Кбайт. Это же значе ние является минимальным при работе с абсолютным шагом приращения. При выборе шага приращения следует учитывать, что размер файла после первого увеличения размера не должен превышать значения, указанного с помощью параметра MAXSIZE. В противном случае размер файла не будет увеличен.

• [,...п ] Наличие в синтаксисе данного параметра говорит о том, что конструкция f i i e s p e o может представлять собой описание более одного файла. Если описывается более одного файла, то они должны разделяться запятой.

Мы полностью рассмотрели синтаксис конструкции f i i e s p e o. Теперь же приведем пример практического использования этой конструкции. Опишем три файла базы данных:

PRIMARY (NAME=PriDataFile, FILENAMESC:\SQL2000\primary', SIZE=100 MB), (NAME=SecFilel, FILENAMESC:\SQL2000\secl', SIZE=1OO MB, MAXSIZE=300, FILEGROWTH=25%) (NAME=SecFile2, FILENAME='C:\SQL2000\sec2', SIZE=3O MB, FILEGROWTH=5 MB) Как нетрудно заметить, в приведенном примере описывается набор файлов дан ных. То есть указанный текст должен быть помещен в команде CREATE DATABASE после ключевого слова ON. ПО аналогии с приведенным примером можно опи сать и файл журнала транзакций.

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

Итак, группы файлов описываются с помощью конструкции fiiegroup, имеющей синтаксис:

filegroup : : = FILEGROOP f i l e g r o u p _ n a m e f i l e s p e c [,...n ] Таким образом, группа файлов определяется путем указания ключевого слова FILEGROUP, после которого следует имя группы. Далее же указывается набор файлов, которые будут входить в соответствующую группу файлов. Как видно, 898 Часть IV. Разработка и сопровождение баз данных входящие в группу файлы описываются с помощью той же самой конструкции f i l e s p e o, которая была рассмотрена в предыдущем разделе.

В качестве примера включим созданные в конце предыдущего раздела файлы в группу файлов:

FILEGROUP PrimGroup PRIMARY (NAME=PriDataFile, FILENAME='C:\SQL2000\primary', SIZE=100 M B ), (NAME=SecFilel, FILENAME='C:\SQL2000\secl', SIZE=100 MB, MAXSIZE=300, FILEGROWTH=25%) (NAME=SecFile2, FILENAME='C:\SQL2000\sec2', SIZE=30 MB, FILEGROWTH=5 MB) Глава 20. Работа с базой данных 899_ Теперь же приведем пример, в котором будет создана база данных FirewailLog, состоящая их трех файлов данных и двух файлов журнала транзакций:

CREATE DATABASE FirewailLog ON PRIMARY =I (NAME=FirewallPrimary, FILENAME c:\Firewall\Firewalldatal.mdf, SIZE=120 MB, MAXSIZE=300, FILEGROWTH=15%), (NAME=FirewallSecl, FILENAME='c:\Firewall\Firewalldata2.ndf', SIZE=150 MB, FILEGROWTH=25 M B ), ( NAME=FirewallSec2, FILENAME^c:\Firewall\Firewalldata3.ndf', SIZE=150 MB, MAXSIZE=300, FILEGROWTH=25%) LOG ON (NAME=Firewalllogl, FILENAME='c:\Firewall\Firewalllogl.ldf', SIZE=10 MB, MAXSIZE=50 MB, FILEGROWTH=5), (NAME=Firewalllog2, FILENAME^1c:\Firewall\Firewalllog2.ldf, SIZE=10, MAXSIZE=50, FILEGROWTH=50%) В завершение представим еще один пример, демонстрирующий использование групп файлов. Будет создана база данных stdDB, включающая три группы фай лов, каждая из которых будет состоять из трех файлов. Журнал же транзакций будет состоять из двух файлов, размещенных на разных дисках:

CREATE DATABASE StdDB FILEGROUP PrimGroup PRIMARY (NAME=StdDB_prm, FILENAME='c:\SQL2000\DataBase\StdDB_Primary.mdf, SIZE=75, MAXSIZE=150, FILEGROWTH=15), (NAME=StdDB_secl, FILENAME='d:\SQL2000\DataBase\StdDB_Secondaryl.ndf', SIZE=20, MAXSIZE=50, FILEGROWTH=20%), (NAME=StdDB_sec2, FILENAME='d:\SQL2000\DataBase\StdDB_Secondary2.ndf', SIZE=20, MAXSIZE=50, FILEGROWTH=20%), FILEGROUP Groupl (NAME=StdDB_sec3, FILENAME='с:\SQL2000\DataBase\StdDB_Secondary3. ndf', SIZE=30, MAXSIZE=150, FILEGROWTH=20%), (NAME=StdDB_sec4, FILENAME='d:\SQL2000\DataBase\StdDB_Secondary4.ndf, SIZE=20, MAXSIZE=150, FILEGROWTH=20%), (NAME=StdDB_sec5, FILENAME='e:\SQL2000\DataBase\StdDB_Secondary5.ndf', SIZE=20, MAXSIZE=150, FILEGROWTH=20%), FILEGROUP Group (NAME=StdDB_sec6, FILENAME='с:\SQL2000\DataBase\StdDB_Secondary6.ndf•, SIZE=30, MAXSIZE=50, FILEGROWTH=25%), (NAME=StdDB_sec7, FILENAME='d:\SQL2000\DataBase\StdDB_Secondary7.ndf', SIZE=30, MAXSIZE=50, FILEGROWTH=25%), (NAME=StdDB_sec8, FILENAME='e:\SQL2000\DataBase\StdDB_Secondary8.ndf', SIZE=3O, MAXSIZE=50, FILEGROWTH=25%), Часть IV. Разработка и сопровождение баз данных LOG ON (NAME=StdDB_Logl, FILENAME^ с:\SQL2000\DBLog\StdDB_Logl.ldf', SIZE=25 MB, MAXSIZE=75 MB, FILEGROWTH=5 MB) (NAME=StdDB_Log2, FILENAME^d:\SQL2000\DBLog\StdDB_Log2.ldf, SIZE=25 MB, MAXSIZE=75 MB, FILEGROWTH=5 MB) Использование Enterprise Manager В предыдущих разделах было рассмотрено создание базы данных средствами Transact-SQL. Хотя описанный метод и не является чересчур сложным, все же для некоторых пользователей он может представлять затруднение. В этом случае создание базы данных можно осуществить средствами графического интерфейса Enterprise Manager. С помощью этого инструмента можно не только создавать базы данных, но и управлять ими, а также удалять их. В общем случае исполь зование Enterprise Manager по сравнению с непосредственным использованием команд Transact-SQL может заметно сократить время, необходимое на создание баз данных. Работа с Enterprise Manager не требует знания синтаксиса команды CREATE DATABASE, что является неоспоримым достоинством.

Рис. 20.1. Папка Databases Глава 20. Работа с базой данных Для управления базами данных SQL Server 2000 используется папка Databases (рис. 20.1), имеющаяся в каждой инсталляции. Непосредственно в этой папке перечисляется набор баз данных, созданных на сервере. Как видно из рисунка, в папке перечислены не только пользовательские базы данных, но и системные.

Однако если не предполагается работать с системными базами данных, а также с системными объектами пользовательских баз данных, и наличие их в панели Enterprise Manager только мешает работе, то можно запретить отображение этих объектов. Для этого достаточно открыть окно регистрации сервера Registered SQL Server Properties (рис. 20.2) и сбросить флажок Show system databases and system objects. Для открытия окна свойств сервера достаточно в контекстном меню сервера выбрать команду Edit SQL Server Registration Properties.

Рис. 20.2. Папка Registered SQL Server Properties Создание новой базы данных выполняется с помощью окна Database Properties (рис. 20.3). Открыть это окно можно разными способами:

• выбрав в контекстном меню папки Databases команду New Database;

• щелкнув правой кнопкой мыши на пустом пространстве правой части и вы брав в открывшемся контекстном меню команду New Database;

О нажав в панели инструментов Enterprise Manager кнопку New Database;

• выбрав в меню Action команду New Database.

Как видно, Enterprise Manager позволяет выполнить одно и то же действие раз личными способами. В дальнейшем, при описании создания объектов базы дан ных, мы не будем упоминать все доступные способы открытия окна для созда Часть IV. Разработка и сопровождение баз данных ния объекта. Однако в большинстве случаев в распоряжении пользователя будут все указанные способы вызова окон создания объектов.

Рис. 20.3. Окно Database Properties базы данных Chair Как видно из рисунка, окно Database Properties имеет три вкладки. Рассмотрим поочередно работу с каждой из них. Первая вкладка имеет имя General (см.

рис. 20.3) и предназначена для указания имени базы данных и сопоставления, которое будет использоваться для базы данных. Проводя аналогию с командой CREATE DATABASE, с помощью вкладки General устанавливаются значения для параметров datab§se_name И COLLATE collation_name.

Остальные элементы управления вкладки General предназначены для предостав ления пользователю различной информации о базе данных. На момент создания базы данных этой информации еще не существует, и поэтому указываются зна чения (Unknown) (неизвестно) и None (нет). Подробно назначение элементов группы Database и Backup будет рассмотрено позже в этой главе.

При выборе имени базы данных, которое должно быть введено в поле Name, следует придерживаться тех же правил, которые используются при непосредст венной работе с командой CREATE DATABASE. Сопоставление, которое будет иметь база данных, выбирается с помощью раскрывающегося списка Collation name. По умолчанию список содержит значение (Server default), что предписы Глава 20. Работа с базой данных вает применять для базы данных то же сопоставление, что было указано на уровне сервера при установке SQL Server 2000. Однако можно выбрать и любое другое сопоставление. Подробно выбор сопоставления был рассмотрен ранее в этой главе в разд. "Выбор сопоставления"., с Замечание Если открыть окно свойств созданной базы данных, то можно увидеть, что вместо раскрывающегося списка Collation name появится текстовое поле, в котором будет указано выбранное при создании базы данных сопоставление. Таким образом, из менить сопоставление после создания базы данных не удастся. Поэтому следует внимательно отнестись к его выбору.

Перейдем же к рассмотрению вкладки Data Files (рис. 20.4), предназначенной для определения файлов данных, из которых будет состоять создаваемая база данных.

Рис. 20.4. Окно Database Properties, вкладка Data Files В верхней части вкладки Data Files расположена таблица Database files, с помо щью которой собственно и определяются файлы базы данных. В столбце File Name указывается логическое имя файла, которое соответствует параметру NAME=logical_file_name, используемому при описании файлов в команде 904 Часть IV. Разработка и сопровождение баз данных CREATE DATABASE. В столбце же Location задается полный путь и имя файла опе рационной системы, что соответствует параметру FiLENAME='os_fiie_name'.

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

В столбце Initial size (MB) находится первоначальный размер, который файл будет иметь непосредственно после создания базы данных. Если отсутствует какой-либо суффикс, то подразумевается, что значение указано в мегабайтах. Однако разре шается и явное задание единиц размера файла — кв (килобайт), мв (мегабайт), GB (гигабайт) или тв (терабайт). С помощью столбца Filegroup можно определить группу файлов, к которой должен принадлежать файл. По умолчанию все файлы размещаются в группе файлов PRIMARY. Элемент столбца Filegroup представляет собой раскрывающийся список, содержащий перечень доступных групп файлов.

Тем не менее, помимо выбора существующего значения также разрешается ввод имени новой группы, которое автоматически вносится в список.

( Замечание ^ Первый файл, указанный в таблице Database files, всегда рассматривается как первичный файл (primary file). Поэтому он может быть размещен только в первичной группе файлов (PRIMARY). Указать в качестве первичного файла иной файл средст вами Enterprise Manager нельзя.



Pages:     | 1 |   ...   | 22 | 23 || 25 | 26 |   ...   | 33 |
 





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.