Oracle 19cのDDLとは｜CREATE・ALTER・DROPと暗黙COMMITの注意点

DDL（Data Definition Language）は、表・索引・ビューなどの定義を作成・変更・削除するSQLです。このページはOracle Database 19cを基準に、基本構文と、DDLを実行すると未確定のDMLまでコミットされる注意点を説明します。他製品の例は比較として分けています。

目的の子ページを選ぶ

詳しい操作は次の子ページから選択してください。

リンク先にも他製品の比較があるため、各例の製品名を確認してください。特にTRUNCATEや索引の運用上の注意は、Oracle 19cの公式仕様と照合して使います。

図は通常の永続オブジェクトへのDDLの境界です。DDL自体の失敗と、先行DMLの取消を混同しません。private temporary tableの作成やTRUNCATEの例外は「トランザクション中の DDL の挙動」で区別します。

DDL とは

OracleのSQL Language ReferenceではGRANT / REVOKEもDDLに含みます。「DCLだからDDLのコミット規則とは無関係」と考えないでください。DDLの対象には、表・索引・ビューのほか、シーケンス、ユーザー、プロシージャ、関数、トリガーなどがあります。Oracle 19c: SQL文の分類

主要 DDL コマンド一覧

この一覧の構文はOracle 19c用です。既存の同名オブジェクトや依存関係を確認し、DROP / TRUNCATEを実行する操作一覧ではありません。

CREATE TABLE: テーブル定義の基本

以下は構文を読むための例です。使い捨ての練習用スキーマを想定し、既存の業務表に貼り付けません。Oracle 19cのSQLは公式資料との照合のみで、Oracle実DBでの実行確認はしていません。

CREATE TABLE users (
    id         NUMBER PRIMARY KEY,
    name       VARCHAR2(100) NOT NULL,
    email      VARCHAR2(255) UNIQUE,
    created_at DATE DEFAULT SYSDATE
);

id NUMBER PRIMARY KEYだけでは自動採番されません。Oracle 19cではidentity列も使えるため、「Oracleは必ず自作シーケンスが必要」ではありません。次は上の表とは別の作成例です。Oracle 19c: CREATE TABLE / identity_clause

CREATE TABLE users_identity_demo (
    id NUMBER GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
    name VARCHAR2(100) NOT NULL
);

カラム定義の主な属性

次表は属性の比較一覧です。VARCHAR / BIGINT / AUTO_INCREMENT等を使うMySQLの例を含みます。Oracleの表定義は直前のNUMBER / VARCHAR2の例、採番は別のidentity例を参照します。

DEFAULTは制約の種類そのものではなく、列の既定値です。Oracleの外部キーは、削除時にON DELETE CASCADEまたはON DELETE SET NULLを指定でき、省略時は参照を壊す親行の削除を拒否します。MySQLのON UPDATE CASCADEをそのまま移植できません。Oracle 19c: constraint

列の追加・変更・名前変更

個々の操作を示す例です。名前変更後はアプリやビューなどの利用側も確認します。型やNULL条件の変更は既存値によって失敗することがあり、列の削除と再追加では元の値は戻りません。

ALTER TABLE users ADD age NUMBER;
ALTER TABLE users MODIFY name VARCHAR2(200);
ALTER TABLE users RENAME COLUMN name TO full_name;

不要な列を削除する構文は次です。削除した列のデータはROLLBACKで戻せません。Oracle 19c: ALTER TABLE

ALTER TABLE users DROP COLUMN age;

元の基本例を読む: 作成から削除まで

次はNUMBER / VARCHAR2 / DATE DEFAULT SYSDATEを用いた一連の基本例です。まとめて実行する推奨スクリプトではありません。 最後のDROPは表を削除します。また、email UNIQUEは通常すでに索引を伴うので、その直後のCREATE INDEX ... (email)を無条件に追加しません。同じ列集合への複数索引には種類・可視性などの条件があり、ここでは実行結果やエラー番号を確認していません。Oracle 19c: UNIQUEと索引、CREATE INDEXの複数索引条件

