8 STA 2.1.0 へのアップグレード

この章では、以前にリリースされたバージョンの STA から STA 2.1.0 にアップグレードする手順を説明します。次のセクションがあります。

STA をはじめてインストールする場合には、新しい基本インストールを実行する必要があります。手順については、第3章 STA のインストールを参照してください。

付録C に、アップグレードアクティビティーの整理および設定の記録に使用できるワークシートがあります。

アップグレードプロセスの概要

アップグレード中、既存の STA データが現在の STA バージョンから新しいものに変換されます。これらの変換が完了するまでは、STA データベースは新しいバージョンの STA で有効になりません。アップグレード後に、STA は、新しい STA スキーマと分析ルールに従って新しいデータを処理します。履歴データは再処理されません。

アップグレードを開始する前に、この章のすべての手順を読み、必ずプロセス全体に十分な時間を配分してください。アップグレード準備タスクの一部において、ネットワーク管理などの、サイトでのほかのグループとの調整が必要となる場合があります。アップグレード自体をできるかぎり少ない時間で終了するには、事前にすべての準備タスクを完了させておく必要があります。

プロセス自体のアップグレードを開始すると、STA を実行できないため、モニター対象のライブラリからの交換情報を受けなくなります。また、新しいバージョンの STA は、アップグレードのすべての手順を完了し、各モニター対象ライブラリへの SNMP 接続をテストするまでは、ライブラリからの情報の受け取りを開始しません。

注:

一部のアップグレード手順には時間の推定が含まれていますが、これは単に計画の目的のために用意されているものです。サーバーの機能 (CPU 数、CPU 速度、ディスク速度、メモリー、および使用可能なスワップ領域など) に応じて、実際の時間は異なる場合があります。

有効な STA 2.1.0 のアップグレードパス

次のリリース済みの STA バージョンのいずれかから STA 2.1.0 にアップグレードできます。

  • STA 2.0.x:

    • STA 2.0.0.83

    • STA 2.0.1.4

  • STA 1.0.x:

    • STA 1.0.0.99

    • STA 1.0.1.133

    • STA 1.0.2.24

    注:

    STA 1.0.x からアップグレードする場合、STA 2.1.0 をインストールする前に新しいバージョンの Linux もインストールする必要があります。詳細は、『STA 要件ガイド』を参照してください。

アップグレード方法

目的および使用可能なリソースに応じて、1 台または 2 台のサーバーを使用して STA のアップグレードを実行できます。2 つの方法のアップグレードタスクは大部分が同じですが、異なる順序でタスクが実行されます。2 つの方法は次のセクションで説明します。

1 台のサーバーのアップグレード方法

1 台のサーバーの方法を使用する場合、新しいバージョンをインストールして同じサーバーのデータベースをアップグレードする前に、STA をアンインストールする必要があります。この処理の実行中は、STA はライブラリをモニターしていません。

この方法には、アップグレードにおいて追加の専用サーバーが不要という利点があります。STA 2.0.x からアップグレードする場合、新しいバージョンの Linux をインストールする必要がないため、この方法はニーズを十分満たしている可能性があります。

図8-1 に、1 台のサーバーの方法を示します。タスク 1 からタスク 9 まで連続した順に実行します。まとめると次のようになります。

  • 現在のデータベースをダンプし、保護のためそれをバックアップサーバーに転送します (タスク 1 およびタスク 2)。

  • STA の現在のバージョンに応じて、Linux 6.x (タスク 3a) をインストールするか、STA 2.0.x をアンインストール (タスク 3b) します。

  • STA 2.1.0 をインストールし、予防策として新しいデータベースをダンプします (タスク 4 およびタスク 5)。

  • バックアップサーバーから古いデータベースのダンプを転送し、それを新しい STA のバージョンにロードおよびアップグレードします (タスク 6 からタスク 8)。

  • モニター対象ライブラリへの接続を再確立し、必要な手動の構成タスクを実行します (タスク 9)。STA 2.1.0 をインストールする前に古いバージョンの STA をアンインストールする必要があるため、一部のユーザー構成データを手動で再入力する必要があります。

図8-1 1 台のサーバーのアップグレードタスクの概要

図8-1 の説明が続きます
説明: 図8-1 1 台のサーバーのアップグレードタスクの概要

2 台のサーバーのアップグレード方法

2 台のサーバーのアップグレード方法では、2 台目の専用 STA サーバーが必要になりますが、STA アプリケーションのダウンタイムが削減されるという利点が得られます。この方法は、STA 1.0.x からアップグレードする場合、古いバージョンの STA が古いサーバーでライブラリのモニターを継続でき、Linux および新しいバージョンの STA の両方が新しいサーバーにインストールされるため、特に便利です。

ただし、この方法であっても、現在のデータベースを新しい STA のバージョンにアップグレードしている間は、STA はライブラリをモニターしていません。ダウンタイムの長さは、現在のデータベースのサイズにより異なります。

図8-2 に、2 台のサーバーの方法を示します。タスクは示された順に実行する必要があります (これらは連続の順では行われず、タスク 6 は省略されます)。新しいバージョンの STA を新しいサーバーにインストールするまでは、現在の STA データベースをダンプしないでください。まとめると次のようになります。

  • 2 台目のサーバーが現在 STA のバージョンを実行しているかどうかに応じて、Linux 6.x (タスク 3a) をインストールするか、STA 2.0.x をアンインストール (タスク 3b) します。

  • 新しいサーバーに STA 2.1.0 をインストールし、予防策として新しいデータベースをダンプします (タスク 4 およびタスク 5)。

  • 現在のデータベースを古いサーバーでダンプし、それを新しいサーバーに転送します (タスク 1 およびタスク 2)。

  • 現在のデータベースを新しい STA バージョンにロードおよびアップグレードします (タスク 7 およびタスク 8)。

  • モニター対象ライブラリへの接続を再確立し、必要な手動の構成タスクを実行します (タスク 9)。

図8-2 2 台のサーバーのアップグレードタスクの概要

図8-2 の説明が続きます
説明: 図8-2 2 台のサーバーのアップグレードタスクの概要

STA 2.1.0 の環境の変更

次に、STA 2.1.0 へのアップグレードの計画時に考慮する必要のある環境の変更をまとめます。

Linux バージョン

