IBM DB2 UDBとOracleのバックアップおよびリカバリーの比較

レベル：入門

アラン W. サム(thamawh@my.ibm.com)
DB2プリセールス・テクニカル・スペシャリスト、ASEAN Techline、IBMマレーシア

2004年7月22日

コンテンツ はじめに バックアップおよびリカバリーの概念 バックアップおよびリカバリーに用いられるデータ構造 バックアップおよびリカバリーのオプション バックアップおよびリカバリーのユーティリティー リカバリー・ケースのシナリオ まとめ 関連資料 著者について

使用しているデータベース管理システムに関係なく、バックアップ・リカバリー戦略はデータ損失を防ぐために不可欠です。この記事はOracleのスキルを持ち、新たにIBM DB2^® Universal Database^TM (UDB) を扱うDBA（データベース管理者）を対象としており、バックアップおよびリストアの機能のDB2 UDB for Linux、UNIX^® and Windows^® での動作を説明します。さらに、DB2 UDBとOracleにおけるバックアップとリカバリーの詳細な比較も行います。

はじめに

Oracleのスキルをお持ちでこれからDB2に触れるという方であれば、DB2 UDBにおけるバックアップとリカバリーの動作は簡単に理解できるでしょう。ここでは、DB2 UDB for Linux、DB2 UDB for UNIXおよびDB2 UDB for Windowsでのバックアップとリカバリーの動作について説明し、Oracleでのこれら機能の動作と比較対照を行います。

ここでは、OracleとDB2 UDBの両方のバックアップおよびリカバリーの以下の側面について説明します。

• バックアップおよびリカバリーの概念
• バックアップおよびリカバリーに用いられるデータ構造
• バックアップおよびリカバリーのオプション
• バックアップおよびリカバリーのユーティリティー
• リカバリー・ケースのシナリオ

バックアップおよびリカバリーの概念

データベースのバックアップとは、障害が発生した場合にすぐリストアできるデータベースのコピーと制御情報を合わせたものを言います。データベース・バックアップによってデータ損失を最小限にとどめ、リカバリー・プロセスを用いてバックアップ・コピーから障害を起こしたデータベースを再構築することが可能になります。

データベースのリカバリーが必要となる障害にはいろいろな種類があります。しかし、すべての種類の障害で人の介入が必要となるわけではありません。直面する可能性のある障害の種類を以下に挙げます。

• ステートメント障害
  ステートメント障害は、アプリケーションで論理ステップに誤りがある場合に起こります。この障害にはいくつかの原因があります。例えば、ステートメントが無限ループで実行されている、特定のタスクを実行するために必要な正しい特権がユーザーにない（このため有効なステートメントが実行できない）、スペース不足による挿入障害などです。
  
  Oracleでは、ステートメント障害が発生しても通常は、ディスク・スペースの追加、アプリケーション論理の修正、または適切なユーザー特権の割当てなどの最小限のタスクの実行を除けば管理者は必要ありません。DB2 UDBでもステートメント障害は同様に処理されます。バックアップとリカバリーに関しては、管理者がステートメント障害を解決する必要はありません。
  
  
• ユーザー・エラー
  給与表全体を削除する、請求表を除去する、あるいはデータベース全体を不用意に除去してしまうなどの、有効であっても破壊的なステートメントによって、使用しているデータベース・アプリケーションのダウン・タイムは長くなります。これらのエラーを避けるためには適切な研修とガイダンスだけでは不十分です。データ定義言語（DDL）ステートメントはロールバックできるステートメントではありません。したがって、ユーザー・エラーにDDLが関わる場合には、データベースを正常に戻すには適切な処置が必要となります。
  
  例えば、表が誤って除去された場合、管理者としては2つの選択肢があります。バックアップ・イメージのコピーを使用して表が除去される直前にロールフォワードする（ポイントインタイム・リカバリー）、あるいはexpユーティリティーを用いて論理バックアップをリストアするのいずれかです。どちらのオプションでもデータの損失につながる可能性があります。
  
  ユーザーがDB2 UDBの表を除去した場合、データベース・レベルのポイントインタイム・リカバリーを行ってその表が除去される前の時点にロールフォワードするか、あるいはより適切な選択として、表スペース・レベル・ロールフォワードを用いるかのいずれかを行うことができます。こうすれば、データベースをダウンさせる必要はなく、ユーザーはデータに引き続きアクセスできます。これについては「シナリオ」のセクションで説明します。
  
  