-- テーブル作成
CREATE TABLE users (
    id    NUMBER PRIMARY KEY,
    name  VARCHAR2(100) NOT NULL,
    email VARCHAR2(255) UNIQUE,
    created_at DATE DEFAULT SYSDATE
);

-- カラム追加
ALTER TABLE users ADD age NUMBER;

-- カラム削除
ALTER TABLE users DROP COLUMN age;

-- インデックス作成
CREATE INDEX idx_users_email ON users(email);

-- テーブル削除
DROP TABLE users;

索引作成そのものを学ぶ場合は、一意制約が付いていない列を使う別例に分けられます。次はusers.name列が存在し、full_nameへ名前変更しておらず、idx_users_nameがない別検体用です。作成・削除をそれぞれ示す教材であり、性能改善の保証ではありません。

CREATE INDEX idx_users_name ON users(name);
DROP INDEX idx_users_name;

Oracleの名前変更はRENAME old_name TO new_nameで、MySQLのRENAME TABLEとは異なります。コメントはCOMMENT ON TABLE users IS 'ユーザー'のように付けます。Oracle 19c: RENAME、COMMENT

トランザクション中の DDL の挙動

Oracle 19cは、構文上正しいDDLの実行前に暗黙COMMITを行い、DDLが正常終了した場合はその後にもCOMMITします。DDLが実行時にエラーになっても、直前のDMLが未確定のまま残るとは限りません。Oracle 19c: COMMIT

ここでは通常の永続表などへのDDLを扱います。例外として、transaction-specific private temporary tableの作成（ON COMMIT DROP DEFINITION）は暗黙COMMITせず、private temporary tableのTRUNCATEも既存トランザクションをコミットしません。session-specificの作成とは条件が異なるため、一時表全般へ同じ規則を広げないでください。Oracle 19c: CREATE TABLE / ON COMMIT、TRUNCATE TABLEの一時表例外

次は、クライアントの自動コミットを無効にし、練習用のusers表が存在し、まだage列がない場合の説明です。OracleではBEGIN;やSTART TRANSACTION;を開始SQLとして付けません。

-- MySQL / Oracle: DDL は暗黙コミット
BEGIN;
INSERT INTO users (email) VALUES ('a@b.c');  -- DML
ALTER TABLE users ADD COLUMN age INT;        -- DDL ← この時点で INSERT が暗黙 COMMIT
ROLLBACK;                                    -- ALTER は取り消せない / INSERT も既に COMMIT 済

-- PostgreSQL: DDL もトランザクション内に
BEGIN;
INSERT INTO users (email) VALUES ('a@b.c');
ALTER TABLE users ADD COLUMN age INT;
ROLLBACK;  -- INSERT も ALTER も取り消される ★

INSERT INTO users (id, name, email)
VALUES (1, 'Alice', 'alice@example.com');

ALTER TABLE users ADD age NUMBER;
ROLLBACK;
-- 仕様上: INSERTはDDL前に確定。追加列もROLLBACKでは消えない。

DDLのあとに新しいDMLを実行した場合、そのDMLは別のトランザクションです。クライアントが自動コミットしていなければ、その後のROLLBACKの対象になります。DDLの前後をまたいで一括取消できるわけではありません。Oracle 19c: Transactions

DROP と TRUNCATE の違い

以下はOracle 19cの通常の永続表についての比較です。速さだけで選ばず、対象、依存関係、取消可能な境界を先に確認します。

DROPを「必ず即座に物理消去」とは説明できません。一方、recycle binがあっても復旧できると決めつけないでください。TRUNCATEも一定時間で終わる保証はなく、独立したシーケンスを一律リセットする命令ではありません。Oracle 19c: DROP TABLE、TRUNCATE TABLE

TRUNCATE文の比較記事もありますが、同記事の製品共通表・混在する開始構文・外部キー回避案を、そのままOracleの実行手順にしません。子表を空にしただけで参照制約がなくなるわけではなく、制約の無効化やCASCADEをエラー解消の標準手順にはしません。

