Реферат: СУБД INFORMIX - текст реферата. Скачать бесплатно.
Банк рефератов, курсовых и дипломных работ. Много и бесплатно. # | Правила оформления работ | Добавить в избранное
 
 
   
Меню Меню Меню Меню Меню
   
Napishem.com Napishem.com Napishem.com

Реферат

СУБД INFORMIX

Банк рефератов / Программирование

Рубрики  Рубрики реферат банка

закрыть
Категория: Реферат
Язык реферата: Русский
Дата добавления:   
 
Скачать
Архив Zip, 37 kb, скачать бесплатно
Заказать
Узнать стоимость написания уникального реферата

Узнайте стоимость написания уникальной работы

СУБД INFORMIX . Администрирование и безопасность Безопасность В сер верах баз данных фирмы INFORMIX можно ограничить или вовсе запретить польз ователям доступ к данным . Доступ можно огр аничить на следующих четырех уровнях : 1. В случае , если БД хранится в фа йлах операционной системы , ограничением доступа можно управлять с по мощью средств ОС . Однако этот уровень недоступен при исп ользовании сервера INFORMIX-OnLine. Это ядро само управля ет собственным дисковым пространством и прави ла операционной системы здесь не применимы. 2. Можно использовать операторы GRANT и REVOKE, что бы предоставить или запретить доступ к БД или отдельным таблицам , а также ра зрешать или запрещать проводить пользователями отдельных операций над БД. 3. Можно использовать оператор CREATE VIEW для соз дания ограничивающего или обновляемого представл ения . Огран ичения могут быть горизонтальн ыми (исключающие некоторые строки ) или вертика льными (исключающие некоторые столбцы ) или одн овременно вертикальными и горизонтальными. 4. Допускается использование оператора GRANT совм естно с оператором CREATE VIEW для достиже ния более полного контроля над частями таблицы и данными , которые пользователь может измен ять. Безопасность на уровне файлов Ядра баз данных INFORMIX (за исклю чением INFORMIX-OnLine) хранят базы данных в файлах оп ерационной системы . Файлы собраны в каталог е , который представляет базу данных в целом . Можно запретить доступ к базе данных , запретив доступ к каталогу базы да нных средствами операционной системы. Предоставление привилегий Разрешение на использование ба зы данных называется привилегией . Например , р азрешение на использование базы данных вообще называется привилегией CONNECT, тогда как разрешение на добавление строк в таблицу называется привилегией INSERT. Можно управлять доступо м к базе данных , предоставляя привилегии п ользователям или отменяя их. Пр ивилегии делятся на две группы : одна группа привилегий касается базы дан ных в целом , другая – отдельных таблиц. Привилегии базы данных Три уровня привилегии базы данных обеспечивают общие средства управления тем , кто имеет доступ к базе данных. Привилегия CONNECT Привилегией самого нижнего уро вня является привилегия CONNECT, которая предоставляет пользователю базовые возможности запрашивать и обновлять таблицы . Пользователь с этой привилегией может производить такие операции : Выполнять операторы SELECT, INS ERT, UPDATE и DELETE при наличии необходимых привилегий уровня таблицы ; Создавать представления при условии , что ему разрешено запрашивать таблицы , на кот орых основаны представления ; Создавать временные таблицы и индексы на них . Для этого пользователь долж ен обладать привилегией CONNECT. Обычно , если БД не содержит конфиденциальной информации , сразу после создания базы данных выполняется опе рация GRANT CONNECT TO PUBLIC. Привилегия RESOURCE Данная привилегия предоставляет те же возможности , что и привилегия CONNECT, кроме того , пользователь с привилегией RESOURCE может выполнять следующие операции : Изменять определения существующих таблиц путем удаления или добавления определенных ст олбцов , индексов ; Создавать новые постоянные таблицы и индексы к ним. Привил егия администратора баз данных На высшем уровне их трех уровней привилегий базы данных находятся п ривилегии администратора базы данных (АБД ). Соз датель базы данных автоматически становится е е администратором . Пользователь этого уровня доступа может осущест влять следующее : Вставлять , удалять или изменять строки в любой из таблиц системного каталога за исключением systables; Удалять или изменять любой объект нез ависимо от того , кому он принадлежит ; Создавать , таблицы , индексы и представлени я , которые будут пр инадлежать другим п ользователям ; Предоставлять привилегии базы данных , вкл ючая привилегию АБД. Привилегии пользователей и др угие общедоступные привилегии Привилегии предоставляются отдельн ым пользователям по их именам , или всем пользователям – под именем P UBLIC. Все привилегии , предоставленные под именем PUBLIC, действую т как привилегии по умолчанию . Прежде , чем выполнить оператор , ядро базы данных опре деляет , располагает ли пользователь необходимыми привилегиями . Сначала ядро ищет привилегии , предоставлен н ые именно данному пол ьзователю . Если необходимые привилегии обнаружены , то они предоставляются данному пользователю . Если же пользователю такие привилегии не предоставлены , то сервер ищет их среди общедоступных . Если такие найдены , то ядро использует их . Т аким образом , мо жно установить минимальный уровень привилегий для пользователей , предоставив привилегии PUBLIC. В конкретных случаях эти привилегии могут быть перекрыты путем предоставления пользователю более сильных привилегий. Если привилегия CONNECT не делается общед оступной , то доступ к базе данных смогут получить только те пользователи , которые имеют этот уровень привилегий . Права владения База данных , так же , как и каждая таблица , представление или индекс и синоним этой базы имеет своего вла дельца . О бычно владельцем БД является тот , кто его создал , хотя администратор ба зы данных может создавать объекты , которые становятся принадлежащими другим пользователям . Владелец объекта имеет на него все пра ва и может изменить или удалить объект без каких-то доп о лнительных привиле гий . Привилегии нужны только для пользователе й , которые не являются владельцами объекта. Привилегии уровня таблицы Существует шесть привилегий ур овня таблицы , позволяющих передать пользователям , не являющихся владельцами таблицы , привилег ии владельца . Четыре из них – SELECT, INSERT, UPDATE и DELETE – управляют доступом к содержимому таблицы . Привилегия INDEX управляет созданием инд екса . Привилегия ALTER определяет возможность изменять определение таблицы . В ANSI-совместимых базах данных п р ивилегии на таблицу с разу после ее создания имеет только владе лец . В других базах данных ядро в проц ессе создания таблицы автоматически делает вс е табличные привилегии , за исключением привил егии ALTER, общедоступными . Это означает , что тольк о что созданна я таблица может б ыть доступна пользователю , который имеет прив илегию CONNECT. Если это нежелательно , то после создания таблицы ее владелец должен отменить все привилегии , предоставленные PUBLIC в связи с этой таблицей. Привилегия доступа Четыре привилегии у правляю т тем , как пользователь может обращаться к таблице . Владелец таблицы может предоставлят ь или не предоставлять , независимо одна от другой , следующие привилегии : Привилегия SELECT позволяет делать выборку , в том числе во временные таблицы ; Привилегия INSERT позволяет добавлять в таблицу новые строки ; Привилегия UPDATE позволяет изменять существующие строки ; Привилегия DELETE позволяет удалять строки. Привилегия SELECT необходима для выборки содер жимого таблицы , однако эта привилегия не я вляется необход имой для обладания другими привилегиями . Пользователь может иметь приви легии INSERT или UPDATE, не имея при этом привилегии SELECT. Привилегии INDEX и ALTER Привилегия INDEX позволяет создавать и изменять индексы в таблицах . Эта прив илегия , так же , как и п ривилегии SELECT, INSERT, UPDATE, DELETE, становится общедоступной после создания таблицы . Можно предоставить привилегию INDEX всем пользователям , но смогут пользоваться ею толь ко те пользователи , кто имеет привилегию RESOURCE уровня базы данных . Таким об р аз ом , хотя привилегия INDEX предоставляется автоматическ и (кроме ANSI-совместиых баз данных ), пользователи , обладающие только привилегией уровня базы данных CONNECT не смогут воспользоваться привилегией INDEX. Это имеет смысл , когда индексные файлы занима ю т много места на диск е. Привилегия ALTER позволяет пользователю использов ать оператор ALTER TABLE, включая возможность добавлять и удалять столбцы и т.д . Следует предост авлять данную привилегия только тем пользоват елям , которые хорошо понимают модель базы данных и достаточно квалифицированы , чтоб ы использовать эту привилегию очень аккуратно . Привилегии уровня столбца Можно детализировать привилегии SELECT и UPDATE именами определенных столбцов . Это по зволит более тонко разграничить доступ пользо вателей к та блице : можно позволять пол ьзователю видеть или обновлять только определ енные столбцы. Например : CREATE TABLE emp_data ( emp_num integer, emp_name char(20), hired date, id-code char (10), salary decimal(4,2) ) Поскольку таблица содержит конфиденциальные да нные , то сразу после ее создани я следует выполнить оператор REVOKE , который запрещает доступ к данным : REVOKE ALL ON emp_data FROM PUBLIC Для отдельных сотрудников отде ла кадров и менеджеров выполняется оператор типа : GRANT SELECT ON emp_data TO andrew_p, michael_d Таким образом , некоторым пользо вателям позволено видеть все столбцы. В общих чертах синтаксическая запись правил безопасности доступа к данным выглядит следующим образом : GRANT список _привилегий _через _запятую [( список _атри бутов через _запятую ) ] ON выражение TO список _пользователей _через _запятую Для менеджеров , которые должны вводить некоторые сведения о служащих , необходимо выполнить оператор типа : GRANT SELECT, UPDATE , INSERT, DELETE (salary, hired) ON emp_data TO alex_v, nataly_d Этот оператор позволяет получить доступ к данным о зарплате и дате приема на роботу служащих . Для нек оторых пользователей из отдела кадров , которы е должны составлять технические данные о сотрудниках , нужно выполнить оператор типа : GRANT SELECT, UPDATE , INSERT, DELETE ( emp_num,emp_name,id-code) ON emp_data TO nataly_d Привилегии в системном катало ге Привилегии регистрируются в та блицах системного каталога . Каждый пользователь , обладающий привилегией CONNECT, может запросить инфо рмацию из таблиц системного каталога , чтобы определить , какие и кому предоставлены привилегии. Привилегии базы данных регистрируется в таблице sysusers, в который первичным ключом яв ляется идентификатор пользователя , а в другом столбце находится символ C ( CONNECT ) , R ( RESOURCE ) или D ( DBA ) , обознач ающий уровень привилегий . Об щедоступные привилегии отображены под именем пользователя public (в нижнем регистре ). Привилегии уровня таблицы находятся в таблице systabauth, в которой используется составной первичный ключ , включающий номер таблицы , ид ентифик атор пользователя , предоставившего при вилегии на таблицу и идентификатор пользовате ля , получившего их . В столбце tabauth привилегии закодированы в виде шестибуквенного списка с ледующим образом (дефис обозначает не предост авленную привилегию ): s – SELECT u – UPDATE - – * привилегия на столбцы i – INSERT d – DELETE x – INDEX a – ALTER r – REFERENCES (обращение к заданной таблице в ограничениях целостности ) Таким образом , полный комплект привилегий выглядит как su-idxar. Например , набор -u------ говорит , что польз ователь обладает только привилегией UPDATE. Если в третьей позиции присутствует з вездочка , то это означает , что для данной таблицы и пользователя существуют еще ка кие-то привилегии уровня столбца . Конкретные п ривилегии регистрируются в таблице sysco lauth. Ее первичный ключ составлен из номера табли цы , идентификатора пользователя , предоставившего п ривилегии , получившего привилегии , и номера ст олбца . Единственный атрибут – двухбуквенный список , показывающий тип привилегии : s-, -u или su. Привилегии и представления При создании представления ядр о БД проверяет привилегии пользователя на соответствующие таблицы и представления . При использовании же представлений проверяются тол ько привилегии на само представление. Привилегии при создании предс тавления При создании представления ядро БД проверяет наличие у пользователя всех привилегий , необходимых для выполнения оператора SELECT в определении представления . Если таких привилегий нет , представление не созд ается . Эта проверка не позволяет пользователю получи т ь несанкционированный доступ к таблице путем создания представления д ля нее и обращения к представлению . После создания представления ядро БД предоставляет его создателю и владельцу , как минимум , привилегию SELECT для этого представления . Оно н е становитс я автоматически общедоступны м , как это происходит с таблицей . Ядро БД определяет определение представления и выя сняет , является ли оно обновляемым . Если д а , то создатель представления получает привил егии INSERT, DELETE и UPDATE для этого представления при н аличии этих привилегий на порожд ающей таблице или представлении . Иными словам и , если создаваемое представление является об новляемым , то ядро БД копирует привилегии INSERT, DELETE и UPDATE создателя представления и предоставляет их ему на новом представлен и и . Если для порождающей таблицы создатель представления располагает только привилегией INSERT, т о он получит на представление только эту привилегию и т.д . Эта проверка не позв оляет пользователям получить какие-либо привилеги и кроме тех , которые у него уже есть. Поскольку для представления нельзя выполн ять операторы ALTER TABLE и CREATE INDEX, привилегии ALTER и INDEX никогд а не распространяются на представления. Привилегии при использовании представления При попытке использовать предс тавление , ядро БД прове ряет лишь те привилегии , которые относятся лишь к самому представлению . Оно не проверяет права на доступ к определяющим его таблицам . Приви легии создателя представления уже отмечались ранее . Для других пользователей привилегии оп ределяются создателем или т ем , у кого есть привилегия WITH GRANT OPTION. Это означает , что можно создать таблицу и отменить ее общедоступность . Затем можно предоставить огранич енные привилегии на доступ к таблице чере з представления . Ниже приводится синтаксис опер атора GRANT : GRANT список _привилегий _через _запятую ON объект TO список _пользователей _через _запятую [ WITH GRANT OPTION ] Директива WITH GRANT OPTION наделяет указанных пользователей о собыми полномочиями – правом предоставления полномочий другим пользователям . Это означает , чт о для работы с данным объектом они могут наделять полномочиями других пользо вателей. Работу с представлениями можно продемонстрировать на примерах с таблицей emp_data: CREATE TABLE emp_data ( emp_num integer, emp_name char(20), hired date, id-code char (1 0), salary decimal(4,2) ) Пусть после создания таблицы был выпо лнен следующий оператор : REVOKE ALL ON emp_data FROM PUBLIC Теперь создадим несколько пред ставлений для разных категорий пользователей . Для тех , кто может иметь доступ по чт ению из неконфиденци альных столбцов , созд адим такое представление : CREATE VIEW emp_data AS SELECT emp_num, emp_name FROM emp_data Пользователи , получившие привилеги ю SELECT для данного представления , могут видеть некоторые данные без возможности обновления . Для работников от дела кадров создадим следующее представление : CREATE VIEW enter_data AS SELECT emp_num,emp_name,id-code,salary FROM emp_data Этим пользователям необходимо предоставить привилегии INSERT и UPDATE для этого предс тавления . Так как создатель таблицы и пред ста вления имеет привилегии на вставку как для таблицы так и для представлени я , можно предоставить привилегии INSERT и UPDATE на представле ние даже тем пользователям , у которых нет такой привилегии : GRANT SELECT, INSERT, UPDATE ON enter_data TO olga_s, helena_ m Для некоторых пользователей , ко торые могут вводить или изменять некоторые данные о сотрудниках , создадим еще одно представление : CREATE VIEW enter_upd AS SELECT emp_num,emp_name,id-code FROM emp_data Это представление отличается о т предыдущего тем , что в последнем н е показываются данные о зарплате сотрудников . Наконец , пусть менеджерам необходим доступ по чтению и редактированию всех данных о работниках фирмы : CREATE VIEW all_data AS SELECT * FROM emp_data Теперь можно дать менеджерам все привилегии : GR ANT SELECT, UPDATE , INSERT, DELETE ON emp_data TO alex_v Администрирование сервера INFORMIX-OnLine Внедрение в информационную сис тему сервера INFORMIX-OnLine Dynamic Server требует решения множества вопросов , которые влияют на производительность системы в целом . Необходимо решить вопросы , где будут храниться данные , как к ним будет осуществляться доступ , как защи тить данные . OnLine Server позволяет настроить систему н а оптимальную производительность . Для этого н еобходимо понимать архитектуру сервера и тр е бований , возникающих во время экс плуатации сервера. Организация хранения данных Сервер INFORMIX-OnLine может хранить данны е на диске двумя способами . Первый способ – это хранение данных в файловой си стеме ОС . Второй способ – хранение данных на “сыром” диск овом пространстве . В последнем случае сервер INFORMIX-OnLine сам управляет вводом-выводом данных . Единицы хранения данных Сервер INFORMIX-OnLine использует следующие физические единицы хранения информации : chunk, page, blobpage, extent . Логические единицы хранения данных связаны с управлением БД . К логическим еди ницам относятся : dbspace, blobspace, database, table, tblspace . В дополнение к этому существуют следу ющие единицы хранения информации о физической и логической целостности данных : logical log , phys ical log , reserved pages . Фрагмент диска chunk – это максимальная физическая единица хранения информации сервером INFORMIX-OnLine. Фрагмент может быть файлом операционной системы или специальным символьным устройств ом системы . В первом случае данные размещ аются в обычном файле и записью н а диск управляет ОС . В этом случае INFORMIX-OnLine не гарантирует , что записанные данные реа льно попадут на диск , так как данные м огут быть помещены в дисковую кэш-память О С . Во втором случае сервер гарантирует , чт о те дан н ые , которые должны по пасть на диск , будут записаны . Кроме этого , заметно выше производительность системы вво да-вывода . Однако не каждая операционная систе ма позволяет организовать chunk на “сыром” диске . INFORMIX-OnLine поддерживает размер chunk до 2 GB. М акс имальное количество chunk ’ ов – 2048. Страница page – это единица информации , которой сервер INFORMIX-OnLine обменивается с устройством хранения данных для доступа к БД . Разме р страницы варьируется . Обычно это 2 или 4 КБ . Фрагмент диска содержит определе нное количество страниц . Страница не может выход ить за пределы chunk ’ а . Blobpage – единица дискового пространства , ко торой INFORMIX-OnLine манипулирует для хранения данных ти па BYTE и TEXT. Размер blobpage задается администратором и может варьироваться. К огда создается таблица , INFORMIX-OnLine выделяет фиксированное число страниц для хранения данных . Когда выделенное пространство исчерпыва ется , сервер выделяет дополнительное место . Фи зическая единица данных , которая используется для этих целей , называется extent . При создании таблицы задаются initial extent siz e и next extent size . Первый – первоначальный объем под таблицу (в килобай тах ). Второй – величина прироста объема т аблицы в килобайтах. Extent всегда хранится в пределах одного chunk ’ а и не может пере крывать его границы . В случае , когда INFORMIX-OnLine не может выде лить достаточно пространства в текущем фрагме нте , он ищет его в другом фрагменте. Базовой логической единицей хранения инфо рмации сервером INFORMIX-OnLine является пр остранство БД (dbspace). Пространств о БД отображает физическое пространство на логическое пространство хранения данных . Обычно одному dbspace соответствует один chunk, хотя одному dbspace может соответствовать несколько фрагментов. Зеркалирование Зеркалирование позволяет резервир овать фрагмент диска точно такого же размера фрагментом . Запись в первичный chunk порождает запись в резервный chunk. В случае с боя первичного фрагмента сервер INFORMIX-OnLine переключаетс я на резервный автоматически , при этом раб ота пользователя не преры в ается. Технология резервирования позволяет админист ратору восстанавливать данные в первичном фра гменте параллельно с работой пользователя с вторичным фрагментом. За возможность зеркалирования придется пл атить дополнительным дисковым пространством. В случае , когда незеркалированный chunk выходит из строя , INFORMIX-OnLine не может добраться к данным из него и будет возвращать ош ибку при обращении к этому фрагменту . Если из строя вышел незеркалированный фрагмент , который хранит logical log, physical log или r o ot dbspace, серве р немедленно переходит в режим off-line, т.е . прек ращает работу. Сервер делает запись в оба фрагмента параллельно и читает из обоих разные части (split read) для минимизации времени ввода-вывода. Когда создается зеркалированный chunk, INFO RMIX-OnLine копирует данные из первичного во вторичный . Такой процесс называется в осстановлением (recovery). Зеркалирование нач инает работать сразу после завершения процесс а восстановления. Физический и логический прото колы работы Физический протокол (physical log) Ведение физического протокола есть процесс сохранения страниц , который INFORMIX-OnLine собирается менять , но до того , как будут внесены реальные изменения в страницы . Друг ими словами , сервер перед модификацией страни ц в памяти сбрасывает и х копии в буфер физического протокола в памяти. Физический протокол – это множество последовательных стра ниц , где INFORMIX-OnLine сохраняет неизмененные страницы ( before-image ). Это нужн о для быстрого восстановления после “падения” сервера. Сервер манипули рует before-image в буфере ф изического протокола до тех пор , пока один из очистителей страниц не запишет ее на диск. Не попадают в протокол blob-страницы из blopspace, т.к . в противном случае может произойти переполнение физического протокола. Во время ини циализации сервер раз мещает файлы логического и физического проток олов в корневом пространстве БД root dbspace. Из-за критичности физического протокола для работы INFORMIX-OnLine рекомендуется зеркалировать dbspace, в котором хран ится этот протокол. Сервер выполняет физический протокол за шесть шагов : Читает страницы данных в буфер. Копирует неизмененные страницы в буфер физического протокола. Отображает изменения в буфере страницы после того , как приложение измен яет данные. Сохраняет буфер физического пр от окола собственно в физическом протоколе на диске. Сохраняет буфер страницы на диске. При срабатывании контрольной т очки (checkpoint) сбрасывает буфер физического протокола на диск и затем очищает физический про токол. Логический протокол (logical log) Серв ер INFORMIX-OnLine хранит историю изменений в БД и сервере с момента генерации последнего архива и сохранения з аписей протокола . Сервер сохраняет записи про токола в логическом протоколе , из которого создаются файлы логического протокола . Этот протокол наз ы вается логическим по той причине , что в нем сохраняются ед иницы работы , связанные с логическими операци ями работы сервера БД в противоположность физическим операциям сервера. Все БД , управляемые одним сервером INFORMIX-OnLine, сохраняют свой протокол в одн ом и том же логическом протоколе сервера. Файлы логического протокола не являются файлами операционной системы . Это часть д искового пространства , управляемого INFORMIX-OnLine. Каждый фа йл логического протокола – это отдельное пространство на диске. При дан ной активности системы , чем меньше будет отдано под файл логического протокола , тем быстрее это место будет заполнено , и больше вероятность того , что активность пользователя будет заблокирована во время архивирования логического протокола и срабатывания к о нтрольной точки. Архивирование файла логическог о протокола Когда файл логического протоко ла заполнен , необходимо его заархивировать . Пр оцесс архивирования может “заморозить” процесс обработки транзакций , которые работают с да нными из того же диска , что и фа йл логического протокола . Поэтому рекомендуется выбирать время малой активности пользователей для архивирования файла протокола. Контрольные точки Как минимум одна контрольная точка должна быть записана в логический протокол . Если необходимо освободить файл , содержащий последнюю контрольную точку , то нужно записать новую контрольную точку в текущий файл логического протокола . Соответстве нно , чем чаще архивируется файл логического протокола и чем чаще он освобождается , тем чаще случаются контрольные точк и . Т.к . контрольная точка блокирует работу пользователей , то это отрицательно сказывает ся на производительности. Общий размер логического протокола есть произведение количества файлов протокола на их размер : Минимальный размер файла логического прот окола – 200 KB. Максимальный размер не ограничен , но с ледует иметь ввиду , что если архивация про исходит на медленный стример , то лучше дел ать размер файла небольшим. Чем меньше размер файла , тем меньше информации может быть потеряно , т.к . есть вероятность потерять последний не сохран енный файл логического протокола при выходе диска из строя. Всегда необходимо иметь минимум 3 файла логического протокола. Необходимо всегда иметь достаточное колич ество файлов логического протокола для того , чтобы всегда иметь возможно сть перек лючиться на новый файл и не допустить переполнения этих файлов. При инициализации дискового пространства INFORMIX-OnLine размещает файлы логического прокола в ко рневом пространстве БД (root dbspace). Файлы логического протокола содержат критически важную информ ацию и должны быть зазеркалированы для об еспечения максимальной надежности данных. Каждый файл имеет свой уникальный иде нтификатор . Последовательность номеров начинается с 1 для первого файла логического протокола , заполненного после инициали зации дисков ого пространства . При заполнении текущего фай ла сервер переключается на следующий и пр исваивает ему номер на 1 больше , чем предыд ущий. Актуальное дисковое пространство , выделенное для каждого файла логического протокола , имеет идентификационный номер logid. Например , ес ли вы сконфигурировали 6 логического протокола , то эти файлы имеют номера от 1 до 6. П осле того , как эти файлы заархивированы и освобождены , INFORMIX-OnLine повторно использует дисковое пространство для файлов логического протоко л а , однако сервер будет нумеровать уникальным идентификатором , которой равен пр едыдущему плюс единица. Файлы логического протокола им еют один из следующих статусов : Added (A) Файл прот окола имеет статус добавленный , когда этот файл только ч то добавлен . Он н е будет доступен для использования до тех пор , пока не будет создан архив нулевого уровня корневого пространства БД. Free (F) Файл логи ческого протокола свободен , когда он доступен для использо вания . Этот файл был освобожден после архи вирования , все транза кции внутри файла протокола были завершены и последняя запис ь контрольной точки находится в следующем по порядку протоколе. Used (U) Файл логи ческого протокола задействован , когда он нужен серверу для восстановления (откат транзакций или поиск последней за писи контрольной точки ). Backed-up (B) Файл про токола имеет статус заархивиров ан после того , как этот ф айл был в самом деле заархивирован. Current (C) Файл прот окола имеет статус текущий , когда сервер заполняет его протоколом. Last (L) Файл имее т статус по следний , когда он содержит самую последнюю запись контрольной точки . Этот файл не может быть освобожден до тех пор , пока сервер не запишет новую контрольную точк у в другой файл логического протокола. Если INFORMIX-OnLine пытается переключиться на следую щий по порядку файл логического протоко ла , который еще не освобожден , то вся р абота приостанавливается . Это происходит даже в том случае , когда один из файлов про токола свободен . Сервер не может использовать произвольный по номеру файл . Работа остан авливаетс я для защиты данных в файле протокола . Файл логического протокола м ожет быть занят по следующим причинам : Файл логического протокола не заархивиров ан. Файл содержит открытую транзакцию. Длинная транзакция – это такая транз акция , которая начинается в одном ф айл е логического протокола и не фиксируется , когда INFORMIX-OnLine нуждается в повторном использовании того же файла протокола . Т.е . длинная тра нзакция перекрывает больше пространства , чем выделено всего под логический протокол. Т.к . сервер не может освобо дить файл логического протокола до тех пор , пока все записи не будут ассоциированы с закрытыми транзакциями , длинная транзакция м ешает освободить первый файл протокола и делает его недоступным для использования. Для предотвращения такой ситуации нужно учес ть следующее : Проверить , не заполняется ли файл логи ческого протокола слишком быстро. Проверить , не остается ли транзакция с лишком долго открытой. Установить границу , по достижении которой INFORMIX-OnLine автоматически свернет обработку длинной транзакции. Архивирование данных Система восстановления INFORMIX-OnLine позволя ет архивировать данные и восстанавливать их в случае порчи. Устройство системы восстановлени я данных Архив – это копия всех или части данных , которыми управляет сервер , т.е . это копия одн ого или более dbspace и любых вспомогательных данных , которые м огут понадобиться для восстановления. Архив логического протокола – это ко пия файлов логического протокола на диске или ленте , которые заполнены и готовы к архивированию . Восстановление – это процесс восст ановления данных INFORMIX-OnLine, в частности , пространств БД из архива и архивированных файлов л огического протокола. Физическое и логическое восст ановление Восстановление данных необходимо производить в два этапа . Первый этап – физическое во сстановление , второй – логическое восстановление . Физическое восстановлен ие – процесс восстановления страниц простран ств БД из архива . Логическое восстановление использует архивированный логический протокол для “наката” транзакций в восстановленных про стр а нствах БД. Система восстановления INFORMIX-OnLine INFORMIX-OnLine предоставляет две системы восстановления данных : ON-Archive и ontype . Они позволяют сделать следующее : Архивировать данные INFORMIX-OnLine; Архивировать файлы логического протокола ; Делать д обавочное архивирование файло в логического протокола ; Восстанавливать данные из архива ; В дополнение к этому On-Archive позволяет следующее : Планирование и отслеживание архивов ; Множество средств защиты и доступа к On-Archive ; Возможность параллельно работ ать с несколькими ленточными устройствами ; Работать без непосредственного участия че ловека. Сохранение страниц и логическ ого протокола в архиве Все , чем управляет INFORMIX-OnLine может быть заархивировано за исключением следующего : Страницы dbspace, выделе нные для сервера , но не привязанные к какому-либо фрагменту tblspace; Конфигурационные файлы не архивируются ; Страницы из зеркальных фрагментов не архивируются , если доступен первичный фрагмент ; Blob ’ ы в blobspace, хранимые на оптическом но сителе ; Уровни а рхива Нет смысла каждый раз архи вировать все данные INFORMIX-OnLine. Поддерживаются три т ипа добавочного архивирования : Level-0 – архивируются все страницы ; Level-1 – архивируются все изменения с м омента последнего архива нулевого уровня ; Level-2 – архивир уются все изменения с момента последнего архива первого уровня. Архивирование логического проток ола Если было инициировано протоко лирование БД , то INFORMIX-OnLine записывает транзакции , пр оизошедшие между процедурами архивирования , в логический протокол , к оторый состоит из определенного числа файлов логического протоко ла на диске . Сервер нуждается как в за писи новых данных в протокол , так и в чтении протокола для восстановления транзакц ий . Для того , чтобы файлы логического прот окола не закончились , необход и мо а рхивировать заполненные файлы логического проток ола. Если же протоколирование не используется , тем не менее , все равно необходимо ар хивировать файлы логического протокола . В это м случае протокол содержит информацию о с оздании и удалении фрагментов диск а и о записи контрольной точки . Эта информаци я нужна для “теплого” восстановления БД д аже в том случае , когда БД не протокол ируются. Автоматическое и непрерывное архивирование Если необходимо архивировать ф айлы логического протокола сразу после их заполнен ия , то нужно запустить автомати ческое архивирование . В этом режиме архивирую тся все файлы логического протокола , готовые к архивированию и процесс останавливается на текущем файле. Также можно запустить непрерывное архивир ование . Тогда сервер автоматически архивируе т файл логического протокола сразу по его заполнению. При автоматическом архивировании нет необ ходимости помнить об архивировании файла , но нужно помнить , что на устройстве архивиро вания всегда должно быть свободное место. Режимы восстановления д ан ных В процессе восстановления INFORMIX-OnLine воссоздает данные , которые стали недоступными в результате аппаратного или программного сб оя . В любом из трех приведенных ниже с лучаях необходимо восстановление данных : Ошибка в программе запортила данные в Б Д ; Необходимо перенести данные на другой компьютер. Процесс восстановления делится на фазы физического и логического восстановления : При физическом восстановлении из архива восстанавливаются страницы dbspace и blobspace; При логическом восстановлении произ во дится восстановление транзакций. Выбор типа физического восста новления Если необходимо восстановить данные после сбоя , в результате которого сервер переше л в режим off-line, то необходимо восстановить в се данные , управляемые сервером . Такой тип восстано вления называется полным восстановле нием системы . Если сбой не привел к ос танову системы , то можно выборочно восстанавл ивать выборочные dbspace или blobspace. При переходе INFORMIX-OnLine в режим off-line из-за сбоя диска критические данные dbspace будут п ов реждены . К критическим dbspace относятся : · root dbspace; · содержащий физический протокол dbspace; · содержащий файлы лог ического протокола dbspace. Восстановление критических dbspace необходимо производить в “холодном ” режиме. Выборочное восстановле ние dbspace или blobspace Если после сбоя INFORMIX-OnLine не пер ешел в состояние off-line, то повреждения dbspace не я вляются критическими . Если сбой случился в фрагменте диска dbspace, который размещается на н ескольких фрагментах , то все активные транзак ц ии в этом dbspace должны быть прерваны перед восстановлением . Можно запустить операцию восстановления до завершения транзакций . Тог да процесс восстановления будет ждать , пока сервер не завершит проверку того , что в се транзакции , активные в момент сбоя , бы л и завершены. “Холодный” режим восстановления Как показано на рис . 1, восст ановление всех dbspace и blobspace (полное восстановление с истемы ) можно сделать с помощью одного физ ического и одного логического восстановления. INFORMIX-OnLine находится в режиме off-line в нач але процесса восстановления , но затем , после восстановления резервных страниц , сервер перехо дит в режим восстановления . С этого момент а сервер находится в данном режиме до тех пор , пока не будет завершено логиче ское восстановление. “Теплый” режим восстановлен ия В данном режиме можно восс танавливать некритичные dbspace и blobspace при работе INFORMIX-OnLine в режиме on-line или quiescent. “Теплый” режим состоит из одного или нескольких физических восс тановлений , логического архивирования и вос становления. При “теплом” восстановлении заархивированные файлы логического протокола “проигрываются” для восстановления транзакций в восстановленных dbspace (рис . 2). Смешанный режим восстановления Смешанный режим восстановления состоит из холодного вос становления , за которым следует теплое восстановление . Некот орые dbspace и blobspace восстанавливаются в холодном режи ме (INFORMIX-OnLine находится в режиме off-line). Такой режим восстановления обычно применяется , когда требуетс я полное восстановление си с темы , н о в ходе его требуется частичный доступ к некоторым таблицам . В этом случае вып олняется холодное восстановление критических dbspace и dbspace, которые содержат важную информацию. Экспорт-импорт данных Миграция данных , т.е . перенос базы данных или ее частей может п онадобиться по следующим причинам : Для переноса разработанной системы заказч ику ; Для переноса на другую аппаратную пла тформу ; Для распространения пользователям ; Для переноса данных между INFORMIX-SE и INFORMIX-OnLine. Методы миграции данных, используемые в INFORMIX-OnLine Сервер INFORMIX-OnLine следующие методы дл я переноса данных из одной БД в другу ю : Утилитами onunload и onload ; Утилитами dbexport и dbimport ; Выражениями LOAD и UNLOAD; Утилитой dbload . Утилиты onunload и onload вз аимосвязан ы , т.е . для того , чтобы загруз ить данные с помощью onload , их необходимо предварительно вы грузить с помощью onunload . Аналогично , для работы dbimport нужны файлы , подготовл енные dbexport . Утили та dbload и выр ажение LOAD могут загружать данные из любого фай ла , если он отвечает определенным т ребованиям по формату. Утилита dbschema по схеме БД создает файл с выра жениями на SQL, который можно использовать затем для создания таблиц с аналогичной структ урой. Использование утилит onunload и onload Эти две утилиты выгружаю т и загружают данные из БД или ее части страницами . Поэтому на использование эт их утилит накладываются некоторые ограничения. При переносе данных между компьютерами необходимо : Убедиться , что размер страницы и предс тавление чисел должно быть одина ковым на обоих системах. Запустить утилиту onc h eck для проверки целостности базы данных. Запустить утилиту onunload . Если нужно , перенести носитель с выгру женными данными на другую систему. Запустить утилиту onload . Установить желаемый статус протоколирова ния новой БД. Создать архив нулевого уровня новой Б Д. При переносе таблиц между компьютерами с помощью onunload и onload необходимо выполнить следующие шаги : Удостовериться , что размер страниц и п редставление чисел одинаково на обоих система х. Запустить ут илиту oncheck для проверки целостности б азы данных. Запустить утилиту onunload . Если нужно , перенести носитель с выгруженными данными на другую систему. Выключить протоколирование Запустить утилиту onload . Создать архив нулевого уровня модифицированной БД. Включить протоколирование , если нужно. Создать необходимые синонимы и права доступа к данной таблице. Выбор между onunload, dbimport и LOAD При невозможности использования утилит onunload и onload , необходимо сделать выбор между dbload , dbimport и LOAD. К аждый из этих способов позволяет модифицировать схему БД. Утилита dbimport загружает БД целиком и ею необходи мо воспользоваться в том случае , когда нет возможности использовать onload . Для загрузки таблиц используйте выражение LOAD или утилиту dbload . При использовании утилиты dbload (или выражения LOAD) нужно загружать данные в уже существующую таблицу . Если таблицы не существует , то ее нужно создать , например , с помощью SQL-выр ажения CREATE можно создать таблицу , представление или синоним. Модификация схе мы БД Утилита dbschema создает файл с SQL-операторами , необходимыми для воспроизведения указанной БД , таблицы и других объектов БД (например , триггера ). После создания файла со схемой БД , этот файл можно вручную отредактировать с целью изменения некоторых характерис тик БД или таблицы (или еще чего-нибудь ). Можно изменить следующие характеристики : Права доступа ; Владельца объекта (таблица , индекс , предста вление ); Режим блокировки ; Размеры начального и последующих extent ’ ов. Dbspace, где хранятся таблицы. Исп ользование выражений UNLOAD и LOAD Выражение UNLOAD позволяет записывать строки , извлеченные выражением SELECT в ASCII-файл . В ыражение UNLOAD создает файл в соответствие с установками в окружении пользовательского прилож ения. Оператор LOAD загружает данные из предв арительно созданного файла в объект БД (та блицу , синоним или представление ). Обычно на входе используется файл , созданный оператором UNLOAD, т.к . оператор LOAD требует строго форматированн ый файл. Использование утилиты dbload Данная утилита , испол ьзуя команды в командном файле dbload , может форматировать вх одные данные перед тем , как вставлять их в указанную таблицу . В дополнение к э тому опции командной строки dbload дают следующие возможн ости : Проверить синтаксис выражений командного файла ; Отклад ывать блокировки таблицы во время вставки данных ; Игнорировать определенное число строк с начала входного файла ; Пропускать некорректные строки ; Прерывать загрузку после определенного ко личества найденных некорректных строк. Утилита dbload может брать на в ходе несколько файлов и вставлять их содержимое в з аданные таблицы , созданные из файла схемы БД. Использование утилит dbexport и dbimport Утилиты dbexport и dbimport манипулируют только базами данных целиком . Дл я использования этих утилит нужно быть по дкл юченным к серверу БД как пользоват ель informix или иметь права системного администратора. Утилита dbexport выгружает данные в ASCII-файлы . В дополн ение к этому dbexport создает ASCII-файл , в котором содержится схема базы данных , необходимая для повторно го создания БД , идентичной данной , на другом сервере. Утилита dbimport читает входные файлы . Она использует файл схемы БД для создания копии базы . Можно указать характеристики протоколирования новой БД с помощью опций командной стр оки . После создания БД проис ходит ее наполнение содержимым файлов , созданных утил итой dbexport . Режимы работы сервера INFORMIX-OnLine Сервер имеет несколько режимов работы : · off-line · quiescent · on-line · read-only · recovery · shutdown В режиме off-line сервер не запущен. В режиме quiescent выполняются административны е процедуры . Для этого прекращается вся ра бота с базой данных . Только пользователи informix и root могут выполнять а дминистративные процедуры с помощью ON-Monitor или утилит кома ндной строки . В этом режиме нельз я подключиться к серверу , однако можно узнать его текущее состояние. В режиме on-line пользователи могут подсоединят ься к своим базам данных и выполнять запросы . В это время администратор может м енять определенные настройки в файле ONCONFIG. Режим read-onl y приложения могут только запрашивать данные с сервера , но не могут их обновлять. Режим recovery является переходным . В этом р ежиме сервер находится при переходе из ре жима off-line в режим quiescent. Быстрое восстановление выпо лняется в этом режиме. Режим shutdown также является переходным . Он может возникнуть при переходе из ре жима on-line (или quiescent) в режим off-line. Средства диагностики сервера INFORMIX-OnLine Системная БД sysmaster INFORMIX-OnLine Dynamic Server создает и поддерживает БД sysmaster. Эта база данных содержит и нформацию о самом сервере . Sysmaster состоит из с ледующих таблиц : Таблицы SMI Таблицы интерфейса системного мониторинга (SMI) содержат информацию о состоянии сервера INFORMIX-OnLine. Можно обращаться к этим таблицам для определен ия “узких мест” в обработке информации , определения использования ресурсов , от слеживания активности сессий или сервера БД , и т.п. Таблицы каталога ON-Archive Эти таблицы содержат информацию о зап росах , наборах томов , наборов сохранения. INFORMIX-OnLine соз дает БД sysmaster автоматически при инициализации дискового пространства . Нельзя удалить эту БД или таблицы в ней , а также нельз я изменить состояние протоколирования БД. Можно , как пользователь informix , создавать хранимые процедуры и триггеры в этой БД . Н о INFORMIX-OnLine не будет исполнять созданные пользователем в sysmaster триггеры. Описание таблиц SMI Интерфейс системного мониторинга состоит из некоторого числа таблиц и псевдотаблиц , которые автоматически поддерживаются INFORMIX-OnLine и не сбрасываютс я на диск во время работы. Таблицы SMI содержат следующую информацию : Аудитинг Обращение к дискам Информация о пользователях Статус протоколирования баз данных Таблицы Chunk ’ и Ввод-вывод chunk ’ ов Пространства БД Блокировки Extent ’ ы Системная информация Люб ой пользователь может з апрашивать информацию из любой таблицы sysmaster за исключением таблиц sysadinfo и sysaudit. Последние две таблицы может просматривать только пользователь informix. Триггеры по изменению в SMI-таблица х никогда не выполняются , т.к . IN FORMIX-OnLine прои зводит изменения в SMI-таблицах не с помощью SQL-выражений. Ниже приведен список используемых SMI-таблиц : sysaudinfo Конфигурационн ая информация аудитинга sysaudit Маски со бытий аудитинга syschkio Статистика ввода-вывода для chunk ’ ов syschunks Информация о chunk ’ ах sysdatabases Информация о базах данных sysdbspaces Информация о пространствах БД sysdri Информация по репликации данных sysextents Информация о размещении extent ’ ов syslocks Информация об активных блокировках syslogs И нформация о файлах логического протокола sysprofile Системная информация sysptprof Информация по таблицам syssesprof Подсчет действий пользователей syssessions Описание каждого пользовательского соединения sysseswts Время ожидания пользователем каждог о из нескольких объектов systabnames Описание каждой таблицы , управляемой INFORMIX-OnLine Из влечение диагностической информации о работе сервера Для извлечения информации из таблиц SMI используется утилита onstat . Ниже приведены некоторые возможные опции этой утилиты : Опции onstat Запрос к таблицам SMI -d sysdbspaces syschunks -D sysdbspaces syschkio -F sysprofile -g dri sysdri -g glo sysvpprof -k syslocks -l syslogs sysprofile -p sysprofile -u syssessions syssesprof
1Архитектура и строительство
2Астрономия, авиация, космонавтика
 