STA 2.1.0 では Linux 6.3 以降が必要です (詳細は『STA 要件ガイド』を参照してください)。現在の STA のバージョンに応じて、STA のアップグレードプロセスの一環として、新しいバージョンの Linux をインストールする必要がある場合があります。

  • STA 1.0.x からアップグレードする場合、STA 2.1.0 をインストールする前に Linux 6.3 以降をインストールする必要があります。Linux では、Linux 5.x から Linux 6.x へのインプレースアップグレードはサポートしておらず、代わりに、STA サーバーに新しい Linux 6.x のインストールを行う必要があります。

  • STA 2.0.x からアップグレードする場合、すでに Linux 6.3 以降を実行していますが、STA 2.1.0 をインストールする前に、現在のバージョンの STA をアンインストールする必要があります。また、必要な Linux RPM パッケージをインストールまたは更新する必要のある場合もあります。アップグレード準備の一環として、すべての必要な RPM パッケージレベルがインストールされていることを確認し、最終チェックとして、不足しているパッケージがある場合には STA インストーラによっても通知されます。

デフォルトの WebLogic ポート番号

デフォルトの WebLogic 管理コンソールのポート番号は、STA 2.1.0 では変わりました。現在、古いデフォルトのポート番号を使用している場合、新しいデフォルト値に変更します。新旧のデフォルトのポート番号は次のとおりです。

  • STA 2.1.0 の新しいデフォルト - 7019 (HTTP) および 7020 (HTTPS)

  • 古いデフォルト (STA 1.0.x および STA 2.0.x) - 7001 (HTTP) および 7002 (HTTPS)

注:

WebLogic 管理コンソールのポートは外部にあります。ネットワーク管理者は、STA サーバーと、WebLogic 管理インタフェースにアクセスするクライアントとの間の通信を開くように、ファイアウォールおよびルーターを構成する必要のある場合があります。

STA 2.0.x 以降で必要なポート

注:

この変更は STA 2.0.x で導入されたため、STA 1.0.x からアップグレードする場合にのみ関係します。

STA 2.0.x では、STA ポートが StaUi および StaEngine 管理対象サーバー用に追加されています。STA 2.0.x および STA 2.1.0 のデフォルトの STA 管理対象サーバーのポート番号は次のとおりです。

  • StaUi - 7021 (HTTP) および 7022 (HTTPS)

  • StaEngine - 7023 (HTTP) および 7024 (HTTPS)

  • StaAdapter - 7025 (HTTP) および 7026 (HTTPS)

注:

StaUi ポートは外部にあります。ネットワーク管理者は、STA サーバーと STA ユーザーインタフェースにアクセスするクライアントとの間の通信を開くように、ファイアウォールおよびルーターを構成する必要のある場合があります。

ユーザー名およびパスワードの要件

STA 2.1.0 では、STA および MySQL のユーザー名およびパスワードの要件が変更されています。これらの要件をサイトの内部要件に合わせて調整する必要のある場合があります。

ユーザー名の要件は次のとおりです。

  • 1 – 16 文字の長さにする必要があります

  • すべてのユーザー名が一意である必要があります

パスワード要件は次のとおりです。

  • 8 – 31 文字の長さにする必要があります

  • 少なくとも 1 つの数字と 1 つの大文字を含める必要があります

  • 空白を含めることはできません

  • 次の特殊文字を含めることはできません

    & ' ( ) < > ? { } *  \ ' "

アップグレード準備タスク

STA のアップグレードを開始する前に、次のタスクを実行します。これらのタスクの多くはオプションで、表8-1 はそれぞれを使用するタイミングのガイドラインを示しています。

表8-1 アップグレード準備タスクを実行するタイミングのガイドライン

タスク
 実行するタイミング

サイトのアップグレード準備済みの確認

すべてのアップグレード

既存のログの保存 (オプション)

現在のバージョンの STA からサービスログを保持するとき。

現在の STA のユーザーおよび構成設定の記録 (オプション)

現在の STA ユーザー名および構成設定を保持するとき。

接頭辞に STA– の付くカスタムテンプレートの名前の変更 (オプション)

接頭辞に「STA–」の付く名前のカスタムテンプレートがあるとき。

現在のカスタムテンプレート設定の記録 (オプション)

既存のカスタムテンプレートの所有権と可視性の設定を保持するとき。

エグゼクティブレポートポリシー設定の記録 (オプション)

既存のエグゼクティブレポートポリシーの所有権の設定を保持するとき。

サイトのアップグレード準備済みの確認

アップグレード要件を再確認し、サイトが準備できていることを確認するには、この手順を使用します。

アップグレード前提条件の確認

使用している環境がすべての STA 2.1.0 前提条件を満たしていることを確認するには、この手順を使用します。

  1. 現在の STA のバージョンを表示します。一部のアップグレードタスクは、STA 1.0.x からアップグレードするか、STA 2.0.x からアップグレードするかによって異なります。

    1. STA 管理者のユーザー名を使用して STA にログインします。

    2. ステータスバーの「About」をクリックします。

    3. 現在リリースされているバージョンの STA を実行していることを確認します。詳細は、有効な STA 2.1.0 のアップグレードパスを参照してください。

  2. 1 台のサーバーのアップグレード方法を使用するか、2 台のサーバーのアップグレード方法を使用するかを選択します。詳細は、アップグレードプロセスの概要を参照してください。

  3. サイトおよびターゲットサーバーが STA 2.1.0 の要件を満たしていることを確認します。詳細は、『STA 要件ガイド』を参照してください。

  4. ターゲットの STA サーバーの /tmp ファイルシステムにアップグレードに十分な容量があることを確認します。/tmp のサイズは、少なくとも既存の非圧縮の STA データベースのサイズと同等の大きさで最低 4G バイト必要で、大きいデータベースに対しては、Oracle は /tmp のサイズを最低でも 32G バイトに増加することをお勧めします。

    /tmp のサイズを増加させる必要があると判断する場合、アップグレードスクリプトを実行する直前にこれを実行できます。手順については、タスク 8: 古いデータベースのアップグレードを参照してください。

  5. アップグレードパスに関連する環境の変更点を確認し、プランや環境に合わせて必要な調整をします。詳細は、STA 2.1.0 の環境の変更を参照してください。

  6. STA 2.0.x からアップグレードする場合、すべての必要な RPM パッケージが STA サーバーにインストールされていることを確認します。詳細は、必要な Linux パッケージのインストールを参照してください。最終チェックとして、不足しているパッケージがある場合には、STA インストーラによっても通知されます。

現在の STA アクティビティーの確認

