【Oracle】SYS・SYSTEM・SYSDBAの違い完全ガイド｜管理ユーザーと管理権限の使い分け・パスワードファイル認証・OS認証・運用ベストプラクティスまで解説

【Oracle】SYS・SYSTEM・SYSDBAの違い完全ガイド｜管理ユーザーと管理権限の使い分け・パスワードファイル認証・OS認証・運用ベストプラクティスまで解説 Oracle

Oracle を触り始めると必ずぶつかる疑問があります。「SYS と SYSTEM は何が違うのか」「AS SYSDBA を付ける理由は何か」「SYSDBA と SYSOPER はどちらを使うべきか」——この 3 つを曖昧なままにすると、権限エラーに振り回され続けるか、逆に何でもできる SYSDBA を配りすぎて監査で指摘される運用になります。

この記事では Oracle の 管理ユーザー（SYS / SYSTEM）と 7 種類の管理権限（SYSDBA / SYSOPER / SYSBACKUP / SYSDG / SYSKM / SYSRAC / SYSASM）の違いを、内部動作・認証の仕組み・確認 SQL・運用ベストプラクティスまで体系的に解説します。2026 年 4 月時点の Oracle 19c / 23ai どちらにも通用する内容です。

スポンサーリンク

まずは全体像を早見表で把握する

Oracle の「管理系のもの」は ユーザー（アカウント）と 権限（接続資格）の 2 つを分けて考えると混乱しなくなります。SYS / SYSTEM はユーザー名、SYSDBA などは権限名です。

種別 名前 役割
ユーザー SYS データディクショナリの所有者。Oracle データベースの本体を動かす特別なアカウント
ユーザー SYSTEM 一般的な管理作業を行う既定の DBA アカウント。ユーザー作成・権限付与などに使う
管理権限 SYSDBA 全権管理者。STARTUP / SHUTDOWN / CREATE DATABASE まで何でもできる
管理権限 SYSOPER 運用オペレータ。起動停止・バックアップ・リカバリは可、スキーマ操作は不可
管理権限 SYSBACKUP バックアップ専門。RMAN 実行と必要最低限の参照のみ
管理権限 SYSDG Data Guard 専門。スタンバイ操作・スイッチオーバーのみ
管理権限 SYSKM TDE 鍵管理専門。ADMINISTER KEY MANAGEMENT のみ
管理権限 SYSRAC RAC クラスターウェア用。srvctl 経由で内部的に使用
管理権限 SYSASM ASM インスタンス管理。Grid Infrastructure 環境で使用
要点: 「SYS でログイン」≠「SYSDBA でログイン」。AS SYSDBA を付けると、接続時点で内部的に SYS ユーザーに昇格します。SYSTEM ユーザーでも管理権限なしで接続すれば通常の DBA ロール権限しか使えません。

SYS ユーザー ── データディクショナリの所有者

SYS はデータベース作成時に自動生成される特別なユーザーで、すべてのデータディクショナリの基表とビュー（USER$ / OBJ$ / TAB$ / DBA_USERS など）を所有します。言い換えれば、Oracle データベースの「神経系」はすべて SYS のスキーマに格納されています。

SYS が持つ特別な性質

  • データディクショナリのすべてを所有する（SELECT owner FROM dba_objects WHERE owner='SYS' で確認可）
  • 既定のパスワードはインストール時に指定（11g 以降はインストーラが必須化）
  • 通常の接続（sqlplus sys/pass@db）では接続できず、AS SYSDBA か AS SYSOPER が必須
  • SYS のアカウントは DROP USER も LOCK も不可
  • 監査設定で AUDIT_SYS_OPERATIONS=TRUE（12c 以降デフォルト TRUE）を有効にすると SYS の全操作がログに残る
SYS が所有するオブジェクト数を数える
SELECT owner, COUNT(*) AS cnt
FROM   dba_objects
WHERE  owner IN ('SYS','SYSTEM')
GROUP  BY owner
ORDER  BY owner;

-- 一般的に SYS は 5 万〜10 万オブジェクト、SYSTEM は 1000〜3000 程度。
-- この圧倒的な差が、SYS がデータディクショナリの「本体」である証拠。
SYS でアプリを作ってはいけません。 SYS スキーマにアプリケーションのテーブルを作ると、アップグレード時に Oracle が生成する DD オブジェクトと衝突する可能性があります。Oracle は ORACLE_MAINTAINED='Y' でシステムスキーマを識別していますが、SYS への直接の DDL は設計上完全に非推奨です。アプリ用スキーマは必ず CREATE USER で別途作成してください。