3Безопасность жизнедеятельности
4Биология
 
5Военная кафедра, гражданская оборона
 
6География, экономическая география
7Геология и геодезия
8Государственное регулирование и налоги
 
9Естествознание
 
10Журналистика
 
11Законодательство и право
12Адвокатура
13Административное право
14Арбитражное процессуальное право
15Банковское право
16Государство и право
17Гражданское право и процесс
18Жилищное право
19Законодательство зарубежных стран
20Земельное право
21Конституционное право
22Конституционное право зарубежных стран
23Международное право
24Муниципальное право
25Налоговое право
26Римское право
27Семейное право
28Таможенное право
29Трудовое право
30Уголовное право и процесс
31Финансовое право
32Хозяйственное право
33Экологическое право
34Юриспруденция
 
35Иностранные языки
36Информатика, информационные технологии
37Базы данных
38Компьютерные сети
39Программирование
40Искусство и культура
41Краеведение
42Культурология
43Музыка
44История
45Биографии
46Историческая личность
47Литература
 
48Маркетинг и реклама
49Математика
50Медицина и здоровье
51Менеджмент
52Антикризисное управление
53Делопроизводство и документооборот
54Логистика
 
55Педагогика
56Политология
57Правоохранительные органы
58Криминалистика и криминология
59Прочее
60Психология
61Юридическая психология
 