現在の STA 環境が正常に機能していることを確認するには、この手順を使用します。

  1. 次の手順を使用して、現在のバージョンの STA が最近、各モニター対象ライブラリと正常に通信したことを確認します。

    1. STA の管理者ユーザーとして STA にログインします。

    2. 「Setup & Administration」タブから、「SNMP Connections」を選択します。

    3. 「Monitored Libraries」表で次の値を確認します。

      • 「Recent SNMP Trap Communication Status」 - 「GOOD」

      • 「Last Connection Status」 - 「SUCCESS」

  2. 次の手順を使用して、STA がすべてのライブラリにわたって交換を処理していることを確認します。

    1. 「Tape System Activity」タブから「Exchanges – Overview」を選択します。

    2. 「Filter」アイコンを選択し、「Exchange End (No. Days) Less Than 1」のフィルタ処理をします。

    3. 表のツールバーで、「View」、「Sort」、「Advanced」の順に選択します。「Drive Library Name」、「Drive Serial Number」でソートします。

    4. すべてのライブラリに交換アクティビティーがあることを確認します。

既存のログの保存 (オプション)

STA 2.1.0 をインストールする前に、現在のバージョンの STA をアンインストールするか、新しいバージョンの Linux をインストールする必要があるため、既存のアプリケーションおよびサービスログはアップグレード後に保持されません。保持する必要のあるログを保存するには、この手順を使用します。

  1. 保持する必要のあるインストールログおよびデータベースログを特定し、それらを安全な場所に移動します。対象となり得るログは、インストール用に定義した STA ログの場所にあります。詳細は、STA ファイルシステムレイアウトの確認を参照してください。

  2. 次の手順を使用して、現在の STA インストールでサービスログスナップショットを実行します。この手順はオプションですが、Oracle Support がこのログを使用して、アップグレード前に存在していた可能性のある問題をトラブルシューティングできるため、お勧めします。

    1. STA の管理者ユーザーとして STA にログインします。

    2. 「Setup & Administration」タブから、「Logs」を選択します。

    3. 「Service – Logs」画面で、「Create New Log Bundle」アイコンをクリックします。

    4. 「Create New Log Bundle」ダイアログボックスでバンドル名を割り当て、「Save」をクリックします。プロセスが完了するには、数分かかる場合があります。

  3. 次の手順を使用して、今作成したサービスログバンドルと、保持する必要のあるほかのものをダウンロードします。バンドルは一度に 1 つずつダウンロードする必要があります。

    1. 「Service – Logs」画面で、ダウンロードするバンドルを選択します。

    2. 「Download Selected Log Bundle」アイコンをクリックします。

    3. ダイアログボックスで、保存先の場所を指定し、ログバンドルを保存します。

現在の STA のユーザーおよび構成設定の記録 (オプション)

このセクションは、STA 2.1.0 に現在の STA のユーザー名および構成の設定を保持する場合のみ適用されます。これらの手順を使用して、現在の値を STA 2.1.0 で再入力できるよう、表示および記録します。これらの値の多くは、アップグレード後に再入力することになります。詳細は、タスク 9: 新しい STA バージョンの構成を参照してください。

MySQL ユーザー名の記録

STA データベースへのアクセスに使用する既存の MySQL ユーザー名を表示および記録するには、この手順を使用します。STA インストーラによりこれらの値がプロンプト表示されます。パスワードは取得できません。

  1. 現在の STA サーバーで端末セッションを開き、システムの root ユーザーとしてログインします。

  2. 次の問合せを発行して、STA データベースのすべてのユーザー名を表示します。入力を求められたら、データベースの root ユーザーパスワードを入力します。例:

    $ mysql -uroot -p -e "select distinct(user) from user order by user ;" mysql
Enter password: password
+--------+
| user   |
+--------+
| root   |
| staapp |
| stadba |
| starpt |
+--------+

  3. ユーザー名を記録します。

STA の SNMP クライアント設定の記録

STA の SNMP クライアント設定を表示および記録するには、この手順を使用します。これらの値は、アップグレード後に再入力することになります。

注:

新しいバージョンの STA で、SNMP 値がモニター対象ライブラリで指定されたものと一致している必要があります。

  1. STA 管理者のユーザー名を使用して STA にログインします。

  2. 「Setup & Administration」タブから、「SNMP Connections」を選択します。

    「Client Attributes」表に、STA SNMP クライアントの構成設定が表示されます。

    snmp_clientupgrade.pngの説明が続きます
    図の説明snmp_clientupgrade.png

  3. 次の列の値を記録します。

    • 「SNMP Username」

    • 「User Community」

    • 「Trap Community」

WebLogic ユーザー名の記録 - STA 1.0.x からのアップグレードのみ

STA 1.0.x からのアップグレードの場合、この手順を使用して STA へのログインに使用した既存の WebLogic ユーザー名を表示および記録します。これらの値は、アップグレード後に再入力することになります。パスワードは取得できません。

注:

STA 2.0.x からは、ユーザー名は STA ユーザーインタフェースを介して作成および管理します。手順については、STA ユーザー名の記録 - STA 2.0.x からのアップグレードのみを参照してください。

  1. コンピュータ上のサポートされている Web ブラウザを起動し、WebLogic 管理コンソールの URL を入力します。

    http(s)://STA_host_name:port_number/console/

    ここでは:

    • host_name は STA サーバーのホスト名です。

    • port_number は、現在の STA のバージョンでの WebLogic 管理コンソールの STA ポート番号です。

    • STA は大文字にする必要があります。

    例:

    https://staserver.example.com:7002/console/

  2. WebLogic 管理コンソールのユーザー名とパスワードを使用してログインします。

  3. 「Domain Structure」ナビゲーションツリーで、「Security Realms」をクリックします。

    wl_secrealm.pngの説明が続きます
    図の説明wl_secrealm.png

    「Summary of Security Realms」画面が表示されます。

  4. 「Name」列で、「myrealm」アクティブリンクを選択します (チェックボックスは選択しません)。

    wl_myrealm.pngの説明が続きます
    図の説明wl_myrealm.png

    「Settings for myrealm」画面が表示されます。

  5. 「Users and Groups」タブを選択します。

    wl_checkusers.pngの説明が続きます
    図の説明wl_checkusers.png

    「Users」表に使用可能なユーザー名が一覧表示されます。

    wl_userstable.pngの説明が続きます
    図の説明wl_userstable.png

  6. 保持するユーザー名を記録します。

