機械翻訳について
  1. 管理者ガイド
  2. ステータスおよびヘルス・モニタリング
  3. サポート・バンドルの使用

サポート・バンドルの使用

サポート・バンドルは、問題の評価および修正に使用される、Private Cloud Applianceから収集された診断データのファイルです。

サポート・バンドルは、Oracleサポートに自動的にアップロードすることも、手動でアップロードすることもできます。 サポート・バンドルは安全にアップロードされ、最小限必要なデータが含まれます: システム・アイデンティティ (IPアドレスではない)、問題の症状、およびログやステータスなどの診断情報。

サポート・バンドルは作成でき、アップロードできません。 自分で使用するためにバンドルを作成することもできます。 サポート・バンドルの作成は、関連データを収集する便利な方法です。

サポート・バンドルは、次の方法で作成およびアップロードされます:

Oracle Auto Service Request (ASR)

特定のハードウェア障害が発生した場合、ASRは自動的にサービス・リクエストとサポート・バンドルを作成します。 サービス・リクエストおよびサポート・バンドルはOracleサポートに自動的に送信され、Private Cloud Appliance管理者に通知されます。 「Oracle Auto Service Requestの使用」を参照してください。

asrInitiateBundle

asrInitiateBundleコマンドは、サポート・バンドルを作成し、既存のサービス・リクエストにサポート・バンドルをアタッチし、OracleサポートにアップロードするPCA-ADMINコマンドです。 「asrInitiateBundleコマンドの使用」を参照してください。

support-bundles

support-bundlesコマンドは、指定したタイプのサポート・バンドルを作成する管理ノード・コマンドです。 Oracleサポートでは、このコマンドを実行してサービス・リクエストに関連するより多くのデータを収集するように求められる場合や、ユーザー自身で使用するためにこのデータを収集する必要がある場合があります。 「support-bundlesコマンドの使用」を参照してください。

Oracleサポートへの手動アップロード

サポート・バンドルまたはその他のデータをOracleサポートにアップロードするには、いくつかのメソッドを使用できます。 「サポート・バンドルのOracle Supportへのアップロード」を参照してください。

asrInitiateBundleコマンドの使用

asrInitiateBundleコマンドには3つのパラメータがあり、すべて必須です: 

PCA-ADMIN> asrInitiateBundle mode=triage sr=SR_number bundleType=auto

triageサポート・バンドルが収集され、サービス・リクエストSR_numberに自動的にアタッチされます。 triageサポート・バンドルの詳細は、「トリアージ・モード」を参照してください。

ASRサービスが有効になっている場合、bundleType=autoはPhone Homeサービスを使用してバンドルをOracle Supportにアップロードします。 Phone Homeサービスの詳細については、「Oracle Auto Service RequestのPrivate Cloud Applianceの登録」を参照してください。

support-bundlesコマンドの使用

support-bundlesコマンドは、ヘルス・チェック・ステータス、コマンド出力、ログなどの診断データの様々なタイプのバンドル(モード)を収集します。 このトピックでは、使用可能なモードについて説明します。 このコマンドを使用する推奨方法は次のとおりです:

  1. triageモードを指定してデータ収集を開始し、Private Cloud Applianceの予備ステータスを理解します。

  2. triageモードの結果にNOT_HEALTHYが表示された場合は、次のいずれかを実行します:

    • time_sliceモードを使用して、タイム・スロット別にデータを収集します。 これらの結果は、ポッド名、ジョブおよびk8s_appラベルを指定することでさらに絞り込むことができます。

    • 特定のヘルス・チェッカからデータを問い合せるには、smartモードを使用します。

support-bundlesコマンドにはモード(-m)オプションが必要です。 一部のモードには、追加のオプションがあります。

次の表に、support-bundlesコマンドのすべてのモードに共通するオプションを示します。

オプション 説明 必須

-m mode

バンドルのタイプ。

はい

-sr SR_number

--sr_number SR_number

サービス・リクエスト番号。

いいえ