SYSTEM ユーザー ── 既定の DBA アカウント

SYSTEM は SYS と同じく自動生成されるデフォルトアカウントですが、役割はまったく別物です。DBA ロールを持つ通常の管理ユーザーで、日常的な管理タスク（ユーザー作成・権限付与・統計情報取得など）に使われます。データディクショナリは所有しません。

SYSTEM の典型的な用途

  • CREATE USER / GRANT / REVOKE での権限管理
  • DBMS_STATS による統計情報収集
  • AWR / ASH レポート生成
  • 監査ポリシーの設定（Unified Audit）
  • 簡易なメンテナンス SQL の実行
SYSTEM で通常接続（AS SYSDBA 不要）
-- OK: SYSTEM は通常の接続が可能
CONNECT system/your_password@orclpdb1

-- 権限一覧を確認
SELECT * FROM session_privs ORDER BY privilege;

-- 主要な権限: CREATE SESSION, DBA ロール, EXP_FULL_DATABASE, IMP_FULL_DATABASE など
SYSTEM は SYS のように特別扱いされません。 アカウントを LOCK したり、パスワードを変更したり、権限を剥奪したりできます。実務では「SYSTEM は日常管理用、SYSDBA 権限を持った別ユーザー（例: DBA_TANAKA）を作って監査証跡を分ける」運用が推奨されます。

SYS と SYSTEM の実務的な使い分け

慣れない時は全部 SYS でログインしてしまいがちですが、それは後で監査指摘・事故の元になります。日常管理は SYSTEM、起動停止やリカバリは SYSDBA 権限を持ったユーザー、と明確に分けるのが基本です。

作業 推奨アカウント 理由
ユーザー作成・権限付与 SYSTEM DBA ロールで十分。SYS を使う必要なし
アプリスキーマでの DDL アプリスキーマ本人 所有者以外の DDL は監査が煩雑になる
統計情報取得 SYSTEM or 専用 DBA ロールで可能
STARTUP / SHUTDOWN SYSDBA または SYSOPER インスタンス制御は管理権限が必須
ARCHIVELOG 切替 SYSDBA または SYSOPER ALTER DATABASE は管理権限が必須
RMAN バックアップ SYSBACKUP バックアップ専用の最小権限
CREATE DATABASE SYSDBA のみ SYSOPER や SYSBACKUP では不可
データディクショナリ直接編集 禁止 SYS でも実務では触らない（Oracle サポートの指示がない限り）

AS SYSDBA 接続の内部動作

sqlplus someuser/pw@db AS SYSDBA と書いたとき、Oracle は以下の順番で動きます。

  1. クライアントがリスナー経由で接続要求を送る
  2. Oracle が「この someuser は SYSDBA 権限を持つか？」を パスワードファイル（または OS 認証）で検証
  3. OK なら、セッションの内部ユーザーを SYS に切り替える
  4. 以降、そのセッションはデータディクショナリを含む全オブジェクトに完全アクセスできる
AS SYSDBA での「見かけ」と「実体」の差
-- 接続: CONNECT dba_tanaka/pw@db AS SYSDBA
SELECT
  SYS_CONTEXT('USERENV','AUTHENTICATED_IDENTITY') AS authn_user,  -- 認証された生のユーザー名 → DBA_TANAKA
  SYS_CONTEXT('USERENV','SESSION_USER')           AS sess_user,   -- 実際のセッションユーザー → SYS
  SYS_CONTEXT('USERENV','CURRENT_USER')           AS curr_user,   -- 現在の実行権限ユーザー → SYS
  SYS_CONTEXT('USERENV','ISDBA')                  AS is_dba,      -- SYSDBA 認証なら TRUE
  USER                                            AS u            -- SYS
FROM dual;
ここが事故の温床: SYSDBA で接続すると、どのユーザー名で CONNECT したかに関係なくセッションは SYS になります。つまり 監査ログの SESSION_USER は SYS 固定で「誰が操作したか」が追えなくなります。これを防ぐには AUDITED_USERID の代わりに OS_USERNAME や AUTHENTICATED_IDENTITY を監査に含める必要があります。

7 種類の管理権限と実行可能操作

Oracle 12c でジョブロール分離（Job Role Separation）が導入され、従来 SYSDBA / SYSOPER の 2 つしかなかった管理権限が 7 種類に拡張されました。最小権限の原則に従って、担当者の役割ごとに権限を割り当てるのが 2026 年のベストプラクティスです。