STA ユーザー名の記録 - STA 2.0.x からのアップグレードのみ

STA 2.0.x からのアップグレードの場合、この手順を使用して STA へのログインに使用したユーザー名を表示および記録します。この情報は、アップグレード後に再入力することになります。パスワードは取得できません。

注:

STA 1.0.x では、ユーザー名は WebLogic 管理コンソールを介して作成および管理されていました。手順については、WebLogic ユーザー名の記録 - STA 1.0.x からのアップグレードのみを参照してください。

  1. STA 管理者のユーザー名を使用して STA にログインします。

  2. 「Setup & Administration」タブから、「Users」を選択します。

    「Configuration – Users」画面にすべての STA のユーザー名とその役割が表示されます。

    upgrade_users.pngの説明が続きます
    図の説明upgrade_users.png

  3. 保持するユーザー名および役割を記録します。

STA の電子メールサーバー設定の記録

STA の電子メールプロトコル、およびアカウントのユーザー名 (電子メールサーバーが認証を必要とする場合) を表示および記録するには、この手順を使用します。これらの値は、アップグレード後に再入力することになります。パスワードは表示できません。

  1. STA 管理者のユーザー名を使用して STA にログインします。

  2. 「Setup & Administration」タブから、「Email」を選択します。

  3. 「SMTP Server Settings」表で、「StorageTek Tape Analytics Alerts」レコードを選択して、「Edit Selected SMTP Server」アイコンをクリックします。

    「Define SMTP Server Details」ダイアログボックスが表示されます。

    email_smtpserverd.pngの説明が続きます
    図の説明email_smtpserverd.png

  4. 次のフィールドの値を記録します。

    • 「Use Secure Connection Protocol」

    • 「Username」

接頭辞に STA– の付くカスタムテンプレートの名前の変更 (オプション)

この手順は、接頭辞に「STA–」の付く名前のカスタムテンプレートがある場合のみ適用されます。STA 2.1.0 のインストール中、「STA–」の接頭辞の付いたすべてのテンプレートが削除され、事前定義済みの新しい STA テンプレートに置き換えられます。

アップグレード中にテンプレートが保存されるように、テンプレートに新しい名前を割り当てるには、この手順を使用します。

注:

STA の事前定義済みテンプレートは、接頭辞「STA–」が付けられています。そのため、Oracle では、カスタムテンプレートに名前を付ける際にこの接頭辞を使用しないことをお勧めします。

  1. 管理者ユーザー名を使用して STA にログインします。

  2. 「Setup & Administration」タブから、「Templates Management」を選択します。

  3. 「Created/Updated」日で表をソートし、STA のインストール日以降に変更されたテンプレートに焦点を置きます。

  4. 接頭辞に「STA–」の付いた名前のカスタムテンプレートのテキストリンクを選択します。

    選択したテンプレートが適用された画面になります。

  5. テンプレートツールバーの「Save Template」をクリックします。

    「Save Template」ダイアログボックスが表示されます。

  6. 「Template Name」フィールドに接頭辞「STA‐」を付けない新しい名前を割り当てます。エントリは一意である必要があります。

  7. 「保存」をクリックします。

    テンプレートが保存されます。

現在のカスタムテンプレート設定の記録 (オプション)

このセクションは、カスタムテンプレートがある場合のみ適用されます。アップグレードではカスタムテンプレートが保存されますが、アップグレード後、すべてのカスタムテンプレートはパブリックの可視性とともに STA に所有されます。

すべてのカスタムテンプレートの現在の所有権および可視性の設定を、必要に応じてアップグレード後に復元できるよう記録するには、この手順を使用します。使用している実装でテンプレートの所有権および可視性が重要でない場合には、この手順を省略できます。

  1. 管理者ユーザー名を使用して STA にログインします。

  2. 「Setup & Administration」タブから、「Templates Management」を選択します。

  3. 「Filter」アイコンを選択して画面をフィルタし、STA に所有されていないテンプレートのみを表示します (カスタムテンプレートのみが表示されます)。

    upgrade_filternotsta.pngの説明が続きます
    図の説明upgrade_filternotsta.png

  4. 各カスタムテンプレートの現在の「Owner」および「Public Visibility」の設定を記録します。テンプレートが多い場合には、スクリーンショットを撮ることもできます。

エグゼクティブレポートポリシー設定の記録 (オプション)

このセクションは、プライベートでエグゼクティブレポートポリシーを所有していた場合のみ適用されます。アップグレードではすべてのエグゼクティブレポートポリシーを保存しますが、アップグレード後、すべてのプライベートポリシーは、パブリックの所有権に割り当てられます。

すべてのプライベートポリシーの現在の所有権の設定を、必要に応じてアップグレード後に復元できるよう記録するには、この手順を使用します。使用している実装でエグゼクティブレポートポリシーの所有権が重要でない場合には、この手順を省略できます。

  1. STA 管理者のユーザー名を使用して STA にログインします。

  2. 「Setup & Administration」タブから、「Executive Reports Policies」を選択します。

  3. 「Filter」アイコンを選択して画面をフィルタし、STA に所有されていないポリシーのみを表示します (プライベートポリシーのみが表示されます)。

    upgrade_rptnotsta.pngの説明が続きます
    図の説明upgrade_rptnotsta.png

  4. 各ポリシーに対する現在の「Report Owner」の設定を記録します。ポリシーが多い場合には、スクリーンショットを撮ることもできます。

アップグレードタスク

注意:

Linux 管理者と STA 管理者のみが、アップグレードを実行するべきです。すべてのタスクが必要で、記載されたとおり正確に指定された順で実行する必要があり、そうしないとデータが失われる可能性があります。

1 台のサーバーのアップグレード方法を使用する場合、連続した順にタスクを実行します。詳細は、図8-1 1 台のサーバーのアップグレードタスクの概要を参照してください。

2 台のサーバーのアップグレード方法を使用する場合、タスクを連続した順には実行せず、タスク 6が省略されます。タスクの順については、図8-2 2 台のサーバーのアップグレードタスクの概要を参照してください。

タスク 1: 古い STA データベースのダンプ