• プロセス障害
  ユーザー・プロセス、サーバー・プロセス、あるいはバックグラウンド・プロセスの障害は、異常終了またはこれらのプロセスの切断が原因です。プロセスの障害が発生すると、タスクを継続できなくなります。
  
  Oracleでプロセス障害が起こった場合、Oracle PMONバックグラウンド・プロセスがこのような異常終了したプロセスを定期的にモニターしているため、人の介入は不要です。ユーザー・プロセスとサーバー・プロセスの場合には、PMONがユーザーが保持しているロックを解放し、すべてのコミットされていないトランザクションをロールバックして、そのプロセスで使用されているリソースがあればそれを解放します。Oracleバックグラウンド・プロセスが異常終了すると、たいていの場合、インスタンスの再起動が必要となります。
  
  DB2 UDBでは、db2agentが非活動状態になるなどのプロセス障害があるとクラッシュ・リカバリーが行われます。クラッシュ・リカバリーでは、コミットされていないトランザクションはロールバックされると同時に、コミット済みのデータはディスクにフラッシュされます。この自動クラッシュ・リカバリー機能を使用可能に設定するには、データベース構成パラメーターのautorestartがONに設定されていることを確認してください。デフォルトで、autorestartはONです。
  
  
• データベース・インスタンス障害
  データベース・インスタンス障害は通常、オペレーティング・システムのクラッシュまたは停電によって生じます。
  
  Oracleでデータベース・インスタンスの障害が起こった場合、Oracle SMONバックグラウンド・プロセスがマシンの再起動直後に問題を検知するため、人の介入は不要です。SMONがインスタンス・リカバリーを開始します。
  
  DB2では、停電、ディスク破壊、またはネットワーク障害のためにデータベース・マネージャーとメモリー構造がダウンした場合、DB2を整合性のある利用可能な状態にリカバリーするためにはクラッシュ・リカバリーが必要となります。この自動クラッシュ・リカバリー機能を使用可能にするためには、データベース構成パラメーターautorestartがONに設定されていることを確認してください。デフォルトで、autorestartはONです。RESTART DATABASEコマンドを発行してデータベースを手動で再起動することもできます。RESTART DATABASEコマンドは、アクティブ・ログを使用して、まだコミットされていない変更をロールバックします。すでにコミット済みであってもディスクにフラッシュされていない変更はディスクにフラッシュされます。
  
  
• メディア障害
  メディア障害は、誰かが誤ってデータベース・ファイルをファイル・システムから削除してしまい、ハード・ディスク全体がそのデータ・ファイルと共にダウンして、その結果データがアクセス不能になるか、単にデータの破壊が生じた場合に起こります。これは先に説明したものに比べてより重大な種類の障害です。
  
  Oracleの場合、メディア障害のリカバリーには管理者が必要です。通常、メディア障害は、データ・ファイルが完全に失われるか、SCNタイムスタンプがデータベースの他の部分と同期していない場合のいずれかが原因で起こります。この種の障害のリカバリーは状況によって異なり、主としてアーカイブのモードと破壊されたデータ・ファイルによって決まります。
  
  この障害は、オフラインまたはオンラインのバックアップのいずれかをリストアし、ロールフォワード操作を用いてログをリカバリーすることにより、DB2 UDBでもOracleでもほぼ同様に処理されます。
  

メディア障害はすべての障害の中でも最も複雑であるため、これに対応する計画を立てるには緻密な戦略が必要です。これ以後は、このメディア障害に対応する計画とリカバリーについて説明します。

バックアップおよびリカバリーに用いられるデータ構造

OracleとDB2 UDBのどちらにも、バックアップおよびリカバリーの機構を構成する一群のコンポーネントがあります。図1と図2に示すアーキテクチャー・ダイヤグラムは、OracleとDB2でのバックアップおよびリカバリーを実現するために使用されている主要コンポーネントを示します。

図1 Oracleのアーキテクチャー

Oracleのメモリー構造

