収録問題 40問 ／ 10問ランダム出題
ランダムに出題・即時フィードバック・間違えた問題の復習機能付き
Databaseの災害復旧要件を決める際、最初に業務側と合意すべき組み合わせはどれですか？
答え： 許容Data損失を表すRPOと、許容停止時間を表すRTO
RPOとRTOを先に定義すると、Backup頻度、Log保管、Replication方式、復旧拠点、Costの選択根拠ができます。測定可能な業務要件として合意します。
Backup Jobが毎日Successになっている。復旧可能性を最も確実に確認する方法はどれですか？
答え： 隔離環境へ定期Restoreし、整合性・Application接続・所要時間を検証する
Backup成功は復元成功を保証しません。実際のRestore DrillでMedia、鍵、権限、手順、依存関係を含めて検証し、達成RTOと復元時点を記録します。
High Availability構成とBackupの関係について正しい説明はどれですか？
答え： HAは停止時間を抑え、Backupは削除・破損・過去時点への復旧を担う
ReplicationやClusterは可用性を高めますが、誤DELETE、Ransomware、論理破損が複製される場合があります。HAと独立したBackup/Restoreを組み合わせます。
Ransomwareや管理者誤操作にも備えるBackup保管設計として適切なのはどれですか？
答え： 別Failure Domainへ複数世代を保管し、Immutable化と削除権限分離を行う
Production Credential侵害がBackup削除へ直結しないよう、Account・Region・Media等を分離します。Retention LockやImmutable Storageと復元試験を組み合わせます。
異なるDB Engineへ一部Schemaを移行する際、一般に扱いやすいBackup形式はどれですか？
答え： DDLとDataを移植可能な形で出すLogical Export
Logical Exportは選択的移行や変換に向きます。ただし型、Collation、Sequence、権限、Procedureなどの差を変換・検証する必要があります。
稼働中Databaseの複数FileをStorage SnapshotでBackupする場合に重要なのはどれですか？
答え： DB Engineが保証する整合手順やApplication-consistent Snapshotを使う
Crash-consistent復旧が可能か、複数VolumeをAtomicに取得できるか、必要なLogが揃うかを製品仕様で確認します。単純File Copyは不整合を招きます。
14:37の誤DELETE直前へDatabaseを戻したい。PITRに必要な構成はどれですか？
答え： 復旧開始点となるBackupと、目標時点まで連続したTransaction Log
PITRはBase BackupへWAL、Binary Log、Transaction Log、Archived Redo等を順序どおり適用します。Log欠落があると、その先の時点へ進めません。
暗号化Backupを遠隔地へ保管する際のKey管理として適切なのはどれですか？
答え： BackupとKeyのFailure Domainを分け、権限・Rotation・旧Key保持・復旧手順を管理する
暗号化はKeyを失うと復旧不能になります。KMS等で権限を分離し、Retention期間中の旧Key利用と災害時のKey復旧をRestore Drillへ含めます。
非同期Replicationの健全性を横断監視する際、優先すべき指標はどれですか？
答え： 送信・受信・適用位置の差、時間Lag、Queue量、Replication Error
ReplicationはTransportとApplyのどこで遅れているかを分けて見ます。単一のSeconds Lagだけでなく、Position、Queue、Worker Error、増加傾向を監視します。
Standbyが接続中でLagも小さい。Failover可能と判断する前に追加確認すべきことはどれですか？
答え： Promotion、Client切替、DNS/Endpoint、書込確認、旧Primaryの隔離を定期演習する
同期状態だけではService復旧を保証しません。Role変更、接続先、Credential、Application再接続、Fencingまで含むFailover Drillで実測RTOを確認します。
非同期Replication構成でPrimary Siteが完全消失した。正しいRisk認識はどれですか？
答え： 未送信・未適用Transactionが失われる可能性があり、実Lagと業務判断が必要
非同期方式は通常Latencyを抑える代わりに、障害時のData損失Windowを持ちます。最後のDurable/Applied Positionを確認し、宣言したRPOとのずれを共有します。
Network分断時に旧Primaryと新Primaryの両方が書込を受けるSplit-brainを防ぐ中核Controlはどれですか？
答え： QuorumとFencingで一方の書込能力を確実に停止してからRoleを切り替える
Promotion前に旧PrimaryをStorage、Network、Process等からFenceし、単一Writerを保証します。曖昧な到達不能を停止済みとみなしてはいけません。
Failover後もApplication変更を最小化する接続設計はどれですか？
答え： Roleを追従するService EndpointやProxyを使い、短いTimeoutと再接続を実装する
Listener、Cluster Endpoint、Proxy、DNS等で接続先を抽象化し、Application側もConnection再生成とTransaction再試行を安全に扱います。DNS TTLだけに依存しません。
計画MaintenanceでPrimaryとStandbyを入れ替えるSwitchover前の手順として適切なのはどれですか？
答え： 同期状態、Capacity、Client Routing、Backup Job、Rollback条件を確認して変更Windowで切り替える
計画切替は事前に同期と依存Jobを確認し、変更中だけAlertをMaintenance扱いにします。切替後はWrite、Read、Job、Backup、監視を検証します。
利用者の大量DELETEが即座に通常Replicaへ反映されるRiskを緩和する選択肢はどれですか？
答え： 通常HAとは別にDelayed ReplicaまたはPITR可能なLog Archiveを維持する
Delayed Replicaは論理誤操作の検知猶予を作れますが、最新Failover先には向きません。PITR、Immutable Backup、権限制御と組み合わせます。
Read Replicaへ書込直後のQueryを振ると古い値が返る。適切な設計判断はどれですか？
答え： Read-after-write要件のある処理はPrimaryへ寄せるか、適用位置を確認してRoutingする
非同期ReplicaにはEventual Consistencyがあります。業務ごとにStaleness許容度を定義し、Session Stickiness、LSN/GTID等のPosition待機、Primary Readを選びます。
異なるDB製品を横断して性能問題を調べる最初の進め方はどれですか？
答え： Workload、Latency、Throughput、Wait、Top Query、変更点のBaselineを比較する
製品名より、何が待たされ、いつから、どのWorkloadで悪化したかを共通Signalで絞ります。その後に各EngineのWait EventやQuery Storeへ掘り下げます。
特定SQLが急に遅くなった。Execution Planを比較する際の適切な確認はどれですか？
答え： Estimateと実測Row数、Access Path、Join順序、Sort/Spill、Parameter、統計・Schema変更を確認する
Cardinality EstimateのずれやPlan変化の原因を、実測と変更履歴で確認します。Plan強制は緊急緩和になり得ますが、適用範囲と解除条件が必要です。
統計情報やIndex Maintenanceを複数DB製品で標準化する際の方針はどれですか？
答え： 製品の自動機能を把握し、変更量・統計鮮度・Fragmentation効果を測って対象を限定する
過剰MaintenanceはI/O、Log、Replication Lag、Lockを増やします。Engineの自動統計・Vacuum・Online機能を理解し、効果と副作用を測って実施します。
Blocking Sessionが増えてApplication Timeoutが発生した。最初の対応として適切なのはどれですか？
答え： Blocking Chain、Transaction開始時刻、SQL、Owner、影響を特定し、最小範囲で解除する
Root Blockerと業務処理を特定して、Cancel、Rollback、Traffic制御を判断します。Evidenceを残し、長時間TransactionやAccess順序を恒久対策します。
Application Instance増加でDB Connection上限に達した。適切な対策はどれですか？
答え： 全体Connection Budgetを定め、Pool上限・Idle Timeout・Queue・Backpressureを調整する
PoolはInstance数との積で考えます。DBのWorker、Memory、Workloadを基にBudget化し、急増時はQueueとAdmission ControlでDatabaseを保護します。
長時間TransactionがMVCC CleanupやLog再利用を妨げている。適切な恒久対策はどれですか？
答え： Transaction Scopeを短くし、Idle-in-transaction TimeoutとBatch分割を設計する
長時間TransactionはOld Version、Undo、WAL/Log、Lockを保持します。Application境界を見直し、Ownerが分かる監視と安全なTimeoutを設けます。
DB Latencyが上昇したがCPUは低い。次に優先して確認すべきものはどれですか？
答え： Storage IOPS・Latency・Queue、fsync/Log Flush、Network、Lock Waitを確認する
DatabaseはI/O、Log Flush、Network、Lockを待つ間CPUを消費しない場合があります。Host、Storage、Engine Waitを同じTime Windowで相関します。
Data File以外の領域が急増してDisk Fullが迫っている。横断的な調査として適切なのはどれですか？
答え： Transaction Log、Archive、Temp、Undo、Replication Slot/Queue、Diagnostic Logの増加源を分解する
容量増加はBackup失敗、Replica停止、長時間Transaction、Large Sort、Log Rotation不備などのSignalです。緊急容量確保と原因除去を並行します。
Application用DB Accountの権限設計として適切なのはどれですか？
答え： 業務Roleごとに必要なObject・OperationだけをGrantし、Schema変更や管理権限を分離する
Runtime、Migration、Monitoring、Backup等のRoleを分離し、Secret Manager、短期Credential、Rotationを使います。権限変更はCode ReviewとAudit対象にします。
緊急障害時だけ強いDB権限を使うBreak-glass運用として適切なのはどれですか？
答え： 承認付きの短時間Accessを発行し、操作を記録して事後Reviewと失効を行う
Break-glassは通常経路が使えない時の例外です。本人性、理由、承認、期限、Session記録、通知を備え、利用後にCredentialと権限を確実に戻します。
Database Audit Logを設計する際の適切な方針はどれですか？
答え： Riskの高い認証・権限・DDL・機密Data操作を定義し、改ざん耐性、Redaction、Retentionを設ける
監査目的と脅威ModelからEventを選び、機密値を最小化します。中央転送、時刻同期、Access制限、改ざん検知、検索可能な共通Fieldを整備します。
Database接続のTLS Certificateを無停止でRotationする準備はどれですか？
答え： 新旧TrustのOverlap、Client更新、段階Rotation、接続試験、旧Trust削除期限を計画する
Serverと多数Clientを同時変更できないため、期限付きOverlapを使います。Hostname検証とEncryptionを維持したままCanaryで接続し、旧Key/CAを撤去します。
大規模TableへNOT NULL列を無停止に近い形で追加したい。一般的に安全なMigration Patternはどれですか？
答え： Nullable追加、Application両対応、段階Backfill、検証後Constraintを有効化するExpand-Contract
SchemaとApplicationの互換期間を作り、BackfillをThrottleします。製品ごとのOnline DDL、Lock、Log量、Replication Lagを事前検証します。
数TBのTableへIndexを追加する際、適切なChange計画はどれですか？
答え： Online/Concurrent機能、追加領域、Log量、Replica Lag、Cancel/Resume可否を検証して段階実施する
Online DDLでもCPU、I/O、Log、短時間Lock等の影響があります。Production相当Dataで測定し、Traffic制御、停止条件、完了後Plan確認を用意します。
PostgreSQLから別EngineへMigrationする際、事前に重点確認すべき互換性はどれですか？
答え： Data Type、NULL/Default、Collation、Timezone、Identity/Sequence、SQL・Procedure・Isolation差
Syntaxが変換できてもSemanticsが同じとは限りません。空文字とNULL、Timestamp、Decimal、文字Sort、Boolean、Generated Key、Transaction挙動をTest Case化します。
大容量Databaseを短い停止時間で異種Engineへ切り替える一般的な方式はどれですか？
答え： 初期Bulk Load後にCDCで差分同期し、Lag収束・書込停止・最終検証後に切り替える
Bulk LoadとChange Data Captureを分けると停止時間を最終差分へ限定できます。DDL変更、順序、重複、Delete、再実行、CDC保持期間も管理します。
Migration前後のData一致を検証する方法として適切なのはどれですか？
答え： Tableごとの件数、Key範囲、Checksum/Aggregate、Sample、業務Invariantを複数段階で比較する
単一指標では欠落、重複、変換誤りを隠します。重要Tableと業務Ruleを優先し、Snapshot時点を揃え、負荷を制御して差分を再現可能に記録します。
Database MigrationのRollback条件として事前定義すべきものはどれですか？
答え： Error率、Latency、Data差分、CDC Lag、業務失敗の閾値と、戻せる最終時点
Go/No-GoとRollbackを数値・Owner・Deadlineで定義します。Targetへの新規Write開始後は逆同期が必要になるため、Point of No Returnを明示します。
Database Major Version Upgrade前の適切な準備はどれですか？
答え： 本番相当CopyでCompatibility、Upgrade時間、Plan変化、Rollback、Backup RestoreをRehearsalする
Major UpgradeはSQL、Driver、Extension、Authentication、Optimizer、Parameter Defaultを変える場合があります。Deprecated機能をInventory化し、Canaryと性能Regression Testを行います。
多数のDatabase InstanceでConfiguration Driftを抑える方法はどれですか？
答え： 共通Policyと製品別TemplateをVersion管理し、承認・自動適用・Drift検知を行う
共通IntentをEncryption、Logging、Backup、Timeout等で定義し、製品別実装へMappingします。例外はOwner、理由、期限を持たせます。
Database Fleetの運用Riskを把握するInventoryとして優先すべき情報はどれですか？
答え： Owner、業務重要度、Engine/Version、Support期限、Data分類、RPO/RTO、Backup/HA状態、依存先
OwnershipとLifecycleが不明なDBはPatch、Backup、廃止判断から漏れます。CMDB/InventoryをDiscoveryと照合し、EOLや未保護Instanceを優先是正します。
PostgreSQL、MySQL、SQL Server、Oracleを一つの監視基盤で扱う設計はどれですか？
答え： Availability、Latency、Traffic、Error、Saturation、Replication、Backupを共通Model化し、製品Adapterで詳細を補う
共通Service HealthでFleetを比較し、異常時はWait Event、Buffer、Log、Replication Worker等の製品詳細へDrill-downします。SLOとBaselineに応じて閾値を調整します。
Database Incidentで再起動が有力な暫定策になった。実行前の適切な行動はどれですか？
答え： 安全な範囲でSession、Wait、Log、Plan、Resource Snapshotを保全し、影響・復旧条件を共有する
再起動はEvidenceとCache内状態を消す場合があります。復旧を遅らせない範囲で取得項目をRunbook化し、再起動後も症状、Data整合性、再発を確認します。
Database横断運用Runbookの品質を継続的に高める方法はどれですか？
答え： 定期演習と実Incidentで手順・権限・時間を計測し、PostmortemからOwner付き改善を反映する
Runbookは実行可能なProductとして扱います。前提、停止条件、Escalation、Vendor差、検証、Rollbackを含め、定期的に別担当者でも完遂できるか試します。