古い (現在の) STA データベースの完全ダンプを実行するには、この手順を使用します。

  1. 次の手順を使用して、現在の STA データベースのサイズを表示します。

    1. STA 管理者のユーザー名を使用して STA にログインします。

    2. ステータスバーの「About」をクリックします。

    3. 「About」ダイアログボックスで、「Database Current Size」が表示されているところまでスクロールダウンし、その値を記録します。

  2. 次の手順を使用して、データベースをダンプする場所に十分な容量があることを確認します。

    1. STA サーバーで端末セッションを開き、システムの root ユーザーとしてログインします。

    2. データベースのダンプ先で使用可能な容量を表示し、ダンプファイルに十分であることを確認します。例:

      # df -h /dbdumpfiles
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/sta_server-STA_DbVol
                      200G   53G   243G  27% /dbdumpfiles

  3. すべての STA サービスを停止します。

    # STA stop all

  4. MySQL サービスを起動します。

    # service mysql start

  5. STA データベースを単一のファイルにダンプします。入力を求められたら、データベースの root ユーザーパスワードを入力します。

    # mysqldump -uroot -p --opt --add-drop-database --comments --complete-insert --dump-date --events --flush-logs --routines --single-transaction --triggers --databases stadb > /dumpfile_path/dumpfile_name.sql
Enter password: mysql_root_password

    注:

    オプションの –v パラメータ (詳細出力用) は、端末ウィンドウに多数のメッセージが表示され、大規模データベースのコマンド処理の速度を大幅に低下させる可能性があるため、推奨しません。

    例8-1 では、STA 1.0.x データベースが STA サーバーの /dbdumpfiles フォルダに Dec14_dump.sql というファイル名でダンプされます。

    例8-1 古いデータベースのダンプ

    # mysqldump -uroot -p --opt --add-drop-database --comments --complete-insert --dump-date --events --flush-logs --routines --single-transaction --triggers --databases stadb > /dbdumpfiles/Dec14_dump.sql

Enter password: mysql_root_password
...
-- Retrieving view structure for table v_library_complex_io...
...
-- Retrieving view structure for table v_library_summary_averages...
-- It's base table, skipped
...
-- Retrieving table structure for table v_mdv_status_codes...-- It's a view, create dummy table for view
...
-- Disconnecting from localhost...

  6. ダンプファイルサイズを約 50% 縮小するには、ファイルを gzip します。

    # cd /path_to_dump_file/
# gzip dump_file_name.sql

タスク 2: 古いデータベースダンプの転送

古い STA データベースの圧縮済みダンプをプラットフォーム外のバックアップサーバー (1 台のサーバーの方法) または新しい STA 2.1.0 サーバー (2 台のサーバーの方法) のいずれかに転送するには、この手順を使用します。

注意:

1 台のサーバーの方法で STA 1.0.x からアップグレードする場合、STA データベースを別のサーバーにバックアップする必要があります。タスク 3a: 新しい Linux バージョンのインストール (STA 1.0.x からのアップグレード) の Linux 6.x のインストールによって、現在の STA サーバー上のデータがすべて破棄されるため、このサーバー上のファイルシステムにはデータベースをバックアップしないでください。

  1. まだ停止していない場合には、すべての STA サービスを停止します。

    # STA stop all

  2. ファイルをバックアップサーバーに転送する前に、チェックサムを実行します。

    # cksum dump_file_name.sql.gz

    出力には、チェックサム値とバイト数が含まれています。チェックサム値を記録します。ファイルをバックアップサーバーに転送したあとで、これを使用してファイルの整合性を検証します。

  3. SCP などの転送ユーティリティーを使用して、ファイルをターゲットサーバーに転送します。–p オプションは、タイムスタンプ値を保存します。

    # scp -p dump_file_name.sql.gz target_host:/path/

    例8-2 では、SCP を使用して、圧縮済みのデータベースダンプファイル Dec14_dump.sql.gz がバックアップホスト backup1 上の /dbdumpfiles フォルダに転送されます。/dbdumpfiles フォルダはすでにバックアップホストに存在しています。

    例8-2 バックアップサーバーへの古いデータベースの転送 (1 台のサーバーの方法)

    # cd /dbdumpfiles
# scp -p Dec14_dump.sql.gz backup1:/dbdumpfiles

    例8-3 では、SCP を使用して、圧縮済みのデータベースダンプファイル Dec14_dump.sql.gz が STA 2.1.0 ホスト sta_new 上の /dbdumpfiles フォルダに転送されます。

    例8-3 新しい STA サーバーへの古いデータベースの転送 (2 台のサーバーの方法)

    # cd /dbdumpfiles
# scp -p Dec14_dump.sql.gz sta_new:/dbdumpfiles

  4. ターゲットサーバーで、転送されたファイルのチェックサムを実行します。チェックサム値が一致することを確認します。

    # cd /path_to_dump_file/
# cksum dump_file_name.sql.gz

タスク 3a: 新しい Linux バージョンのインストール (STA 1.0.x からのアップグレード)

この手順は、STA 1.0.x からのアップグレードのみに適用されます。Linux 6.3 以降を STA サーバーにインストールします。手順については、第2章 Linux のインストールを参照してください。

注意:

このアクティビティーにより、サーバー上のすべてのデータが破棄されます。1 台のサーバーのアップグレード方法を使用する場合、この手順は、タスク 1: 古い STA データベースのダンプおよびタスク 2: 古いデータベースダンプの転送の実行後にのみ使用します。

タスク 3b: 古い STA バージョンのアンインストール (STA 2.0.x からのアップグレード)

この手順は、STA 2.0.x からのアップグレードのみに適用されます。現在のバージョンの STA をアンインストールします。手順については、STA のアンインストールおよびアンインストールが成功したことの確認を参照してください。

注意:

このアクティビティーにより、サーバー上のすべての STA データが破棄されます。1 台のサーバーのアップグレード方法を使用する場合、この手順は、タスク 1: 古い STA データベースのダンプおよびタスク 2: 古いデータベースダンプの転送の実行後にのみ使用します。

タスク 4: 新しい STA バージョンのインストール

