Ответ таков: это зависит от того, как ваша компания определила свои правила табличного пространства.
Пользователи Oracle (или схемы) могут иметь одно «табличное пространство по умолчанию», которое вы можете увидеть, запросив базу данных:
select username, default_tablespace from dba_users;
или если у вас нет разрешения на это, и вы хотите знать, что это только для текущего пользователя:
select username, default_tablespace from user_users;
Или, возможно, это, чтобы увидеть всех пользователей, которые видны вашему текущему подключенному пользователю:
select username, default_tablespace from user_users;
Согласно документации Oracle (https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_8003.htm) вот что это значит:
Укажите табличное пространство по умолчанию для объектов, которые создает пользователь. Если вы опустите это предложение, то объекты пользователя будут храниться в табличном пространстве базы данных по умолчанию. Если для базы данных не указано табличное пространство по умолчанию, то объекты пользователя сохраняются в табличном пространстве SYSTEM.
Таким образом, для ваших намерений и целей, когда вы создаете таблицу без явного использования табличного пространства в конце, она вообще переходит в табличное пространство пользователя по умолчанию. Если ваши администраторы баз данных склонны не определять табличное пространство по умолчанию, это начинает иметь более серьезные последствия, потому что таблица будет храниться в глобальном табличном пространстве по умолчанию или (не дай бог) она перейдет в табличное пространство SYSTEM. Этот последний вариант был бы крайне вредным для здоровья базы данных.
Некоторые компании имеют привычку назначать разные табличные пространства, например, для таблиц и индексов. В этом случае у пользователей может быть только одно табличное пространство по умолчанию, и если вы опустите предложение табличного пространства в операторе создания индекса (или создания таблицы), объекты попадут в неправильное табличное пространство.
Теперь о последствиях наличия таблицы или индекса в неправильном табличном пространстве. Табличное пространство — это набор из одного или нескольких физических файлов операционной системы (Oracle называет их файлами данных). Всякий раз, когда вы создаете таблицу или индекс в табличном пространстве, оракул выделяет место в этом файле данных, который оракул называет сегментами. Сегменты — это логические единицы внутри файла данных. Имейте в виду, что Oracle далее разбивает сегменты на более мелкие логические единицы, называемые экстентами и блоками, но это немного выходит за рамки данной темы. Если вам интересно, здесь можно прочитать больше: https://docs.oracle.com/cd/B19306_01/server.102/b14220/logical.htm
Вернемся к сегментам. Сегменты существуют внутри файлов данных, принадлежащих табличным пространствам. Когда вы помещаете свой объект в табличное пространство и хотите переместить его в другое табличное пространство, Oracle необходимо физически записывать файлы в ОС. И это может быть просто, если таблица пуста, или может потребовать значительного объема работы, если речь идет о массивной таблице, охватывающей несколько файлов данных или содержащей гигабайты или терабайты данных. Это может означать, что для исправления требуется сбой приложения.
Oracle предоставляет определенные методы, чтобы избежать простоев приложений в таких сценариях, например, онлайн-переопределение (пакет DBMS_REDEFINITION). Но я надеюсь, что мы сможем согласиться с тем, что их использование может быть лучше использовано для миграции приложений и тому подобного.
Использование параметров табличного пространства по умолчанию во многих случаях допустимо, но, если вы мне позволите, эмпирическое правило для многих вещей Oracle заключается в том, что если вы можете написать код, который делает что-то явно, вместо того, чтобы полагаться на значения по умолчанию, сделайте сами и ваш DBA одолжение. В общем, гибкость полагаться на него превосходит даже пару раз, когда вы сталкиваетесь с сюрпризом, а затем несете ответственность за его очистку позже.
person
Francisco Sitja
schedule
04.07.2019