【完全ガイド】ORA-01455: converting column overflows integer datatype の原因と解決方法｜NUMBER 変換・JDBC getInt・PL/SQL 徹底解説

Oracle 開発者がJava アプリケーションやPL/SQL ストアドで意外に頻発するデータ型エラー:

java.sql.SQLException: ORA-01455: converting column overflows integer datatype
  at oracle.jdbc.driver.T4CTTIoer.processError...

「列を整数型に変換するとオーバーフロー」というシンプルなメッセージ。実はOracle の NUMBER 型と各言語の integer 型のサイズ差が原因です:

• Oracle NUMBER: 最大 38 桁の任意精度
• Java int: 32 bit、最大 2,147,483,647 (約 21 億)
• PL/SQL PLS_INTEGER: 32 bit、同じ上限
• C int: 32 bit、同じ上限

NUMBER 値がこの上限を超えると ORA-01455。

現場で最も典型的な発生パターン:

-- ❌ 日付を YYYYMMDDHH24MISS 形式（14桁）で数値化
SELECT TO_NUMBER(TO_CHAR(created_at, 'YYYYMMDDHH24MISS')) FROM logs;
-- 20260615123456 = 20兆超 → INTEGER オーバーフロー

-- Java 側で
int val = rs.getInt(1);   -- ORA-01455

14 桁の日時数値 = 20 兆 = INTEGER 上限（21 億）を大幅超過、当然オーバーフロー。

さらに、SAP BR*Tools や PeopleSoft など大規模エンタープライズシステムでも典型的:

SAP BR*Tools:
DBA_TAB_MODIFICATIONS の INSERTS/UPDATES/DELETES カラムが
long time で 21億超 → ORA-01455

PeopleSoft SCM:
PS_PL_STK_PERIODS.VERSION カラムが Integer 想定
実データが 2,147,483,647 超 → ORA-01455

多くの日本語記事が「大きなデータ型を使え」で終わりますが、実務では:

• Java int vs long vs BigDecimal の使い分け
• JDBC getInt() vs getLong() vs getBigDecimal()
• PL/SQL PLS_INTEGER vs NUMBER vs BINARY_INTEGER
• TO_NUMBER(TO_CHAR(...)) アンチパターンの回避
• DBMS_STATS 統計情報リセットによる解消
• Rails / ActiveRecord での自動対応
• Python oracledb の自動昇格
• OCI / OCCI ドライバの内部処理
• SAP / PeopleSoft 等のパッチ対応

さらに、PL/SQL の PLS_INTEGER 制限は、多くの開発者を悩ませます:

DECLARE
  v_count PLS_INTEGER;   -- 32bit、上限 2,147,483,647
BEGIN
  SELECT COUNT(*) INTO v_count FROM huge_table;
  -- COUNT が 21億超 → ORA-01455
END;
/

日常業務では稀ですが、巨大テーブルや長期運用で発生します。

本記事では、ORA-01455: converting column overflows integer datatype の完全な原因と解決方法を、リファレンスとして実用的に整理します。10大発生パターン、INTEGER の上限、5つの解決策、Rails/Java/Python 対応、実践シナリオ、FAQまで完全網羅。この1本で ORA-01455 に冷静に対処できるようになります。

結論：より大きなデータ型を使う

時間がない方向けに、最速の対処を先に示します。

エラーメッセージの読み方

ORA-01455: converting column overflows integer datatype
                             ↑                    ↑
                        列変換で              整数型オーバーフロー

= Oracle NUMBER 値が受け側の integer 型に収まらない

INTEGER の上限（重要）

32-bit INTEGER: 2,147,483,647  ≈ 21億 4千万
32-bit UINT:    4,294,967,295  ≈ 42億 9千万
64-bit LONG:    9,223,372,036,854,775,807 ≈ 922京

14 桁の日時数値 (20兆超) は 32-bit INTEGER に収まらない。

最速の診断

-- ① 該当列のデータ範囲確認
SELECT MIN(col), MAX(col) FROM my_table;

-- ② NUMBER 列の精度確認
SELECT column_name, data_type, data_precision, data_scale
FROM user_tab_columns 
WHERE table_name = 'MY_TABLE';

5つの解決策

データ型サイズ比較表

詳細は以下で解説します。

Oracle NUMBER 型と各言語の整合性

NUMBER の柔軟性

Oracle NUMBER:

NUMBER              -- 最大 38 桁
NUMBER(10)          -- 10 桁（38 桁未満）
NUMBER(10, 2)       -- 全 10 桁のうち小数 2 桁
NUMBER(38)          -- 最大精度

任意精度で 10 進小数を扱える。

Java 型との対応

JDBC の自動マッピング:

NUMBER (整数)      → int / long / BigDecimal
NUMBER(p, s)       → BigDecimal (精度保持)
NUMBER (小数)      → double / BigDecimal

問題: getInt() を使うと 32-bit に収まらない値でオーバーフロー。

PL/SQL の整数型

NUMBER              -- 標準、任意精度
INTEGER             -- NUMBER(38, 0) の別名
PLS_INTEGER         -- 32bit ネイティブ整数（高速）
BINARY_INTEGER      -- PLS_INTEGER の別名（旧型）
SIMPLE_INTEGER      -- NOT NULL、オーバーフロー時ラップ（10g+）

PLS_INTEGER は高速だが、32 bit 上限。

【原因①】TO_NUMBER(TO_CHAR(date, ‘YYYYMMDDHH24MISS’))（最頻出）

症状（超典型）

SELECT TO_NUMBER(TO_CHAR(created_at, 'YYYYMMDDHH24MISS')) 
FROM logs;
-- 20260615123456 = 約 20 兆

-- Java 側
int val = rs.getInt(1);
-- ORA-01455

原因

14 桁の数値 = 約 20 兆 >> INTEGER 上限（21 億）。

解決A: Java 側で long / BigDecimal

long val = rs.getLong(1);
// または
BigDecimal val = rs.getBigDecimal(1);

解決B: SQL 側で TO_CHAR のまま返す

SELECT TO_CHAR(created_at, 'YYYYMMDDHH24MISS') FROM logs;
-- 文字列として受け取り、必要時に long にパース

解決C: 日付は日付型で扱う

SELECT created_at FROM logs;
-- Timestamp / Date として受け取り

原則: 日付は日付型のまま、無理に数値化しない。

【原因②】JDBC getInt() で大きい NUMBER

症状

ResultSet rs = ps.executeQuery();
while (rs.next()) {
    int amount = rs.getInt("total_amount");
    // total_amount が 30 億の場合 → ORA-01455
}

解決

getLong() に変更:

long amount = rs.getLong("total_amount");

または BigDecimal:

BigDecimal amount = rs.getBigDecimal("total_amount");

推奨: 金額など大きな数値の可能性がある列は最初から long or BigDecimal。

【原因③】PL/SQL PLS_INTEGER への代入

症状

DECLARE
  v_count PLS_INTEGER;
BEGIN
  SELECT COUNT(*) INTO v_count FROM audit_log;
  -- audit_log が 21億行超 → ORA-01455
END;
/

解決

NUMBER 型を使用:

DECLARE
  v_count NUMBER;
BEGIN
  SELECT COUNT(*) INTO v_count FROM audit_log;
  DBMS_OUTPUT.PUT_LINE(v_count);
END;
/

PLS_INTEGER の使い所

-- ✅ ループカウンタ（数万〜数百万）
FOR i IN 1..1000000 LOOP ... END LOOP;

-- ❌ 巨大テーブルの COUNT / SUM
-- → NUMBER 使う

【原因④】SAP BR*Tools 統計情報

症状

SAP システムで:

BR*Tools:
ORA-01455 error in program brconnect

DBA_TAB_MODIFICATIONS の INSERTS/UPDATES/DELETES が
21 億超え

診断

SELECT table_name, inserts, updates, deletes
FROM dba_tab_modifications
WHERE inserts > 2147483647
   OR updates > 2147483647
   OR deletes > 2147483647;

解決

統計情報リセット (Oracle 公式手順):

BEGIN
  DBMS_STATS.gather_table_stats(
    ownname => 'SCHEMA',
    tabname => 'TABLE_NAME',
    estimate_percent => 0.1   -- 0.1%サンプル
  );
END;
/
-- DBA_TAB_MODIFICATIONS がリセットされる

【原因⑤】PeopleSoft VERSION カラム

症状（PeopleSoft SCM）

INSERT INTO PS_PL_STK_PERIODS 
(PROBINST, BUSINESS_UNIT, INV_ITEM_ID, VERSION)
SELECT ..., 0 FROM ...
-- 実行時
Error Position: 0 Return: 1455 - ORA-01455

原因

VERSION カラムが長期運用で 21億超。

解決

Oracle Support (MOS) 提供のパッチ適用、VERSION カラム型変更。

【原因⑥】OCI / OCCI ドライバ

症状（C++ アプリ）

// OCI アプリケーション
OCIDefineByPos(stmt, &defn, err, 1, 
               &intbuf, sizeof(int), 
               SQLT_INT, ...);
// 実行時 ORA-01455

解決

より大きい型を宣言:

long long intbuf;
OCIDefineByPos(stmt, &defn, err, 1, 
               &intbuf, sizeof(long long), 
               SQLT_INT, ...);

または SQLT_NUM で NUMBER として扱う。

【原因⑦】ROWNUM の巨大取得

症状

SELECT ROWNUM, id FROM huge_table WHERE ROWNUM < 3000000000;
-- 30 億まで → INTEGER オーバーフロー

解決

-- ROWNUM は暗黙 NUMBER、明示的に扱う
SELECT TO_NUMBER(ROWNUM), id FROM huge_table;

Java 側で getLong() 使用。

【原因⑧】SEQUENCE の巨大値

症状

-- 長年運用で SEQUENCE が 21億超
CREATE SEQUENCE seq_id INCREMENT BY 1 START WITH 3000000000;

SELECT seq_id.NEXTVAL FROM DUAL;
-- Java int で受けると ORA-01455

解決

long / BigDecimal で受ける:

long id = rs.getLong(1);

または NOCYCLE MAXVALUE 設定確認:

SELECT sequence_name, max_value, min_value, cache_size 
FROM user_sequences;

【原因⑨】集計関数のオーバーフロー

症状

SELECT SUM(amount) FROM transactions;
-- SUM が 21 億超 → Java int で ORA-01455

解決

BigDecimal total = rs.getBigDecimal("total");
// SUM は BigDecimal で受ける

または PL/SQL 内:

DECLARE
  v_total NUMBER;   -- NUMBER で受ける
BEGIN
  SELECT SUM(amount) INTO v_total FROM transactions;
END;

【原因⑩】BLOB / CLOB のサイズ

症状

BLOB blob = rs.getBLOB("data");
int size = (int) blob.length();   -- 2GB 超で ORA-01455 or キャストエラー

解決

long size = blob.length();   // long で受ける

LOB 関連は ORA-00932: inconsistent datatypes の記事も参照してください。

診断ツール完全リファレンス

該当列のデータ範囲

SELECT MIN(col), MAX(col), COUNT(*) 
FROM my_table;

列の精度確認

SELECT column_name, data_type, data_precision, data_scale
FROM user_tab_columns 
WHERE table_name = 'MY_TABLE';

DBA_TAB_MODIFICATIONS

SELECT table_name, inserts, updates, deletes, timestamp
FROM dba_tab_modifications
WHERE table_owner = 'MY_SCHEMA'
ORDER BY inserts + updates + deletes DESC
FETCH FIRST 10 ROWS ONLY;

SEQUENCE 現在値

SELECT sequence_name, last_number, increment_by, max_value 
FROM user_sequences;

V$SQL でオーバーフロー SQL 特定

SELECT sql_id, sql_text, executions, elapsed_time
FROM v$sql
WHERE sql_text LIKE '%TO_NUMBER(TO_CHAR%'
  OR sql_text LIKE '%YYYYMMDDHH24MISS%';

5つの解決策 完全リファレンス

解決策① Java getLong() / getBigDecimal()

// int → long
long val = rs.getLong("col");

// BigDecimal（推奨、精度保持）
BigDecimal val = rs.getBigDecimal("col");

// null 対応
long val = rs.wasNull() ? 0L : rs.getLong("col");

解決策② PL/SQL NUMBER 型

-- ❌ PLS_INTEGER
DECLARE
  v_count PLS_INTEGER;
BEGIN
  SELECT COUNT(*) INTO v_count FROM t;
END;

-- ✅ NUMBER
DECLARE
  v_count NUMBER;
BEGIN
  SELECT COUNT(*) INTO v_count FROM t;
END;

解決策③ DBMS_STATS 実行（SAP系）

BEGIN
  DBMS_STATS.gather_table_stats(
    ownname => 'SAPUSER',
    tabname => 'TABLE_NAME',
    estimate_percent => 0.1
  );
END;
/

解決策④ スケール調整

-- ❌ 14桁数値
TO_NUMBER(TO_CHAR(date, 'YYYYMMDDHH24MISS'))

-- ✅ より小さい桁
TO_NUMBER(TO_CHAR(date, 'YYYYMMDD'))   -- 8桁、約1億

-- ✅ 文字列のまま
TO_CHAR(date, 'YYYYMMDDHH24MISS')

解決策⑤ TO_CHAR で文字列化

-- 表示用途なら文字列
SELECT TO_CHAR(created_at, 'YYYY-MM-DD HH24:MI:SS') FROM logs;

Java 側で getString() で受ける、パースして処理。

Rails / Java / Python 対応

Rails ActiveRecord

Rails は BigDecimal 自動使用、通常 ORA-01455 は稀:

# ActiveRecord は NUMBER を BigDecimal / Integer 自動判定
User.find(1_000_000_000)  # OK

# エラーハンドリング
begin
  User.count
rescue ActiveRecord::StatementInvalid => e
  if e.message.include?("ORA-01455")
    Rails.logger.error "NUMBER オーバーフロー: #{e.message}"
  end
end

Rails 8 系の詳細は Rails 8 アップグレードガイドの記事、find/find_by/where の記事も参照してください。

Java (JDBC)

PreparedStatement + getLong:

try (PreparedStatement ps = conn.prepareStatement(
        "SELECT COUNT(*) FROM audit_log");
     ResultSet rs = ps.executeQuery()) {
    if (rs.next()) {
        long count = rs.getLong(1);   // int でなく long
        System.out.println("Count: " + count);
    }
}

BigDecimal で精度保持:

BigDecimal total = rs.getBigDecimal("amount");

Python (oracledb)

Python は int 型が任意精度、通常問題なし:

import oracledb

with oracledb.connect(user=u, password=p, dsn=d) as conn:
    cursor = conn.cursor()
    cursor.execute("SELECT COUNT(*) FROM huge_table")
    count, = cursor.fetchone()
    print(f"Count: {count}")   # Python int は任意精度

明示的な型指定:

cursor.outputtypehandler = lambda c, name, dt, s, p, sc: (
    cursor.var(int) if dt == oracledb.DB_TYPE_NUMBER else None
)

実践シナリオ

シナリオ1：本番の緊急対応

-- STEP 1: エラー発生列特定
SELECT column_name, data_type, data_precision, data_scale
FROM user_tab_columns 
WHERE table_name = 'MY_TABLE';

-- STEP 2: データ範囲確認
SELECT MIN(problematic_col), MAX(problematic_col) 
FROM my_table;

-- STEP 3: 21億超の値があれば
SELECT COUNT(*) FROM my_table 
WHERE problematic_col > 2147483647;

-- STEP 4: Java 側修正 or 統計情報リセット

シナリオ2：Java コード修正

// 修正前
public int getUserCount() {
    try (Statement stmt = conn.createStatement();
         ResultSet rs = stmt.executeQuery("SELECT COUNT(*) FROM users")) {
        rs.next();
        return rs.getInt(1);   // ❌ 21億超で ORA-01455
    }
}

// 修正後
public long getUserCount() {
    try (Statement stmt = conn.createStatement();
         ResultSet rs = stmt.executeQuery("SELECT COUNT(*) FROM users")) {
        rs.next();
        return rs.getLong(1);   // ✅ 長期運用対応
    }
}

シナリオ3：SAP 環境の統計情報リセット

-- SAP DBA タスク
BEGIN
  FOR r IN (SELECT table_name FROM dba_tab_modifications 
            WHERE table_owner = 'SAPSR3'
              AND (inserts + updates + deletes) > 2000000000) LOOP
    DBMS_STATS.gather_table_stats(
      ownname => 'SAPSR3',
      tabname => r.table_name,
      estimate_percent => 0.1
    );
  END LOOP;
END;
/

シナリオ4：Rails でのマイグレーション時

# migration
class ChangeUserIdToLong < ActiveRecord::Migration[8.0]
  def change
    # Integer → BigInt
    change_column :users, :id, :bigint
  end
end

Rails 8 系の詳細は Rails 8 アップグレードガイドの記事、find/find_by/where の記事も参照してください。

シナリオ5：Python 大量データ処理

import oracledb
from decimal import Decimal

with oracledb.connect(user=u, password=p, dsn=d) as conn:
    cursor = conn.cursor()
    
    # 大きな数値も安全に処理
    cursor.execute("""
        SELECT id, transaction_amount 
        FROM transactions 
        WHERE created_at > TRUNC(SYSDATE - 30)
    """)
    
    total = Decimal(0)
    for row in cursor:
        total += row[1]   # Python の任意精度 int / Decimal
    
    print(f"Total: {total}")

シナリオ6：ETL パイプライン

-- ❌ 14桁数値化アンチパターン
INSERT INTO staging
SELECT TO_NUMBER(TO_CHAR(created_at, 'YYYYMMDDHH24MISS')), name
FROM source;

-- ✅ 日付型のまま
INSERT INTO staging
SELECT created_at, name FROM source;

-- または文字列
INSERT INTO staging
SELECT TO_CHAR(created_at, 'YYYY-MM-DD HH24:MI:SS'), name
FROM source;

シナリオ7：Docker Oracle テスト

docker exec -it oracle-xe sqlplus scott/tiger <<EOF
DECLARE
  v_num PLS_INTEGER;
BEGIN
  v_num := 3000000000;
END;
/
-- ORA-01455: PLS_INTEGER に 30 億は入らない

-- 修正
DECLARE
  v_num NUMBER;
BEGIN
  v_num := 3000000000;
END;
/
EOF

Docker 関連は docker daemon 接続エラーの記事、Docker no space left on device の記事も参照してください。

シナリオ8：SEQUENCE の対応

-- SEQUENCE 現在値確認
SELECT sequence_name, last_number 
FROM user_sequences;

-- 21億超なら Java 側 long 対応必須

シナリオ9：Java Spring での対応

@Entity
public class Transaction {
    @Id
    @GeneratedValue(strategy = GenerationType.SEQUENCE)
    private Long id;   // Integer でなく Long
    
    @Column(name = "amount")
    private BigDecimal amount;   // int でなく BigDecimal
}

@Repository
public class TransactionRepo {
    @Autowired
    private JdbcTemplate jdbc;
    
    public long count() {
        return jdbc.queryForObject(
            "SELECT COUNT(*) FROM transactions", 
            Long.class   // Integer でなく Long
        );
    }
}

シナリオ10：Autonomous DB

Autonomous DB では
- NUMBER 型で自動昇格
- OCI ドライバ経由でも long 対応
- ただし Java int は同じ問題

トラブルシューティング

発生する SQL が特定できない

-- V$SQL_MONITOR で最近の失敗
SELECT sql_id, sql_text 
FROM v$sql
WHERE last_active_time > SYSDATE - 1/24
  AND sql_text LIKE '%TO_NUMBER%';

統計情報リセットしても再発

**根本原因（アプリのデータ型）**が未修正、Java コード側で getLong() に。

PL/SQL で PLS_INTEGER を使いたい

ループカウンタなど、確実に 21 億未満なら OK。

Rails / Django で自動対応

通常は自動、明示的に BigInteger/BigDecimal 使用でより安全。

Data Pump インポート

インポート時にオーバーフロー検知、事前に対象列型変更。

Data Pump の詳細は Oracle Data Pump 使い方の記事も参照してください。

レガシーコード修正が困難

View で ROUND / DIV で桁を減らす（一時対応）:

CREATE VIEW v_safe AS
SELECT id, ROUND(amount / 1000) AS amount_k FROM transactions;

よくある質問（FAQ）

Q1. INTEGER の上限

32-bit INTEGER: 2,147,483,647 (約 21 億)。

Q2. PLS_INTEGER vs NUMBER

• PLS_INTEGER: 高速、上限 21 億
• NUMBER: 汎用、任意精度

Q3. Java int vs long

• int: 32bit、21億まで
• long: 64bit、922京まで

Q4. Rails での対応

自動対応、稀に BigInteger 明示。

Q5. Python での対応

任意精度 int、通常問題なし。

Q6. TO_NUMBER(TO_CHAR(date)) アンチパターン

日付は日付型で扱う、無理に数値化しない。

Q7. SAP でのパターン

DBA_TAB_MODIFICATIONS カウンタ超過、DBMS_STATS でリセット。

Q8. SEQUENCE の対応

MAXVALUE 設定 + アプリ側 long 対応。

Q9. LOB のサイズ

long で受ける、int は 2GB 上限。

Q10. パフォーマンスへの影響

BigDecimal は int より遅い、必要時のみ使用。

Q11. Autonomous DB での挙動

同じ。アプリ側の型対応が必要。

Q12. 予防策

• Java: long / BigDecimal 優先
• PL/SQL: 疑わしいなら NUMBER
• 日付: 数値化避ける
• 定期的な統計情報リセット

参考リンク

Oracle 公式

• Oracle Database Error Messages: ORA-01455
• Oracle Database SQL Language Reference: Numeric Data Types
• Oracle Database PL/SQL Language Reference: PL/SQL Data Types
• JDBC Developer’s Guide: Data Types

まとめ

ORA-01455: converting column overflows integer datatype の要点を再整理します。

エラーの本質

Oracle NUMBER 値が受け側の integer 型（32bit）に収まらない
→ 21 億超の値
→ Java int, PL/SQL PLS_INTEGER 等

エラーメッセージの読み方

ORA-01455: converting column overflows integer datatype
                             ↑                    ↑
                        列変換で              整数型オーバーフロー

INTEGER の上限

32-bit signed:  2,147,483,647  ≈ 21 億
32-bit unsigned: 4,294,967,295 ≈ 42 億
64-bit signed:  9,223,372,036,854,775,807 ≈ 922 京

10大原因

5つの解決策

// ① Java getLong() / getBigDecimal()
long val = rs.getLong("col");
BigDecimal val = rs.getBigDecimal("col");

-- ② PL/SQL NUMBER 型
DECLARE
  v_count NUMBER;
BEGIN
  SELECT COUNT(*) INTO v_count FROM t;
END;

-- ③ DBMS_STATS 実行（SAP系）
BEGIN
  DBMS_STATS.gather_table_stats(
    ownname => 'SCHEMA',
    tabname => 'TABLE',
    estimate_percent => 0.1
  );
END;

-- ④ スケール調整
TO_NUMBER(TO_CHAR(date, 'YYYYMMDD'))   -- 8桁

-- ⑤ TO_CHAR で文字列化
TO_CHAR(date, 'YYYY-MM-DD HH24:MI:SS')

データ型サイズ比較

各言語での対応

Java:   int → long / BigDecimal
Rails:  自動対応、稀に BigInteger
Python: 任意精度 int、通常問題なし
PL/SQL: PLS_INTEGER → NUMBER
C++:    int → long long, SQLT_NUM

予防のポイント

1. Java の int は避け、long / BigDecimal 優先
2. PL/SQL の PLS_INTEGER は上限確認
3. 日付を数値化するアンチパターン避ける
4. SEQUENCE MAXVALUE 設定
5. 定期的な統計情報リセット（SAP）
6. Rails は BigInteger 明示可
7. LOB サイズは long
8. マイグレーションで型拡張検討
9. CI/CD で大きい値のテスト
10. コードレビューで getInt() チェック

これらの知識は、Oracle でのアプリ開発・Java / Python / Rails 開発・PL/SQL 設計・SAP / PeopleSoft 運用・ETL パイプライン・大規模データ処理など、あらゆる場面で活用できます。本記事をブックマークしておけば、ORA-01455 に出会っても冷静に的確に対処できるようになります。

本記事は2026年6月時点の情報をもとに、Oracle Database 19c〜23ai での動作確認・公式ドキュメントに基づき作成しています。Oracle のバージョンにより挙動が異なる場合があるため、最新の情報は Oracle 公式ドキュメント（docs.oracle.com）もあわせてご確認ください。