STA 2.1.0 をインストールするには、この手順を使用します。

  1. STA 2.1.0 をインストールします。手順については、STA のインストールを参照してください。

  2. STA が正常に動作していることを確認し、WebLogic での STA 管理者設定を完了させるには、STA アプリケーションにログインします。

    「Dashboard」が表示されます。

    注:

    アップグレード処理がまだ完了していないため、「Dashboard」ポートレットに「No data to display」のメッセージが表示されます。これは正常です。ライブラリデータは、データベースをアップグレードし、新しい STA のバージョンを構成したあとに、正常に表示されます。

  3. STA からログアウトします。

  4. STA サーバーで端末セッションを開き、システムの root ユーザーとしてログインします。

  5. すべての STA サービスを停止します。

    # STA stop all

  6. この手順は、SNMP v2c を使用して STA にライブラリをモニターさせる場合にのみ適用されます (詳細は、付録F SNMP v2c モードの構成を参照してください)。STA 2.0.x からは、SNMP v2c はデフォルトで有効にされます。次の手順を使用して、これが有効になっていることを確認します。

    1. STA 構成ファイルのディレクトリに移動します。

      # cd /Oracle_storage_home/Middleware/user_projects/domains/TBI

    2. SNMP バージョンプロパティーファイル表示し、V2c パラメータが true に設定されていることを確認します。

      # cat TbiSnmpVersionSupport.properties
V2c=true
Verbal=false

    3. パラメータが true に設定されていない場合、変更する方法の手順は、STA の SNMP v2c モードの有効化を参照してください。

タスク 5: 新しい STA データベースのダンプ (オプション)

この手順はオプションですが、推奨されます。予防策として空の STA 2.1.0 データベースをダンプするには、この手順を使用します。データベースのアップグレード (「タスク 8: 古いデータベースのアップグレード」) を完了できない場合、空のデータベースを復元して STA 2.1.0 をデータなしで新しくインストールされたかのように実行するよう構成できる状態に回復することができます。復元処理の詳細は、「失敗したデータベースアップグレードの回復 (オプション)」を参照してください。

  1. STA サーバーで端末セッションを開き、システムの root ユーザーとしてログインします。

  2. まだ停止していない場合には、すべての STA サービスを停止します。

    # STA stop all

  3. MySQL サービスを起動します。

    # STA start mysql

  4. データベースバックアップファイルを作成します。入力を求められたら、データベースの root ユーザーパスワードを入力します。

    # mysqldump -uroot -p --opt --add-drop-database --comments --complete-insert --dump-date --events --flush-logs --routines --single-transaction --triggers --databases stadb > /dumpfile_path/dumpfile_name.sql

    注:

    オプションの –v パラメータ (詳細出力用) は、端末ウィンドウに多数のメッセージが表示され、大規模データベースのコマンド処理の速度を大幅に低下させる可能性があるため、推奨しません。

    例8-4 では、STA 2.1.0 データベースが STA サーバーの /dbdumpfiles フォルダに /dbdumpfiles というファイル名でダンプされます。

    例8-4 新しいデータベースのダンプ

    # mysqldump -uroot -p --opt --add-drop-database --comments --complete-insert --dump-date --events --flush-logs --routines --single-transaction --triggers --databases stadb >  /dbdumpfiles/STA_FRESH_INSTALL_BACKUP.sql
Enter password: mysql_root_password
...
-- Retrieving view structure for table v_mdv_request_states...
-- Retrieving view structure for table version_info...
...
-- Disconnecting from localhost...

    注:

    「Can't connect to local MySQL server」のメッセージが表示された場合には、MySQL サーバーは動作していません。MySQL が起動されていることを確認します (手順 3)。

タスク 6: 古い STA データベースの STA サーバーへの転送

注:

この手順は、1 台のサーバーの方法にのみ適用されます。

STA 1.0.x または STA 2.0.x のデータベースバックアップを STA 2.1.0 サーバーに転送するには、この手順を使用します。

  1. まだ停止していない場合には、すべての STA サービスを停止します。

    # STA stop all

  2. データベースを転送します。SCP 用の–p オプションは、タイムスタンプ値を保存します。

    # scp -p backup_host:/path_to_dump_file/dump_file_name.sql.gz /local_path

    例8-5 では、SCP を使用して、圧縮済みのデータベースダンプファイル Dec14_dump.sql.gz がホスト backup1 の /dbdumpfiles から STA 2.1.0 サーバー上の /dbdumpfiles フォルダに転送されます。

    例8-5 新しい STA サーバーへの古いデータベースの転送

    # scp -p backup1:/dbdumpfiles/Dec14_dump.sql.gz /dbdumpfiles

  3. 転送されたファイルのチェックサムを実行します。チェックサム値が、タスク 1: 古い STA データベースのダンプで受け取った値と一致することを確認します。

    # cd /path_to_dump_file/
# cksum dump_file_name.sql.gz

タスク 7: 古い STA データベースの処理およびロード

STA 1.0.x または STA 2.0.x のデータベースを圧縮解除し、それを STA 2.1.0 サーバーに回復するには、この手順を使用します。圧縮解除されたデータベースは、圧縮されたデータベースの 10 - 15 倍の容量を必要とする場合があります。

  1. まだ停止していない場合には、すべての STA サービスを停止します。

    # STA stop all

  2. バックアップファイルを圧縮解除します。

    # gunzip dump_file_name.sql.gz

  3. 次の手順を使用して、SNMP レコードや空の分析レコードなどの廃止されたデータの STA データベースをパージします。

    推定時間: STA 1.0.x および STA 2.0.x では、1G バイトの非圧縮のデータベーススナップショットサイズにつき最大 1 分です。

    注:

    purgerecs コマンドアクティビティーの永続レコードは、STA データベースに保存されます。STA 2.0.x からは、データベースのパージも実行時に自動的に行われます。MySQL イベントスケジューラがさまざまなテーブルからのレコードを定期的にパージして、データベースの拡張を緩和します。

    1. STA データベースの更新ディレクトリに変更します。

      # cd /Oracle_storage_home/StorageTek_Tape_Analytics/db/updates

    2. パージを開始します。

      # ./purgerecs /path_to_dump_file/dump_file_name.sql /path_to_dump_file/dump_file_name_PURGED.sql

      注:

      purgerecs コマンドのヘルプについては、次のコマンドを入力します。 
      # ./purgerecs -h

    例8-6 では、purgerecs ユーティリティーが /dbdumpfiles の MySQL ダンプファイル Dec14_dump.sql を処理します。出力は、 /dbdumpfiles の Dec14_dump_PURGED.sql という名前の新しいファイルに送られます。200 個のレコードが処理されるたびに、進捗を示すドットが 1 つ表示されます。

    例8-6 古いデータベースバックアップからの廃止されたデータのパージ

    # cd /Oracle/StorageTek_Tape_Analytics/db/updates
# ./purgerecs /dbdumpfiles/Dec14_dump.sql /dbdumpfiles/Dec14_dump_PURGED.sql
................................................
          STA v1.0.2, Schema 33.02 
Processed 11,689 lines from '20130711_dump.sql':
------------------------------------------------
snmp_storage_cells........1,614,255
snmp_media................110,205
...
media_summaries...........254
transform_logs............0
================================================
Records Processed:........13,143,283
Records Purged:...........2,857,623
Records Remaining:........10,285,660
Elapsed Time:.............00:00:11

  4. この手順はオプションです。データベースファイルサイズを特定し、ロード処理時間を推定します。

    推定時間: STA 1.0.x および STA 2.0.x では、1G バイトの非圧縮のデータベーススナップショットサイズにつき最大 3 - 10 分です。

    # ls -s -h dump_file_name_PURGED.sql

  5. MySQL サーバーを起動します。

    # STA start mysql

  6. STA 1.0.x データベースまたは STA 2.0.x データベースをロードします。入力を求められたら、データベースの root ユーザーパスワードを入力します。–v (詳細) オプション (推奨されません) を指定した場合を除き、プロセスの実行中にコマンド出力は表示されません。

    注:

    オプションの –v パラメータ (詳細出力用) は、端末ウィンドウに多数のメッセージが表示され、大規模データベースのコマンド処理の速度を大幅に低下させる可能性があるため、推奨しません。
    # mysql -uroot -p -e "SET SESSION SQL_LOG_BIN=0; SOURCE /path_to_dump_file/dump_file_name_PURGED.sql;"
Password: mysql_root_password

    ここでは:

    • –p - STA のインストール中に設定したデータベースの root パスワードを要求します。

    • –e - 次の引用符で囲まれた文を実行します。

      • SET SESSION SQL_LOG_BIN=0; - 不要なバイナリロギングをオフにし、ロードの速度を上げます。

      • SOURCE /path_to_dump_file/dump_file_name_PURGED.sql - ダンプファイルを DB にロードします。

    コマンドが成功した場合は、プロセスの完了後にコマンドプロンプトに戻ります。

タスク 8: 古いデータベースのアップグレード

STA 1.0.x または STA 2.0.x のデータベースを新しい STA 2.1.0 スキーマにアップグレードするには、この手順を使用します。

推定時間: 1G バイトの非圧縮のデータベーススナップショットサイズごとの概算時間。

  • STA 1.0.x - 1G バイトにつき最大 5 分

  • STA 2.0.x - 1G バイトにつき最大 30 分

  1. まだ停止していない場合には、すべての STA サービスを停止します。

    # STA stop all

  2. アップグレード前提条件の確認 で /tmp のサイズがアップグレードに不十分であることが判明した場合、必要に応じて /tmp のサイズを増やします。

    これができない場合には、次の手順を使用して MySQL の環境変数を代替の一時的な場所を使用するように設定します。

    1. 代替の一時的場所を作成し、それにオープン権限を割り当てます。例:

      # mkdir /dbbackup/tmp
# chmod 777 /dbbackup/tmp

    2. MySQL を停止します。

      # STA stop mysql

    3. MySQL 構成ファイルを編集します。例:

      #  vi /etc/my.cnf

    4. ファイルの mysqld セクションで、tmpdir 変数で特定される、代替の一時的場所を定義する行を追加します。この行の追加後のファイルの例を次に示します。

      [mysqld]
#----- mysqld MySQL Server Options -------------------------
 
tmpdir                          = /dbbackup/tmp
server-id                       = 1
...

    5. MySQL を再起動します。

      # STA start mysql

  3. データベースの更新ディレクトリに変更します。

    # cd /Oracle_storage_home/StorageTek_Tape_Analytics/db/updates

  4. アップグレードスクリプトを開始し、入力を求められたら、データベースの root ユーザーパスワードを入力します。セキュリティー保護のため、パスワードは画面に表示されません。

    # ./upgradedb.sh

    注:

    この手順は、システムの root ユーザーまたは Oracle インストールユーザーのいずれかとして実行できます。

    次に、画面の表示例を示します。

    # ./upgradedb.sh

DB Root Password: 
+-------------------------------------------------------------+
| STA DATABASE UPGRADE                                        |
| Upgrading DB schema from 58.00r0 to 59.00r0                 |
| Started: 2014-12-12 15:14:45                                |
+-------------------------------------------------------------+
STA database is 5.15 GB and contains approximately 12,636,002 records.
Checking if current database v58.00 is a valid upgrade candidate...
...DB v58.00 is a valid upgrade candidate...
+-------------------------------------------------------------+
==> You may ABORT using CTRL-C within 7 seconds
==> .....6.....5.....4.....3.....2.....1
==> CTRL-C disabled!
+-------------------------------------------------------------+
Starting upgrade...

    処理が完了すると、次のようなバナーが表示されます。

    注意:

    このバナーが表示されるまで待機してから次に進みます。
    +-------------------------------------------------------------+
| Started.................2014-12-12 15:14:45                 |
| Finished................2014-12-12 17:07:11                 |
| Elapsed Time............01:52:26                            |
| Starting Version........58.00r0                             |
| Final Schema Version....59.00r0                             |
| Schema Release Date.....2014-12-12 11:00:00                 |
| Records (approximate)...12,636,002                          |
+-------------------------------------------------------------+

  5. タスク 8: 古いデータベースのアップグレードで /tmp のサイズを増やしたか、代替の一時的場所を作成した場合、それを通常のサイズおよび場所に戻します。

  6. すべての STA サービスを開始します。

    # STA start all

  7. この手順はオプションです。STA_FRESH_INSTALL_BACKUP.sql ファイルを削除して、STA データベースのバックアップボリュームのディスク領域を解放します。

タスク 9: 新しい STA バージョンの構成

STA がライブラリアクティビティーのモニタリングを開始できるよう、ライブラリおよび STA 2.1.0 を構成するには、これらの手順を使用します。

ライブラリでの STA トラップ受信者の更新