62Радиоэлектроника
63Религия
 
64Сельское хозяйство и землепользование
65Социология
66Страхование
 
67Технологии
68Материаловедение
69Машиностроение
70Металлургия
71Транспорт
72Туризм
 
73Физика
74Физкультура и спорт
75Философия
 
76Химия
 
77Экология, охрана природы
78Экономика и финансы
79Анализ хозяйственной деятельности
80Банковское дело и кредитование
81Биржевое дело
82Бухгалтерский учет и аудит
83История экономических учений
84Международные отношения
85Предпринимательство, бизнес, микроэкономика
86Финансы
87Ценные бумаги и фондовый рынок
88Экономика предприятия
89Экономико-математическое моделирование
90Экономическая теория

 Анекдоты - это почти как рефераты, только короткие и смешные Следующий
Тут мужики в унитаз попасть не могут, а вы говорите, рождаемость повышать...
Anekdot.ru

Узнайте стоимость курсовой, диплома, реферата на заказ.

Обратите внимание, реферат по программированию "СУБД INFORMIX", также как и все другие рефераты, курсовые, дипломные и другие работы вы можете скачать бесплатно.

Смотрите также:


Банк рефератов - РефератБанк.ру
© РефератБанк, 2002 - 2016
Рейтинг@Mail.ru