ほとんどのモードでは、support-bundlesコマンドは単一のアーカイブ・ファイルを生成します。 出力アーカイブ・ファイルの名前は[SR_number_]pca-support-bundle.current-time.tgzです。 SR_numberは、-srオプションを指定した場合に使用されます。 サービス・リクエストのサポート・バンドルを作成する場合は、SR_numberを指定する必要があります。

nativeモードの場合、support-bundlesコマンドはアーカイブ・ファイルのディレクトリを生成します。

アーカイブ・ファイルは、管理ノードの/nfs/shared_storage/support_bundles/に格納されます。

管理ノードへのログイン

support-bundlesコマンドを使用するには、Pacemakerリソースを実行している管理ノードにrootとしてログインします。 Pacemakerリソースを実行している管理ノードから、必要に応じてほかの管理ノードからデータを収集します。

Pacemakerリソースを実行している管理ノードがわからない場合は、管理ノードにログインし、Pacemakerクラスタのステータスを確認します。 次のコマンドは、Pacemakerクラスタ・リソースがpcamn01で実行されていることを示しています。 

[root@pcamn01 ~]# pcs status
Cluster name: mncluster
Stack: corosync
Current DC: pcamn01
...
Full list of resources:

scsi_fencing (stonith:fence_scsi): Stopped (disabled)
Resource Group: mgmt-rg
vip-mgmt-int (ocf::heartbeat:IPaddr2): Started pcamn01
vip-mgmt-host (ocf::heartbeat:IPaddr2): Started pcamn01
vip-mgmt-ilom (ocf::heartbeat:IPaddr2): Started pcamn01
vip-mgmt-lb (ocf::heartbeat:IPaddr2): Started pcamn01
vip-mgmt-ext (ocf::heartbeat:IPaddr2): Started pcamn01
l1api (systemd:l1api): Started pcamn01
haproxy (ocf::heartbeat:haproxy): Started pcamn01
pca-node-state (systemd:pca_node_state): Started pcamn01
dhcp (ocf::heartbeat:dhcpd): Started pcamn01
hw-monitor (systemd:hw_monitor): Started pcamn01

Daemon Status:
corosync: active/enabled
pacemaker: active/enabled
pcsd: active/enabled

トリアージ・モード

triageモードでは、Prometheus platform_health_checkはHEALTHYステータスとNOT_HEALTHYステータスの両方で問い合せられます。 NOT_HEALTHYが見つかった場合は、time_sliceモードを使用して詳細を取得します。 

[root@pcamn01 ~]# support-bundles -m triage

出力アーカイブ・ファイルには、次のファイルがあります。

ファイル 説明

header.json

このバンドルを生成するためのタイムスタンプとコマンド行。

compute_node_info.json

コンピュート・ノードで実行されているポッド。

management_node_info.json

管理ノードで実行されているポッド。

rack_info.json

ラックの取り付け時間とビルド・バージョン。

loki_search_results.log.n

jsonのチャンク・ファイル。

タイム・スライス・モード

タイム・スライス・モードでは、データは開始タイムスタンプと終了タイムスタンプを指定することによって収集されます。

-jオプションまたは--allオプションを指定しない場合、データはすべての健全性チェッカ・ジョブから収集されます。

次のいずれかを指定して、データ収集を絞り込むことができます:

  • Lokiジョブ・ラベル

  • Loki k8s_appラベル

  • ポッド名

[root@pcamn01 ~]# support-bundles -m time_slice -j flannel-checker -s 2021-05-29T22:40:00.000Z \
-e 2021-06-29T22:40:00.000Z -l INFO

次のその他の例を参照してください。

support-bundlesコマンドのタイム・スライス・モードには、このトピックの最初にリストされているモードおよびサービス・リクエスト番号オプションに加えて、次のオプションがあります。

  • 指定できるのは、--job_name、--allおよび--k8s_appのいずれか1つのみです。

  • --job_name、--allまたは--k8s_appのいずれも指定されていない場合、ポッド・フィルタリングはデフォルト(.+checker)で実行されます。

  • --allオプションは大量のデータを収集できます。 タイム・スライスを48時間に制限できます。

