Понятие и классификация АИС

ся по ключевому индексу «Номер», то есть по следующим полям – «Тип

документа», «Дата», «Номер», «Тема».

Перенос документов одного типа в другой тип

Используя экспорт/импорт можно также переносить документы одного

типа в реестр документов другого типа. Например, можно перенести рас-

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

другой базе. Для этого нужно либо просто переименовать имена внешних

файлов, либо сделать два описания экспорта выборки в файле ресурсов, в

которых одно и то же имя внешнего файла будет соответствовать в одном

случае расходным накладным, а в другом - приходным. Только не стоит

забывать про наименования документов.

Рекомендации по импорту из других

программ

При импорте данных в комплекс СБиС++ из других программ советуем

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

Учитесь на образцах

Перед тем как подготовить файл для передачи данных в СБиС++, создайте

в программе несколько пробных записей в тех реестрах или справочниках,

которые предполагается переносить. Экспортируйте эти записи. Внима-

тельно изучите состав и структуру полученных эталонных файлов.

Обратите внимание на связи

В некоторых случаях при экспорте программа создаёт не один, а несколь-

ко внешних файлов. Для организации связи таких файлов между собой не-

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

занной таблице.

Например, любая запись таблицы «Организации» связана с

записями таблицы «Расчетные счета» по полю «ЛицоРСче-

та». В свою очередь записи таблицы «Расчетные счета»

связаны с записями таблицы «Банки» по полю «БанкРСче-

та». Поэтому при импорте организаций все связи будут со-

хранены.

 

В отличие от программ типа Foxpro, комплекс СБиС++ использует не ре-

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

ные поля должны обязательно присутствовать в файлах, даже если во всех

записях его содержимое придется сделать равным –1 (то есть даже, если

нет связи).

Учтите, что в dbf-файлах нумерация записей ведётся не с 1, как в Foxpro, а

с 0 (в терминологии FoxPro используется значение «RECNO()–1»). Если

связи нет, то в таких полях записывается значение «–1».

По умолчанию, имена таких служебных полей совпадают с соответст-

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

файле ресурсов в описании формата экспорта/импорта указать соответст-

вие для полей связи.

Особенности dbf-формата

Обратите внимание, что программа СБиС++ поддерживает импорт только

формата DBF DBase III.

Как уже говорилось, при работе с dbf-форматом могут возникать пробле-

мы с русскими именами полей. Поэтому лучше не использовать русские

имена полей, и в файле ресурсов указать соответствующие английские

имена.

Типы полей должны совпадать

При создании файлов обращайте внимание на типы полей – строка, число

или дата. Они должны совпадать с типами аналогичных полей в эталон-

ных файлах.

 

 

4.2Утилиты экспорта и импорта данных

 

Утилиты экспорта и импорта предоставляют простой механизм перемещения объектов базы данных между базами данных Oracle. Они вызываются командами exp и imp соответственно. Эти утилиты поддерживают формат данных XMLType, тогда как помпа данных экспорта и импорта нет.

Экспорт -копирование данных во внешние файлы только для импорта в другую базу данных Oracle. Такие файлы имеют собственный бинарный формат.

Импорт -копирование данных в базу из внешних файлов, которые были созданы экспортом из другой базы данных Oracle.

 

Для экспорта или импорта дампа базы данных в Oracle используются утилиты входящие в состав ПО Oracle. В зависимости от версии БД утилиты могут именоваться по разному. Так, для версии Oracle 8.0x используются файлы exp80.exe и imp80.exe, а для Oracle 8.1.x или старше exp.exe, imp.exe соответственно. Эти утилиты можно найти в каталоге BIN установленного сервера Oracle или его клиента. Узнать версию можно при помощи запроса: SELECT VERSION FROM V$INSTANCE; Запрос выполнится только для пользователя имеющего DBA привилегии, например SYSTEM или SHURA.

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

Утилиты экспорта/импорта работают с файлами специальной структуры имеющими как правило расширение DMP. При экспорте/импорте имеет значение версия дамп-файла. Узнать версию дамп-файла можно открыв его на просмотр. В самом начале имеется характерная строка вида EXPORT:V08.00.06, по которой можно судить о версии дамп-файла. В данном примере версия 8.0.6. Это важно при выполнении импорта, так, при импортировании дампа более старшей версии чем версия базы могут возникнуть проблемы.

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

 

 

4.3Преобразование  данных при экспортировании

 

4.4Конвертирование, согласование, проверка данных

 

 

Тема 5.Восстановление информации в базах данных. Обеспечение достоверности информации в процессе хранения и обработки

 