比較: MySQL 8.4のDDL

ここからはOracle構文ではありません。MySQL/MariaDBのSQLカテゴリへの比較導線として、MySQL 8.4 / InnoDBの例を示します。MariaDBや他の版に同じ挙動を保証するものではありません。

CREATE TABLEと外部キー

次の2表は比較用の空のスキーマに作る教材です。AUTO_INCREMENT / ENUM / DATETIME / ENGINE=InnoDBはOracle 19cの表定義へコピーしません。MySQL 8.4: CREATE TABLE

CREATE TABLE users (
    id              BIGINT          NOT NULL AUTO_INCREMENT,
    email           VARCHAR(255)    NOT NULL,
    name            VARCHAR(100)    NOT NULL DEFAULT '',
    age             INT             CHECK (age >= 0 AND age <= 150),
    status          ENUM('active', 'inactive') NOT NULL DEFAULT 'active',
    created_at      DATETIME        NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updated_at      DATETIME        NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    deleted_at      DATETIME        NULL,
    PRIMARY KEY (id),
    UNIQUE  KEY uq_users_email (email),
    KEY     idx_users_status (status, created_at)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

FOREIGN KEY (外部キー)

次のCASCADEは「親の変更に子を追従させる」という業務要件がある場合の比較です。削除を通すための設定ではありません。InnoDBのNO ACTIONはRESTRICTと同等で、SET NULLにはNULLを許可する列が必要です。SET DEFAULTはパーサーに認識されてもInnoDBでは拒否されるため、選択肢として推奨できません。MySQL 8.4: FOREIGN KEY constraints

CREATE TABLE posts (
    id          BIGINT          NOT NULL AUTO_INCREMENT,
    user_id     BIGINT          NOT NULL,
    title       VARCHAR(255)    NOT NULL,
    PRIMARY KEY (id),
    CONSTRAINT fk_posts_user
        FOREIGN KEY (user_id)
        REFERENCES users(id)
        ON DELETE CASCADE         -- 親削除時に子も削除
        ON UPDATE CASCADE         -- 親更新時に子も更新
) ENGINE=InnoDB;

-- ON DELETE / ON UPDATE のオプション
--   CASCADE     : 親に連動
--   SET NULL    : NULL に
--   RESTRICT    : 子があれば親削除を拒否（デフォルト）
--   NO ACTION   : RESTRICT と同等
--   SET DEFAULT : DEFAULT 値に

CREATE TABLE posts (
    id BIGINT NOT NULL AUTO_INCREMENT,
    user_id BIGINT NOT NULL,
    title VARCHAR(255) NOT NULL,
    PRIMARY KEY (id),
    CONSTRAINT fk_posts_user FOREIGN KEY (user_id)
        REFERENCES users(id)
        ON DELETE CASCADE
        ON UPDATE CASCADE
) ENGINE=InnoDB;

ALTER TABLE: スキーマ変更

以下は個別操作の一覧です。全部を順次実行しません。 CHANGE COLUMN以降は列名が変わります。users.emailには上の例ですでに一意索引があり、postsにも外部キーがあるため、同じ用途の追加例を重ねないでください。MODIFY / CHANGEでは必要な属性を省略しないよう現定義と照合します。MySQL 8.4: ALTER TABLE

次のMODIFY / CHANGE例はDEFAULTを省略しており、直前のusers定義のnameの既定値（空文字）を維持しません。既定値を残す場合は、それぞれ別の検体で ALTER TABLE users MODIFY COLUMN name VARCHAR(200) NOT NULL DEFAULT ''; または ALTER TABLE users CHANGE COLUMN name full_name VARCHAR(200) NOT NULL DEFAULT ''; とします。これらもコメント・文字セット・照合順序等を含む現定義との照合が必要です。

-- カラム追加
ALTER TABLE users ADD COLUMN phone VARCHAR(20) NULL AFTER email;

-- カラム削除
ALTER TABLE users DROP COLUMN phone;

-- カラム型変更
ALTER TABLE users MODIFY COLUMN name VARCHAR(200) NOT NULL;

-- カラム名変更
ALTER TABLE users CHANGE COLUMN name full_name VARCHAR(200) NOT NULL;

-- インデックス追加
ALTER TABLE users ADD INDEX idx_email (email);
ALTER TABLE users ADD UNIQUE KEY uq_email (email);

-- インデックス削除
ALTER TABLE users DROP INDEX idx_email;

-- 外部キー追加
ALTER TABLE posts
    ADD CONSTRAINT fk_posts_user
    FOREIGN KEY (user_id) REFERENCES users(id);

-- 外部キー削除
ALTER TABLE posts DROP FOREIGN KEY fk_posts_user;

インデックス・ビュー・プロシージャ

これらも独立した例です。冒頭の表ですでに作った同名索引は重ねて作りません。ビュー例はusers.nameが存在する構成を使います。MySQL 8.4: CREATE INDEX、DROP INDEX、CREATE VIEW

-- INDEX
CREATE INDEX idx_users_status ON users(status, created_at);
DROP INDEX idx_users_status ON users;

-- VIEW
CREATE VIEW active_users AS
SELECT id, email, name FROM users WHERE status = 'active';

CREATE OR REPLACE VIEW v_user_post_count AS
SELECT u.id, u.name, COUNT(p.id) AS post_count
FROM users u LEFT JOIN posts p ON p.user_id = u.id
GROUP BY u.id, u.name;

DROP VIEW active_users;

-- STORED PROCEDURE (MySQL)
DELIMITER //
CREATE PROCEDURE add_user(IN p_email VARCHAR(255), IN p_name VARCHAR(100))
BEGIN
    INSERT INTO users (email, name) VALUES (p_email, p_name);
END //
DELIMITER ;

CALL add_user('foo@example.com', 'Foo');

-- TRIGGER
CREATE TRIGGER before_user_update
BEFORE UPDATE ON users
FOR EACH ROW
SET NEW.updated_at = NOW();

-- FUNCTION
CREATE FUNCTION user_count() RETURNS INT
DETERMINISTIC
BEGIN
    DECLARE c INT;
    SELECT COUNT(*) INTO c FROM users;
    RETURN c;
END;

-- MySQL 8.4: DROP INDEXにはONと表名を付ける
CREATE INDEX idx_users_status ON users(status, created_at);
DROP INDEX idx_users_status ON users;

CREATE VIEW active_users AS
SELECT id, email, name FROM users WHERE status = 'active';

CREATE OR REPLACE VIEW v_user_post_count AS
SELECT u.id, u.name, COUNT(p.id) AS post_count
FROM users u LEFT JOIN posts p ON p.user_id = u.id
GROUP BY u.id, u.name;

DROP VIEW active_users;

次はmysqlクライアントで区切り文字を変更する例です。DELIMITERはサーバーへ送るSQLそのものではありません。表の行数は入力が同じでも変わるので、user_countをDETERMINISTICとは宣言しません。関数作成時の権限やバイナリログ設定によっては作成が拒否されますが、検証のために保護設定を緩めません。MySQL 8.4: stored routines

DELIMITER //
CREATE PROCEDURE add_user(IN p_email VARCHAR(255), IN p_name VARCHAR(100))
BEGIN
    INSERT INTO users (email, name) VALUES (p_email, p_name);
END //

CREATE FUNCTION user_count() RETURNS INT
NOT DETERMINISTIC READS SQL DATA
BEGIN
    DECLARE c INT;
    SELECT COUNT(*) INTO c FROM users;
    RETURN c;
END //
DELIMITER ;

CALL add_user('foo@example.com', 'Foo');

トリガーの比較例です。updated_at列がある場合を想定します。上の列定義のON UPDATE CURRENT_TIMESTAMPと役割が重なるため、両方を設定する推奨ではありません。MySQL 8.4: trigger syntax

CREATE TRIGGER before_user_update
BEFORE UPDATE ON users
FOR EACH ROW
SET NEW.updated_at = NOW();

Online DDL (MySQL 8 / PostgreSQL)

MySQL 8.4の対応するInnoDB DDLにはatomic DDLがありますが、原子的な1文の処理と、利用者がROLLBACKで戻せることは別です。ここで示す通常の永続表へのDDLでは、DDL前のトランザクションは終了します。CREATE TEMPORARY TABLEなどの例外へ一律に広げません。「失敗したDDLは常に中途半端」とも「複数のDDLを一括取消できる」とも言えません。MySQL 8.4: atomic DDL、暗黙COMMITと一時表の例外

PostgreSQL 18では、次の通常のCREATE TABLEはトランザクション内で取り消せます。すべてのDDLが同様という意味ではありません。既存のusers表へのINSERT / ALTERも通常は同じトランザクションに含められますが、列の有無や必須値を満たす別の検体が必要です。PostgreSQL 18: BEGIN

-- PostgreSQL 18: logsがまだ存在しない練習用スキーマ
BEGIN;
CREATE TABLE logs (id INT);
ROLLBACK;
-- 仕様上: このCREATEで表は残らない。

次はMySQL 8.4の個別のALTER例です。対象にemail列がまだない場合だけを想定します。INPLACEは常に表再構築する意味でも、ロックが一切ない意味でもありません。対応操作や条件によって使えるアルゴリズムは異なり、LOCK=NONEでもmetadata lockによる待機はあり得ます。MySQL 8.4: ALTER TABLE、online DDL limitations

-- MySQL 8 の Online DDL
ALTER TABLE users
    ADD COLUMN email VARCHAR(255),
    ALGORITHM=INPLACE,    -- INSTANT / INPLACE / COPY
    LOCK=NONE;            -- NONE / SHARED / EXCLUSIVE

-- ALGORITHM の意味
--   INSTANT  : メタデータのみ更新（最速、対応操作限定）
--   INPLACE  : テーブル再構築するが行ロック取らない
--   COPY     : 旧形式（テーブル全体ロック、長時間）

-- PostgreSQL: CONCURRENTLY でインデックス追加（行ロックなし）
CREATE INDEX CONCURRENTLY idx_users_email ON users(email);

-- 巨大テーブルは pt-online-schema-change (Percona) や gh-ost (GitHub) で
-- ダウンタイム無しに ALTER 推奨

-- MySQL 8.4 / InnoDB: 実行可否と負荷は対象定義で確認
ALTER TABLE users
    ADD COLUMN email VARCHAR(255),
    ALGORITHM=INPLACE,
    LOCK=NONE;

PostgreSQL 18の次の例は別機能です。CONCURRENTLYは通常の書込みを妨げにくくする一方、待機・追加スキャン・失敗後の無効索引があり得ます。この命令はトランザクションブロック内では実行できません。PostgreSQL 18: CREATE INDEX concurrently

-- PostgreSQL 18: 同名索引がない、別の練習用表
CREATE INDEX CONCURRENTLY idx_users_email ON users(email);

「online」「concurrently」や外部の変更ツールという名前だけで、無停止・無ロック・一定時間を保証できません。OracleのDDLへこれらの構文を混ぜず、対象操作の仕様、依存、同時処理、復旧可能性を別々に確認します。

FAQ

DDLに失敗したら、直前のUPDATEも戻りますか？ Oracleの通常の永続オブジェクトへのDDLでは、構文上正しいDDLの実行前にCOMMITされるため、失敗したからUPDATEも取り消されたとは言えません。変更処理の途中にDDLを挟まない設計が重要です。一時表の例外は「トランザクション中の DDL の挙動」で区別します。

DROP TABLE IF EXISTSを共通構文として使えますか？ このページのOracle 19c例はIF EXISTSを前提にしていません。対象リリース・更新版と文ごとの対応を確認します。存在確認やエラー抑制は、定義の一致やデータ復旧の保証ではありません。

次に何を読むとよいですか？ SQLの分類と行を操作するDMLを対比し、取消範囲はROLLBACKで確認してください。