• Buffer Cache：　物理的データ・ファイルから読み取ったデータ・ブロックを保存するために割り当てられたメモリー
• Shared Pool：　構文解析されたSQLステートメント、PL/SQLプロシージャー、およびディクショナリー情報を保存するために割り当てられたメモリー
• Log Buffer：　変更されたデータの前後のイメージを保存するために割り当てられたメモリー。入力は、順次書き込まれます。
• Large Pool：　RMANによるバックアップおよびリカバリーでの使用のために割り当てられたメモリー

Oracleのバックグラウンド・プロセス

• Database Writer (DBWr)：　バッファのダーティー・ビットを非同期で物理的データ・ファイルに書き込みます。
• Log Writer (LGWr)：　ログ・バッファからの入力を書き込んでログ・ファイルを再構成します。
• CheckPoint (CKPt)：　データ・ファイルと制御ファイルのヘッダーを現在のREDOログとチェックポイント番号に同期します。
• Archiver (ARCH)：　REDOログのコピーを自動化します。これがオンでない場合は、REDOログの手動アーカイブが必要です。

Oracleのデータベース構造

• データ・ファイル：　データが保存される物理的ファイル
• 制御ファイル：　絶対パス付きのデータ・ファイル名やログ・ファイル名、ファイルのサイズ、ブロックのサイズ、データ・ファイルの状況がオンラインかオフラインかなどの、データベースの物理的構造と状況を格納するファイル。ファイル名やログ・ファイルのパス、ファイル・サイズ、ブロック・サイズも含みます。
• REDOログ：　変更されたデータの前後のイメージを格納するファイル。REDOログはリカバリーに必要です。
• パラメーター・ファイル：　インスタンスの起動用のパラメーターを保存するファイル。インスタンスは複数の方法で起動できるようにできます。Oracleは最初にspfile_SID.oraが存在するかどうかを調べます。これが存在しない場合、spfile.oraパラメーター・ファイルを探します。spfile_SID.oraとspfile.oraがどちらも存在しない場合、Oracleはinit_SID.oraパラメーター・ファイルを使用します。
• アーカイブ・ログ：　オンラインREDOログの物理的コピー。アーカイブされたログはオンライン・リカバリーに必要です。

次は、DB2 UDBのアーキテクチャーと構造を説明します。

図2　DB2 UDBのアーキテクチャー

DB2 UDBのメモリー構造

• Package Cache：　静的および動的なSQLステートメントの両方を保存するために使用されたメモリー
• Buffer Pool：　ディスクにフラッシュする前にデータを保存するために割り当てられたメモリー
• Log Buffer：　ディスク上のログにフラッシュする前にデータベースに対するすべての変更を保存するために割り当てられたメモリー

図3　DB2 UDBのデータベース構造

• ドライブ／ディレクトリー：　CREATE DATABASEコマンドで指定されたドライブまたはディレクトリー
• DB2インスタンス名：　DB2インスタンスのオーナー名
• NODE0000：　データベースのパーティション番号。パーティションのないデータベースは0です。
• SQL00001：　1から始まるデータベースID
• SQLOGDIR：　データベースのデフォルト・ログ・ディレクトリー
• SQLT0000.0：　カタログ表スペース、SYSCATSPACE
• SQLT0001.0：　一時表スペース、TEMPSPACE1
• SQLT0002.0：　ユーザー表スペース、USERSPACE1
  
  

バックアップおよびリカバリーのオプション

OracleデータベースとDB2 UDBデータベースのどちらにも、バックアップのモードが2つあります。すなわち、オフラインとオンラインです。どちらのモードでも、完全リカバリーまたは不完全リカバリーのいずれかが可能です。

オフライン・バックアップでは、すべてのアプリケーションがデータベースから切り離されていることが必要ですが、オンライン・バックアップではバックアップの進行中でもトランザクションを継続することができます。バックアップ・モードの選択がリストアに影響します。なぜなら、バックアップ・モードによってリカバリー・モードが決まるからです。これは後のセクションで説明します。

その名称が示すように完全リカバリーではすべてのコミット済みトランザクションがリカバリーされ、不完全リカバリーではトランザクションは元に戻りますが、データの一部は失われます。OracleとDB2 UDBのどちらでも、データ損失のない現在時刻へのリカバリーと、データの一部が失われる現在時刻の前の時刻へのリカバリーの両方が可能です。