オプション 説明 必須

-j job_name

--job_name job_name

Lokiジョブ名。 デフォルト値: .+checker

次のラベル・リスト問合せを参照してください。

いいえ
--all audit、kubernetes-audit、vault-auditおよびk8s_appラベルpcacorednsなど、ロギングが多すぎることが認識されているジョブを除くすべてのジョブ名を問い合せます。 いいえ
--k8s_app label

k8s-stdout-logsジョブ内で問い合せるk8s_appラベル値。

次のラベル・リスト問合せを参照してください。

 いいえ

-l level

--levelname level

メッセージ・レベル

いいえ

-s timestamp

--start_date timestamp

開始日(書式yyyy-mmm-ddTHH:mm:ss)

最小引数はyyyy-mmm-ddです

はい

-e timestamp

--end_date timestamp

yyyy-mmm-ddTHH:mm:ss形式の終了日

最小引数はyyyy-mmm-ddです

はい
--pod_name pod_name ポッドに基づいて出力をフィルタするためのポッド名(kubeやnetwork-checkerなど)。 開始文字のみが必要です。 いいえ

ラベル・リスト問合せ

ラベル・リスト問合せを使用して、使用可能なジョブ名とk8s_appラベル値をリストします。 

[root@pcamn01 ~]# support-bundles -m label_list
2021-10-14T23:19:18.265 - support_bundles - INFO - Starting Support Bundles
2021-10-14T23:19:18.317 - support_bundles - INFO - Locating filter-logs Pod
2021-10-14T23:19:18.344 - support_bundles - INFO - Executing command - ['python3', 
'/usr/lib/python3.6/site-packages/filter_logs/label_list.py']
2021-10-14T23:19:18.666 - support_bundles - INFO -
Label:  job
Values: ['admin', 'api-server', 'asr-client', 'asrclient-checker', 'audit', 'cert-checker', 'ceui', 
'compute', 'corosync', 'etcd', 'etcd-checker', 'filesystem', 'filter-logs', 'flannel-checker', 
'his', 'hms', 'iam', 'k8s-stdout-logs', 'kubelet', 'kubernetes-audit', 'kubernetes-checker', 
'l0-cluster-services-checker', 'messages', 'mysql-cluster-checker', 'network-checker', 'ovm-agent', 
'ovn-controller', 'ovs-vswitchd', 'ovsdb-server', 'pca-healthchecker', 'pca-nwctl', 'pca-platform-l0', 
'pca-platform-l1api', 'pca-upgrader', 'pcsd', 'registry-checker', 'sauron-checker', 'secure', 
'storagectl', 'uws', 'vault', 'vault-audit', 'vault-checker', 'zfssa-checker', 'zfssa-log-exporter']
 
Label:  k8s_app
Values: ['admin', 'api', 'asr-client', 'asrclient-checker', 'brs', 'cert-checker', 'compute', 
'default-http-backend', 'dr-admin', 'etcd', 'etcd-checker', 'filesystem', 'filter-logs', 
'flannel-checker', 'fluentd', 'ha-cluster-exporter', 'has', 'his', 'hms', 'iam', 'ilom', 
'kube-apiserver', 'kube-controller-manager', 'kube-proxy', 'kubernetes-checker', '
l0-cluster-services-checker', 'loki', 'loki-bnr', 'mysql-cluster-checker', 'mysqld-exporter', 
'network-checker', 'pcacoredns', 'pcadnsmgr', 'pcanetwork', 'pcaswitchmgr', 'prometheus', 'rabbitmq', 
'registry-checker', 'sauron-api', 'sauron-checker', 'sauron-grafana', 'sauron-ingress-controller', 
'sauron-mandos', 'sauron-operator', 'sauron-prometheus', 'sauron-prometheus-gw', 
'sauron-sauron-exporter', 'sauron.oracledx.com', 'storagectl', 'switch-metric', 'uws', 'vault-checker', 
'vmconsole', 'zfssa-analytics-exporter', 'zfssa-csi-nodeplugin', 'zfssa-csi-provisioner', 'zfssa-log-exporter']

例:

ジョブ・ラベルなし、k8s_appラベルなし、すべてのヘルス・チェッカからログを収集します。

[root@pcamn01 ~]# support-bundles -m time_slice -sr 3-xxxxxxxxxxx -s "2022-01-11T00:00:00" -e "2022-01-12T23:59:59"

1ジョブの停滞。

[root@pcamn01 ~]# support-bundles -m time_slice -sr 3-xxxxxxxxxxx -j ceui -s "2022-01-11T00:00:00" -e "2022-01-12T23:59:59"

1つのk8s_appネットワーク・チェッカ。

[root@pcamn01 ~]# support-bundles -m time_slice -sr 3-xxxxxxxxxxx --k8s_app network-checker -s "2022-01-11T00:00:00" -e "2022-01-12T23:59:59"

すべてのジョブと日付。

[root@pcamn01 ~]# support-bundles -m time_slice -sr 3-xxxxxxxxxxx -s `date -d "2 days ago" -u +"%Y-%m-%dT%H:%M:%S.000Z"` -e `date -d +u +"%Y-%m-%dT%H:%M:%S.000Z"`

全ジョブ

[root@pcamn01 ~]# support-bundles -m time_slice -sr 3-xxxxxxxxxxx --all -s "2022-01-11T00:00:00" -e "2022-01-12T23:59:59"

出力アーカイブ・ファイルには、次のファイルがあります。

ファイル 説明

header.json

このバンドルを生成するためのタイムスタンプとコマンド行。

loki_search_results.log.n

jsonのチャンク・ファイル。

スマート・モード

スマート・モードでは、最近のNOT_HEALTHYステータスについてヘルス・チェッカが問い合せられます。 デフォルトでは、2日間のログが収集されます。 2日を超えるログが必要な場合は、--forceオプションを指定します。 ヘルス・チェッカを指定するには、-hcオプションを使用します。 

[root@pcamn01 ~]# support-bundles -m smart

次のその他の例を参照してください。

support-bundlesコマンドのスマート・モードには、このトピックの最初にリストされているモードおよびサービス・リクエスト番号オプションに加えて、次のオプションがあります。

開始日または終了日のみが指定されている場合、時間は計算され、指定された終了日の2日前または指定された開始日の2日後に問い合せられます。 開始日のみが指定され、2日の時間範囲内では、デフォルトの最近の異常時間が使用されます。

オプション 説明 必須

-hc health_checker_name

--health_checker health_checker_name

Lokiヘルス・チェッカ名。

次の健全性チェッカ・ログファイルの表を参照してください。

いいえ
--errors_only レベル名のフィルタリングは、エラー、クリティカルおよび重大でのみ実行されます。 いいえ
--force

開始日が2日の時間範囲制限を上書きするように強制します。

 いいえ

-s timestamp

--start_date timestamp

開始日(書式yyyy-mmm-ddTHH:mm:ss)

最小引数はyyyy-mmm-ddです

デフォルト値: 終了日マイナス2日

いいえ

-e timestamp

--end_date timestamp

yyyy-mmm-ddTHH:mm:ss形式の終了日

最小引数はyyyy-mmm-ddです

デフォルト値: 最新の異常時間

いいえ

次の表に、各ヘルス・チェッカに対するログ・ファイルを示します。

ヘルス・チェッカ サポート・ログ・ファイル

L0_hw_health-checker

  • pca.log, pca.health.log, pca.l1api.log, pacemaker.log

  • pca-platform-l1api

  • pca-healthchecker

  • ペース・メーカー

  • pca-platform-l0

cert-checker

ログなし - 証明書と有効期限(チェッカから)のみ

etcd-checker

  • etcd-container.log

flannel-checker

k8s-stdout-logs: ポッド(flannel)、ノードおよびコンテナによるフィルタ

kubernetes-checker

k8s-stdout-logs: ポッド(kube-apiserver)、ノードおよびコンテナによるフィルタ

l0-cluster-services-checker

  • pacemaker.log, corosync.log

  • corosync

  • pcsd

mysql-cluster-checker

  • mysqld

network-checker

  • HMS

registry-checker

メッセージ(レジストリ自体はログを生成しません)

vault-checker

  • hc-vault-audit.log

  • hc-vault-audit.log

zfssa-checker

  • zfssa-checker

  • zfssa-log-exporter (ログ= alert | audit | pcalog)

例:

-hcはありません。 すべてのヘルス・チェッカから異常なデータを問い合せます。 

[root@pcamn01 ~]# support-bundles -m smart -sr 3-xxxxxxxxxxx

-hcを使用して、1つのヘルス・チェッカを指定します。 

[root@pcamn01 ~]# support-bundles -m smart -sr 3-xxxxxxxxxxx -hc network-checker

--forceのタイムスタンプ。 

[root@pcamn01 ~]# support-bundles -m smart -sr 3-xxxxxxxxxxx -s "2022-01-11/00:00:00" -e "2022-01-15/23:59:59" --force

出力アーカイブ・ファイルには、次のファイルがあります。

ファイル 説明

header.json

このバンドルを生成するためのタイムスタンプとコマンド行。

loki_search_results.log.n

jsonのチャンク・ファイル。

ネイティブ・モード

他のサポート・バンドル・モードとは異なり、ネイティブ・バンドル・コマンドはただちに戻り、バンドル・コレクションはバックグラウンドで実行されます。 ネイティブ・バンドルでは、収集に時間がかかる場合があります。 収集の進捗情報は、バンドル・ディレクトリのnative_collection.logにあります。

また、他のサポート・バンドル・モードとは異なり、ネイティブ・バンドルの出力は単一のアーカイブ・ファイルではありません。 かわりに、バンドル・ディレクトリは管理ノードの/nfs/shared_storage/support_bundles/領域に作成されます。 このディレクトリには、native_collection.logファイルおよび多数のtar.gzファイルが含まれています。 

[root@pcamn01 ~]# support-bundles -m native -t bundle_type [-c component_name] [-sr SR_number]

support-bundlesコマンドのネイティブ・モードには、このトピックの最初にリストされているモードおよびサービス・リクエスト番号オプションに加えて、次のオプションがあります。

オプション 説明 必須

-t bundle_type

--type bundle_type

バンドル・タイプ: sosreportまたはzfs-bundle

はい

-c component_name

--component component_name

コンポーネント名

このオプションは、sosreport型にのみ適用されます。

いいえ

ZFSバンドル

typeがzfs-bundleの場合、ZFSサポート・バンドル・コレクションは両方のZFSノードで開始され、新しいZFSサポート・バンドルがバンドル・ディレクトリにダウンロードされます。 

[root@pcamn01 ~]# support-bundles -m native -t zfs-bundle
2021-11-16T22:49:30.982 - support_bundles - INFO - Starting Support Bundles
2021-11-16T22:49:31.037 - support_bundles - INFO - Locating filter-logs Pod
2021-11-16T22:49:31.064 - support_bundles - INFO - Executing command - ['python3', '/usr/lib/python3.6/site-packages/filter_logs/native.py', '-t', 'zfs-bundle']
2021-11-16T22:49:31.287 - support_bundles - INFO - LAUNCHING COMMAND: ['python3', '/usr/lib/python3.6/site-packages/filter_logs/native_app.py', '-t', 'zfs-bundle', '--target_directory', '/support_bundles/zfs-bundle_20211116T224931267']
ZFS native bundle collection running to /nfs/shared_storage/support_bundles/zfs-bundle_20211116T224931267
Monitor /nfs/shared_storage/support_bundles/zfs-bundle_20211116T224931267/native_collection.log for progress.
 
2021-11-16T22:49:31.287 - support_bundles - INFO - Finished running Support Bundles

SOSレポート・バンドル

typeがsosreportの場合、component_nameは管理ノードまたはコンピュート・ノードです。 component_nameを指定しない場合、レポートはすべての管理ノードおよびコンピュート・ノードから収集されます。 

[root@pcamn01 ~]# support-bundles -m native -t sosreport -c pcacn003 -sr SR_number

Oracleサポートへのサポート・バンドルのアップロード

「support-bundlesコマンドの使用」の説明に従ってsupport-bundlesコマンドを使用してサポート・バンドルを作成した後、このトピックで説明するメソッドを使用して、サポート・バンドルをOracleサポートにアップロードできます。

これらのメソッドを使用するには、次の要件を満たす必要があります:

  • ファイルのアップロードに使用される各サポートID (SI)の適切なカスタマ・ユーザー管理者(CUA)によって付与された、SRの作成および更新権限を持つMy Oracle SupportユーザーIDが必要です。

  • 既存のサービス・リクエストにファイルをアップロードする場合は、サービス・リクエストに関連付けられたサポートIDがプロファイルに含まれている必要があります。

  • 2 GBより大きいファイルをアップロードするには、送信マシンがFTPSおよびHTTPSを使用するには、transport.oracle.comのMy Oracle Supportサーバーに接続するためのネットワーク・アクセス権を持っている必要があります。

    Oracle FTPSサービスはパッシブ実装です。 暗黙的な構成では、初期接続はクライアントから990の制御ポート上のサービスに接続され、その後、接続は上位ポートに切り替えられてデータを交換します。 Oracleは、データ・ポート32000から42000の範囲を定義し、ネットワーク構成によっては、ポート990とポート32000から42000の両方でアウトバウンド接続を有効にする必要がある場合があります。 TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256のみが有効な暗号化メソッドです。

    Oracle HTTPS診断アップロード・サービスは、443の標準HTTPSポートを使用し、追加のポートを開く必要はありません。

    コマンドライン・プロトコルを使用する場合は、コマンドにパスワードを含めないでください。 要求された場合にのみパスワードを入力します。

  • Oracleでは、すべてのファイル転送にTLS 1.2 +を使用する必要があります。

  • 暗号化ファイルまたはパスワードで保護されたファイル(スタンドアロンまたはアーカイブ内)はアップロードしないでください。 サービス・リクエストの更新では、これは破損ファイルとして記録されるか、許可されていないファイル・タイプが見つかったためアップロードを拒否します。 FTPSおよびHTTPSを使用すると、ファイルは暗号化されます。追加の保護は必要ありません。

  • ファイル・タイプ拡張子がexe, bat, aspまたはcomのファイルは、スタンドアロンまたはアーカイブ内でアップロードしないでください。 サービス・リクエストの更新により、許可されていないファイル・タイプが見つかったことが通知されます。

ファイル2 GB以下のアップロード

My Oracle SupportポータルでSRファイル・アップロード・ユーティリティを使用します。

  1. My Oracle Supportユーザー名とパスワードを使用してMy Oracle Supportにログインします。

  2. 次の内の1つを実行します。

    • 新規サービス・リクエストを作成し、次のステップでアップロード・ボタンを選択します。

    • 既存のサービス・リクエストを選択して開きます。

  3. ページ上部の添付の追加ボタンをクリックします。

  4. 「ファイルの選択」ボタンをクリックします。

  5. ナビゲートして、アップロードするファイルを選択します。

  6. ファイルの添付ボタンをクリックします。

また、次のセクションで説明するメソッドを使用して、大きなファイルを作成することもできます。

GBが2つを超えるファイルのアップロード

200GBを超えるファイルはアップロードできません。 「ファイルの分割」を参照してください。

FTPS

構文:

サービス・リクエスト番号の後に/文字を含めてください。 

$ curl -T path_and_filename -u MOS_user_ID ftps://transport.oracle.com/issue/SR_number/

例:

$ curl -T /u02/files/bigfile.tar -u MOSuserID@example.com ftps://transport.oracle.com/issue/3-1234567890/

HTTPS

構文:

サービス・リクエスト番号の後に/文字を含めてください。 

$ curl -T path_and_filename -u MOS_user_ID https://transport.oracle.com/upload/issue/SR_number/

例:

$ curl -T D:\data\bigfile.tar -u MOSuserID@example.com https://transport.oracle.com/upload/issue/3-1234567890/

送信中のファイルの名前変更 

$ curl -T D:\data\bigfile.tar -u MOSuserID@example.com https://transport.oracle.com/upload/issue/3-1234567890/NotSoBig.tar

プロキシの使用 

$ curl -k -T D:\data\bigfile.tar -x proxy.example.com:80 -u MOSuserID@example.com https://transport.oracle.com/upload/issue/3-1234567890/

ファイルの分割

大きなファイルを複数のパートに分割し、パートをアップロードできます。 Oracleすべてのパートのアップロードが完了すると、トランスポートによってセグメントが連結されます。

HTTPSプロトコルのみを使用できます。 使用できるのはUNIXスプリット・ユーティリティのみです。 Microsoft Windows分割ユーティリティは、互換性のない書式を生成します。

アップロード時間を短縮するには、分割する前に元のファイルを圧縮します。

  1. ファイルを分割します。

    次のコマンドは、ファイルfile1.tarをfile1.tar.partaaおよびfile1.tar.partabという名前の2つのGB部分に分割します。

    重要:

    次に示すように、.part拡張子を正確に指定します。 

    $ split –b 2048m file1.tar file1.tar.part

  2. 結果のfile1.tar.partaaおよびfile1.tar.partabファイルをアップロードします。

    重要:

    これらの出力パート・ファイルの名前を変更しないでください。

    $ curl -T file1.tar.partaa -u MOSuserID@example.com https://transport.oracle.com/upload/issue/SR_number/
$ curl -T file1.tar.partab -u MOSuserID@example.com https://transport.oracle.com/upload/issue/SR_number/

  3. コマンドを送信してパーツをまとめます。

    ス・ピット・ファイルはサービス・リクエストに添付されません。 最終連結ファイルのみがサービス・リクエストに添付されます。 

    $ curl -X PUT -H X-multipart-total-size:original_size -u MOSuserID@example.com https://transport.oracle.com/upload/issue/SR_number/file1.tar?multiPartComplete=true

    前述のコマンドで、original_sizeは、ファイル・リストに示されている元の分割されていないファイルのサイズです。

  4. 新しく添付されたファイルのサイズを確認します。

    ノート:

    この検証コマンドは、ステップ3の連結コマンドの直後に実行する必要があります。 それ以外の場合は、ファイルの処理が開始され、このコマンドで使用できなくなります。 

    $ curl -I -u MOSuserID@example.com https://transport.oracle.com/upload/issue/SR_number/file1.tar
    X-existing-file-size: original_size

中断されたHTTPSアップロードの再開

異常終了したファイル・アップロードを再開できます。 再開はHTTPSを使用してのみ実行できます。 再開はFTPSでは機能しません。 アップロードがイベントによって中断された場合、中断されたファイルのファイル・サイズの取得から開始

  1. すでにアップロードされているファイルの量を確認します。

    $ curl -I -u MOSuserID@example.com https://transport.oracle.com/upload/issue/SR_number/myinfo.tar
HTTP/1.1 204 No Content
Date: Tue, 15 Nov 2022 22:53:54 GMT
Content-Type: text/plain
X-existing-file-size: already_uploaded_size
X-Powered-By: Servlet/3.0 JSP/2.2

  2. ファイルのアップロードを再開します。

    ステップ1の「X-existing-file-size」で返されるファイル・サイズに注意してください。 このファイル・サイズは、-Cスイッチの後および-H “X-resume-offset:”スイッチで使用します。 

    $ curl -Calready_uploaded_size -H "X-resume-offset: already_uploaded_size" -T myinfo.tar -u MOSuserID@example.com https://transport.oracle.com/upload/issue/SR_number/myinfo.tar

  3. 最終ファイル・サイズを確認します。

    $ curl -I -u MOSuserID@example.com https://transport.oracle.com/upload/issue/SR_number/myinfo.tar
-H X-existing-file-size: original_size

    前述のコマンドで、original_sizeは、ファイルのリストに示されている元のファイルのサイズです。