操作別の対応表

操作 SYSDBA SYSOPER SYSBACKUP SYSDG SYSKM
STARTUP / SHUTDOWN ○ ○ ○ ○ ×
ALTER DATABASE OPEN / MOUNT ○ ○ ○ ○ ×
ALTER DATABASE ARCHIVELOG ○ ○ ○ × ×
RECOVER DATABASE（完全） ○ △制限あり ○ × ×
CREATE DATABASE ○ × × × ×
CREATE / ALTER USER ○ × × × ×
RMAN BACKUP / RESTORE ○ × ○ × ×
SWITCHOVER / FAILOVER（DG） ○ × × ○ ×
ADMINISTER KEY MANAGEMENT ○ × × × ○
SELECT ANY TABLE ○ × △必要時のみ × ×
SYSOPER と SYSBACKUP の違い: どちらもバックアップ系に見えますが、SYSOPER は「起動停止中心で最低限の RECOVER のみ」、SYSBACKUP は「RMAN を使ったバックアップ / リストアの専門家」です。RMAN 運用を外部委託している場合は、委託先に SYSBACKUP のみ付与すれば SELECT ANY TABLE が付かないため、業務データを覗かれる心配がなくなります。

パスワードファイル認証と OS 認証の仕組み

管理権限でログインする方法は 2 つあります。ネットワーク経由で認証するなら パスワードファイル認証、サーバーに直接ログインしているなら OS 認証です。運用シーンに応じて使い分けます。

パスワードファイル認証

Oracle は $ORACLE_HOME/dbs/orapw<SID>（Windows は %ORACLE_HOME%\database\PWD<SID>.ora）に管理ユーザーの認証情報を保存します。このファイルは orapwd ユーティリティで作成します。

パスワードファイルの作成と再作成
# 12c 以降の構文（FORMAT=12.2 推奨）
orapwd file=$ORACLE_HOME/dbs/orapworcl \
  entries=30 \
  format=12.2 \
  sys=your_sys_password

# ユーザーを追加したい時は再作成せずに GRANT だけで OK
# （ファイルが既に存在すればそのまま使われる）
現在パスワードファイルに登録されているユーザー確認
-- V$PWFILE_USERS で管理権限を持つ全ユーザーが見える
SELECT username, sysdba, sysoper, sysbackup, sysdg, syskm
FROM   v$pwfile_users
ORDER  BY username;

-- SYSDBA/SYSOPER/SYSBACKUP/SYSDG/SYSKM 列は TRUE/FALSE

OS 認証

サーバー OS の特定グループ（Linux なら dba、Windows なら ORA_DBA）に所属しているユーザーは、パスワードなしで管理権限として接続できます。サーバーのシェルに入れる時点で SYSDBA を与える、というのが基本思想です。

OS 認証での接続（Linux 例）
# oracle ユーザーで OS にログイン中
whoami              # → oracle
groups              # → oinstall dba oper backupdba dgdba kmdba

# パスワードなしで SYSDBA 接続
sqlplus / as sysdba

# 各 OS グループと Oracle 管理権限の対応
# dba        → SYSDBA
# oper       → SYSOPER
# backupdba  → SYSBACKUP
# dgdba      → SYSDG
# kmdba      → SYSKM
# racdba     → SYSRAC
# asmadmin   → SYSASM（Grid 環境）
OS 認証は便利ですが、サーバーに shell アクセスできる人=全員 DBA という意味です。 SRE / SIer の多人数オペレーションでは、oracle ユーザーのパスワードをチーム共有にすると、実質的に誰が何をしたか追えなくなります。本番では 個人 OS アカウントを dba グループに入れる 運用が理想です。

管理権限の付与と剥奪

12c 以降、管理権限は GRANT SYSDBA TO ユーザー の構文でシンプルに付与できます。これを実行すると Oracle が自動的にパスワードファイルにエントリを追加します。

管理権限を付与する SQL
-- 事前にユーザーを作成しておく（SYSDBA として接続中）
CREATE USER dba_tanaka IDENTIFIED BY "Strong#Pass_2026";
GRANT CREATE SESSION TO dba_tanaka;

-- 管理権限を付与（この時点で v$pwfile_users に現れる）
GRANT SYSDBA    TO dba_tanaka;   -- 全権 DBA
GRANT SYSOPER   TO dba_oper;     -- 運用オペレータ
GRANT SYSBACKUP TO rman_user;    -- バックアップ担当
GRANT SYSDG     TO dg_user;      -- Data Guard 担当
GRANT SYSKM     TO tde_user;     -- TDE 鍵管理担当