5.1Журнализация  и восстановление

 

 

Одно из основных требований к любой системе управления базами данных состоит в том, что СУБД должна надежно хранить базы данных. Это означает, что СУБД должна поддерживать средства восстановления состояния баз данных после любых возможных сбоев. К таким сбоям относятся индивидуальные сбои транзакций (например, деление на ноль в прикладной программе, инициировавшей выполнение транзакции); сбой процессора при работе СУБД (так называемые мягкие сбои) и сбои (поломки) внешних носителей, на которых расположены базы данных (жесткие сбои).

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

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

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

Как отмечает Дейт [34], любое восстановление состояния базы данных должно основываться на наличии некоторой дополнительной, избыточной информации. Из общих соображений очевидно, что для восстановления базы данных необходима информация, которая не теряется при сбоях, вызывающих потребность в восстановлении. Тем самым, задача любой СУБД и System R, в частности, состоит в выборе некоторого базового механизма поддержки такой избыточной информации, который удовлетворял бы потребностям всех используемых типов восстановлений.

Алгоритмы восстановления System R основаны на двух базовых средствах - ведении журнала и поддержке теневых состояний сегментов. Рассмотрим сначала механизм журнализации. Мы уже упоминали о наличии журнала в предыдущих подразделах. Журнал это отдельный файл внешней памяти, для которого для надежности обычно поддерживаются две копии и в который помещается информация по поводу всех операций изменения состояния базы данных. В предыдущем подразделе мы упоминали об использовании журнала для отката транзакции по явной операции RESTORE или при неявных откатах при разрушении тупиков. Та же схема употребляется и при откатах индивидуальных транзакций при сбоях.

Механизм индивидуального отката основан на обратном выполнении всех изменений, произведенных данной транзакции (undo). При этом из журнала в обратном хронологическому порядке выбираются все записи об изменении базы данных, произведенные от имени данной транзакции. Для этого необходима идентификация всех записей в журнале. В System R все записи одной транзакции связываются в один список в порядке обратном хронологическому. Ссылка в списке представляет собой адрес записи в файле-журнале. Поскольку схема индивидуального отката едина для всех ситуаций индивидуальных сбоев, в частности для ситуации разрушения тупиков, то обратное выполнение операций сопровождается снятием установленных при прямой работе транзакции синхронизационных захватов с объектов базы данных. Следовательно, после выполнения индивидуального отката транзакции ситуация в системе такова, как если бы транзакция никогда и не начиналась.

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

Заметим, что размер буферного пула СУБД во многом определяет ее производительность. Более того, как отмечает Дейт в [34], обычная реляционная СУБД такая, как System R, при наличии достаточного размера буферного пула вполне конкурентноспособна по отношению к системам, основанным на специализированной аппаратуре машин баз данных.

Задача System R по обеспечению надежного завершения транзакций, т.е. гарантированию наличия произведенных ими изменений в базе данных, требует наличия на внешней памяти информации об этих изменениях. Реально для этого при оканчивании любой транзакции поддерживается гарантированное присутствие в файле-журнале все записей об изменениях, произведенных этой транзакцией. При использовании буферизации для записи в журнал для этого достаточно насильственно вытолкнуть на внешнюю память недозаполненный буфер журнала. Под насильственным выталкиванием понимается запись буфера на внешнюю память в соответствии не с логикой ведения журнала, а с логикой оканчивания транзакции. Только после произведения такого насильственного выталкивания буфера журнала транзакция считается закончившейся. Заметим, что последней записью в журнале от любой изменяющей базу данных транзакции является запись о конце транзакции. Эти записи используются при восстановлении. Рассмотрим теперь (пока не совсем точно) как осуществляется в System R восстановление базы данных после мягкого сбоя.

Основой алгоритма восстановления является то, что система придерживается правила упреждающей записи в журнал (WAL Write Ahead Log). Это правило означает, что при выталкивании любой страницы из буфера страниц сначала гарантируется наличие в файле журнала записи, относящейся к изменениям этой страницы после момента ее вталкивания в буфер. Поскольку записи в журнал блокируются, то для соблюдения правила WAL перед выталкиванием страницы данных необходимо вытолкнуть недозаполненный буфер журнала, если он содержит запись, относящуюся к изменению страницы. Применение правила WAL гарантирует, что если на внешней памяти находится страница базы данных, то в файле журнала находятся все записи об операциях, вызвавших изменение этой страницы. Обратное неверно: в файле журнала могут содержаться записи об изменении некоторых страниц базы данных, а сами эти изменения могут быть не отражены в состояниях страниц на внешней памяти.

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