おつおつー＾＾
明日は友達と遊び、今日も通話してていろいろ今週は人とかかわる時間が多い週になっています笑
今日は黒本半分復習はしましたが、肝心のこれからの計画は立てれませんでした。
そんなに焦ってはいないため、明日やれればやろうというというくらいでゆっくりしていきたいと思います。
今日はあんまり勉強しませんでしたー！
おつおつー＾＾
ちょっと、今日は朝にjavaの勉強してそこからはなにもせずに今23時20分です。
明日からはやったことをきちんと書いていこうと思います。
あったこともいろいろ書いていきたいと思います。
では今日はすみませんおやすみなさい！
GW最後に今月末受験予定のoracleDBの勉強計画立てました
おつおつー＾＾
GWの計画である黒本については一週目読破し、計画通りとは全然いっていないものの最低限目標は達成しました。
今後の今月末受験予定のoracleDBの勉強計画を立てようとおもい記事にしました。
GWの振り返りはいったんおいておいてとりあえず、計画立てていきます。
oracle DB bronze 1z0-085 勉強計画
そもそも何をどれくらいする必要があるのかわかっていなかったため、合格体験記をネットで調べてまとめました。
【合格者がやったこと】
- 黒本3周と問題解く（5/6~5/16）
- ping-t（5/18~5/23） ping-t.com
- oracleによるサンプル問題（5/17) www.oracle.com
余力があったら
* OracleMaster Bronze DBA 12c (通称”白本”)
合格記 ping-t.com
昨日できなかった分の続きやるわー＠GW最終日～10章の勉強やっていくよー
おつおつー＾＾
昨日は勉強ほぼせずに最終日迎えましたー
現在時刻は10時半過ぎです、電脳コイルを見てました笑
とりあえずoracleの勉強を終わらせていこうと思います。
バックアップリカバリ
メディアリカバリを行うには、あらかじめデータベースをARCHIVELOGモードで運用する必要があります。
ARCHIVELOGモードで運用すると、データベースのOPEN中にバックアップを取得できます。
NOARCHIVELOGモードにしていた場合、メディア障害が発生しても障害発生前の状態に復旧することはできません。
ARCHIVELOGモードではアーカイブログファイルが、指定したディレクトリ以下に出力されます。このことをアーカイブといいますが、この動作によりデータベースに対する一連の変更履歴を保管できます。
データベースをARCHIVELOGモードの構成は2つの手順を実行します。
高速リカバリ領域の構成とARCHIVELOGモードに変更です。
高速リカバリ領域は、oracleDatabase10gより導入されたリカバリ関連ファイルを一元的に管理するためのファイルシステム上の記憶域です。
ここでのリカバリ関連ファイルとはバックアップファイルやアーカイブログファイルなど、また加えて制御ファイルやREDOログファイルの多重化したコピーを配置する場合もあるそうです。
高速リカバリ領域はARCHIVELOGモードの場合、使用必須ではないですがリカバリファイルの管理を不要ファイル自動削除などして簡素化できます。
この領域の実態はDB_RECOVERY_FILE_DEST初期パラメータで表示され、_SIZEを付けることで領域のサイズ指定ができます。
ARCHIVELOGモードへの変更はALTER DATABASE ARCHIVELOG;を実行します。
NOARCHIVELOGについては、メディア障害発生時にバックアップ取得時点の状態にしか復旧できないため、本番環境ではARCHIVELOGモードで運用されます。
RMANでの操作としてバックアップの取得ができます。BACKUP DATABASEコマンドを実行することで取得でき、そのバックアップ出力先には、ファイルシステム上の記憶域またはテープ装置を使用できます。
RMANでのバックアップ取得はバックアップセット、イメージコピーといったファイル形式を使用できます。
バックアップセットは未使用領域の圧縮や暗号化など様々な拡張機能が利用可能でRMAN独自のファイル形式です。
イメージコピーはバックアップ元のファイルと物理的に同一のコピーでファイルサイズも元ファイルと同じになります。
データベースのバックアップではすべてのデータファイルおよび制御ファイル、SPFILEをバックアップ対象とします。RMANのBACKUP DATABASEコマンドを使えば自動的に対象ファイルをバックアップできます。一部のファイルが欠けていると復旧できません。
非一貫性バックアップと一貫性バックアップですが、取得時のデータベースのOPENか停止かの状態により分類されます。
データベースがOPENとなっている際にバックアップ取得すると非一貫性バックアップやオンラインバックアップ、ホットバックアップと呼びます。
バックアップを非一貫性バックアップとして取得する運用が一般的です。
一方、データベースを停止して取得することを一貫性バックアップやオフラインバックアップ、コールドバックアップといいます。
データベース取得時にREDOログファイルに記載されたコミット済みのトランザクションによる更新がデータファイルに反映され、データベースファイルが一貫性を持つ状態となります。
次にリストアについてですが、破損したファイルをあらかじめ取得していたバックアップで置き換えることで、置き換えについては同じファイル名でのリストア以外に異なるファイル名でのリストアも可能です。
リストアは古い状態のためリカバリで障害発生直前の状態にします。
リストアリカバリのコマンドは以下になります。
RMAN>RESTORE DATAFILE パス; RMAN>RECOVER DADTAFILE パス; RMAN>ALTER TABLESPACE 表領域名 ONLINE;
RMANでのRECOVERコマンドはデフォルトで障害発生直前の状態になるまでデータファイルにREDOデータを適用します（完全リカバリ）。
またRMANでのoracleデータベースはSYSBACKUP権限など指定しない場合はSYSDBA権限で接続されます。
$ rman target / or $ rman target '"ユーザー名/パスワード as sysbackup"'
TARGETはバックアップ対象のデータベースに接続することを示しています。
rmanコマンドに続けてAS SYSBACKUP を指定する場合、シングルクオーテーションとダブルクオーテーションの両方で囲む必要があります。
先ほど完全リカバリについて説明しましたが、不完全リカバリも復旧方法としてあります。
不完全リカバリは障害発生直前の状態ではなく、指定した過去のある時点にデータベースを復旧する方法です。
Point-in-Timeリカバリと呼ぶこともあります。
適用するREDOデータはリストアしたバックアップの取得時点から復旧のターゲット時点までです。
話が飛びますが、障害の対処法をそれぞれまとめたものを表として次の説明に移ります。
| 障害の種類 | 障害の要因・状況 | 障害発生時の動作および対処方法 |
|---|---|---|
| トランザクション実行中の意図しないセッション切断 | ユーザーの誤操作やクライアントアプリケーションの異常終了 | PMONプロセスが実行中トランザクションを自動的にロールバックする |
| インスタンスの異常終了 | HW障害、SHUTDOWN ABORTの実行、Oracleのバグなどの理由でインスタンスが異常終了した | インスタンスリカバリ |
| メディア障害 | ディスクドライブやコントローラの障害、利用者の操作ミスなどの理由でファイルが破損消失 | メディアリカバリ |
| ユーザーの誤操作によるデータの消失 | 表やデータを誤って変更または削除した | 管理者がフラッシュバック操作を実行 |
可用性を高める構成（機能）
黒本には用語とそれの理解をするだけでいいと書いてあったため、そうします。
Oracle Real Application Clusters
データベースサーバーまたはインスタンスに障害が起きるとサービスは停止しますが、この構成を使うとサービス停止を回避できます。
この機能は複数のデータベースサーバーを連携して動作させることが可能です。
すべてのデータベースファイルを共有ストレージ上に配置し、すべてのデータベースサーバーのインスタンスが共有ストレージ上の一つのデータベースにアクセスする構成です。
またこの機能だとデータベースを停止することなくデータべースサーバーを追加し、性能向上できるスケールアウトや、データベースバッファキャッシュにキャッシュされたブロックをデータベースサーバー間で共有し、高い性能を実現できるキャッシュフュージョンジョンがあります。
Oracle Clusterware
複数のデータベースサーバーを連携して動作するのに必要なソフトウェアです。
oracleDataBaseには含まれておらずOracleGridInfrastructureに含まれています。
データベースサーバー上でインスタンスやプロセス監視をし、障害時プロセスを起動するデータベースサーバーの変更やサービス引継ぎ（フェイルオーバー）などの処理を実行します。
Oracle Automatic Storage Management
複数のストレージ統合、複数ストレージへの並列書込み読み込みを行うストライピング、同一データを複数ストレージに重複書込みをして耐障害性を高めるミラーリングの機能があります。
ASMの使用の際にはASMインスタンスが必要です。
Oracle Data Guard
データセンターや地域レベルでの災害を想定した機能です。
遠隔地にスタンバイデータベースと呼ばれる予備用データベースを作成します。
通常使用するデータベースをプライマリーデータべースとして、障害発生時はフェイルオーバーを行います。
スタンバイデータベースにはREDOデータを伝播させます。
平常時は読取り専用としてオープンし、負荷の高い処理をスタンバイデータベースを実行できます。（オフロード）
フィジカルスタンバイデータベースとロジカルスタンバイデータベースがありますが、一般的にはフィジカルスタンバイデータベースです。
ゴールデンウィークもあと少し！今日でとりあえず目標の黒本終わらせるぞー10章の勉強やっていくよー
おつおつー＾＾
現在朝9時35分です。
朝から少しアニメ（電脳コイル）を見てそのまま寝てしまい今日の朝のjavaコーディングはなしに...
とりあえず、今のところoracleDBの勉強は順調なのですが、javaが...
昨日終わらせるはずのすっきりわかるjava入門が終わっていません！
11章から16章まで終わっていないため、それもやらないといけませんが、とりあえずoracleDBを先に終わらせていこうと思います。
バックアップリカバリと構成について
メディアリカバリとは、データベースファイルが破損した場合に実行するデータベースファイルが破損した場合に実行する出たベースの復旧手段です。
ファイル破損はメディア障害と呼ばれます。
メディア障害はストレージ装置の異常動作や故障、データベース管理者の作業ミスによるファイル誤削除などにより発生します。
メディアリカバリのポイントを以下にまとめます。
バックアップおよびメディアリカバリ操作は、Recovery Manager（RMAN）というoracleに含まれるツールを使用し、実行します。
※本当にすみません今日はここまでです..
GWも終盤！今日はoracleDB9章やっていくよ！
おつおつー＾＾
今日はやること盛りだくさんですが、oracleDBの9章勉強していきます！
勉強は14時スタートです....
データベースの監視とアドバイザの使用
データベースの監視
EM Expressを使用したデータベースの状態とワークロード（処理負荷）およびパーフォーマンス（処理性能）を監視する機能について説明します。
EM Expressのデータベースホームでは、以下のセクションで分けられており監視できます。
| セクション | 説明 |
|---|---|
| ステータス | データベースの状態の概要 |
| パフォーマンス | アクティブなセッション情報 |
| リソース | 最新のデータポイント（過去1分間）のリソース使用率 |
| インシデント | データベース内でのクリティカルエラーの発生 |
| 実行中のジョブ | 現在実行されているデータベースジョブ |
| SQL監視 | SQLのアクティビティ |
指定した期間に応じたパフォーマンスを確認する場合は、パフォーマンスハブを使用します。
デフォルトでは過去1時間のリアルタイムデータが表示されます。
パフォーマンスハブにあるアクティブセッション履歴（ASH）では、1秒間隔で取得されたOracleDBのアクティブな全セッションの履歴情報です。
処理実行中の情報であるため、オラクルデータベースで過去実行された処理の詳細を把握できます。
ASHデータはAWRスナップショットの一部として保管されます。
先ほどまではEM Expressによる管理の説明でしたが、これからoracleデータベースが自データベースを自己監視/診断するための機能について説明します。
先ほどアクティブセッション履歴でも出ていたAWR（自動ワークロードリポジトリ）はoracleデータベースの問題の検出と自己チューニングを目的として、統計情報とワークロード情報を自動的に収集・管理する機能です。
AWR使用する際はとくにインストール等する必要はありません。
AWRスナップショットについてですが、AWRにより収集されたある時点の統計情報とワークロード情報のことをAWRスナっプショットといいます。
ADDMやアドバイザといった機能によって、データベースの稼働状況を分析し、改善策を提示するための基礎データとなります。
AWRスナップショットはSYSAUX表領域に保存されます。
デフォルトでは60分間隔で収集され、SYSAUX表領域に8日間保存されます。
ADDM（自動データベース診断モニター）は、oracleデータベースに搭載された自己診断エンジンです。
ADDMを使用すると、oracleデータベースによってデータベース自身のパフォーマンスが診断され、問題の解決方法を数値化した効果とともに管理者へ推奨します。
ADDMはデータベースがオープンされていない状態では分析できず、ほかのアドバイザからADDMが起動されることはありません。
ADDMは分析の結果に応じて、アドバイザ機能を実行する場合があります。
ADDMはAWRスナップショットが生成されるたびに自動実行されます。分析はAWRスナップショットに含まれる情報をもとに実行され、その結果はSYSAUX表領域内のAWRに格納されます。
ちなみに、ADDMは手動で実行することが可能です。
パフォーマンス診断
オラクルには最適な設定値やパフォーマンスの改善策を推奨するアドバイザ機能が実装されています。
SQLチューニングアドバイザとSQLアクセスアドバイザについて説明します。
以下一旦それらについて表にてまとめます。
| アドバイザ | 機能 | |
|---|---|---|
| ADDM | データベース全体のアドバイス | |
| メモリーアドバイザ | メモリーアドバイザ | 自動メモリー管理モードの場合、インスタンス全体のメモリーを最適化 |
| PGAアドバイザ | 自動PGAメモリ管理モードの場合、インスタンス全体のメモリーを最適化 | |
| SGAアドバイザ | 自動共有メモリー管理モードの場合、SGAの構成に関する各コンポーネントサイズを最適化する | |
| 共有プールアドバイザ | 共有プールの最適サイズを提供する | |
| データバッファキャッシュアドバイザ | データベースバッファキャッシュの最適サイズを提供する | |
| SQLアドバイザ | SQLチューニングアドバイザ | パフォーマンスを向上させる推奨項目（SQLの書き換え、索引作成の推奨）を作成する |
| SQLアクセスアドバイザ | SQLを実行する際のアクセスパスに関するチューニング（索引やマテリアライズドビューの作成）を推奨する |
SQLチューニングとは、パフォーマンス基準を満たさないSQL文を診断および修復する試みです。
チューニングの概念は実行計画にあります。
実行計画とは表などにアクセスする経路のことでアクセスパスとも呼ばれます。
最善の実行計画を選択するためには、オプティマイザ統計情報や索引をもとに実行計画を作成されているためオプティマイザ統計情報が古いまたは索引が作成されていないといった場合を避ける必要があります。
オプティマイザとはSQL実行する場合に使用する内部コンポーネントのことです。
SQLチューニングアドバイザはオプティマイザ統計の収集や新規索引の作成、SQLの修正、SQLプロファイルの作成などを推奨事項を出力するものです。
SQLチューニングアドバイザの推奨事項を見るのは管理者です。
またSQLチューニングアドバイザはチューニング対象とする高負荷SQLをソースから取得可能にします。
そのソースと説明を以下表としてまとめました。
| ソース | 説明 |
|---|---|
| トップアクティビティ | 過去1時間に実行されたSQLのうち、問題ありそうな（最もリソースを割いている）SQLをが評価される |
| 履歴SQL | 24時間単位でSQL |
| SQLチューニングセット | AWRスナップショットによって取得されたSQLまたは任意のSQLワークロードから作成された一連のSQLが評価される |
SQLチューニングセット（STS）はSQLが実行された状況を示す情報（実行コンテキスト）、SQL実行時の実行統計（経過時間、CPU時間、バッファ読取り、ディスク読取り、処理された行数など）をまとめたものです。
SQLチューニングセットにSQLを追加するには、AWR、共有プールなどから情報を登録します。
oracleデータベース管理者がSQLを直接指定して追加することも可能です。
自動SQLチューニングタスクはSQLチューニングアドバイザを自動的に実行する仕組みです。
自動SQLチューニングタスクはAWRから負荷の大きい問い合わせ（SELECT文）を選択し、SQLチューニングアドバイザを実行し、推奨事項を出力します。
SQLアクセスアドバイザも説明しようと思いましたが、明日更新します。(2021/05/04/22:47更新できず）