-- 剥奪
REVOKE SYSDBA FROM dba_tanaka;
権限付与後に正しく入ったか確認
SELECT username, sysdba, sysoper, sysbackup, sysdg, syskm
FROM   v$pwfile_users
WHERE  username IN ('DBA_TANAKA','RMAN_USER','DG_USER','TDE_USER')
ORDER  BY username;
GRANT は CDB ルートで実行: マルチテナント環境（12c 以降）で管理権限を Common User に付与する場合は CONTAINER=ALL を付けるか、CDB$ROOT で接続して実行します。PDB ローカルの管理権限付与は 18c 以降で可能です。マルチテナントの設計については Oracle マルチテナント（CDB / PDB）完全ガイド を参照してください。

セッションの管理権限を確認する SQL 集

今のセッションが何者として動いているかは、USER 関数だけではわかりません。必ず SYS_CONTEXT('USERENV', ...) と SESSION_PRIVS を組み合わせて確認します。人気記事の Oracle ユーザ権限を確認する方法完全ガイド で紹介しているビューと合わせて使うと、権限調査が完結します。

① 今のセッションは誰として認証されているか
SELECT
  SYS_CONTEXT('USERENV','AUTHENTICATED_IDENTITY') AS authn,     -- 生の認証名
  SYS_CONTEXT('USERENV','SESSION_USER')           AS sess_user, -- 実行ユーザー
  SYS_CONTEXT('USERENV','CURRENT_USER')           AS curr_user, -- 定義者権限時の実行者
  SYS_CONTEXT('USERENV','ISDBA')                  AS is_dba,    -- SYSDBA 認証されていれば TRUE
  SYS_CONTEXT('USERENV','IDENTIFICATION_TYPE')    AS id_type,   -- LOCAL / EXTERNAL / GLOBAL
  SYS_CONTEXT('USERENV','OS_USER')                AS os_user
FROM dual;
② 今のセッションで有効な権限一覧
-- SESSION_PRIVS: 直接付与とロール経由の両方を含む、今「使える」権限
SELECT privilege
FROM   session_privs
ORDER  BY privilege;

-- SESSION_ROLES: 有効なロール一覧
SELECT role FROM session_roles ORDER BY role;
③ パスワードファイルの管理権限保持者を棚卸し
-- セキュリティ監査で最初に見るべきビュー
SELECT
  username,
  CASE WHEN sysdba    = 'TRUE' THEN '○' END AS sysdba,
  CASE WHEN sysoper   = 'TRUE' THEN '○' END AS sysoper,
  CASE WHEN sysbackup = 'TRUE' THEN '○' END AS sysbackup,
  CASE WHEN sysdg     = 'TRUE' THEN '○' END AS sysdg,
  CASE WHEN syskm     = 'TRUE' THEN '○' END AS syskm
FROM   v$pwfile_users
ORDER  BY username;

-- SYSDBA 保持者が SYS / SYSTEM 以外に何人いるかを把握する
④ SYS による操作の監査ログ（Unified Audit）
-- AUDIT_SYS_OPERATIONS=TRUE（12c 以降デフォルト）が効いていれば、
-- SYS 経由の全 SQL が UNIFIED_AUDIT_TRAIL に記録される
SELECT event_timestamp,
       dbusername,
       os_username,
       action_name,
       SUBSTR(sql_text, 1, 80) AS sql_text
FROM   unified_audit_trail
WHERE  dbusername = 'SYS'
  AND  event_timestamp > SYSDATE - 1
ORDER  BY event_timestamp DESC
FETCH FIRST 50 ROWS ONLY;

よくあるエラーと対処

ORA-01031: insufficient privileges

SYS でのログインを AS SYSDBA なしで試みた、または管理権限を持っていないユーザーが SYSDBA 接続を試みた場合に出ます。

再現と対処
# NG: SYS は通常接続できない
$ sqlplus sys/pass@db
ERROR: ORA-01017: invalid username/password; logon denied
# （または ORA-01031: insufficient privileges）

# OK: AS SYSDBA を付ける
$ sqlplus sys/pass@db AS SYSDBA
詳細は ORA-01031 完全ガイド を参照してください。PL/SQL 内のロール権限の落とし穴まで解説しています。

ORA-28009: connection as SYS should be as SYSDBA or SYSOPER