多くの場合、選択したリカバリー・モードを用いてビジネスのニーズと運用上のニーズの折り合いを付けることが目標となります。例えば、データベースが主幹業務用でなく、運用も1日24時間、週7日でもなければ、ある程度のダウン・タイムとデータ損失は許容可能で、メディア障害が起こった場合のデータの再入力も許容可能な選択肢です。利用可能なバックアップとログによって異なりますが、不完全リカバリーを行うしか方法がない場合もあり得ます。

DB2のロギングには2種類あり、どちらもリカバリーに影響します。この2種類のロギングは、循環ロギングとアーカイブ・ロギングです。循環ロギング（デフォルト）を選択すると、選択できるのはオフライン・バックアップとバージョン・リカバリーだけです。アーカイブ・ロギングの使用、オンライン・バックアップとロールフォワード・リカバリーの実行を選択すると、ある時点またはログの終わりへのリカバリーを、データ損失を最小限に抑えながら行うことができます。

バックアップとリカバリーのこの2つのモードを次に詳しく説明します。

オフライン（コールド）バックアップ
Oracleで最もシンプルな形式は、オフライン・バックアップすなわちコールド・バックアップを実行することです。オフライン・バックアップは、通常のデータベース・シャットダウン後の物理的データベース・ファイルすべてのバックアップです。このバックアップ方法が最も一般的です。このバックアップの形式を用いるデータベースはNOARCHIVELOGモードで稼働しており、この場合バックアップ後にデータベースに対して行われた変更は、メディア・リカバリーが必要になるとリカバリー不能です。NOARCHIVELOGの名称が示すように、REDOログのアーカイブはありません。したがって、オンラインREDOログ以降のロールフォワードは行われません。データベース・ファイルのいずれかの部分にメディア障害が起こった場合は、すべてのデータベース・ファイルをリストアするだけで、もちろんバックアップ後に行われたすべての変更はリカバリー不能です。管理者には、データベースのスキーマが変わった場合、あるいはデータ・ファイルの追加または削除、ならびに表スペースの追加または削除などの変更が行われた場合には、必ずオフライン・バックアップを行うことをお勧めします。

データベース・ファイルは、選択されたバックアップ手順により、ディスクからディスクに、またはディスクからテープにコピーできます。UNIXのcpio、tar、およびdd、Windowsのbackup managerすなわちocopyなどのオペレーティング・システム・コマンドを使用して、物理的データベース・ファイルをバックアップ・メディアにコピーすることができます。データベース・ファイルは以下のものから構成されています。

• データ・ファイル
• 制御ファイル
• オンラインREDOログ

OracleのOFA（Optimal Flexible Architecture）に準拠していれば、これらのファイルを見つけることができます。図4を参照してください。

図4　OFA（Optimal Flexible Architecture）

この例では、ORACLE_BASEが値/u01/app/oracleに設定され、ORACLE_HOMEが/u01/app/oracle/product/8.0.4または/u01/app/oracle/product/8.1.7のいずれかに設定されます。

Oracleでオフライン・バックアップを実行するステップは以下のとおりです。

• データベースを通常モードでシャットダウンします。
• すべてのデータ・ファイル、制御ファイル、およびオンラインREDOログ・ファイルをバックアップ・メディアにコピーします。

オフライン・バックアップもDB2 UDBでの非常にシンプルなバックアップの形式です。オフライン・バックアップでは、完全なデータベース・バックアップが取られており、当然ながらバックアップの進行中にはデータベースがオフラインでなければなりません。言い換えれば、オフライン・バックアップの実行中、ユーザーはデータベースにアクセスできないということです。

循環ロギングを用いている場合は、オフライン・バックアップがサポートされている唯一のバックアップの種類です。データベースを初めて作成する場合はこれがデフォルトのロギング方法となっています。循環ロギングでは、log retain for recovery statusとuser exit for logging statusの両方がNOに設定されています。2つのパラメーターLOGRETAINおよびUSEREXITはどちらもOFFに設定されています。

図5　OFFのLOGRETAIN

循環ロギングでは、OracleがNoArchiveLogモードでREDOログを使用するのとほぼ同様に、ラウンド・ロビン方式でログが使用されます。ログ内のトランザクションがディスクにフラッシュされている限り、ログは再利用できます。ただし、実行時間の長いトランザクションでは、すべての1次ログがアクティブな状態でログが一杯になることがあります。この状態になると、2次ログは動的に割り当てられます。DB2構成パラメーターLOGSECONDが、必要な場合に動的に割り当てられる2次ログの最大数（254まで）を指定します。2次ログは、データベースが非アクティブの場合にのみ削除されます。