STA 2.0.x では、13 (テストトラップ) および 14 (ヘルストラップ) の新しい 2 つのトラップレベルが導入されました。各モニター対象ライブラリで次の手順を実行して、これらのトラップレベルが STA トラップ受信者の定義に含まれていることを確認します。

  1. アップグレードパスに応じて、次のように進みます。

    • STA 2.0.x からのアップグレードに 1 台のサーバーの方法を使用する場合、STA での SNMP 設定の構成に進みます。

    • STA 1.0.x からのアップグレードに 1 台のサーバーの方法を使用する場合、手順 2 に進み、各モニター対象ライブラリの既存の STA トラップ受信者に新しいトラップレベルを追加します。

    • 2 台のサーバーのアップグレード方法を使用する場合、手順 3 に進み、各モニター対象ライブラリに新しい STA トラップ受信者を追加します。

  2. STA 1.0.x からのアップグレードに 1 台のサーバーの方法を使用する場合、ライブラリモデルに適した手順を使用し、STA トラップ受信者に新しいトラップレベルを追加します。

    SL150 以外のすべてのライブラリモデルにおいて、トラップ受信者を変更するには、既存の定義を削除してから新しい定義を追加する必要があります。

    SL150 以外のすべてのライブラリ 

    1. ライブラリ CLI にログインします。

    2. 既存のすべてのトラップ受信者を表示し、STA 受信者のインデックス番号をメモします。

      snmp listTrapRecipients

    3. STA トラップ受信者を削除します。

      snmp deleteTrapRecipient id index

      ここでは:

      • index は、STA トラップ受信者のインデックス番号です。

    4. STA トラップ受信者を再度追加し、トラップレベルリストに新しいトラップレベルを含めます。手順については、STA SNMP v3 トラップ受信者の作成またはライブラリでの STA SNMP v2c トラップ受信者の作成を参照してください。

    SL150 ライブラリ 

    1. ブラウザベースのユーザーインタフェースにログインします。

    2. 「SNMP」メニューから「SNMP Trap Recipients」を選択します。

    3. リストから STA トラップ受信者を選択します。

    4. 「Modify Trap Recipient」を選択します。

    5. トラップレベルリストに新しいトラップレベルを追加し、「Save」をクリックします。

  3. 2 台のサーバーのアップグレード方法を使用する場合、各モニター対象ライブラリで新しい STA 2.1.0 サーバーをトラップ受信者として追加します。STA SNMP v3 トラップ受信者の作成またはライブラリでの STA SNMP v2c トラップ受信者の作成を参照してください。

STA での SNMP 設定の構成

すべてのアップグレードに対して次の手順を実行します。これらの手順は、STA で実行されます。

  1. STA の管理者ユーザーとして STA にログインします。

  2. アップグレード前に記録した値を使用して、STA SNMP クライアントの構成設定を再入力します。現在の STA のユーザーおよび構成設定の記録 (オプション)を参照してください。これらの値は、モニター対象ライブラリで構成されたものと一致している必要があります。手順については、STA の SNMP クライアント設定の構成を参照してください。

  3. STA とライブラリ間の SNMP 通信を復元するため、各モニター対象ライブラリへの接続をテストします。手順については、ライブラリへの SNMP 接続のテストを参照してください。

    注:

    この手順が正常に完了すると、STA は各モニター対象ライブラリからデータの受信および処理を開始します。

    STA が停止されたとき、またはライブラリ接続が復元されたときに、「Exchanges Overview」画面で進行中の交換からの不完全な交換に気づくことがあります。不完全な交換の詳細については、『STA ユーザーズガイド』を参照してください。

  4. 各ライブラリからの最新の SNMP 構成データを取得します。手順については、手動データ収集の実行を参照してください。

STA サービスおよびユーザー情報の構成

すべてのアップグレードに対してこれらの手順を実行します。これらの手順は、STA サーバーで実行されます。

以前の STA バージョンから設定を維持する場合には、アップグレード前に記録した値を使用します。現在の STA のユーザーおよび構成設定の記録 (オプション)を参照してください。

注:

アップグレード後、すべての論理グループが STA に所有されます。論理グループの所有権は STA の機能には重大ではなく、オペレータ権限または管理者権限を持つ STA ユーザーは論理グループを変更できます。

  1. STA バックアップサービスユーティリティーおよび STA リソースモニターサービスユーティリティーを構成します。詳細は、第7章 STA サービスの構成を参照してください。

  2. STA のユーザー名およびパスワードを作成します。手順については、『STA ユーザーズガイド』を参照してください。また、次のこともします。

    • STA 2.1.0 の新しいパスワード要件についてユーザーに通知します。

    • 該当する場合、ユーザーにカスタムユーザープリファレンスを再入力させます。

  3. STA 電子メールサーバーで認証が必要な場合、電子メールアカウントのユーザー名およびパスワードを入力する必要があります。手順については、『STA ユーザーズガイド』を参照してください。

  4. 該当する場合は、元の所有権をカスタムテンプレートに復元します。手順については、『STA ユーザーズガイド』を参照してください。

  5. 該当する場合は、元の所有権をプライベートエグゼクティブレポートポリシーに復元します。手順については、『STA ユーザーズガイド』を参照してください。

古い STA サーバーの廃止 (オプション)

この手順は、2 台のサーバーのアップグレード方法を使用した場合のみ適用されます。この手順は、新しい STA サーバーが期待どおりに機能していることを確認したあと、使用できます。

  1. 各ライブラリの SNMP 構成から、トラップ受信者として古い STA 1.0.x サーバーまたは STA 2.0.x サーバーを削除します。手順については、『STA ユーザーズガイド』を参照してください。

  2. 古い STA 1.0.x サーバーまたは STA 2.0.x サーバーを廃止します。

失敗したデータベースアップグレードの回復 (オプション)

注意:

この手順は Oracle サポート担当者 の指導に従ってのみ実行してください。

この手順は、タスク 8: 古いデータベースのアップグレードでのデータベースのアップグレードが正常に完了せず、アップグレードの繰り返しの試行も失敗した場合のみ使用します。

  1. タスク 7: 古い STA データベースの処理およびロード、手順 6 からタスク 8: 古いデータベースのアップグレードを繰り返します。

    アップグレードが再度失敗した場合、データベースは不明な破損状態になっている可能性があるため、データベースを元の新しくインストールされた状態に復元する必要があります。次の手順に進みます。

  2. 破損したアップグレード済みデータベースを削除します。

    # mysql -uroot -p -e "drop database stadb;"

  3. STA データベースのバックアップ場所に変更し、タスク 5: 新しい STA データベースのダンプ (オプション)で作成した新しいインストールデータベースダンプファイルをロードします。

    例:

    # cd /dbbackup
# mysql -uroot -p -e < /home/oracle/STA_FRESH_INSTALL_BACKUP.sql

  4. タスク 8: 古いデータベースのアップグレードを実行します。

  5. STA を新しいインストールとして構成します。詳細は、次のセクションを参照してください。