Изменение первичного ключа - PullRequest
Новая
       5

Изменение первичного ключа

3 голосов
/ 01 ноября 2011

Я видел 2 подхода для изменения первичного ключа. подход 1, это то, в чем я удаляю первичный ключ (он также удаляет соответствующий индекс), а затем создаю первичный ключ с новым индексом, в котором, например, 

alter table TABLE_NAME drop constraint PK_TABLE_NAME drop index;
alter table TABLE_NAME
add constraint PK_TABLE_NAME PRIMARY KEY ("COL1") 
  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) 
  TABLESPACE "USERS" ENABLE;
COMMIT;
/

Второй подход заключается в индивидуальном выполнении всех шагов, т. Е. 

alter table TABLE_NAME drop constraint PK_TABLE_NAME;
drop index PK_TABLE_NAME;

CREATE UNIQUE INDEX PK_TABLE_NAME ON TABLE_NAME
(COL1)
LOGGING
TABLESPACE USERS
PCTFREE    10
INITRANS   2
MAXTRANS   255
STORAGE    (
            INITIAL          64K
            MINEXTENTS       1
            MAXEXTENTS       UNLIMITED
            PCTINCREASE      0
            BUFFER_POOL      DEFAULT
            FLASH_CACHE      DEFAULT
            CELL_FLASH_CACHE DEFAULT
           )
NOPARALLEL;

alter table TABLE_NAME add constraint PK_TABLE_NAME PRIMARY KEY ("COL1") USING INDEX PK_TABLE_NAME;
COMMIT;
/

Так что теперь мои вопросы

  1. у этих двух подходов есть что-то другое в бэкэнде, кроме того, что шаги разделены?
  2. Я вижу, что мы можем упомянуть имя столбца с кавычками, т.е. "COL1" или без кавычек, т.е. COL1 . Эти 2 подхода будут иметь какое-либо значение?
  3. Учитывая, что эти шаги выполняются для таблицы, в которой есть TRILLION OF DATA, какой-нибудь из них дает выигрыш в производительности по сравнению с другим?

1 Ответ

2 голосов
/ 01 ноября 2011

С DDL точно так же, как у вас, насколько я знаю, между ними нет никакой разницы. (Это основано на сравнении select dbms_metadata.get_ddl('TABLE', 'TABLE_NAME') from dual;, некоторых простых тестах производительности и моем предыдущем опыте работы с этими двумя подходами.)

Но если у вас триллионы строк или байтов, то вам, вероятно, следует использовать параллелизм, и тогда будет существенная разница. Первый подход не позволяет вам создавать индекс параллельно (ORA-03001: unimplemented feature), но второй метод делает. Даже если вы не хотите, чтобы индекс был параллельным, вам, вероятно, следует создать его параллельно, а затем изменить его на noparallel.

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

Несколько других заметок. Вы можете рассмотреть возможность использования NOLOGGING. И COMMIT; не требуется, DDL автоматически вызывает коммит.

...