図6　1次ログおよび2次ログ

図7　データベース構成LOGSEC

循環ロギングとオフライン・リカバリーをバックアップ戦略として用いる場合には、最後のオフライン・バックアップ後のトランザクションはすべて失われることに注意してください。

オフライン・バックアップは、コントロールセンターから、あるいはコマンド行プロセッサを使用して実行することができます。コントロールセンターからバックアップを行う手順は以下のとおりです。

• コントロールを立ち上げます。
• 対象のデータベース（例えばSample）に移動し、図8に示すように [Backup] を右クリックします。
  
  図8　DB2 UDBでのコントロールセンターからのバックアップ
  
  
  
• ロギングの状態が表示されます。
  
  図9　循環ロギング
  
  
  
• [Next] をクリックします。File Systemをメディア・タイプとして選択します。[Add] をクリックして、パスを入力します（例えば、e:\tmp）。[Next] をクリックします。
  
  図10　メディア・タイプの選択
  
  
  
• オプションとしてFull Backupだけが表示されます。[Next] をクリックします。
  
  図11　バックアップ・オプション画面
  
  
  
  
• デフォルトを使用します。[Next] をクリックしてください。
  
  図12　バックアップ・パラメーターの選択
  
  
  
• ユーザーIDとパスワードを入力します。その他はデフォルトのままにしてください。
  
  図13　即時の実行またはタスクとしての実行の選択
  
  
  
• タスクとしての実行を選択した場合、図14の画面が表示されます。
  
  図14　タスク作成サマリー
  
  
  
• DB2 Task Managerから即時に実行するか、予定時間に従ってトリガーするかのいずれかが可能です。完了したタスクは図15のように表示されます。
  
  図15　Task Centerのタスク
  

DB2コマンド行からのバックアップの実行を選択する場合、コマンドDB2 backupの構文は以下のとおりです。

リスト1　コマンド行バックアップの構文

BACKUP DATABASE database-alias [USER username [USING password]]
      [TABLESPACE (tblspace-name [ {,tblspace-name} ... ])] [ONLINE]
      [INCREMENTAL [DELTA]] [USE {TSM | XBSA} [OPEN num-sess SESSIONS]] |
   TO dir/dev [ {,dir/dev} ... ] | LOAD lib-name [OPEN num-sess SESSIONS]]
      [WITH num-buff BUFFERS] [BUFFER buffer-size] [PARALLELISM n]
      [WITHOUT PROMPTING]

バックアップをオフライン・モードで実行するには、単にDB2コマンドを発行するだけです。

リスト2　シンプルなオフライン・バックアップ例

backup database sample to e:\tmp

または、以下のような他のオプションも使用できます。

リスト3　いくつかのパラメーターを用いたオフライン・バックアップ例

backup database sample to e:\tmp
backup database sample to e:\tmp1, e:\tmp2 
with 4 buffers 
buffer 4096
parallelism 2

backupコマンドが発行されると、バックアップ・イメージが作成されます。バックアップ・ファイル名はUNIXとWindowsで若干異なるため注意してください。Windowsの場合、パスとファイル名は以下の形式になります。

図16　Windowsのバックアップ・ファイル

UNIXバックアップ・ファイルは以下のようになります。

図17　UNIXのバックアップ・ファイル

表1は、オフライン・バックアップでのOracleとDB2 UDBの類似点と相違点を示します。

表1　OracleとDB2 UDBのオフライン・バックアップの比較

Oracleでのオフライン（コールド）バックアップからのリカバリー
Oracleでのオフライン・バックアップのリストアに関しては何の不思議もありません。単に物理的データベース・ファイルを正しいロケーションにコピーして戻すだけです。データ・ファイルのロケーションを変更する必要がある場合には、以下のコマンドを発行して制御ファイルを更新する必要があります。

リスト4　Oracleでデータ・ファイルのロケーションを変更するコマンド

alter database rename file <oldpath> to <newpath>

DB2 UDBの場合、バックアップごとにタイムスタンプが作成されます。したがって、データの損失を最小限に抑えるために最新のバックアップ・イメージがリストアされるよう、リストアはバックアップ・タイムスタンプに従います。バックアップを頻繁に行えば、失われるデータも少なくなります。

