【読了】世界一わかりやすい20秒プレゼン実践メソッド
自己分析ツール使った結果、自己主張が弱いとあって、確かに物事始める時悩むことあるので色々勉強し始めました。もっとうまい主張の仕方があると思います。 ピープルマネジメント本はよく読んでましたが、ビジネスリーダーシップに関する書籍はあまり読んでこなかったので数冊読んで勉強中です。 その中からの1冊。ピッチスキルの習得により、頭のやりたいことを整理する力、それを伝える力を習得したい。これ以外にアサーションについても勉強しようと思います。今よりさらに物事うまく進めたい。
より実践的で、明日から試せる内容もたくさんあるので、特に営業始めての方は読むといいかなと思いました。伝えたいものを整理し短時間で伝え、次のアクションにつなげる。そんな要素が詰まってると思います。詳細知りたい方は是非本と手に取ってみてください。
メモです
EP エレベータピッチとは
- ハーバードで初日に教わるスキル
- 投資家にエレベーターの短時間で、興味を惹き次にアクションにつなげるスキル、短時間で強力に売り込む
- EPの要素、人を動かす3要素
- 論理 = 内容
- 信頼 = 伝え方
- 情熱 = 熱意
戦略
- ゴール設定:EP後にどんなアクションをして欲しいのか、何をお願いしたいのか
シナリオをまとめる
- ダイヤモンドメソッド:結論、利点1・2・3、展望
- 想定問答を準備する:否定的な内容から作る
- 一言で言うと?なぜこの提案を考えた?熱意、思いは何?我々にどんな価値を提供できる?ゴールは?方法は?競合は?ハードルは?誰と実現する?市場調査は?
話し方
- 復唱、結論、理由、以上
- ジェスチャー
練習
- とにかく練習、録画する、時間厳守
詳細気になる方は、是非書籍を手に取ってみてください。
【読了】「もえつき」の処方箋
思うところがあって読みました。 今の自分にとっていい本でした。 人はうまくいってないことが続くと、さらに頑張ろうとするが、解決しない状況が続くと燃え尽きる。 本人が全て悪いというより、環境だったり、状況だったり、本人ではどうしようもないケースもあるが、責任感ゆえに自責にしすぎて、自分が壊れていくこともあるんだなと学びました。
辛くなったら、一度立ち止まって、逃げる。それは負けではなく、次につながる一歩。
この本のおかげで、自分を客観的に分析できたのでスッキリしました。悶々としている人は、もえつきる前に気づいてほしい。
メモです
- できない時の対処法を持っていない
- 断るとか時期をずらすとか調整できていない
- とにかく、全部うまくやるという感じになってる
- 自分は共依存になっている?
- 自分の進め方と環境や状況の問題の区別がついていない
- ダイエットもできていない、プロジェクトもできていない、仕事の成果が上がってない、何もかもうまくいってない感じがしている、でも、だからこそ、自分がもっと頑張らないとという気持ちになっている、これが半年続いている自己肯定感や自己効力感を失ってるのかも
- 今のスケジュールにそもそも無理がある、状況を整理すべき
- 自分の黄色信号
- 今までやってたことがすべてめんどくさくなる
- お酒をひたすら飲む、休みの日朝から飲むことも
- 食べすぎる、とにかくお腹いっぱい食べてしまう
- SNS投稿控える
- 誰かと遊ぶのがおっくう
- アクション
- 休息とやること減らすようにする
- 集中と選択、優先順位をつける、今最も大事なことは?
- 自分ができていることを認める
- どうしたいか、だうなってほしいか、ノートに書き出す
- 助けてほしいって伝える
- ポイント
- 適切な境界を持つこと
- 限度、限界に気づくこと
- 自分を許し認める
- 助けを求める能力
- 手を抜く能力
- 手放す能力
- Noという能力
- 交渉する能力
- 降参する能力
【読了】最高の結果を出すKPIマネジメント
読みました。めちゃ参考になりました。 具体例がたくさん明示されており、とても読みやすかったです。KPIの真髄を学べました。体型的にかつミスしやすいポイントが詳しく載っていおり、自分のKPIの認識がかなり変わりました。つまり、間違いまくってましたw この本のおかげで、実務に導入できそうです。
読書メモです
KPIの基礎知識
- KPIマネジメント
- 現在の事業にとっての最重要プロセスを明確にし(CSF) > KGIを達成するためにもっとも重要なプロセスを1つ選択
- それをどの程度実行すると(KPI) > CSFを数値にしたもの
- 事業計画が達成できるのか(KGI) > 期末にクリアしたいこと
- KPI設定で間違いすいポイント
- KPIだけを見て、KGIやCSFがない
- たくさんのデータを集めて満足している
- たくさんの数値目標を設定している
- コントロールできないものを指標としている
- 旬なデータではない
- モニタリングする指標や数値が間違っている
- KPIのステップ
- KGIの確認(利益など)
- キャップの確認(現在との差)
- プロセスの確認(モデル化)
- 絞り込み(CSFの設定)
- 目標設定(KPIの目標を決める)
- 運用性の確認(整合性・安定性・単純性があるか)
- 対策の事前検討(KPI悪化時の対策と有効性の事前検討)
- コンセンサス(関係者との合意)
- 加えてリスク管理:どれくらいKPIが悪化した場合、いつ誰が判断し、どうアクションするか
- 運用
- 継続的に改善
KPIマネジメントを実践するコツ
- 分母が変数になるときは十数にする。ヒット率ではなく、ヒット数にする
- CSFはひとつだけに絞る
- 相互作用する変数は、影響が少ないものは定数にしてしまう(例:コスト削減する必要があるが、広告するには費用が発生する。この広告費は定数にしてしまう)
- 受注率、営業量であれば、先に受注率を上げる施策を行っていないとだめ。優先順位をつける。
【読了】オープンオーガニゼーション
読みました。すごくいい本でした。経営者が何に悩みどういうアクションが会社の成果につながったのかが分かりました。また、超トップダウンの企業からボトムアップ企業への転職したCEOなので、そのオープンな組織とのギャップが描かれていました。これまたおもしろい。
一番印象に残ったことは、実力主義な組織ということ。役割関係なく実力あるものが発言力もあるし成果を出しているということ。オープンでフラットな組織がどういうものか、そしてオープンな組織で求められるリーダー力がありのまま書かれていました。とても参考になりました。
内容を思い返すと、「我々の間には、チームプレーなどという都合のよい言い訳は存在せん。有るとすればスタンドプレーから生じる、チームワークだけだ。」という言葉を思い出す組織だなと。
心に残ったことをメモ
モチベーションと情熱
- リーダーの役割は、継続的に社員の情熱を掻き立てること
- 論点がずれていても社員のディスカッションを大切にする。それは必ず主体性につながる。ギブアンドテイクが必要
- フィードバック自体に価値はないかもしれないが、ちゃんと向き合うことは従業員の主体的な参加を引き出す
- 悪いニュースは直接の話すのがよい。誠意を持って対応する。
- 自分の仕事は、背景、課題、ゴールを作るところ
- アワード、アンケートをポイント制にする。リワード。信頼関係、透明性、実力主義を支える
- 業務、ブログ、革新の割合決める
- アイデアを、試すのに承認が面倒とかあったりします?
- 事例化は顧客をヒーローにしたい、という思いから
- 提案しやすい雰囲気を作る、働きやすい環境
- 月次で職務技術書を振り返る
- 強力を得るには困ってることを打ち明ける
- リーダーは誠実で率直であること
- 評判を得るには時間と努力が必要
- 全員がリーダーでありマネージャーであるなど、入社時のオンボーディングに入れる
- 難易度の高い課題に立ち向かう姿勢
- 顧客フィードバックを大切にする
- ディスカッションできる場を作るための勉強する
- 議論において創造的摩擦というのがある。紛争が破壊よりも創造にながりもっともうまく機能する。ピクサーはこれに従っている。集団的知識と率直な意見を引き出す。
- 自分が利用したい!というサービスになっているか?
- 理想主義と現実主義とのギャップをどう埋めるか
実力主義
- 実力主義とは、自然と非公式のリーダーが生まれ、経営システム全体の鍵を握る。実力を持っている人が決定権の割合が大きくなる。誰かが決めるのではなく自然とそうなるのが実力主義。
- 先駆者の文化を作る(成果高いメンバーをプリンシパルにする
- 一貫性があって私心がない
- ずる賢く立ち回るだけだと成果として認められない文化
- 会社のミッション、目的に積極的にかかわり、目的地達成のため汗を流した人が影響力を持つ
- ポジティブな実力主義を作る
- 管理職はエンジニアリング+マーケティングなどの二重の技術を持つ物がより昇進するようにする。これがより実力があるということ。
- 全員何かしらのスターになってほしいなぁ
- フィードバックを恐れない、誰でもオープンに発言できる。ただし、批判だけするものは評価されないだろう。批判に加えてアクションを起こしたものが評価される。
- カスタマーエクスペリエンス&エンゲージ部門がある
- フラットにしている。自己紹介で副社長という紹介はしない。サポート野郎だという。
- カジュアルな服装だけではなく、オープンな振る舞いが大切。
- 多くの企業は、率直な対話が欠如している
- 経営者がやることは、スタッフからアイデアを引き出し、常に貢献させること
- フィードバックは贈り物だと捉える
- 部屋の中の像を避けていないか?どうやったら議論できるか考えよう
意思決定
- 意思決定に社員を巻き込む、当事者意識が生まれる
- 自分の考えに意見もらうようにする、どう思う?、一緒に解決策を練ることに価値がある
- 意思決定に反対する人は少なからずいる。そのとき、命令で無理やり意見を通すのではなく、耳を傾け代案を提示するのがよい。例えば、やってみて失敗したら元に戻すなど。
- 個人的にもっとファシリテーションの勉強したほうが良い、もう少しオープンに話したい
- なんだかんだ、最終的な意思決定社員はリーダー
- 不人気な施策でも、透明性をもって時間をかけて説明することで、計画を進めることができた
- オープンソースの早く頻繁にリリースを組織の意思決定にも利用する
- 企業理念をオープンな手法で決めた話。フラットに社員に意見を求める。共感できたし、みんな納得感あるものになる。
- ミッションやビジョンについて、確信が持てる納得できるまで質問や提案をしてもらう。企業戦略立案の民主化
- 社員とのコミュニケーションを取るのではなく、関係性を深めるところを重要にしている
- この意思決定プロセスを顧客ともやっている
- 欠点は、意思決定に参加したい人は思ったほど多くないということ、グループでの意思決定は時間がかかること、全体へ広げるには徐々にすすめる
- まずは先駆者メンバーからの意見をもらう
- 誰かが驚くような意思決定か自問自答し、驚く人がいれば巻き込む
- リーダーは触媒、海にある杭のようなもの。杭があることで様々な生物が集まる
- リーダーの役割は課題設定し議論の範囲を定め、ひとをまとめる場を作る力
- リーダーとしての立場をどう力するか?
- 直接あって話すことも大切
- 生焼けでも考えを共有する
- リーダーの役割は部下たちの感情にリアルに響くメッセージと目的意識を明確に述べる、ポジティブな方向へと動かすこと
- 製品のパフォーマンスや機能など技術的な利点、使いやすさやドキュメント品質、この次に求められるのは顧客ビジネスを理解することが求められる。成長すればするほど顧客に焦点を当てることが必要かとなる
- 顧客に耳を傾けることが重要。それによりより強力な製品になる。ただし、最前線のテクノロジーと顧客の要望に応えることはトレードオフの関係。顧客に耳を傾けることは今後の将来において重要だということを説明する。具体的なアクションやチームを作るわけではない、これが生焼けのアイデア。
- 行動を起こすきっかけを作るのがリーダーの仕事
- 社員全員が課題を正しく理解し、自由な発想で問題解決に取り組めるよう、絶妙なバランスで体制を整える
- 小さく頻繁にリリースし、早く失敗する、これを組織運営にも取り入れている。成功したプロジェクトは自然と大きくなり、失敗したプロジェクトは終了しメンバーはまた違うプロジェクトへ移っていく
- 議論する場合を見つけるor作る、課題への質問をする、解決プロセスはあえて曖昧にする、チームにアイデアや提案を求める
- ボトムアップで緻密な飛行機が作れるか?この問いは、密結合な飛行機、疎結合なソフトウェアの違いに感じた。逆に飛行機を疎結合にできたらボトムアップでも作れそうな
短期的な成果よりも、長期的な成長期を重要にする
なぜ無料のソフトウェアで稼げるか?なぜ人は水を買うのか?と同じ。インターネットのソフトウェアは沼地の水をのようなもの。それをペットボトル入りの水にしている。マルウェア対策などのセキュリティ向上、様々な変更を可視化しテストすることで様々なデバイスでの動作を保証している。
トップダウンは密結合な組織、オープンな組織は疎結合な組織な印象でした。
オープンソースコミュニティは、同じような課題を持つ会社がタッグを組む場所。協力し合うことで早く高い価値を得られる。例えばLinuxを一から作ると、8000年収と100億ドルかかる。オープンなコミュニティによるグローバルなげんきだまで、これらがものすごいスピードで作られ、かつ無料で利用できるのは本当すごい。
【読了】日本医療の不都合な真実
どの業界でも闇というか、課題があるんだなと思いました。また、ITで普通に使っている仕組みなど、他の業界では当たり前じゃないのだなと。そして逆も然りかもです。他の業界を見るのもいいなと改めて感じました。
ただ守ればいい。ではなく、本人の意思も尊重すべきだ、と考えさせられる本でした。
- 日本の一人当たりの病床数は世界トップ
- しかしコロナで確保された病床数は2%以下、なので足りない、ホテル使ったり
- 背景には、公共の病院が少ないので、国から指示が出せない。病院側も未知の領域のため強力に躊躇して。国としても統制ができない。そんな感じ。
- また、なぜ日本の病床が多いかというと、市場失敗の原理が適用されているから。日本は国で保険を用意し、病院行っても負担が少ない。なので、気軽に病院に行き検査や入院も気軽にできる。海外は別。医療費保険がない場合もある。日本は病院を立て、病床数を確保し、継続的な通院や入院により利益が増える。気軽に利用してもらう。利用者が増え医師不足。この状況が成り立ってしまう保険制度。国の医療費が増える一方。国から負担しているため、公共の病院にしすると解決するのでは?という提案。
- 現状、たくさんある病床は高齢者メインで利用されている。介護に近いレベルのもの、老衰末期の延命対応など。
- ビジネス構造的には建売に似てるなと思った
- イギリスではプライマリケアという制度があり、必ず担当医がつく。その人を知り、幅広く見てくれる。重症な場合は、高度な医療へエスカレーション。サポートでいうと、ヘルプデスクとエスカレーションチームのような関係。確かに効率的なやり方はありそうだなと思った。
- 夕張では財政破綻し、大病院が縮小し、医療破綻が叫ばれた。だけど結果を見ると死亡者が増加していない。プライマリケアのように、在宅メインの診療にしたり、クライアントに寄り添った対応をすることで、柔軟な対応により病床数が減ったが、実質医療崩壊は起きなかった。医療費も減った。経験より、縮小してもやっていける。
- ITILの運用プロセスの考え方が、プライマリケアに似てるな感じた
【読了】読むだけで絶対やめられる禁酒セラピー
禁酒セラピー [セラピーシリーズ] (LONGSELLER MOOK FOR PLEASURE R)
- 作者:アレン・カー
- 発売日: 2011/12/23
- メディア: 新書
読みました。ゆっくり2ヶ月くらいかけて。結果はというと。
- お酒に対するコントロールを失っていた事に気づいた
- 依存していないと考えていたが、毎晩飲まずにはいられない状態は依存しているということを理解した
- アルコールは体に良くない、毒であると理解した
- 毎晩やっていた晩酌がなくなった
- 飲んだ後のだるさが怖くなった
- 飲まなくても眠れることに気づいた
- だるくて体調が悪い日がなくなった
- 時間がめちゃくちゃ増えた
- ゲームとか読書の時間が増えた
- 暇だなーと思うことが増えた、アルコールから解放されたんだなと思うようになった
- 「飲むことが幸せ」から「飲まない方が幸せ」という考えに変わった
- 禁酒した結果、いいことしかない
過去を思い出すと、もともとかなりお酒は弱い自分だった。135mlの小さいビール缶も残すくらいの人だった。気づいた時は500ml を3缶飲み、飲まないと一日が終われないという考え方になっていた。休日の昼から飲む時もあった。暇な時の時間潰しに飲む時もあった。
今思うと、「時間がない」原因がアルコールだったんだなと思う。
新しい自分を手に入れた感じがして、とても清々しい。
タバコやめた時、辞めるのはかなり辛かった。タバコは毒だと言い聞かせ、吸うのが恐怖になるくらいタバコについて調べまくったことを思い出した。この感覚に近い。この本は、アルコールは毒だということを教えてくれる。無理に辞めるのではなく、不要なものだと理解させてくれるので自然とやめられる。依存していることに気づかせてくれる。
自分にとって、かなりいい本だった。ありがとう。
AWS Certified Database - Specialty Practice 勉強しました記録
AWS Certified Database - Specialty Practice 受験しました。 勉強したことをメモしておきます。
ToDo
よくある質問、Blackbelt、AWSドキュメントを読む
- [x] DMS・SCT(blackbelt済、よくある質問済、AWSドキュメント未)
- [x] KMS(blackbelt未、よくある質問する未、AWSドキュメント未)
- [x] DynamoDB(blackbelt済、よくある質問済、AWSドキュメント未)
- [x] Neptune(blackbelt済、よくある質問済、AWSドキュメント未)
- [x] DocumentDB(blackbelt済、よくある質問済、AWSドキュメント未)
- [x] Elasticache(blackbelt済、よくある質問済、AWSドキュメント未)
- [x] Aurora/Global/Serverless(blackbelt済、よくある質問済、AWSドキュメント未)
- [x] パフォーマンスインサイト(blackbelt無、よくある質問済、AWSドキュメント未)
- [x] RDS(blackbelt済、よくある質問済、AWSドキュメント未)
- [x] AWS Backup
後で読む
AWS環境操作
RDS/Aurora
- [x] DBへの接続方法(認証方式、IAM認証、Lambda実行、SSL)
- [x] aurora IAM認証
- [x] aurora パラレルクエリー
- [x] aurora バックトラック
- [x] 暗号化スナップショットのリージョン間コピー
- [x] Aurora Multi Master/Global/Serverless/リードレプリカ論理/Parallel Query
- [x] DBエンジン間の移行、EC2からの移行、mysqlからauroraへの移行
- [x] バックアップリストア、rds、dynamo 、 elasticach
- [x] aurora グローバルデータベースの作成(別リージョンへの物理的なリードレプリカ)
- [x] Auroraクロスレプリケーションインスタンスに対するリードレプリカの追加
- [x] Auroraクロスレプリケーション(物理/論理)
- [x] aurora サーバーレス作成
- [x] 別リージョンへのリードレプリカ作成
- [x] 別リージョンへの移行、暗号化インスタンス
- [x] 拡張メトリクス有効化、cwlogs確認
インスタンス構築、バックアップ、冗長化、暗号化、DR
- [x] SCT
- [x] DMS
- [x] Elasticache
- [x] Neptune
- [x] DocumentDB
- [x] DynamoDB
DynamoDB
- [x] Dynamodb オンデマンド
- [x] ローカルセカンダリインデックスの作成とGetItem
- [x] グローバルテーブル
- [x] GSIの設定
- [x] LISの設定
ElastiCache
- [x] アプデ、アプグレ(エンジンはサービス更新、インフラは継続的な管理メンテナンスで必須)
- [x] ノードが置き換え対象となった場合に実行可能なアクション
- [x] 通信暗号化
- [x] データ暗号化
- [x] バックアップ・リストア
模擬試験
- [x] Udemy https://www.udemy.com/course/aws-certified-database-specialty-practice-exam-exampods/
- [x] 模擬試験
- [x] サンプル問題
Udemyの正解が間違っているケースがたくさんありました。自分を信じていきましょう。
試験の時間配分
- 180分
- 65問
- 2分/1問 + 見直し50分
- 悩んだ問題はフラッグ立てて、後から新しい目で見直す
勉強ノート
RDS
- DBプロキシ: プーリング機能の保持、フェイルオーバーの高速化
- リードレプリカ、ソースDB削除
- シャーディング: 1インスタンス以上のパフォーマンスを得たいばい
- 移行
- Oracle to RDS for Oracle
- Data dump > S3 > RDS ロード
- マテビュー:RDSからオンプレへDBリンク > マテビュー > 定期リフレッシュ > オンプレ書き込み停止 > マテビューを表へ変換 > アプリ向き先変更
- SQL Server
- バックアップ復元: .bak > S3 > RDS
- SQL Server Integration Service: SQL Serverの ETL ツールを利用
- レプリケーション: SQL Serverのレプリケーション機能を利用
- DMS:
- DMS
- Oracle to RDS for Oracle
- ポイントインタイムリカバリ。戻したい時間を指定して、インスタンスを新規作成
Aurora
- Auroraへの移行
- mysqldump
- RDS スナップショット
- Aurora リードレプリカ作成、昇格
- DMS
- S3インポート
- リージョンレベルのフェイルオーバーは手動
- フェイルオーバー動作
- 読み込み:一時中断、新プライマリへ割り当て。障害発生したノードが復旧後、リードエンドポイントは復旧ノードへ
- 書き込み:フェイルオーバーし、昇格した新プライマリノードへ
- レプリケーション
- MultiMaster: 複数のAZに渡って、書き込み性能をスケールアウトできる
- Aurora Serverless
- Database Cloning: コピーオンライト方式でクローン。完全なコピーではないので、データ容量への影響がほぼない、本番への影響もない。本番データを使った、検証、分析、DBの再構成などに利用
- Parallel Query
- バックトラック:戻したい時間を指定して復元、インスタンスが新規作成されず既存のデータベースのデータが戻る。テーブル単位での巻き戻しはできない。
- RDS MySQL/Aurora MySQLは、S3上のバックアップデータ(Percona XtraBackup )からリストアが可能
- AuroraではRAMを利用した、アカウント間でのインスタンスをクローン化(データ更新した分だけ料金が発生する)
- グローバルデータベース
- IAM認証
DynamoDB
- 1キャパシティ:リード4KB、ライト1KB
- 強い結果整合性の場合は、キャパシティを2倍使う
- パーティションキー設計をうまくやらないと、偏りが発生してパフォーマンスが出ないことがある
- キャパシティは過去300秒までリザーブする。このリザーブを使ってバーストすることができる
- LSI(Local Secondary Indes):キーは固定、ソートキーを追加できる
- GSI(Global Secondary Indes):キー自体を追加できる
- Point in Recoveryに対応している。復元したい時間を指定して、新しいテーブルを作成
- AWS Backupによるバックアップに対応している
- アダプティブキャパシティ:アクセス頻度の高いデータは別パーティションに自動で分離する
- DynamoDB オンデマンド:既存テーブルの移行可能、事前のキャパシティ設計不要でプロビジョニング。クエリごと単位での確認
mamcached
- コンフィグレーションエンドポイントにノードリスト。aouto discovery ライブラリで、アプリ側でノードの追加削除を自動検知
- マルチコア
redis
- クラスター無の場合は、RDS同様なフェイルオーバー方式
- バックアップ リストア
- シングルコア
- 監視: CPU、メモリ使用率、Eviction(キャッシュアウト数)、キャッシュヒット率、swap、レプリカラグ
- redisクラスター
- シャード単位で分散、最大15シャードまでスケール
- クラスタ専用のライブラリ、クライアント側でマッピンを保持
- シャードごとに最大5つのリードレプリカ
- プライマリノード障害時は、リードレプリカがプライマリへ昇格、フェイルオーバー
- ダウンタイム0で、シャードの増減が可能、オンラインリサイズ機能
- 暗号化: クライアント間通信、S3とディスク上のバックアップファイルを暗号化
DocumentDB
Neptune
- アーキテクチャはAurora
- データ移行は、S3またはDMS
- 対応言語
- インデックスは自動管理、ユーザーで変更できない
- OLTP、OLAP両方対応できる
- クロスリージョンレプリカは非対応
- 暗号化されてないデーベースの移行には、新規インスタンス作成後、データ移行が必要
- リーダーエンドポイントには負荷分散機能がない。アプリ側で分散するか、Route53を利用する
DMS
- フルロード
- DBソース:1万行8テーブルのSELECT > INSERT
- To Redshift:1万行8テーブルのSELECT > CVS to S3 > Redshift Copy
- S3ソース:
- フルロードの監視:CPU、Swap、メモリ、ストレージの空き、ネットワーク帯域
- CDC(変更データキャプチャ)
- フルロード + CDC
- フルロード中の更新をキャプチャ
- フルロード完了後、キューイングした1の更新を適用
- 完了後は、トランザクションとして更新を適用
- CDCの監視:
- CDCChangeDiskSource(ソースのコミット待機数)が多い場合は、ディスクサイズをあげる(キューイングが多く発生するため)
- CDCChangesDiskTarget(ターゲットのコミット待機数)はターゲットの処理能力が原因の可能性
- CDCLatencySource(ソースDB実行完了から、DMSがキャプチャするまでのラグ)
- CDCLatencyTarget(キャプチャからターゲットへ適用するまでのラグ)
- 暗号化されたデータの読み書きが可能
- SCT