初期化パラメータ O7_DICTIONARY_ACCESSIBILITY=FALSE（デフォルト）の環境で、SYS にそのまま接続しようとすると出るエラーです。必ず AS SYSDBA または AS SYSOPER を付けます。

ORA-01017: invalid username/password; logon denied

パスワードファイル自体が存在しないか、パスワードが違う、大文字小文字が違う——複数の原因があります。12c 以降はパスワード検証機能（12C verifier）の採用でパスワードの大文字小文字がデフォルトで区別されるため、すべて一致させる必要があります。

ORA-01017 完全ガイド では、パスワードベリファイアの種類（10G / 11G / 12C）の違いまで踏み込んで解説しています。

ORA-01994: GRANT failed: cannot add users to public password file

パスワードファイルの entries が不足、またはファイル自体が REMOTE_LOGIN_PASSWORDFILE=NONE に設定されている場合に出ます。orapwd で作り直すか、初期化パラメータを EXCLUSIVE（推奨）に変更します。

パスワードファイルを再作成（既存を保持したい場合）
# 既存ユーザーを退避
sqlplus / as sysdba
SQL> SELECT username FROM v$pwfile_users;

# orapwd で entries を増やして再作成（既存ユーザーは GRANT で戻す）
orapwd file=$ORACLE_HOME/dbs/orapworcl entries=60 format=12.2 force=y sys=<pw>

運用セキュリティのベストプラクティス

SYS / SYSTEM を日常的に使わない

SYSDBA 権限を持つ専用の個人 DBA ユーザー（例: DBA_TANAKA、DBA_SATO）を作り、SYS / SYSTEM のパスワードは金庫・パスワードマネージャーに封印します。「誰が何をしたか」を監査ログで追えるようになります。

最小権限の原則でジョブロール分離を徹底する

RMAN バックアップ担当者には SYSBACKUP、Data Guard 担当者には SYSDG、TDE 運用者には SYSKM を個別付与します。「SYSDBA を配ってしまえ」は監査で一撃アウトなので、必ず権限を絞ってください。

AUDIT_SYS_OPERATIONS を TRUE のまま運用

12c 以降デフォルトで TRUE ですが、ログ量削減のために FALSE にしている現場があります。これは本番環境では禁じ手です。SYS が何をしたかの完全なトレイルを残せる唯一の仕組みなので、Unified Audit の保持期間を確保しつつ有効化し続けてください。Unified Audit の詳細は 統合監査（Unified Audit）完全ガイド を参照してください。

パスワードファイルとリスナーへのアクセスを絞る

orapw* ファイルのパーミッションは 600（oracle ユーザーのみ読める）に限定します。REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE のまま運用し、必要なければ NONE でネットワーク越しの SYSDBA 自体を禁止する選択肢もあります。

パスワードを定期的にローテーションする

SYS / SYSTEM も PROFILE の PASSWORD_LIFE_TIME 対象です。アプリ接続と違って期限切れで障害化すると影響範囲が広いため、期限切れの前にローテーションを実施する運用チェックリストを必ず作っておきます。プロファイル設計は プロファイル完全ガイド で詳解しています。

マルチテナント環境では Common と Local を混同しない

CDB$ROOT に作った Common User（C## プリフィックス付）と、PDB 内の Local User は完全に別物です。PDB 内で SYSDBA を付与する場合、その権限はその PDB 内でのみ有効な Local 管理権限になります。CDB 全体の SYSDBA は CDB$ROOT の Common User にのみ付与できます。

よくある質問