図18に例を示します。UOW (Unit of Work) nで、メディア障害によってディレクトリーが破壊され、アクセス不能になりました。Backup DB3またはそれ以前にリストアすることができます。仮にBackup DB3が取られていないとすると、2004062510で取られたバックアップより前に戻る以外に方法はありません。

図18　オフライン・バックアップおよびリストア

DB2 UDBの場合にも、リストアの実行には2つの方法を選択できます。コントロールセンターまたはコマンド行プロセッサー（CLP）のいずれかを使用できます。コントロールセンターからリストアするには、以下のステップを実行してください。

• コントロールセンターから、データベース（例えば、Sample）を選択し、右クリックしてリストアを実行します。以下に示すいくつかのオプションがあります。[Next] をクリックします。
  
  図19　オフライン・リストア・オプション
  
  
  
• バックアップ・イメージを強調表示し、右パネルに移動します。[Next] をクリックします。
  
  図20　バックアップ・イメージの選択
  
  
  
• 必要であればコンテナーのリダイレクトを選択できます。
  
  図21　コンテナー・リダイレクト・オプション
  
  
  
• 唯一のオプションとしてFull Backupが表示されます。[Next] をクリックします。
  
  図22　リストア・パラメーターの選択
  
  
  
• デフォルトを使用します。[Next] をクリックしてください。
  
  図23　その他のリストア・パラメーターの選択
  
  
  
• デフォルトを使用するか、即時の実行を選択します。ユーザーIDとパスワードを入力します。[Next] をクリックしてください。
  
  図24　タスクのスケジューリング
  
  
  
• [Finish] をクリックします。
• リストアが完了すると、Task Managerに以下のような内容が表示されます。
  
  図25　タスク作成サマリー
  
  
  

オフライン・バックアップのCLPリストアを行うためのコマンド構文は、リスト5のとおりです。

リスト5　データベース・リストア用のコマンド

RESTORE DATABASE source-database-alias 
   { restore-options | CONTINUE | ABORT }

restore-options:
  [USER username [USING password]] [{TABLESPACE [ONLINE] |
  TABLESPACE (tblspace-name [ {,tblspace-name} ... ]) [ONLINE] |
  HISTORY FILE [ONLINE]}] [INCREMENTAL [AUTOMATIC | ABORT]]
  [{USE {TSM | XBSA} [OPEN num-sess SESSIONS] |
  FROM dir/dev [ {,dir/dev} ... ] | LOAD shared-lib
  [OPEN num-sess SESSIONS]}] [TAKEN AT date-time] [TO target-directory]
  [INTO target-database-alias] [NEWLOGPATH directory]
  [WITH num-buff BUFFERS] [BUFFER buffer-size]
  [DLREPORT file-name] [REPLACE EXISTING] [REDIRECT] [PARALLELISM n]
  [WITHOUT ROLLING FORWARD] [WITHOUT DATALINK] [WITHOUT PROMPTING]

例えば、E:\tmpから特定のイメージをリストアするには、リストアするバックアップ・イメージを指定する必要があります。リスト6のコマンドは、6月17日の午前10時頃に取得されたイメージをリストアします。

リスト6　シンプルなデータベース・リストア・コマンド

db2 restore database sample from e:\tmp taken at 2004061710

メデイア障害があるなど、元のディレクトリーへのリストアが不可能な場合があります。そのような場合は、RESTORE DATABASE…REDIRECTを用いて異なるコンテナーを使用することができます。ディレクトリーとファイル・コンテナーが作成されていない場合には、自動的に作成されます。例えば、tablespace 0をリダイレクトする必要のある場合は、私なら以下のコマンドを発行します。

リスト7　CLPを使用したコンテナーのリダイレクト

db2 restore database sample from e:\tmp taken at 2004061710 replace existing
db2 set tablespace containers for 0 using (path 'E:\tmp\0') 
     (note if it’s a DMS tablespace, you will need a set  tablespace containers for 0 
     using (file 'e:\tmp\0.dms' <size>)
db2 restore database sample continue

表2は、DB2 UDBとOracleのオフライン・リストアを比較したものです。

表2　OracleとDB2 UDBのオフライン・リストアの比較

次ページへ

上に戻る