Sysaux oracle что там хранится
This chapter discusses using Oracle Enterprise Manager Database Express (EM Express) to view and manage the storage structures of your database. This chapter contains the following sections:
6.1 About Database Storage Structures
An Oracle database is made up of physical and logical structures. Physical structures can be seen and operated on from the operating system, such as the physical files that store data on a disk.
Logical structures are created and recognized by Oracle Database and are not known to the operating system. The primary logical structure in a database, a tablespace, contains physical files. The applications developer or user may be aware of the logical structure, but is not usually aware of this physical structure. The database administrator (DBA) must understand the relationship between the physical and logical structures of a database.
Figure 6-1 shows the relationships between logical and physical structures. This figure also shows recovery-related structures that are optionally kept in the fast recovery area. See "Fast Recovery Area" for more information.
Figure 6-1 Oracle Database Storage Structures
Oracle Database can automate much of the management of its structure. Oracle Enterprise Manager Database Express (EM Express) provides a Web-based graphical user interface (GUI) to enable easier management and monitoring of your database.
From a physical perspective, a multitenant container database (CDB) has basically the same structure as a non-CDB, except that each pluggable database (PDB) has its own set of tablespaces (including its own SYSTEM and SYSAUX tablespaces) and data files.
A CDB contains the following files:
One control file
One online redo log
One or more sets of temp files
One set of undo data files
A set of system data files for every container
Zero or more sets of user-created data files
This section provides background information about the various database storage structures. It contains the following topics:
Oracle Database Concepts for more information about database storage structures
Oracle Multitenant Administrator's Guide for more information about database files in a CDB
6.1.1 About Control Files
A control file tracks the physical components of the database. It is the root file that the database uses to find all the other files used by the database. Because of the importance of the control file, Oracle recommends that the control file be multiplexed , or have multiple identical copies. For databases created with Oracle Database Configuration Assistant (DBCA), two copies of the control file are automatically created and kept synchronized with each other.
If any control file fails, then your database becomes unavailable. If you have a control file copy, however, you can shut down your database and re-create the failed control file from the copy, then restart your database. Another option is to delete the failed control file from the CONTROL_FILES initialization parameter and restart your database using the remaining control files.
Oracle Database Concepts for an overview of control files
Oracle Database Administrator’s Guide for detailed information about control files
6.1.2 About Online Redo Log Files
Every Oracle database has a set of two or more online redo log files. The set of online redo log files is collectively known as the redo log for the database. A redo log is made up of redo entries, which are also called redo records .
The online redo log stores a copy of the changes made to data. If a failure requires a data file to be restored from backup, then the recent data changes that are missing from the restored data file can be obtained from the online redo log files, so work is never lost. The online redo log files are used to recover a database after hardware, software, or media failure. To protect against a failure involving the online redo log file itself, Oracle Database can multiplex the online redo log file so that two or more identical copies of the online redo log file can be maintained on different disks.
The online redo log for a database consists of groups of online redo log files. A group consists of an online redo log file and its multiplexed copies. Each identical copy is considered to be a member of that group. Each group is defined by a number, such as Group 1.
Figure 6-2 shows the configuration of a database that has three online redo log groups and two members in each group. For each group, the members are stored on separate disks for maximum availability. For example, the members of Group 1 are the redo log files A_LOG1 and B_LOG1 .
Figure 6-2 Online Redo Log Groups and Their Members
The database log writer process (LGWR) writes redo records from the memory buffer to a redo log group until the log files in that group reach their storage size limit, or until you request a log switch operation. The LGWR process then writes to the next log group. The LGWR process performs this action in a circular fashion so that the oldest group is overwritten by the most recent redo records.
Oracle Database Concepts for an overview of online redo logs
Oracle Database Administrator’s Guide for detailed information about redo logs
Начиная с Oracle Database 10g требуется обязательное создание табличного пространства Sysaux, которое служит вспомогательным табличным пространством по отношению к табличному пространству System. До последнего времени табличное пространство System было местоположением по умолчанию для хранения объектов, относящихся к таким компонентам, как Workspace Manager, Logical Standby, Oracle Spatial LogMiner и т. д. Чем больше средств предлагает база данных, тем большего объема должно быть табличное пространство System. Вдобавок несколько средств должны иметь свои собственные репозитории, такие как Enterprise Manager и его Repository. Помимо всего этого потребуется создать специальное табличное пространство для Statspack Repository.
Чтобы снизить эту нагрузку на табличное пространство System и консолидировать все репозитории для различных средств Oracle, в Oracle Database предусмотрено табличное пространство Sysaux в качестве единого централизованного хранилища различных компонентов базы данных. Использование табличного пространства Sysaux обеспечивает следующие преимущества:
- Приходится управлять меньшим количеством табличных пространств, потому что не нужно создавать отдельные табличные пространства для множества компонентов базы данных. Вы просто назначаете табличное пространство Sysaux в качестве местоположения по умолчанию для размещения всех компонентов.
- Снижается нагрузка на табличное пространство System.
Размер табличного пространства Sysaux зависит от размера компонентов базы данных, которые вы будете хранить в нем. Таким образом, вы должны основывать размер вашего табличного пространства Sysaux на компонентах и средствах, используемых вашей базой данных. Oracle рекомендует создавать табличное пространство Sysaux с минимальным размером в 240 Мбайт. Обычно репозиторий OEM бывает самым крупным пользователем табличного пространства Sysaux.
Обязательные файлы:
Файлы паролей (Password File)
Необязательный файл, используется для защиты информации о подключениях привилегированных пользователей. Если отсутствует, то вы можете выполнять администрирование своей базы данных, только локально. Кроме того, с его помощью контролируется количество привилегированных подключений для управления в одно и то же время.
Tags: Oracle Database, Файлы базы данных Oracle,
Ограничения на использование табличного пространства Sysaux
Хотя применение команды ALTER TABLESPACE для изменения табличного пространства Sysaux может создать впечатление, что пространство Sysaux похоже на любое другое табличное пространство в базе данных, некоторые моменты в его использовании ставят это табличное пространство особняком. Вот эти ограничения.
A mandatory tablespace that consists of the data dictionary, including definitions of tables, views, and stored procedures needed by the database. Oracle Database automatically maintains information in this tablespace.
A mandatory, auxiliary system tablespace that is used by many Oracle Database features and products. This tablespace contains content that was previously stored in the DRSYS , CWMLITE , XDB , ODM , OEM_REPOSITORY , and SYSTEM tablespaces.
An user-created tablespace that consists of application data. As you create and enter data into tables, Oracle Database fills this space with your data.
A mandatory tablespace that contains temporary tables and indexes created during SQL statement processing. You may have to expand this tablespace if you run SQL statements that involve significant sorting, such as ANALYZE COMPUTE STATISTICS on a very large table, or the constructs GROUP BY , ORDER BY , or DISTINCT .
System-managed tablespaces that contain undo data for each instance. Each Oracle RAC instance uses a different value for n in the tablespace name. These tablespaces are used for automatic undo management.
A system tablespace that contains rollback segments. If you do not use automatic undo management, then you must configure the RBS tablespace. The RBS tablespace should only be used when needed for compatibility with earlier versions of Oracle Database.
Посмотреть, какие табличные пространства имеются в базе данных можно следующим запросом.
В каких файлах хранятся табличные пространства.
Необязательные файлы:
-
(необязательные в том смысле, что база может быть настроена для работы без данных файлов) (Alertlog - если нет необходимости в изучении данных по ошибкам, можно удалить. Трассировочные файлы по умолчанию не создаются. Чтобы создавались, нужно включать трассировку и потом не забыть отключить) (По умолчанию не используются. Нужно специально создавать специальными командами.)
Файлы параметров pfile, spfie (Parameter Files)
Файлы параметров используются для конфигурирования действий Oracle предже всего при старте. Для того, чтобы запустить экземпляр базы данных, Oracle должен прочесть файл параметров и определить, какие параметры инициализации установлены для этого экземпляра. В файле параметров содержатся многочисленные параметры и их установленные значения. Oracle считывает файл параметров при запуске базы данных. Можно создать несколько файлов параметров, каждый будет соответствовать различным конфигурациям экземпляра.
- spfile - бинарный файл, который используется сервером Oracle при старте.
- pfile - текстовый файл с параметрами, будет использоваться при старте, если не будет найден spfile.
При старте, Oracle считает файл spfileora112.ora. (файл серверных параметров). Преимущество spfile заключается в том, что при работе с базой данных, любые изменения в базе касающиеся изменения параметра системы, автоматически записываются в данный файл.
Если используется pfile, для сохранения изменений, необходимо либо “руками вносить эти изменения” в текстовый файл, либо в консоли выполнять команды для создания данных файлов Ораклом.
Файлы данных (Data Files)
Все данные в базе данных Oracle сохраняются в файлах данных. Все таблицы, индексы, триггеры, последовательности, программы на PL/SQL, представления - все это находится в файлах данных. И хотя эти и другие объекты базы данных логически содержатся в табличных пространствах, в действительности они сохраняются в файлах на жестком диске компьютера.
В каждой базе данных Oracle имеется по крайней мере один файл данных (но обычно их бывает больше). Если вы создаете в Oracle таблицу и заполняете ее строками, Oracle помещает эту таблицу и строки в файл данных. Каждый файл данных может быть связан только с одной базой данных.
У каждого файла данных имеется специальный формат, внутренний для программного обеспечения Oracle. Важно отдавать себе отчет в том, что файл данных состоит из заголовка и совокупности блоков. Заголовок файла данных Oracle содержит несколько структур, в том числе и идентификатор базы данных, номер и имя файла, тип файла, SCN создания и состояния файла.
Данные в файлы вносятся исключительно средствами Oracle.
Следующий запрос, покажет, где находятся файлы данных.
Табличное пространство sysaux
Табличное пространство sysaux служит вспомогательным табличным пространством по отношению к табличному пространству system.
Предполагается, что вы инсталлировали базу данных, согласно документа.
Оперативные файлы журналов повтора (Online Redo Log Files)
Оперативные файлы журналов повтора - предназначены для записи всех изменений, выполненных над данными базы данных Oracle. Используется для хранения на диске информации для повторного выполнения операций.
Для компьютера выполнить задачи повторно - означает выполнить ее точно так, как она выполнялась в предыдущий раз. Поэтому назначение оперативного файла журнала повтора заключается в сохранении информации об изменениях в базе данных таким, образом, чтобы позже их можно было повторить.
Каждая база данных должна иметь не менее двух оперативных файлов журналов повтора. Текущий файл постепенно заполняется, после его заполнения (или переключения некоторыми командами), база данных приступает к записи в следующий файл. Эта операция называется переключением журналов.
Поскольку файлы повтора необходимы для выполнения восстановления базы данных и являются критичными, их объединяют в группы. Запись происходит одновременно в файлы одной группы.
Oracle DBA
Лучше потратить какое-то количество времени, чтобы записать успешный опыт, чем потом повторно воспроизводить его по памяти.
Все материалы обновляются по мере нахождения лучших практик и апгрейда знаний. Если будут желающие добавлять свои знания или исправлять ошибки и неточности, пишите в телеграм чате. Если будет учавствовать больше людей, качество материалов будет улучшаться и обновляться быстрее. Ссылки на ваши профили в соц. сетях будут добавлены в статьях, в которых вы учавствуете.
This chapter describes the nature of and relationships among logical storage structures. These structures are created and recognized by Oracle Database and are not known to the operating system.
This chapter contains the following sections:
Табличное пространство system
В табличном пространстве system хранится «Словарь данных Oracle»
Каждая база данных Oracle содержит набор таблиц, доступных только для чтения и известных как словарь данных (data dictionary), который содержит метаданные (информацию о различных компонентах базы данных). Словарь данных Oracle – сердце системы управления базой данных.
Словарь данных создается при создании экземпляра базы данных выполнением инструкций в файле $ORACLE_HOME/rdbms/admin/catalog.sql
Oracle не позволяет обращаться к таблицам словаря данных напрямую. Он создает представления на базе этих таблиц и общедоступные синонины для тих представлений, к которым могут обращаться пользователи. Существует три набора представлений словаря данных: USER, ALL и DBA – каждый из которых содержит сходный набор представлений со сходным набором столбцов.
Посмотреть содержимое табличного пространства system
6.1 About Database Storage Structures
An Oracle database is made up of physical and logical structures. Physical structures can be seen and operated on from the operating system, such as the physical files that store data on a disk.
Logical structures are created and recognized by Oracle Database and are not known to the operating system. The primary logical structure in a database, a tablespace, contains physical files. The applications developer or user may be aware of the logical structure, but is not usually aware of this physical structure. The database administrator (DBA) must understand the relationship between the physical and logical structures of a database.
Figure 6-1 shows the relationships between logical and physical structures. This figure also shows recovery-related structures that are optionally kept in the fast recovery area. See "Fast Recovery Area" for more information.
Figure 6-1 Oracle Database Storage Structures
Oracle Database can automate much of the management of its structure. Oracle Enterprise Manager Database Express (EM Express) provides a Web-based graphical user interface (GUI) to enable easier management and monitoring of your database.
From a physical perspective, a multitenant container database (CDB) has basically the same structure as a non-CDB, except that each pluggable database (PDB) has its own set of tablespaces (including its own SYSTEM and SYSAUX tablespaces) and data files.
A CDB contains the following files:
One control file
One online redo log
One or more sets of temp files
One set of undo data files
A set of system data files for every container
Zero or more sets of user-created data files
This section provides background information about the various database storage structures. It contains the following topics:
Oracle Database Concepts for more information about database storage structures
Oracle Multitenant Administrator's Guide for more information about database files in a CDB
6.1.1 About Control Files
A control file tracks the physical components of the database. It is the root file that the database uses to find all the other files used by the database. Because of the importance of the control file, Oracle recommends that the control file be multiplexed , or have multiple identical copies. For databases created with Oracle Database Configuration Assistant (DBCA), two copies of the control file are automatically created and kept synchronized with each other.
If any control file fails, then your database becomes unavailable. If you have a control file copy, however, you can shut down your database and re-create the failed control file from the copy, then restart your database. Another option is to delete the failed control file from the CONTROL_FILES initialization parameter and restart your database using the remaining control files.
Oracle Database Concepts for an overview of control files
Oracle Database Administrator’s Guide for detailed information about control files
6.1.2 About Online Redo Log Files
Every Oracle database has a set of two or more online redo log files. The set of online redo log files is collectively known as the redo log for the database. A redo log is made up of redo entries, which are also called redo records .
The online redo log stores a copy of the changes made to data. If a failure requires a data file to be restored from backup, then the recent data changes that are missing from the restored data file can be obtained from the online redo log files, so work is never lost. The online redo log files are used to recover a database after hardware, software, or media failure. To protect against a failure involving the online redo log file itself, Oracle Database can multiplex the online redo log file so that two or more identical copies of the online redo log file can be maintained on different disks.
The online redo log for a database consists of groups of online redo log files. A group consists of an online redo log file and its multiplexed copies. Each identical copy is considered to be a member of that group. Each group is defined by a number, such as Group 1.
Figure 6-2 shows the configuration of a database that has three online redo log groups and two members in each group. For each group, the members are stored on separate disks for maximum availability. For example, the members of Group 1 are the redo log files A_LOG1 and B_LOG1 .
Figure 6-2 Online Redo Log Groups and Their Members
The database log writer process (LGWR) writes redo records from the memory buffer to a redo log group until the log files in that group reach their storage size limit, or until you request a log switch operation. The LGWR process then writes to the next log group. The LGWR process performs this action in a circular fashion so that the oldest group is overwritten by the most recent redo records.
Oracle Database Concepts for an overview of online redo logs
Oracle Database Administrator’s Guide for detailed information about redo logs
Начиная с Oracle Database 10g требуется обязательное создание табличного пространства Sysaux, которое служит вспомогательным табличным пространством по отношению к табличному пространству System. До последнего времени табличное пространство System было местоположением по умолчанию для хранения объектов, относящихся к таким компонентам, как Workspace Manager, Logical Standby, Oracle Spatial LogMiner и т. д. Чем больше средств предлагает база данных, тем большего объема должно быть табличное пространство System. Вдобавок несколько средств должны иметь свои собственные репозитории, такие как Enterprise Manager и его Repository. Помимо всего этого потребуется создать специальное табличное пространство для Statspack Repository.
Чтобы снизить эту нагрузку на табличное пространство System и консолидировать все репозитории для различных средств Oracle, в Oracle Database предусмотрено табличное пространство Sysaux в качестве единого централизованного хранилища различных компонентов базы данных. Использование табличного пространства Sysaux обеспечивает следующие преимущества:
- Приходится управлять меньшим количеством табличных пространств, потому что не нужно создавать отдельные табличные пространства для множества компонентов базы данных. Вы просто назначаете табличное пространство Sysaux в качестве местоположения по умолчанию для размещения всех компонентов.
- Снижается нагрузка на табличное пространство System.
Размер табличного пространства Sysaux зависит от размера компонентов базы данных, которые вы будете хранить в нем. Таким образом, вы должны основывать размер вашего табличного пространства Sysaux на компонентах и средствах, используемых вашей базой данных. Oracle рекомендует создавать табличное пространство Sysaux с минимальным размером в 240 Мбайт. Обычно репозиторий OEM бывает самым крупным пользователем табличного пространства Sysaux.
Как я могу узнать, что моя база данных использует PFILE или SPFILE?
Выполните следующий запрос, чтобы увидеть какой файл параметров был использован:
Архивные файлы журналов повтора (Archive Log Files)
Как только оперативный файл журнала повтора (Redolog) оказывается заполнен, программное обеспечение сервера Oracle начинает запись в следующий файл. Эта операция повторяется, как следствие информация в оперативных файлах журнала (Redolog) многократно перезаписывается.
Если необходимо сохранить историю изменений, нужно, чтобы после переключения журналов сохранялась их копия. Для этого достаточно перевести работу базы данных в режим работы ARCHIVELOG.
Архивные файлы журналов повтора жизненно важны при восстановлении. Если часть базы данных потеряна или повреждена, то для устранения повреждений обычно требуется несколько архивных журналов или туева хуча этих журналов. Файлы журналов повтора должны применяться к базе данных последовательно. Если один из архивных файлов журналов повтора пропущен, то остальные архивные файлы журналов не могут использоваться. Храните все свои архивные файлы журналов повтора с момента выполнения последней резервной копии. Файлы журналов постепенно накапливаются и разрастаются. Иногда необходимо их удалять. Все операции с данными файлами по применению их к базе выполняются исключительно средствами базы данных. А копировать и переносить их при желании можно как угодно. Бездумно удалять их руками не рекомендуется.
Управляющие файлы (Control Files)
Поскольку база данных Oracle является физическим набором связанных файлов данных, то для их синхронизации и контроля требуется особые методы. Для этих целей используются управляющие файлы.
База данных Oracle может иметь один или несколько управляющих файлов. Если имеется несколько управляющих файлов, все они должны быть абсолютно идентичными. При каждом запуске базы данных Oracle читает информацию управляющего файла, а при каждом изменении размещения или добавления новых файлов данных и журналов базы данных обновляет управляющий файл.
Создание табличного пространства Sysaux
Если вы используете средство Oracle Database Configuration Assistant (DBCA), то можете автоматически создать табличное пространство Sysaux при создании новой базы данных, будь то база, основанная на начальной (seed) базе данных, либо совершенно новая, построенная с нуля, определенная пользователем база данных. Во время процедуры создания базы DBCA предлагает выбрать местоположение файла табличного пространства Sysaux. При обновлении до Oracle Database 10g инструмент Database Upgrade Assistant просто запросит информацию о файле для создания нового табличного пространства Sysaux.
Совет. Табличное пространство Sysaux является обязательным, независимо от того, создаете вы новую базу Oracle либо производите миграцию от выпуска, предшествующего Oracle Database 10g.
Табличное пространство Sysaux можно создать вручную при создании базы данных.Ниже показан синтаксис команды создания этого табличного пространства:
Если вы пропустите опцию создания SYSAUX в операторе CREATE DATABASE, то Oracle создаст табличные пространства System и Sysaux автоматически, поместив их файлы данных в определенное системой место по умолчанию. Если вы используете Oracle Managed Files, то местоположение файла данных будет зависеть от инициализационных параметров OMF. Если включить конструкцию DATAFILE для табличного пространства System, нужно будете использовать конструкцию DATAFILE и для табличного пространства Sysaux, если только не применяется OMF.
Устанавливать местоположение файла данных можно только при создании табличного пространства Sysaux, создавая базу данных, как показано в предыдущем примере.Oracle устанавливает все остальные обязательные и не изменяемые атрибуты командой ALTER TABLESPACE. Как только вы укажете местоположение и размер файла данных,Oracle создает табличное пространство Sysaux со следующими атрибутами:
- постоянное;
- доступное для чтения и записи;
- локально управляемое;
- с автоматическим управлением пространством сегментов.
Вы можете изменить табличное пространство Sysaux, используя ту же команду ALTER TABLESPACE, которую применяете для других табличных пространств. Вот пример:
Introduction to Logical Storage Structures
Oracle Database allocates logical space for all data in the database.
The logical units of database space allocation are data blocks, extents, segments, and tablespaces. At a physical level, the data is stored in data files on disk. The data in the data files is stored in operating system blocks.
The following figure is an entity-relationship diagram for physical and logical storage. The crow's foot notation represents a one-to-many relationship.
Figure 14-1 Logical and Physical Storage
Logical Storage Hierarchy
A segment contains one or more extents, each of which contains multiple data blocks.
The following figure shows the relationships among data blocks, extents, and segments within a tablespace. In this example, a segment has two extents stored in different data files.
Figure 14-2 Segments, Extents, and Data Blocks Within a Tablespace
From the lowest level of granularity to the highest, Oracle Database stores data as follows:
A data block is the smallest logical unit of data storage in Oracle Database.
One logical data block corresponds to a specific number of bytes of persistent storage, for example, 2 KB. Data blocks are the smallest units of storage that Oracle Database can use or allocate.
Traditionally, data files have been stored on magnetic disk or Solid State Disk (SSD). Oracle Database also supports Persistent Memory (PMEM) for storage of database files. Regardless of how the underlying data is physically stored, Oracle processes always read and write logical data blocks.
An extent is a set of logically contiguous data blocks allocated for storing a specific type of information
In the preceding graphic, the 24 KB extent has 12 data blocks, while the 72 KB extent has 36 data blocks.
A segment is a set of extents allocated for a specific database object, such as a table .
For example, the data for the employees table is stored in its own data segment , whereas each index for employees is stored in its own index segment . Every database object that consumes storage consists of a single segment.
A tablespace is a database storage unit that contains one or more segments.
Each segment belongs to one and only one tablespace. Thus, all extents for a segment are stored in the same tablespace. Within a tablespace, a segment can include extents from multiple data files, as shown in the preceding graphic. For example, one extent for a segment may be stored in users01.dbf , while another is stored in users02.dbf . A single extent can never span data files.
Logical Space Management
Oracle Database must use logical space management to track and allocate the extents in a tablespace.
When a database object requires an extent, the database must have a method of finding and providing it. Similarly, when an object no longer requires an extent, the database must have a method of making the free extent available.
Oracle Database manages space within a tablespace based on the type that you create. You can create either of the following types of tablespaces:
Locally managed tablespaces (default)
The database uses bitmaps in the tablespaces themselves to manage extents. Thus, locally managed tablespaces have a part of the tablespace set aside for a bitmap. Within a tablespace, the database can manage segments with automatic segment space management (ASSM) or manual segment space management (MSSM).
The database uses the data dictionary to manage extents.
Figure 14-3 shows the alternatives for logical space management in a tablespace.
Figure 14-3 Logical Space Management
Locally Managed Tablespaces
A locally managed tablespace maintains a bitmap in the data file header to track free and used space in the data file body.
Each bit corresponds to a group of blocks. When space is allocated or freed, Oracle Database changes the bitmap values to reflect the new status of the blocks.
The following graphic is a conceptual representation of bitmap-managed storage. A 1 in the header refers to used space, whereas a 0 refers to free space.
Figure 14-4 Bitmap-Managed Storage
A locally managed tablespace has the following advantages:
Avoids using the data dictionary to manage extents
Recursive operations can occur in dictionary-managed tablespaces if consuming or releasing space in an extent results in another operation that consumes or releases space in a data dictionary table or undo segment.
Tracks adjacent free space automatically
In this way, the database eliminates the need to coalesce free extents.
Determines the size of locally managed extents automatically
Alternatively, all extents can have the same size in a locally managed tablespace and override object storage options.
Oracle strongly recommends the use of locally managed tablespaces with Automatic Segment Space Management.
Segment space management is an attribute inherited from the tablespace that contains the segment. Within a locally managed tablespace, the database can manage segments automatically or manually. For example, segments in tablespace users can be managed automatically while segments in tablespace tools are managed manually.
Automatic Segment Space Management
The automatic segment space management (ASSM) method uses bitmaps to manage space in a tablespace.
Bitmaps provide the following advantages:
ASSM avoids the need to manually determine correct settings for many storage parameters. Only one crucial SQL parameter controls space allocation: PCTFREE . This parameter specifies the percentage of space to be reserved in a block for future updates (see "Percentage of Free Space in Data Blocks" ).
Multiple transactions can search separate lists of free data blocks, thereby reducing contention and waits. For many standard workloads, application performance with ASSM is better than the performance of a well-tuned application that uses MSSM.
Dynamic affinity of space to instances in an Oracle Real Application Clusters (Oracle RAC) environment
ASSM is more efficient and is the default for permanent, locally managed tablespaces.
This chapter assumes the use of ASSM in all of its discussions of logical storage space.
Manual Segment Space Management
The legacy manual segment space management (MSSM) method uses a linked list called a free list to manage free space in the segment.
For a database object that has free space, a free list keeps track of blocks under the high water mark (HWM) (HWM), which is the dividing line between segment space that is used and not yet used. As blocks are used, the database puts blocks on or removes blocks from the free list as needed.
In addition to PCTFREE , MSSM requires you to control space allocation with SQL parameters such as PCTUSED , FREELISTS , and FREELIST GROUPS . PCTUSED sets the percentage of free space that must exist in a currently used block for the database to put it on the free list. For example, if you set PCTUSED to 40 in a CREATE TABLE statement, then you cannot insert rows into a block in the segment until less than 40% of the block space is used.
For example, suppose you insert a row into a table. The database checks a free list of the table for the first available block. If the row does not fit in the block, and if the used space in the block is greater than or equal to PCTUSED , then the database removes the block from the list and searches for another block. If you delete rows from the block, then the database checks whether used space in the block is now less than PCTUSED . If so, then the database places the block at the beginning of the free list.
An object may have multiple free lists. In this way, multiple sessions performing DML on a table can use different lists, which can reduce contention. Each database session uses only one free list for the duration of its session.
As shown in Figure 14-5, you can also create an object with one or more free list groups , which are collections of free lists. Each group has a master free list that manages the individual process free list in the group. Space overhead for free lists, especially for free list groups, can be significant.
Figure 14-5 Free List Groups
Managing segment space manually can be complex. You must adjust PCTFREE and PCTUSED to reduce row migration and avoid wasting space. For example, if every used block in a segment is half full, and if PCTUSED is 40 , then the database does not permit inserts into any of these blocks. Because of the difficulty of fine-tuning space allocation parameters, Oracle strongly recommends ASSM. In ASSM, PCTFREE determines whether a new row can be inserted into a block, but it does not use free lists and ignores PCTUSED .
Oracle Database Administrator’s Guide to learn about locally managed tablespaces
Oracle Database Administrator’s Guide to learn more about automatic segment space management
Oracle Database SQL Language Reference to learn about storage parameters such as PCTFREE and PCTUSED
Alert log и трассировочные файлы (trace file)
При работе базы данных события и ошибки регистрируются в текстовых файлах на сервере базы данных. Файл журнала предупреждений (alert log) нужен администратору базы данных для отслеживания важнейших действий с базой данных - наподобие открытия и закрытия базы данных, установления параметров загрузки базы данных и переключения оперативных журналов повтора. Также в эти файлы записываются многие ошибки базы данных для последующего расследования их причин. Любые структурные изменения базы данных также регистрируются в файле журнала предупреждений.
Когда возникает ошибка базы данных, может генерироваться файл трассировки (trace file). Они содержит подробную информацию о возникновении ошибки.
Читайте также: