Segment creation immediate oracle что это
Обновлено: 04.07.2024
Типы табличных пространств (постоянные, временные и отката)
Основными типами табличных пространств в базах данных Oracle являются постоянные и временные табличные пространства, а также табличные пространства отката.
В постоянных табличных пространствах содержатся сегменты, существование которых не ограничено текущим сеансом или транзакцией.
Хотя табличные пространства отката также могут содержать сегменты, которые будут сохранены и после окончания сеанса или транзакции, они обеспечивают согласованность по чтению (read consistency) для операторов выборки данных (select), которые обращаются к модифицируемым таблицам, а также данные отката для значительного количества ретроспективных (flashback) возможностей базы данных. Однако главным назначением сегментов отката является сохранение старых значений модифицируемых (обновляемых и удаляемых) столбцов, или указание на то, что не существует строки для вставки, так что, если сеанс пользователя аварийно закончится еще до того, как пользователь задаст команду commit или rollback, все обновления, вставки или удаления будут автоматически отменены. Прямой доступ к сегментам отката из сеанса пользователя всегда запрещен, и в табличных пространствах отката могут содержаться только управляемые автоматически сегменты отката (undo segments).
Как следует из их названия, во временных табличных пространствах содержатся только переменные (динамические) данные (transient data), которые существуют исключительно во время сеанса, например дисковое пространство, необходимое для завершения операции сортировки, которая не умещается целиком в оперативной памяти.
Табличные пространства типа bigfile могут быть использованы для любого из трех упомянутых выше типов табличных пространств, и они упрощают управление табличными пространствами, перенося точку приложения усилий по сопровождению с файлов данных на табличные пространства. Табличные пространства тина bigfile состоят из одного и только одного файла данных.
Табличные пространства создаваемые в процессе стандартной инсталляции Oracle с использованием универсального инсталлятора Oracle (OUI).
SYSTEM
SYSAUX
TEMP
UNDOTBS1
USERS
EXAMPLE
Управление табличными пространствами и файлами данных
Управление табличными пространствами с помощью Oracle отличная идея, предполагающая соответствие простых старых файлов на диске хост-системы более абстрактному понятию пространства, в котором база данных Oracle может хранить информацию. То, что физический и логический компоненты отображаются совместно, является основой понимания материала.
SQL> select file_name, tablespace_name, bytes/1024/1024 as megs from dba_data_files;
Описание логической структуры базы данных
Три основных компонента мира логических дисковых ресурсов Oracle - табличные пространства, сегменты и экстенты. Табличное пространство (tablespace) логическая структура базы данных, предназначенная для хранения других логических структур базы данных. Oracle представляет табличное пространство как большую область пространства, в котором Oracle может размещать новые объекты. Место в табличных пространствах выделяется в сегментах.
Сегмент (segment) выделение пространства, используемого для хранения данных таблиц, индексов, сегментов отмены или временного объекта. Когда объект базы данных исчерпает пространство в своем сегменте, а ему потребуется добавить данные, Oracle позволяет выделить ему дополнительное пространство в форме экстента.
Экстент (extent) аналогичен сегменту в части хранения информации, относящейся к таблице, индексу, сегменту отмены или временному объекту.
Другая организация, представленная в базе данных Oracle, та, которая обеспечивается операционной системой хост-машины. В основе логической памяти в Oracle лежит физический метод, используемый хост-системой для хранения данных, краеугольным камнем которых является блок (block). Сегменты и экстенты состоят из блоков данных, а взятые вместе блоки, в свою очередь, содержат файл данных (datafile).
Значение параметра инициализации DB_BLICK_SIZE задается в байтах. Этот параметр определил стандартный размер каждого блока Oracle. Как правило, размер блока кратен размеру блока операционной системы. Блоки Oracle обычно раны 2, 4, 8 и иногда 16 Кбайт.
Табличное пространство может состоять из одного или многих файлов данных, а объекты табличного пространства Oracle может хранить где-нибудь в многочисленных файлах данных, составляющих табличное пространство. Хотя у табличного пространства может быть много файлов данных, каждый из них должен принадлежать только одному табличному пространству.
Как Oracle осуществляет управление местом в табличном пространстве
Управление свободным местом важная задача, так как без этого Oracle не знала бы, где размещать таблицы или индексы, когда вам потребуется создать и изменить их.
Начиная с версии Oracle8i, существует тип табличного пространства, называемый локально управляемым табличным пространством (locally managed tablespace). Локально управляемые табличные пространства используются для битовых массивов, которые хранятся в заголовках составляющих табличное пространство файлов данных, в целях отслеживания использования свободного пространства. Этот битовый массив представляет каждый блок в файле данных, а каждый бит в карте показывает, является этот блок свободным или нет.
Внутри табличных пространств Oracle управляет свободным пространством, объединяя его в непрерывные сегменты. Этим объединением в Oracle автоматически управляет системный монитор, или фоновый процесс SMON. При создании новых объектов базы данных, Oracle получает необходимый объем непрерывного пространства в памяти в виде сегмента для нового объекта. Объем используемого SMON пространства зависит от собственной конструкции объекта storage, от конструкции default storage для этого табличного пространства или от назначения однородного экстента, сконфигурированного для данного табличного пространства. SMON процесс, управляющий текущим объединением свободного пространства в непрерывные участки памяти во время работы таблицы словаря в табличное пространство SYSTEM, чтобы Oracle знала, где в управляемом словарем пространстве есть свободное место, или это поддерживает битовый массив в файлах данных табличного пространства, если используются локально управляемые табличные пространства.
Табличное пространство SYSTEM всегда управляемое словарем табличное пространство. Прочему? Поскольку файлы словаря в любом случае находятся в табличном пространстве SYSTEM, локально управляемое табличное пространство SYSTEM не сможет обеспечить достаточный рос производительности, если словать данных уже является локальным по отношению к табличному пространству!
Почему может потребоваться табличное пространство, управляемое локально, а не словарем? Локально управляемые табличные пространства предлагают более высокую производительность, потому что Oracle хранит информацию о памяти в заголовках файла и битовых массивах, устраняя рекурсивные операции, необходимые при выделении пространства под управлением словаря.
Начиная с Oracle9i для табличных пространств, за исключением табличного пространства SYSTEM, по умолчанию, задается локальное управление пространством. Однако можно явно указать, что вам требуется создать табличное пространство, управляемое словарем.
Постоянные табличные пространства и временные табличные пространства.
Независимо от конфигурации Oracle для управления пространством в табличном пространстве, само табличное пространство, как правило, конфигурируется для хранения двух типов сегментов: постоянного и временного. Постоянный сегмент предназначен для долговременного хранения данных таблицы или другого объекта. Например, если Oracle используется для управления информацией о сотрудниках в большой корпорации, вполне вероятно, что данные о сотрудниках будут находиться в базе данных, в течение многих месяцев или лет. Таким образом, для размещения таких данных в базе данных вы использовали бы постоянные сегменты. Продолжая рассуждать таким же образом, вы захотели бы поместить постоянные сегменты в постоянное табличное пространство. Так и есть в действительности, Oracle требует, чтобы постоянные сегменты находились в постоянных табличных пространствах.
Временные табличные пространства по умолчанию
DEFAULT TEMPORARY TABLESPACE tempTEMPFILE /u04/oradata/oracle/temp01.dbf SIZE 100M;
Создание табличного пространства
Исторически в Oracle табличное пространство SYSTEM было единственным табличным пространством, которое можно было создать во время создания базы данных. Это делалось в явном виде; определялось местоположение файла данных табличного пространства SYSTEM в команде create database. Все это можно делать и до сих пор, но начиная с Oracle9i одновременно можно создавать два других типа табличных пространств. Мы уже рассматривали пример, где в команде create database создавалось временное табличное пространство по умолчанию. Другой пример табличное пространство сегмента отмены. Тем, кто переходит на Oracle, имея опыт работы администратором в предыдущих версиях Oracle, следует учесть, что отмена (undo) то же самое, что откат (rollback). В Oracle 9i, при создании базы данных можно создать следующие табличные пространства: SYSTEM, временное и UNDOTDS.
Какие табличные пространства могут понадобиться?
В типовой базе данных может потребоваться разнести различные типы данных по разным табличным пространствам. Как правило, создается следующий минимальный набор табличных пространств:
SYSTEM - Каждая база данных должна иметь табличное пространство SYSTEM. Оно создается во время создания базы данных.
DATA - табличное пространство DATA используется для размещения данных таблиц.
INDEX - табличное пространство INDEX используется для размещения индексов отдельно от других типов объектов.
UNDOTBS - табличное пространство UNDOTBS содержит сегменты отмены (в предыдущих версиях Oracle они назывались сегментами отката). Их нужно хранить отдельно от других типов объектов иза непостоянства назначения экстентов.
TEMP табличное пространство TEMP содержит временные сегменты. Их также следует хранить отдельно от других типов объектов из-за непостоянства назначения экстентов.
TOOLS табличное пространство TOOLS содержит объекты, поддерживающие административные или другие инструментальные средства, которые могут применяться вместе с базой данных, например Oracle Enterprise Manager.
Создание табличного пространства для хранения постоянных сегментов
Все дополнительные табличные пространства должны создаваться с помощью команды create tablespace после создания базы данных.Рассмотрим пример создания локально управляемого табличного пространства для хранения табличных данных в базе данных, работающей под Windows. Откуда может быть известно, что в этом табличном пространстве будут содержаться данные таблицы? Из-за спецификации обратите внимание на имя табличного пространства DATA. Как правило, это говорит о том, что табличное пространство будет использоваться для хранения данных таблицы. А теперь рассмотрим саму команду:
SQL>CREATE TABLESPACE DATA DATAFILEE:\oradata\oracle\data01.dat SIZE 20M,
F:\oradata\oracle\data01.dat SIZE 30M,
AUTOOEXTEND ON NEXT 10M MAXSIZE 50M
MINIMUM EXTENT 150K
EXTENT MANAGEMENT LOCAL
PERMANENT ONLINE;
На создание табличного пространства может потребоваться довольно много времени, в зависимости от задаваемого размера файлов данных табличного пространства. Причина в том, что Oracle должна физически назначить себя файлу любого размера, задаваемого вами в хост-системе. Эта операция требует терпения, особенно если задано очень большое табличное пространство.
Как видим, в команде create tablespace существует несколько компонентов. Сначала с помощью абсолютных имен путей определяются файлы данных табличного пространства. Учтите, что в одном из файлов данных для этого определена фраза autoextend. Это свойство позволяет файлу данных автоматически выходить за пределы первоначально определенного размера, чтобы соответствовать росту данных.
На следующем шаге необходимо определить фразу default storage, чтобы задать применяемые к созданию объекта базы данных опции, если для созданного объекта не определены параметры памяти. Если для помещенного в это табличное пространство объекта задана своя собственная фраза storage, то настройки фразы storage объекта отменят заданные по умолчанию настройки фразы storage табличного пространства за одним исключением. Существует одна опция памяти, которую нельзя отменить, если она определена в табличном пространстве. Это опция minimum extent - обеспечивает кратность каждого используемого в табличном пространстве размера экстента целочисленному значению. Вскоре мы рассмотрим параметры default storage более подробно.
Постоянные табличные пространства, аналогичные созданным в предыдущем блоке кода, могут содержать постоянные и временные сегменты. Эта функциональная возможность обеспечивается Oracle для обратной совместимости. Однако вам следует помещать временные сегменты во временные табличные пространства.
Обратите также внимание на то, что фраза extent management local позволяет определить это табличное пространство как локально управляемое. В версиях Oracle9i и выше, эта настройка управления пространством для табличного пространства задается по умолчанию, поэтому нет необходимости указывать эту фразу, чтобы задать локальное управлении экстентом. Если бы потребовалось определить табличные пространства, управляемые словарем, вместо этого мы воспользовались бы фразой extent management dictionary. Можно указать, что табличное пространство содержит постоянные объекты базы с помощью ключевого слова permanent; однако Oracle предполагает, что табличное пространство является постоянным, даже если ключевое слово permanent опущено. И наконец, ключевое слово online дает Oracle указание перевести созданное табличное пространство в оперативных режим. Оперативное (online) это задаваемое по умолчанию состояние созданного табличного пространства. Если в команде create tablespace ключевое слово online опущено, табличное пространство все равно будет оперативным. Впоследствии его также можно сделать оперативным, введя команду alter tablespace name online.
Если в команде create tablespace нет никаких указаний на локальное управление или управление словарем. Oracle9i создаст его как локально управляемое табличное пространство.
Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd. Перевод: zCarot
Картинка для придания нужного настроения
Доброго времени суток!
В интернете вообще и на Хабре в частности немало публикаций о ремонте битых блоков. Например, здесь о выдергивании неповрежденных данных, а тут история победы над битым LOB сегментом.
Приводить легионы ссылок на инет с подобными статьями не буду. Но есть в большинстве этих статей общая черта. Когда данные спасены (или уничтожены, как получится), предлагается победить поврежденный free block захватом всего свободного места в tablespace. И почему то это предложение описательно.
Так добавим конкретики!
Напишем скрипт, который скушает (почти как рыбки на картинке), а потом освободит всё свободное место Oracle DB.
Подготовительная часть.
Посмотрели на наши битые блоки:
Убедились, что они есть.
Посмотрели точно ли все наши блоки «free»(вдруг еще один сломанный сегмент затерялся?):
Не забудем отключить autoextend для всех файлов нашего TS с битыми free блоками. Последствия забывчивости могут оказаться не очень приятными.
Да, «сжать» файлы обратно можно успеть. Но зачем нам лишние проблемы?
Получили список команд. Запустили их. Потом таким же образом сформируем список команд, которые вернут autoextend.
Но здесь надо быть внимательным. Может датафайлы располагаются на разных дисках? И у них разные настройки расширения? Здесь стоит быть аккуратнее.
(Да, моя специальность «Специалист SAP BASIS». Этим и объясняется выбор имени для tablespace. Ведь ошибки я вынужден чинить именно там.)
И только теперь, когда подготовительные шаги завершены.
Основная часть
Для работы с Oracle sql я использую SQL Developer. В нем есть все что нужно, и не наблюдается того, что не нужно.
Чего мы хотим?
Переформатировать все свободные блоки tablespace. Для этого будем создавать таблицы, и добавлять им экстенты пока место не закончится.
Вот такой скриптик PL\SQL нормально делает то, что нам нужно.
(Прошу обратить внимание на два лишних слеша "\". В строках с «create table» и «drop table». Они для того, чтобы выделение цветом не ехало. Перед боевым использованием их надо снести. А менять кавычки на другие я не хочу. Очень раздражает последующее выискивание «неверных».)
Опять же, заданные константы TABLESPACE_FOR_FULL и USER_SCHEMA как бы намекают на специфику моих баз.
Комментировать алгоритм работы мне видится излишним.
Скорость работы такой методы меня устраивает.
Чуть менее 100Gb за 3 минуты. Ясно, что оборудование играет очень большую роль, но там где оборудование слабое и размеров особых не будет. Тем более что Tb свободного места достаточно странная ситуация.
Завершающие шаги
Теперь вернув autoextend можно заняться проверкой базы.
После чего представление v$database_block_corruption должно быть чистым как… ну вы поняли.
В ходе выполнения лабораторных работ по дисциплине «СУБД» необходимо освоить основные операции для работы с такими СУБД как MSSQLиORACLE.
Темой для выполнения последующих лабораторных работ будет: «Распределение учебной нагрузки».
Необходимо распределять нагрузку между преподавателями кафедры. Имеются сведения о преподавателях, включающие наряду с анкетными данными сведения об их ученой степени, занимаемой должности и стаже работы. Преподаватели кафедры должны обеспечить проведение занятий по некоторым дисциплинам. По каждой из них существует определенное количество часов. В результате распределения нагрузки необходимо получить информацию следующего рода: «Такой-то преподаватель проводит занятия по такой-то дисциплине с такой-то группой».Все проводимые занятия делятся на лекционные и практические. По каждому виду занятий устанавливается свое количество часов. Кроме того данные по нагрузке нужно хранить несколько лет.
Лабораторная работа №1
Проектирование базы данных с использованием ER-технологии
Построение ER-диаграммы
Определим основные сущности: Преподаватели, Группы, Предметы и Нагрузка, которая будет соединять неидентифицирующими связями мощностью «один-ко-многим».
Графическое представление (IDEF1X)
Все поля таблицы Нагрузка, кроме Year, должны быть обязательно снабжены атрибутом not null, т. к. при распределении нагрузки вся информация должна быть занесена в таблицу.
Все внешние ключи (FK) созданы с правилом каскадного удаления и обновления. При этом обновление дочерней таблицы вызовет автоматическое обновление родительской таблицы.
Лабораторная работа №2
Создание и связывание таблиц базы данных
С официального сайта было установлено ПО MicrosoftSQLServer2012. После установки необходимых компонентов в графическом режиме была создана база данных с названиемLoad_distribution.
Затем в окне создания запросов выполним скрипт:
SET QUOTED_IDENTIFIER ON
SET ARITHABORT ON
SET NUMERIC_ROUNDABORT OFF
SET CONCAT_NULL_YIELDS_NULL ON
SET ANSI_NULLS ON
SET ANSI_PADDING ON
SET ANSI_WARNINGS ON
CREATE TABLE [dbo].[Teachers](
[Id_teacher] [int] NOT NULL,
[Surname] [nchar](20) NULL,
[Name] [nchar](20) NULL,
[Patronymic] [nchar](20) NULL,
[Post] [nchar](20) NULL,
[Date_of_hiring] [date] NULL,
CONSTRAINT [PK_Teachers] PRIMARY KEY CLUSTERED
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
SET QUOTED_IDENTIFIER ON
SET ARITHABORT ON
SET NUMERIC_ROUNDABORT OFF
SET CONCAT_NULL_YIELDS_NULL ON
SET ANSI_NULLS ON
SET ANSI_PADDING ON
SET ANSI_WARNINGS ON
CREATE TABLE [dbo].[Disciplines](
[Id_discipline] [int] NOT NULL,
[Hours_of_practice] [time](7) NULL,
[Hours_of_lectures] [time](7) NULL,
[Discipline] [ntext] NULL,
CONSTRAINT [PK_Disciplines] PRIMARY KEY CLUSTERED
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
SET QUOTED_IDENTIFIER ON
SET ARITHABORT ON
SET NUMERIC_ROUNDABORT OFF
SET CONCAT_NULL_YIELDS_NULL ON
SET ANSI_NULLS ON
SET ANSI_PADDING ON
SET ANSI_WARNINGS ON
CREATE TABLE [dbo].[Groups](
[Id_group] [int] NOT NULL,
[Name_group] [ntext] NULL,
CONSTRAINT [PK_Groups] PRIMARY KEY CLUSTERED
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
SET QUOTED_IDENTIFIER ON
SET ARITHABORT ON
SET NUMERIC_ROUNDABORT OFF
SET CONCAT_NULL_YIELDS_NULL ON
SET ANSI_NULLS ON
SET ANSI_PADDING ON
SET ANSI_WARNINGS ON
CREATE TABLE [dbo].[Load](
[Id_load] [int] NOT NULL,
[Id_teacher] [int] NOT NULL,
[Id_group] [int] NOT NULL,
[Id_discipline] [int] NOT NULL,
CONSTRAINT [PK_Load] PRIMARY KEY CLUSTERED
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
ALTER TABLE [dbo].[Load] WITH CHECK ADD CONSTRAINT [FK_Load_Disciplines] FOREIGN KEY([Id_discipline])
REFERENCES [dbo].[Disciplines] ([Id_discipline])
ALTER TABLE [dbo].[Load] CHECK CONSTRAINT [FK_Load_Disciplines]
ALTER TABLE [dbo].[Load] WITH CHECK ADD CONSTRAINT [FK_Load_Groups] FOREIGN KEY([Id_group])
REFERENCES [dbo].[Groups] ([Id_group])
ALTER TABLE [dbo].[Load] CHECK CONSTRAINT [FK_Load_Groups]
ALTER TABLE [dbo].[Load] WITH CHECK ADD CONSTRAINT [FK_Load_Teachers] FOREIGN KEY([Id_teacher])
REFERENCES [dbo].[Teachers] ([Id_teacher])
ALTER TABLE [dbo].[Load] CHECK CONSTRAINT [FK_Load_Teachers]
Теперь созданы таблицы с первичными ключами и связями между ними в базе данных.
С официального сайта было установлено ПО OracleDatabase11gExpressEditionиSQLDepeloper(удобное средство для разработчика). После установки необходимых компонентов в графическом режиме было создано новое соединение и пользовательAdmin с определенными правами.
Создать таблицы можно, запустив этот скрипт:
CREATE TABLE "ROOT"."DISCIPLINES"
( "ID_DISCIPLINE" NUMBER(*,0) NOT NULL ENABLE,
"DISCIPLINE" VARCHAR2(50 CHAR),
CONSTRAINT "DISCIPLINES_PK" PRIMARY KEY ("ID_DISCIPLINE")
USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
TABLESPACE "USERS" ENABLE
) SEGMENT CREATION IMMEDIATE
PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
CREATE TABLE "ROOT"."GROUPS"
( "ID_GROUP" NUMBER(*,0) NOT NULL ENABLE,
"NAME_GROUP" VARCHAR2(50 CHAR),
CONSTRAINT "GROUPS_PK" PRIMARY KEY ("ID_GROUP")
USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
TABLESPACE "USERS" ENABLE
) SEGMENT CREATION IMMEDIATE
PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
CREATE TABLE "ROOT"."LOAD"
( "ID_LOAD" NUMBER(*,0) NOT NULL ENABLE,
"ID_TEACHER" NUMBER(*,0) NOT NULL ENABLE,
"ID_GROUP" NUMBER(*,0) NOT NULL ENABLE,
"ID_DISCIPLINE" NUMBER(*,0) NOT NULL ENABLE,
CONSTRAINT "LOAD_PK" PRIMARY KEY ("ID_LOAD")
USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
TABLESPACE "USERS" ENABLE,
CONSTRAINT "ID_DISCIPLENE" FOREIGN KEY ("ID_DISCIPLINE")
REFERENCES "ROOT"."DISCIPLINES" ("ID_DISCIPLINE") ENABLE,
CONSTRAINT "ID_GROUP" FOREIGN KEY ("ID_GROUP")
REFERENCES "ROOT"."GROUPS" ("ID_GROUP") ENABLE,
CONSTRAINT "ID_TEACHER" FOREIGN KEY ("ID_TEACHER")
REFERENCES "ROOT"."TEACHER" ("ID_TEACHER") ENABLE
) SEGMENT CREATION IMMEDIATE
PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
CREATE TABLE "ROOT"."TEACHER"
( "ID_TEACHER" NUMBER(*,0) NOT NULL ENABLE,
"SURNAME" VARCHAR2(50 CHAR),
"NAME" VARCHAR2(50 CHAR),
"PATRONYMIC" VARCHAR2(50 CHAR),
"POST" VARCHAR2(50 CHAR),
CONSTRAINT "TEACHER_PK" PRIMARY KEY ("ID_TEACHER")
USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
TABLESPACE "USERS" ENABLE
) SEGMENT CREATION IMMEDIATE
PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
Администраторы баз данных Oracle создают и управляют объектами схем, включая таблицы, индексы, представления, материализованные представления, синонимы, триггеры, ссылки на базы данных и т.д. Однако прежде чем рассматривать различные объекты схем, следует посмотреть, как управлять важнейшими табличными пространствами Oracle. Табличные пространства — это логические сущности, и каждая из прикладных таблиц и индексов хранятся в сегменте, в то время как сегменты хранятся в файлах данных, являющихся частью табличного пространства. Таким образом, табличное пространство - это логически веденное пространство для размещения объектов схемы Oracle. Однако не существует отношения “один к одному” между объектами схемы вроде таблицы или индекса и табличным пространством.
Когда вы используете словосочетание табличное пространство, то на самом деле имеете в виду непрерывное табличное пространство — место, где хранятся объекты вашей схемы. (Если вы перешли от базы данных выпуска, предшествовавшего Oracle Database 10g, то сначала потребуется создать табличное пространство Sysaux). Все постоянные табличные пространства создаются с использованием файлов данных Oracle. В дополнение к постоянным табличным пространствам существуют следующие важные типы табличных пространств Oracle.
-
служат для хранения объектов, существующих на протяжении существования пользовательского сеанса. Вы используете временные файлы вместо файлов данных для создания временного табличного пространства.
- Табличные пространства отмены (undo) — разновидность постоянных табличных пространств, служащих для хранения данных отмены, которые используются для возврата измененных данных в исходное состояние.
Каждое табличное пространство Oracle должно иметь обязательные табличные пространства System и Sysaux. Табличное пространство System является постоянным и содержит важнейшую информацию словаря, которая помогает работе базы данных. Табличное пространство System — это первое табличное пространство, которое вы создаете при создании новой базы данных. Табличное пространство Sysaux дополняет табличное пространство System, храня метаданные для различных приложений Oracle,а также оперативные данные для внутренних инструментов управления производительностью вроде Automatic Workload Repository. Табличные пространства System и Sysaux трактуется иначе, чем другие табличные пространства. Ни одно из них нельзя переименовывать либо удалять.
Прежде чем создать таблицы или индексы, вы должны создать табличные пространства для хранения данных. Табличные пространства состоят из одного или более файлов данных (или временных файлов, если речь идет о временном табличном пространстве). Хотя ваши данные и объекты располагаются в файлах операционной системы,организация этих файлов в табличные пространства Oracle облегчает группировку взаимосвязанной информации.
Сначала нужно убедиться, что у вас создана необходимая структура каталогов на принимающей системе, чтобы можно было создавать файлы данных. Oracle отформатирует файлы операционной системы и назначит их табличным пространствам, когда вы укажете размер файлов данных с полностью специфицированными именами при создании табличного пространства.
На заметку! Табличные пространства не уникальны для Oracle. СУБД DB2 также имеет табличные пространства, а вот базы данных Microsoft SQL Server их не используют. База данных tempdb в СУБД SQL Server соответствует временному табличному пространству в Oracle.
Установка размера экстента табличного пространства и управление пространством
Прежде чем вы в действительности создадите табличное пространство, следует разобраться в двух других важных концепциях: установке размеров экстента (extent sizing) и управлении пространством сегмента (segment space management).
Выделение размера экстента: AUTOALLOCATE или UNIFORM
Всякий раз, когда объект Oracle нуждается в увеличении своего размера, дополнительное место добавляется ему в виде экстентов. Когда вы создаете локально управляемые табличные пространства, то есть два варианта управления размерами экстентов: можно позволить базе данных автоматически выбирать размер экстента (указав опцию AUTOALLOCATE) или же специфицировать для табличного пространства добавление экстентов унифицированного размера (опция UNIFORM).
Если выбрана опция UNIFORM, потребуется специфицировать конкретное значение размера новых экстентов в конструкции SIZE. Если вы пропустите конструкцию SIZE,то Oracle будет создавать все экстенты с унифицированным размером в 1 Мбайт, но при желании можно указать и намного большее значение.
Однажды создав табличное пространство, вы не можете изменить размер экстента. Если вы полагаете, что все сегменты в табличном пространстве будут примерно одного размера, и они будут расти сходным образом, можете применить опцию размера экстента UNIFORM. И если вы поступите так, то сможете выбрать несколько размеров экстентов, создать все табличные пространства с одним из этих размеров и размещать объекты в табличных пространствах на основе их размера.
Традиционно администраторы баз данных Oracle беспокоятся о количестве экстентов в сегменте. Вы должны более внимательно относиться к выбору размера экстентов, поскольку это влияет на производительность чтения и записи в сегменте.
Например, если выбран очень маленький размер экстента UNIFORM, база данных не сможет выполнять упреждающее чтение данных либо многоблочное чтение, что плохо отразится на производительности. Oracle рекомендует следующие размеры экстентов, если вы решите устанавливать их самостоятельно:
- 64 Кбайт — для малых сегментов;
- 1 Мбайт — для средних сегментов;
- 64 Мбайт — для крупных сегментов.
При выборе опции AUTOALLOCATE Oracle управляет размером экстентов автоматически. Размер экстента начинается с 64 Кбайт и увеличивается базой данных прогрессивно до 64 Мбайт. База данных автоматически решает, каким должен быть размер нового экстента для объекта — на основе шаблона расширения экстента. Интересно, что Oracle в этом случае увеличивает размер экстента с ростом объекта! Автоматическое выделение особенно удобно, если вы не представляете коэффициента роста объекта и предоставляете Oracle право позаботиться об этом.
На заметку! По умолчанию для управления экстентами табличного пространства выбирается опция AUTOALLOCATE.
Если вы точно знаете потребности в пространстве для ваших объектов, можете выбрать опцию экстентов UNIFORM, что позволит эффективно использовать доступное пространство. Например, предположим, известно, что ваши крупнейшие таблицы потребуют большого пространства, и потому будут иметь очень большой размер экстента. Создавайте для них табличное пространство с очень большим унифицированным размером экстента.
Если вы не уверены в том, какой размер экстента будет наилучшим, то AUTOALLOCATE позволит базе данных определить размер экстента, но при этом она может впустую потратить некоторое пространство ввиду переменной величины экстентов.
Совет. Oracle рекомендует, что если только все объекты в табличном пространстве не имеют один и тот же размер, следует использовать AUTOALLOCATE. В дополнение к простоте управления опция AUTOALLOCATE для размеров экстентов может потенциально сэкономить существенный объем дискового пространства по сравнению с опцией UNIFORM.
Сравнение автоматического и ручного управления пространством сегментов
Пространство в блоке Oracle можно использовать в двух целях: для вставки свежих данных либо для обновления существующих данных в блоках. Когда вы удаляете данные из блока или обновляете их, изменяя размер данных в меньшую сторону, в блоке увеличивается свободное пространство. Управление пространством сегментов определяет то, как Oracle управляет свободным пространством внутри индивидуальных блоков данных Oracle.
Если вы специфицируете ручное управление размерами сегментов (посредством ключевого слова MANUAL), то база данных управляет свободным пространством сегментов в табличном пространстве, используя сущности, называемые свободными списками (freelists), и пары параметров хранения — PCTFREE и PCTUSED. Oracle отслеживает наличие свободного пространства в блоках данных, поддерживая свободные списки. Каждая таблица или индекс поддерживает список всех своих блоков данных, размер которых превышает PCTUSED. То есть свободные списки содержат список всех блоков, пригодных для вставки данных. Сначала Oracle проверяет соответствующий свободный список, прежде чем выполнить вставку в таблицы или индексы. База данных Oracle вынуждена выполнять много работы по поддержанию свободных списков, по мере того, как блоки достигают порогового значения PCTUSED при вставке и возвращаются к значениям ниже порогового при удалении.
Параметр PCTFREE позволяет резервировать определенный процент пространства в каждом блоке данных для будущих обновлений существующих данных. Например, в некотором блоке могут быть данные, содержащие адрес лица. Если позднее вы обновите этот адрес так, что он станет больше, то в идеале в существующем блоке должно быть место, чтобы вместить увеличенный адрес. Именно это и обеспечивает параметр PCTFREE: место для роста существующих строк. Параметр PCTUSED, с другой стороны,имеет дело с пороговым значением свободного пространства, превышение которого позволит вставлять новые данные в блок. Например, если параметр PCTFREE установлен в 40%, Oracle не сможет вставлять новые данные в блок до тех пор, пока объем занятого пространства не упадет ниже порогового значения.
Вы можете легко увидеть, как параметры PCTFREE и PCTUSED вместе позволяют оптимизировать использование пространства внутри блока Oracle. Предположим, что 80% пространства в блоке занято данными. Это будет максимальным объемом данных, которые вы сможете вставить внутрь блока, если параметр PCTFREE установлен в значение 20%. Если в блоке произойдут какие-то удаления, появится место для потенциальной вставки новых строк, однако Oracle применяет параметр PCTUSED интеллектуальным образом, не позволяя использовать немедленно любое освободившееся пространство для новых вставок. Попытки Oracle воспользоваться свободным пространством в блоках данных сопряжены с накладными расходами, поэтому Oracle ждет, пока использованное пространство не упадет ниже установки PCTUSED, прежде чем задействовать его.Поэтому, даже несмотря на то, что может быть свободное пространство в частично занятых блоках, Oracle игнорирует их и применяет для вставки данных новые блоки.
Параметры PCTFREE и PCTUSED вместе со свободными списками представляют собой ручной способ проверки пространства, поскольку вы заставляете Oracle непрерывно проверять блоки на наличие достаточного свободного пространства. В базе данных с интенсивными обновлениями, вставками и удалениями это может привести к замедлению транзакций.
Если вы предпочтете автоматическое управления пространством сегментов при создании табличного пространства (указав значение AUTO), то база данных использует битовые карты (bitmaps) для отслеживания доступного свободного пространства в сегменте. Битовая карта, которая содержится в специальном блоке, указывает, составляет ли свободное пространство в блоке объем менее 25%, либо между 25 и 50%, между 50 и 75% или же свыше 75%. Для индексного блока битовая карта может сообщить, является блок пустым или форматированным.
Переход от табличных пространств, управляемых словарем, к локально управляемым табличным пространствам
Хотя локально управляемые табличные пространства являются стандартными для выпуска Oracle Database 11g, если вы переходите к этому выпуску от более старых версий, то можете перевести свои табличные пространства из управляемых словарем к локально управляемым. Для этого нужно просто создать новые табличные пространства, которые будут по умолчанию локально управляемыми, и затем перенести все таблицы в новое табличное пространство командой ALTER TABLE, как показано ниже:
Чтобы перенести индексы, используйте команду ALTER INDEX REBUILD, как показано ниже:
Завершив миграцию всех объектов в новые локально управляемые табличные пространства, удалите старые табличные пространства, чтобы освободить занимаемое ими место.Если вы не хотите создавать новые табличные пространства или боитесь сложностей переноса всех таблиц и индексов, можете прибегнуть к PL/SQL-пакету DBMS_SPACE_ADMIN, который позволит выполнить миграцию имеющихся табличных пространств. Сначала потребуется выполнить миграцию к локально управляемым всех табличных пространств кроме System, а затем перевести в локально управляемые табличное пространство System. Если вы поступите наоборот, то все прочие табличные пространства станут доступными только для чтения. Не забудьте перед миграцией создать резервную копию базы данных. Ниже приведен пример переноса управляемого словарем табличного пространства (USERS) в локально управляемое табличное пространство:
Процедура TABLESPACE_MIGRATE_TO_LOCAL может быть использована в оперативном режиме, пока пользователи занимаются выборкой и модификацией данных. Однако если некоторые операции DML нуждаются в выделении новых экстентов, они будут блокированы до окончания миграции.
После перевода всех рабочих табличных пространств в локально управляемые можно перевести табличное пространство System. Ниже показана команда (предварительно потребуется выполнить некоторую черновую работу вроде переключения прочих табличных пространств в режим доступа только для чтения и т.п.):
Обратите внимание, что если вы применяете пакет DBMS_SPACE_ADMIN для миграции от управляемых словарем к локально управляемым табличным пространствам, то не имеете возможности переключения на использование нового средства автоматического управления пространством сегментов (Automatic Segment Space Management). Все управляемые словарем табличные пространства используют по умолчанию старое ручное управления пространством сегментов, и вы не можете изменить его на автоматическое, когда переходите на локально управляемые табличные пространства. Поскольку автоматическое управление пространством сегментов предоставляет много преимуществ (вроде возможности использования онлайнового сжатия сегментов из Segment Advisor), вероятно лучше убить двух зайцев и запланировать перевод всех объектов во вновь созданные локально управляемые табличные пространства. По умолчанию Oracle создает все новые табличные пространства как локально управляемые с автоматическим управлением пространством сегментов.
Вдобавок, если ваши текущие управляемые словарем табличные пространства имеют проблему фрагментации свободного места, эта проблема не исчезнет, когда вы преобразуете их в локально управляемые табличные пространства посредством миграции “по месту” с помощью пакета DBMS_SPACE_ADMIN. В этом случае лучше создать новое локально управляемое табличное пространство и переместить необходимые объекты в него. Далее в блоге будет показано, как легко выполнить эту миграцию с помощью средств онлайновой реорганизации таблиц Oracle.
Oracle рекомендует использовать автоматическое управление сегментами и отмечает, что оно как масштабируемо, так и эффективно, когда речь идет об управлении пространством. Особенно заметен выигрыш в производительности, если объекты базы данных имеют строки различного размера. Поддержка этих битовых карт требует дополнительного места, однако оно составляет не более 1% от размера самых крупных объектов.
На заметку! Управление пространством сегментов, которое специфицируется во время создания табличного пространства, применяется ко всем сегментам, создаваемым позднее в этом табличном пространстве.
Читайте также: