「システム運用」タグアーカイブ

Oracle, データベース, トラブル対応, ブログ

ORA-12541の原因と対処法｜「TNS: リスナーがありません。」エラーを最速で解決する方法

2025年11月13日管理者コメントする

Oracle接続時に突然出る ORA-12541: TNS: リスナーがありません。
現場でも頻出するエラーの1つで、接続テストが通らない・アプリがDBに繋がらないなどのトラブルを引き起こします。

この記事では、最速で復旧するためのチェック手順 → 原因の深掘り → 正しい対処法をわかりやすくまとめます。

結論：ほとんどは「リスナーが動いていない or 設定が不一致」

ORA-12541 は、Oracle に接続する際の窓口である Listener（リスナー） が見つからない時に発生します。

主な原因は以下のどれかです。

リスナーサービスが停止している
listener.ora のホスト名／ポート構成が間違っている
tnsnames.ora のHOST/IPが一致していない
ファイアウォールで1521ポートが遮断
サーバIPの変更後に設定未修正（Windows/VM/クラウドで多い）

では最速で治すチェック順を紹介します。

1. 最速で直す！ORA-12541のチェック手順（5ステップ）

① リスナーサービスが停止していないか確認

Windows

サービス → OracleOraDB…TNSListener を確認
停止していたら「開始」を押す。

で状態が確認できます。

Linux

TNS-12541: TNS:no listener が返った場合はリスナーが死んでいます。

② リスナーを再起動する

Windows / Linux 共通

成功すればほとんどのケースはこれで復旧します。

③ listener.ora のHOST/IPが本当に正しいか確認

リスナーが動いていても、設定されているホスト名が正しくないとリスナーは動作しません。

例：ホスト名変更後に listener.ora を更新していないケース

が myserver01 なのに一致していない → ORA-12541

IPアドレス変更後に放置している場合も同じです。

④ tnsnames.ora の接続先HOST/IPが一致しているか

クライアント側の設定が間違っていると当然繋がりません。

→ listener.ora 側と一致しているか要確認。

⑤ ポート（1521）がファイアウォールで塞がれていないか

Windows Firewall
Linux firewalld
クラウド（AWS SecurityGroup、Azure NSG など）

で 1521 が閉じていると ORA-12541 になります。

2. ORA-12541 が発生する代表的な原因まとめ

✔ リスナーが起動していない（最も多い）

DBサーバの再起動後に自動で上がっていない、手動停止したなど。

✔ listener.ora と tnsnames.ora の不整合

HOST名が一致していない
PORTが違う
サービス名（SERVICE_NAME）が間違い

設定変更後の再起動忘れもよくあります。

✔ DNS・ホスト名解決の問題

ホスト名を指定しているが DNS で解決できないケース。
→ IPアドレス直書きで繋がれば DNS が原因。

✔ VM・クラウドのIP変更

Oracle XE や開発環境で特に多い事例。
IPが変わったのに listener.ora を更新していないパターン。

3. 対処法まとめ（状況別）

🔧 ① リスナー停止が原因 → 再起動でOK

🔧 ② listener.ora の設定ミス → 修正 → リスナー再起動

ファイル場所

Windows: C:\oracle\product\...\network\admin\listener.ora
Linux: $ORACLE_HOME/network/admin/listener.ora

🔧 ③ tnsnames.oraが間違い → 修正

接続文字列を見直して、listener.ora と整合性を取る。

🔧 ④ ポート塞ぎ → FWで1521を許可

クラウド環境では SecurityGroup / NSG も要確認。

🔧 ⑤ DNS問題 → HOST をIPに変更する

接続先を一時的にIPにすると原因切り分けになる。

4. 再発防止のためのポイント

サーバ再起動後の リスナー自動起動設定を確認
listener.ora／tnsnames.ora の バックアップ運用
接続情報を IP指定 に統一する（開発環境向け）
FW設定変更の履歴をチームで共有

5. まとめ

ORA-12541「TNS:リスナーがありません。」 は、
リスナーが動いていない or 設定不一致が原因の9割です。

✔ 最速で確認すべきは以下の5つ

lsnrctl status
リスナーサービスの起動確認
listener.ora のHOST/IP
tnsnames.ora の整合性
ポート1521の開放

HULFT, Web開発, ブログ

HULFTの転送速度を理論値で算出する方法：単独転送と間欠転送で何が変わる？

2025年11月13日管理者コメントする

HULFTで大容量ファイルを送信する際、
「単独転送と間欠転送では速度がどれくらい違うのか？」
と気になる場面は多いはずです。

特に、S3送信やネットワーク負荷対策で間欠転送を設定した場合、
「どれだけ転送時間が増えるのか？」を事前に把握しておきたいところです。

本記事では、HULFTの転送処理を理論値（数式）で算出する方法をわかりやすく解説します。

1. HULFT転送の基本：ブロック単位で送られる

HULFTはファイルをそのまま送るのではなく、
一定サイズ（ブロック長）に分割してブロック単位で送信します。

例えばブロック長を 16KB に設定している場合：

1ブロック = 16KB
1MBのファイルなら 1,048,576 ÷ 16,384 ≒ 64ブロック

という計算になります。

この「ブロック数 × ブロックあたりの処理時間」が転送時間に大きく影響します。

2. 単独転送の理論値：最速で送るシンプルな動作

単独転送（=間欠転送なし）は、
ブロックを休まず連続で送っていく動作です。

■ 単独転送の理論値計算式

※実効転送速度（Throughput）はネットワーク・HULFTヘッダなどのオーバーヘッドを含む実測値。

■ 例：500MBのファイルを100Mbpsで送信する場合

理論上は40秒となります。

実際にはHULFTヘッダ分のオーバーヘッドで数秒増える程度。

3. 間欠転送の理論値：休止時間の積み重ねで大幅に遅くなる

間欠転送は、各ブロック送信後に**休止時間（インターバル）**が入ります。

HULFTの設定例：

ブロック長：16KB
ブロック回数：100回
休止時間：30ms

■ 間欠転送の理論計算式

ここが最も重要なポイント。

ブロックが多い場合、休止時間が膨れ上がります。

4. 実例：500MBファイルを間欠転送で送るとどうなる？

★ 前提

ブロック長：16KB
500MB = 32,768ブロック
単独転送時間：40秒（前述）
休止時間：20ms

■ 間欠転送の追加時間

■ 合計転送時間

→ 実際の現場でも「間欠転送は数倍遅くなる」理由はここにある

ブロック数 × 休止時間 → これが爆発的に効いてくるためです。

5. 実効転送速度（Throughput）の簡易算出方法

実測値を1回取るだけで、理論値がもっと正確になります。

■ 実測からの計算式

例えば

100MBのファイル
送信実測15秒
→ 実効速度 = 100MB ÷ 15 = 6.6MB/s（53Mbps）

これを単独転送の基準値にすることで、
間欠転送の予測精度が向上します。

6. 間欠転送の「適切な使いどころ」

間欠転送は遅くなるため万能ではありませんが、
以下の目的では効果的です。

S3/クラウド側で転送速度制限がある場合
受信側の負荷分散が必要な場合
夜間バッチでNW帯域を食いすぎるのを避けたい時
他システムの処理性能に合わせたいケース

速度ではなく安定性や負荷分散を目的に使うのが本来の用途。

7. 間欠転送設定によるエラー（S3Timeout など）について

休止時間を入れると、
1ブロックあたりの処理が遅くなる → 全体が長くなる → タイムアウトに近づく
という問題があります。

特にS3送信では

S3Timeout（約60秒）
NW機器の制限
プロキシのタイムアウト

などに引っかかるケースが多い。

✔ 大容量ファイルほど間欠転送はリスクが高い

500MB・1GB級のファイルではブロック数が膨大になるため、
一気にタイムアウト領域に入ります。

まとめ

項目	単独転送	間欠転送
速度	最速	休止時間分だけ遅い
仕組み	ブロックを連続送信	ブロック送信→休止の繰り返し
理論値算出	単独転送時間のみ	単独転送＋(ブロック数×休止時間)
メリット	最速で送れる	負荷を抑え安定性を上げる
デメリット	帯域を多く使う	極端に遅く、タイムアウトを誘発

PowerShell, ブログ, プログラミング

PowerShellでログ収集とバックアップを自動化する実践スクリプト

2025年10月28日管理者コメントする

システム運用や開発現場では、ログ収集やバックアップ作業を「手動で行う」ケースがまだ多く残っています。しかし、PowerShellを使えばこれらを自動化し、毎日の定型作業を一気に効率化できます。

この記事では、**「ログを自動収集してバックアップするPowerShellスクリプト」**を実例付きで紹介します。
スクリプトはWindows環境でそのまま動作し、日次・週次の定期ジョブとしても活用可能です。

⚙️ 実践スクリプト：ログ収集＆バックアップ自動化

以下のスクリプトは、

ログフォルダをスキャン
日付別フォルダにコピー
古いバックアップを自動削除
する一連の処理を行います。

# ============================
# PowerShell ログ収集＆バックアップ自動化スクリプト
# ============================

# 設定項目
$SourceDir  = "C:\Logs"                     # 元ログフォルダ
$BackupRoot = "D:\Backup\Logs"              # バックアップ先ルート
$KeepDays   = 30                            # 保持期間（日数）

# 日付フォルダ名 (例: 20251028)
$Today = (Get-Date).ToString("yyyyMMdd")
$BackupDir = Join-Path $BackupRoot $Today

# バックアップフォルダ作成
if (!(Test-Path $BackupDir)) {
    New-Item -ItemType Directory -Path $BackupDir | Out-Null
    Write-Host "バックアップフォルダを作成しました: $BackupDir"
}

# ログファイルをコピー
Write-Host "ログ収集中..."
Get-ChildItem -Path $SourceDir -Filter "*.log" -Recurse | ForEach-Object {
    $dest = Join-Path $BackupDir $_.Name
    Copy-Item $_.FullName $dest -Force
}
Write-Host "コピー完了。"

# 古いバックアップ削除
Write-Host "古いバックアップを削除中..."
Get-ChildItem -Path $BackupRoot -Directory | Where-Object {
    $_.Name -match "^\d{8}$" -and
    (Get-Date($_.Name.Substring(0,4)+'-'+$_.Name.Substring(4,2)+'-'+$_.Name.Substring(6,2))) -lt (Get-Date).AddDays(-$KeepDays)
} | ForEach-Object {
    Remove-Item $_.FullName -Recurse -Force
    Write-Host "削除: $($_.FullName)"
}

Write-Host "バックアップ処理が完了しました。"

# ============================

# PowerShell ログ収集＆バックアップ自動化スクリプト

# ============================

# 設定項目

$SourceDir = "C:\Logs" # 元ログフォルダ

$BackupRoot = "D:\Backup\Logs" # バックアップ先ルート

$KeepDays = 30 # 保持期間（日数）

# 日付フォルダ名 (例: 20251028)

$Today = (Get-Date).ToString("yyyyMMdd")

$BackupDir = Join-Path $BackupRoot $Today

# バックアップフォルダ作成

if (!(Test-Path $BackupDir)) {

New-Item -ItemType Directory -Path $BackupDir | Out-Null

Write-Host "バックアップフォルダを作成しました: $BackupDir"

}

# ログファイルをコピー

Write-Host "ログ収集中..."

Get-ChildItem -Path $SourceDir -Filter "*.log" -Recurse | ForEach-Object {

$dest = Join-Path $BackupDir $_.Name

Copy-Item $_.FullName $dest -Force

}

Write-Host "コピー完了。"

# 古いバックアップ削除

Write-Host "古いバックアップを削除中..."

Get-ChildItem -Path $BackupRoot -Directory | Where-Object {

$_.Name -match "^\d{8}$" -and

(Get-Date($_.Name.Substring(0,4)+'-'+$_.Name.Substring(4,2)+'-'+$_.Name.Substring(6,2))) -lt (Get-Date).AddDays(-$KeepDays)

} | ForEach-Object {

Remove-Item $_.FullName -Recurse -Force

Write-Host "削除: $($_.FullName)"

}

Write-Host "バックアップ処理が完了しました。"

📦 処理の流れ

処理	内容
① 初期設定	ログフォルダ・バックアップフォルダ・保持日数を設定
② 日付フォルダ作成	yyyyMMdd形式で新しいバックアップフォルダを作成
③ ログコピー	対象フォルダからすべての.logファイルをコピー
④ 古いフォルダ削除	30日より古いフォルダを自動削除

🕒 定期実行する方法（Windows タスクスケジューラ）

Windows検索バーで「タスクスケジューラ」と入力して起動
「基本タスクの作成」→ タスク名を「ログバックアップ」とする
「毎日」または「毎週」を選択
「操作」で「プログラムの開始」を選択し、以下を指定

Program/script: powershell.exe Add arguments: -File "D:\Scripts\log_backup.ps1"
完了後、右クリック → 「プロパティ」 → 「最上位の特権で実行する」を有効にする

💡 応用ポイント

ZIP圧縮も追加可能：Compress-Archiveを使ってバックアップサイズを削減
ログローテーション：ファイルサイズや日付で自動的にローテーションするよう拡張可能
メール通知：バックアップ完了後にSend-MailMessageで報告を送信可能
CSVやJSON対応：ログ形式が異なる場合もGet-Content＋ConvertFrom-Jsonなどで加工可能

🚀 まとめ

PowerShellを使えば、GUI操作では面倒なログバックアップを簡潔に自動化できます。
1日1回の定期タスクに登録するだけで、手動の手間を大幅削減。
運用の安定化にもつながります。

ポイント：小さなスクリプトでも「業務時間を削減」できるのがPowerShellの強みです。

HULFT, トラブル対応, ブログ

HULFTで「完了コード250 エラー」が発生したときの対応手順

2025年9月20日管理者コメントする

HULFT (UNIX/Linux 環境) でファイル配信を行った際、「完了コード250」が返されることがあります。公式ドキュメントではこのコードを “A server error” としており、集信側（受信側）で異常が発生したことを示しています。⇒ HULFT

本記事では、完了コード250の意味、原因、公式で推奨されている対処方法、実践的なチェックポイント、および再発防止策をまとめます。

完了コード250とは？

項目	内容
エラーコード	250
英語名称	A server error HULFT
意味	「集信側に異常が発生したと考えられます」 HULFT
詳細	完了コード250が設定された場合、さらに詳細コードが設定されており、それが集信側の完了コードとなります。 HULFT

つまり、完了コード250は「送信側から配信は試みられたが、受信側で何かしら正常でない処理が起きて失敗した」ということを示す総称的なエラーで、原因の切り分けには “詳細コード” を見る必要があります。HULFT

主な原因（公式の可能性を含む）

ドキュメントに明記されている「完了コード250 → 集信側に異常が発生」の具体的な事例としては以下があげられます。これらは「詳細コード」によってどのような異常かが特定されます。HULFT

ディスク容量不足など、受信側で書き込みができない状態 HULFT
ファイルアクセス権限エラーやファイルロック状態 HULFT
テキスト転送で「1 レコードのデータ長が最大値を超えている」 HULFT
配信途中でファイルの編集や移動・削除など、ファイルの整合性が保てなくなる操作が行われた場合 HULFT
フォーマットミスマッチ・バージョン不一致など、データ形式やコードセットに関する不整合 HULFT

対応手順（公式の指示＋実践的対応）

以下は、公式ドキュメントの「対処（処置）」に加えて現場でよく使われるチェック項目を織り交ぜた手順です。

ステップ 1：ログ・詳細コードの確認

HULFT の hulog、trnlog もしくは配信ログを確認
完了コードが 250 の行を探す
その行に 詳細コード（集信側の完了コード）が記録されているか確認 HULFT
詳細コードに応じて原因の方向性を絞る

ステップ 2：受信側（集信側）の環境チェック

以下を重点的に確認します。

項目	チェック内容
ディスク容量	受信ディレクトリのあるファイルシステムの空き容量を確認
ファイルアクセス・ロック	該当ファイル名が他プロセスにより使用中でないか、書き込み権限があるか
ファイル操作	配信中に受信側でファイルを移動・削除・名前変更などしていないか
フォーマット・レコード長	テキスト転送時に1レコードの長さが制限（32768バイト）を超えていないかなど HULFT
バージョン・コードセット	転送や受信のフォーマット定義、文字コード変換などが正しく一致しているか

ステップ 3：通信経路・送受信設定の確認

ネットワーク切断、遅延、ファイアウォールによる通信遮断等の影響がないか
送信側・受信側両方の HULFT 定義（配信パラメータ、フォーマットID、文字コードなど）が整合しているか
マウントされているネットワークファイルシステム（NFS等）を使っている場合、属性キャッシュやマウントオプションが影響していないか確認 HULFT

ステップ 4：修正・再実行

問題箇所が見つかったら修正（空き容量確保、権限修正、ファイルの整合性維持、フォーマット修正など）
修正後、再度配信ジョブを実行
再送前に、テスト環境や限定ファイルで動作を確認できるならそれを行う

再発防止策

公式仕様と実践双方から以下が有効です：

監視体制の整備
- ディスク容量の自動監視
- ファイルシステムの状態／マウントオプションの監視
- HULFT ジョブのステータス監視（完了コードを含む）
設定の標準化とレビュー
- フォーマット定義・文字コード・レコード長などをドキュメント化
- 新しいノードや定義を追加する際のチェックリストを整備
テスト運用
- 転送前に小さなデータでテスト送受信を行う
- 大容量／長レコード／特殊文字を含むデータの事前検証
エラー通知システムの活用
- 完了コード250やその詳細コードをトリガーにアラートをあげるように設定
- 関係者に通知が行くようにすることで早期対応

ケーススタディ（想定例）

例 1：テキストファイルの 1 レコードが長すぎる

ある送信ジョブで、伝票データを1行にまとめすぎてしまい、1 レコードの文字数が制限（32,768バイト）を超えていた → 詳細コードが 251 の可能性あり。HULFT
対策：レコードを分割するか、フォーマットを見直す

例 2：受信側のディスクフル

受信サーバ上のディスク容量がゼロ近く、書き込みができずにエラー
対策：不要ファイルの削除、ディスク拡張、ログのローテーション設定など

まとめ

完了コード 250 は「受信側での異常」を示し、詳細コードにより原因の絞り込みが可能
ログの確認 → 環境チェック → 設定見直し → 修正・再実行が基本の流れ
再発防止のための監視・標準化・テストが重要

Web開発, Windowsバッチ, その他, ブログ

Windowsバッチで西暦8桁・月日2桁のゼロ埋め日付を出力する方法

2025年9月13日管理者コメントする

バッチ処理を作成するときに、ログファイル名やバックアップファイル名に日付を付与するケースはよくあります。その際「20250913」のように 西暦8桁（YYYYMMDD形式） でゼロ埋めされた日付を出力したいことがあります。
この記事では、Windowsバッチでゼロ埋めした日付を取得する方法を紹介します。

基本的な考え方

Windowsバッチでは %date% 変数を使うことで、現在の日付を取得できます。ただし環境によって表示形式が異なり、例えば以下のようになります。

日本語ロケール（Windows 10/11 既定）

2025/09/13
英語ロケール

Sat 09/13/2025

このため、文字列の位置を指定して切り出す必要があります。

実用例：西暦8桁＋月日2桁のゼロ埋め

以下のバッチスクリプトでは、YYYYMMDD 形式で日付を取得します。

実行結果（2025年9月13日の場合）

応用：時刻と組み合わせて使う

ファイル名などで「日付＋時刻」を付けたい場合は、%time% も組み合わせられます。

@echo off set YMD=%date:~0,4%%date:~5,2%%date:~8,2% set HMS=%time:~0,2%%time:~3,2%%time:~6,2% REM 時刻の先頭スペースを除去（1桁時間帯対策） if "%time:~0,1%"==" " set HMS=0%time:~1,1%%time:~3,2%%time:~6,2% echo %YMD%_%HMS%