QSYS と SYSTEM のパスワードは両方とも必ず変更しなければいけませんか？
Aはい、本番環境では両方とも必須です。デフォルトパスワード（CHANGE_ON_INSTALL / MANAGER）のまま運用している現場は、監査で即指摘されます。DBA_USERS_WITH_DEFPWD ビューでデフォルトのまま放置されているユーザーを確認できます。SYS / SYSTEM だけでなく、DBSNMP / OUTLN / XDB などの既定アカウントもロックまたはパスワード変更が必要です。
QAS SYSDBA で接続すると誰が何をしたかわからなくなるのは本当ですか？
A監査ログの SESSION_USER は SYS になりますが、AUTHENTICATED_IDENTITY や OS_USERNAME には認証時のユーザー名・OS ユーザー名が記録されます。Unified Audit を有効にすると dbusername は SYS 固定でも、client_identifier や os_username を監査クエリに含めれば実際の担当者を追えます。個人単位で SYSDBA 権限を持ったユーザーを作り、SYS / SYSTEM 直接接続を禁止するのが標準運用です。
QSYSOPER と SYSDBA のどちらを運用オペレーターに与えるべきですか？
A起動停止・バックアップ・簡易リカバリしか行わない運用担当者には必ず SYSOPER で十分です。SYSOPER では CREATE USER / DROP TABLESPACE などの破壊的な DDL ができないため、誤操作のリスクを限定できます。ただし 12c 以降の新しい設計では、バックアップ専任には SYSBACKUP、Data Guard 専任には SYSDG を使うほうが最小権限の原則に沿います。
Qorapwd の FORMAT オプションは何を指定すればいいですか？
A19c / 23ai では FORMAT=12.2 を指定します。これは 12c Release 2 以降で導入された形式で、パスワードの強度チェック・OraSSL 暗号化などが有効になります。旧形式 FORMAT=12 / FORMAT=legacy は互換性のためだけに残されています。過去の形式で作成したパスワードファイルは、パスワードファイル作り直し＋ GRANT 再実行で移行できます。
Qパスワードファイルを消してしまった場合、どうやって復旧しますか？
Aデータベースが起動中なら OS 認証（sqlplus / as sysdba）で接続し、v$pwfile_users の内容をメモします。その後 orapwd でファイルを再作成し、GRANT SYSDBA TO ユーザー で権限を再付与すれば復旧できます。SYSDBA 保持者の一覧を日次でバックアップしておくと、事故時の復旧が格段に楽になります。
QSYS でアプリケーションのテーブルを作ってしまいました。削除すべきですか？
Aはい、必ず別スキーマに移動してください。SYS スキーマ内の非 Oracle テーブルは、データベースのアップグレードや Data Pump エクスポート（FULL=Y）で予期せぬ挙動を起こします。expdp で該当テーブルをダンプし、新規ユーザーで impdp を使ってインポートし直す手順が定番です。移行中はシノニムを残すとアプリの参照先を段階的に切り替えられます。Data Pump の使い方は Data Pump 完全ガイド で詳解しています。
QSYSDBA を与えたユーザーの SYSDBA だけを剥奪したい場合は？
AREVOKE SYSDBA FROM ユーザー で管理権限のみを剥奪できます。通常のデータベース権限（DBA ロールや CREATE SESSION など）は別扱いなので、管理権限だけ外して一般ユーザーとしては残す運用が可能です。剥奪後は必ず V$PWFILE_USERS と DBA_SYS_PRIVS の両方を確認してください。
Qマルチテナント環境で PDB 内に SYSDBA を持つユーザーを作れますか？
Aはい、18c 以降は PDB ローカルの管理権限を作成できます。PDB に接続した状態で CREATE USER pdba IDENTIFIED BY pw CONTAINER=CURRENT → GRANT SYSDBA TO pdba CONTAINER=CURRENT とすれば、その PDB 内でのみ有効な SYSDBA が完成します。CDB ルートの SYSDBA は持たないため、他 PDB を触れないマルチテナント安全運用が実現できます。マルチテナント詳細は マルチテナント完全ガイド を参照してください。

まとめ

  • SYS はデータディクショナリの所有者、SYSTEM は既定の DBA アカウント。役割も用途もまったく別物なので使い分ける
  • SYSDBA は接続時に SYS に昇格する管理権限。ユーザー名に関係なく SYS として動く
  • 管理権限は 7 種類（SYSDBA / SYSOPER / SYSBACKUP / SYSDG / SYSKM / SYSRAC / SYSASM）。12c 以降のジョブロール分離で最小権限運用が可能に
  • 認証方式はパスワードファイル認証と OS 認証の 2 種類。OS 認証は便利だが shell アクセス権=SYSDBA になるため個人アカウント運用が前提
  • 日常作業は個人 DBA ユーザー＋必要な管理権限。SYS / SYSTEM は金庫に封印し、AUDIT_SYS_OPERATIONS で全操作を監査
  • V$PWFILE_USERS で SYSDBA 保持者を定期棚卸し。監査で最初に見られる重要ビュー
  • マルチテナント環境では Common / Local の区別を意識。PDB ローカル管理権限で PDB 単位の権限分離ができる

権限確認の SQL は Oracle ユーザ権限を確認する方法完全ガイド、ユーザー・ロール管理全般は ユーザー・権限・ロール完全ガイド、プロファイルによるパスワード管理は プロファイル完全ガイド、監査ログの活用は 統合監査（Unified Audit）完全ガイド もあわせてご覧ください。