1	@echo off set YMD=%date:~0,4%%date:~5,2%%date:~8,2% set HMS=%time:~0,2%%time:~3,2%%time:~6,2% REM 時刻の先頭スペースを除去（1桁時間帯対策） if "%time:~0,1%"==" " set HMS=0%time:~1,1%%time:~3,2%%time:~6,2% echo %YMD%_%HMS%

実行例

ロケールに依存しない方法

環境によって %date% のフォーマットが変わるとバッチが動作しなくなることがあります。
その場合、wmic を使うとロケール非依存で日付を取得できます。

実行結果

まとめ

%date% を切り出す方法は簡単だがロケール依存。
確実性を求めるなら wmic を使うのがおすすめ。
日付はログやバックアップのファイル名に利用すると便利。

バッチで日付をゼロ埋めして扱うと、ファイルの並び順も自然になり管理がしやすくなります。
ぜひ日常の運用バッチに取り入れてみてください。

結論：ほとんどは「リスナーが動いていない or 設定が不一致」

1. 最速で直す！ORA-12541のチェック手順（5ステップ）

① リスナーサービスが停止していないか確認

Windows

Linux

② リスナーを再起動する

Windows / Linux 共通

③ listener.ora のHOST/IPが本当に正しいか確認

④ tnsnames.ora の接続先HOST/IPが一致しているか

⑤ ポート（1521）がファイアウォールで塞がれていないか

2. ORA-12541 が発生する代表的な原因まとめ

✔ リスナーが起動していない（最も多い）

✔ listener.ora と tnsnames.ora の不整合

✔ DNS・ホスト名解決の問題

✔ VM・クラウドのIP変更

3. 対処法まとめ（状況別）

🔧 ① リスナー停止が原因 → 再起動でOK

🔧 ② listener.ora の設定ミス → 修正 → リスナー再起動

ファイル場所

🔧 ③ tnsnames.oraが間違い → 修正

🔧 ④ ポート塞ぎ → FWで1521を許可

🔧 ⑤ DNS問題 → HOST をIPに変更する

4. 再発防止のためのポイント

5. まとめ

✔ 最速で確認すべきは以下の5つ

関連記事

1. HULFT転送の基本：ブロック単位で送られる

2. 単独転送の理論値：最速で送るシンプルな動作

■ 単独転送の理論値計算式

■ 例：500MBのファイルを100Mbpsで送信する場合

3. 間欠転送の理論値：休止時間の積み重ねで大幅に遅くなる

■ 間欠転送の理論計算式

4. 実例：500MBファイルを間欠転送で送るとどうなる？

★ 前提

■ 間欠転送の追加時間

■ 合計転送時間

→ 実際の現場でも「間欠転送は数倍遅くなる」理由はここにある

5. 実効転送速度（Throughput）の簡易算出方法

■ 実測からの計算式

6. 間欠転送の「適切な使いどころ」

7. 間欠転送設定によるエラー（S3Timeout など）について

✔ 大容量ファイルほど間欠転送はリスクが高い

まとめ

関連記事

⚙️ 実践スクリプト：ログ収集＆バックアップ自動化

📦 処理の流れ

🕒 定期実行する方法（Windows タスクスケジューラ）

💡 応用ポイント

🚀 まとめ

関連記事

完了コード250とは？

主な原因（公式の可能性を含む）

対応手順（公式の指示＋実践的対応）

ステップ 1：ログ・詳細コードの確認

ステップ 2：受信側（集信側）の環境チェック

ステップ 3：通信経路・送受信設定の確認

ステップ 4：修正・再実行

再発防止策

ケーススタディ（想定例）

例 1：テキストファイルの 1 レコードが長すぎる

例 2：受信側のディスクフル

まとめ

関連記事

基本的な考え方

実用例：西暦8桁＋月日2桁のゼロ埋め

実行結果（2025年9月13日の場合）

応用：時刻と組み合わせて使う

実行例

ロケールに依存しない方法

実行結果

まとめ

関連記事

「駑馬十駕」を信念に IT系情報を中心に調べた事をコツコツ綴っています。

　関連記事

　関連記事

　関連記事

　関連記事

　関連記事