データサイエンスとデータベース

OracleからSQLServerおよびSQLServerからOracleへの移行ガイド-Pt。 3

最初そして二番目このシリーズの一部では、トランザクションの実装におけるOracleDatabaseとMicrosoftSQL Serverの違い、結果として生じる変換の落とし穴、および一般的に使用される構文要素について説明しました。

この最後の記事では、オラクル一貫性と、この概念に基づいてアーキテクチャをに変換する方法を読んでください。 Microsoft SQL Server バージョン。また、シノニムの使用（およびそれらを使用しない方法）と、データベース環境の管理における変更管理プロセスの役割についても説明します。

SQLServerでのOracle読み取りの一貫性とそれに相当するもの

Oracle読み取りの一貫性は、単一のSQLステートメントによって返されるすべてのデータが同じ特異点からのものであることを保証します。

これは、SELECTを発行した場合を意味します12：01：02.345のステートメントで、結果セットを返す前に5分間実行すると、12：01：02.345の時点でデータベースにコミットされているすべてのデータ（およびデータのみ）がリターンセットになります。返品セットには、データベースがステートメントを処理するのにかかった5分間に新しいデータが追加されたり、更新が行われたりすることはなく、削除は表示されません。

Oracleアーキテクチャは、データへのすべての変更を内部的にタイムスタンプし、永続データファイルと元に戻すセグメント（または「ロールバックセグメント」）の2つのソースから結果セットを構築することにより、読み取りの一貫性を実現します。バージョン10gまで知られていました）。

それをサポートするために、元に戻す情報保存する必要があります。上書きすると、悪名高いORA-01555: snapshot too oldになりますエラー。

元に戻すセグメント管理はさておき、ORA-01555: snapshot too oldをナビゲートする方法エラー-Oracleの実際の実装における読み取りの一貫性の影響を見てみましょう。また、SQL Serverでどのようにミラーリングする必要がありますか。これは、他のRDBMS実装の場合と同様に、PostgreSQLの可能性のある修飾された例外を除いて、サポートしていません。

重要なのは、Oracleの読み取りと書き込みが相互にブロックしないことです。また、実行時間の長いクエリリターンセットに最新のデータが含まれていない可能性があることも意味します。

ノンブロッキングの読み取りと書き込みは、オラクルが持つ利点であり、トランザクションスコープに影響します。

ただし、読み取りの一貫性は、データの最新の状態がないことも意味します。一部のシナリオ（特定の時間のレポートの作成など）が完全に優れている場合、他のシナリオで重大な問題が発生する可能性があります。

最新のデータ（「ダーティ」またはコミットされていないデータ）がないことが重要になる可能性があります。典型的なシナリオは、ホテルの部屋の予約システムです。

次の使用例を検討してください。部屋の予約注文を同時に受け付けている2人のカスタマーサービスエージェントがいます。部屋がオーバーブッキングにならないようにするにはどうすればよいですか？

SQL Serverでは、明示的なトランザクションを開始してSELECTを開始できます。利用可能な部屋のリスト（テーブルまたはビューの場合があります）からのレコード。このトランザクションが（COMMITまたはROLLBACKによって）閉じられない限り、選択したのと同じ部屋の記録を誰も取得できません。これにより、二重予約が防止されますが、他のすべてのエージェントは、予約要求が1つずつ順番に完了するのを互いに待機します。

Oracleでは、SELECT ... FOR UPDATEを発行することで同じ結果を得ることができます。検索条件に一致するレコードに対するステートメント。

注：部屋へのアクセスを盲目的にロックするのではなく、「検討中」の部屋をマークする一時的なフラグを設定するなど、より良い解決策が存在します。しかし、これらはアーキテクチャ上のソリューションであり、言語オプションではありません。

ccorpまたはscorp

結論：Oracleの読み取りの一貫性は「すべて良い」または「すべて悪い」ではありませんが、十分に理解する必要があり、クロスプラットフォームのコード移行に不可欠なプラットフォームの重要なプロパティです。

OracleおよびMicrosoftSQL Serverのパブリック（およびプライベート）シノニム

「公の同義語は悪です。」それは正確には私の個人的な発見ではありません、しかし、私の日、週、年が公の同義語によって救われるまで、私はそれを福音として受け入れていました。

多くのデータベース環境（私が使用する機会があったすべてのOracle環境と言えますが、私が設計したものはありません）では、CREATE PUBLIC SYNONYMを使用します。 すべてのオブジェクトに対して 「私たちはいつもそうしてきた」ので、日常的でした。

これらの環境では、パブリックシノニムには、所有者を指定せずにオブジェクトへの参照を許可するという1つの機能しかありませんでした。そしてこれは1つですよく考えられていない理由パブリックシノニムを作成します。

ただし、オラクルのパブリックシノニムは非常に有用であり、正しく実装および管理されている場合、理由があれば、チームの生産性にメリットがあり、すべての欠点を大幅に上回ります。はい、「チームの生産性」と言いました。しかし、どのように？このためには、Oracleで名前解決がどのように機能するかを理解する必要があります。

Oracleパーサーが名前（予約されていないキーワード）を検出すると、次の順序で既存のデータベースオブジェクトとの照合を試みます。

入力としてmy_objectで始まるフローチャート。発行セッションの現在のスキーマにmy_objectという名前のオブジェクトがありますか？もしそうなら、私たちは

注：発生するエラーはORA-00942: table or view does not existになりますDMLステートメントの場合、またはPLS-00201: identifier 'my_object' must be declaredストアドプロシージャまたは関数呼び出し用。

この名前解決の順序では、開発者が独自のスキーマで作業している場合、パブリックシノニムと同じ名前のローカルオブジェクトが隠すこの公の同義語。（注：Oracle 18cは「ログインのみ」のスキーマ型を実装しており、この説明は適用されません。）

スケーリングチームのパブリックシノニム：Oracle Change Control

ここで、同じデータベースで作業している100人の開発者からなる架空のチームを見てみましょう（これは私が経験したことです）。さらに、全員が個人のワークステーションでローカルに作業し、データベース以外のビルドを個別に実行し、すべて同じデータベース開発環境にリンクされていると仮定します。データベース以外のコード（C＃、Java、C ++、Pythonなど）にマージされるコードの解決は、変更管理のチェックイン時に行われ、次のコードビルドで有効になります。ただし、データベーステーブル、コード、およびデータは、進行中の開発中に何度も変更する必要があります。各開発者はこれを独立して行い、すぐに有効になります。

このため、すべてのデータベースオブジェクトは共通のアプリケーションスキーマで作成されます。これは インクルード アプリケーションが参照するスキーマ。各開発者：

個人のユーザーアカウント/スキーマでデータベースに接続します
常に空の個人スキーマで始まります
上記のように、名前解決を通じてのみパブリックシノニムへの共通スキーマを参照します

開発者が作成する必要がある場合 どれか データベースへの変更（テーブルの作成または変更、プロシージャコードの変更、またはテストシナリオをサポートするためのデータセットの変更）は、個人スキーマにオブジェクトのコピーを作成します。 DESCRIBEを使用してDDLコードを取得することでこれを行いますコマンドを実行し、ローカルで実行します。

この時点から、この開発者のコードには、オブジェクトとデータのローカルバージョンが表示されます。これらは、他の人には表示されません（影響もありません）。開発が完了すると、変更されたデータベースコードがソース管理にチェックインされ、競合が解決されます。次に、最終的なコード（および必要に応じてデータ）が共通スキーマに実装されます。

この後、開発チーム全体が同じデータベースを再び見ることができます。コードを配信したばかりの開発者は、自分の個人スキーマからすべてのオブジェクトを削除し、新しい割り当ての準備ができています。

複数の開発者が独立して並行して作業できるようにするこの機能は、パブリックシノニムの主な利点であり、誇張することはできません。ただし、実際には、「常に実行しているという理由だけで」、チームがOracleの実装でパブリックシノニムを作成しているのを引き続き見ています。対照的に、SQL Serverを使用しているチームでは、一般的な慣習として確立されたパブリックシノニムの作成は見当たりません。この機能は存在しますが、あまり使用されません。

SQL Serverでは、ユーザーの現在のデフォルトスキーマはユーザー構成で定義されており、「ユーザーの変更」権限がある場合はいつでも変更できます。 Oracleについて上で説明したのとまったく同じ方法論を実装できます。ただし、この方法を使用しない場合は、パブリックシノニムをコピーしないでください。

Microsoft SQL Serverは、デフォルトでは（Oracleのように）新しいユーザーアカウントを独自のスキーマに関連付けないため、関連付けは標準の「ユーザーの作成」スクリプトの一部である必要があります。

以下は、専用のユーザースキーマを作成し、それをユーザーに割り当てるスクリプトの例です。

まず、DevelopmentDatabaseという名前のデータベースにオンボーディングする必要がある新しいユーザーのスキーマを作成します（各スキーマは独自のバッチで作成する必要があります）：

use DevelopmentDatabase; GO CREATE SCHEMA Dev1; GO CREATE SCHEMA Dev2; GO

次に、割り当てられたデフォルトスキーマを使用して最初のユーザーを作成します。

CREATE LOGIN DevLogin123 WITH PASSWORD = 'first_pass123'; CREATE USER Dev1 FOR LOGIN DevLogin123 WITH DEFAULT_SCHEMA = Dev1; GO

この時点で、ユーザーのデフォルトスキーマDev1 Dev1になります。

Ruby on Railseコマースチュートリアル

次に、デフォルトスキーマのない他のユーザーを作成します。

CREATE LOGIN DevLogin321 WITH PASSWORD = 'second_pass321'; CREATE USER Dev2 FOR LOGIN DevLogin321; GO

ユーザーのデフォルトスキーマDev2 dboです。

ここでユーザーを変更しますDev2デフォルトのスキーマをDev2に変更するには：

ALTER USER Dev2 WITH DEFAULT_SCHEMA = Dev2; GO

これで、ユーザーのデフォルトスキーマDev2 Dev2です。

このスクリプトは、Microsoft SQLServerデータベースでユーザーのデフォルトスキーマを割り当てて変更する2つの方法を示しています。 SQL Serverは複数のユーザー認証方法（最も一般的なのはWindows認証）をサポートしており、ユーザーのオンボーディングはDBAではなくシステム管理者が処理できるため、ALTER USERデフォルトスキーマを割り当て/変更する方法がより使いやすくなります。

注：スキーマの名前をユーザーの名前と同じにしました。 SQL Serverではこの方法である必要はありませんが、（1）Oracleでの実行方法と一致し、（2）ユーザー管理を簡素化する（正しく実行することに対するDBA側の最大の反対意見に対処する）ため、私の好みです。そもそも）-ユーザーの名前がわかっていて、ユーザーのデフォルトのスキーマが自動的にわかります。

結論：パブリックシノニムは、安定した十分に保護されたマルチユーザー開発環境を構築するための重要なツールです。残念ながら、業界での私の観察では、これは間違った理由で使用されることが多く、チームがその利点を実現せずに、混乱やその他の公的な同義語の欠点に苦しんでいます。パブリックシノニムから真のメリットを引き出すためにこのプラクティスを変更すると、チームの開発ワークフローに真のメリットをもたらすことができます。

データベースアクセス管理および変更管理プロセス

大規模なチームによる並列開発のサポートについて説明したばかりですが、1つの別個の、よく誤解されているトピックである変更管理プロセスに取り組む価値があります。

変更管理は、多くの場合、チームリーダーとDBAによって制御される官僚的形式主義の形式になり、「昨日」ではなく「今」ではなくすべてを提供したい反抗的な開発者に軽蔑されます。

DBAとして、私は常に「my」データベースへの途中で保護バリアを配置します。そして、これには非常に正当な理由があります。データベースは共有リソースです。
つぶやき

ソース管理のコンテキストでは、変更管理は、チームが新しいが壊れたコードから古いが機能しているコードに戻すことができるため、一般的に受け入れられています。しかし、データベースのコンテキストでは、変更管理はDBAによって課せられた一連の不合理な障壁と制限のように見える可能性があります。それは開発を不必要に遅らせる純粋な狂気です！

この開発者の怒りを脇に置いておきましょう。私はDBAであり、自分自身に石を投げることはありません。 DBAとして、私は常に「自分の」データベースに入る途中で保護バリアを設定します。そして、これには非常に正当な理由があります。データベースは共有リソースです。

すべての開発チーム（およびその各開発者）には、非常に具体的に定義された目的と非常に具体的な成果物があります。 DBAのデスクに毎日ある唯一の目的は、共有リソースとしてのデータベースの安定性です。 DBAは、すべてのチームにわたるすべての開発作業を監視し、すべての開発者がアクセスするデータベースを制御するという、組織内での独自の役割を担っています。すべてのプロジェクトとすべてのプロセスが互いに干渉することなく実行され、それぞれが機能するために必要なリソースを備えていることを保証するのはDBAです。

問題は、開発チームとDBAチームの両方がそれぞれの象牙の塔に閉じ込められている場合です。

開発者は、データベースが正常に実行されている限り、データベースが何であるかを知らず、アクセスできず、何が起こっても気にしません。（これは成果物ではなく、パフォーマンス評価にも影響しません。）

scorpとccorpの違い

DBAチームはデータベースを胸の近くに保ち、チームの目的はデータベースの安定性であるため、データベースについて「何も知らない」開発者からデータベースを保護します。また、安定性を確保するための最善の方法は、破壊的な変更を防ぐことです。多くの場合、データベースを可能な限り変更から保護する姿勢になります。

これらデータベースに対する相反する態度私が見てきたように、開発チームとDBAチームの間に敵意を引き起こし、実行不可能な環境をもたらす可能性があります。しかし、DBAと開発チームは、共通の目的を達成するために協力する必要があります。それは、ビジネスソリューションを提供することであり、それが最初にそれらをまとめたものです。

開発者とDBAの分裂の両側にいたので、DBAが開発チームの共通のタスクと目的をよりよく理解すれば、問題は簡単に解決できることを私は知っています。彼らの側では、開発者はデータベースを抽象的な概念としてではなく共有リソースとして見る必要があります。そこでは、DBAが教育者の役割を担う必要があります。

開発者以外のDBAが犯す最も一般的なエラーは、データディクショナリとコード最適化ツールへの開発者のアクセスを制限することです。 OracleへのアクセスDBA_カタログビュー、動的V$ビュー、およびSYS実際、これらが重要な開発ツールである場合、テーブルは多くのDBAにとって「DBA特権」のように見えます。

同じことがSQLServerにも当てはまりますが、1つの問題があります。一部のシステムビューへのアクセスを直接許可することはできませんが、それはSYSADMINの一部にすぎません。データベースの役割。この役割は、DBAチームの外部に付与しないでください。これは、SYSADMINで実行されるビューとストアドプロシージャを作成することで解決できます（プロジェクトがOracleからSQL Serverに移行する場合は解決する必要があります）。特権がありますが、DBA以外のユーザーがアクセスできます。これは 開発DBA 新しいSQLServer開発環境として実行するジョブが構成されます。

データ保護は、DBAの主な責任の1つです。それにもかかわらず、開発チームがフィルタリングされていない本番データに完全にアクセスして、データ関連のチケットのトラブルシューティングを可能にすることは非常に一般的です。これらは、データ構造（彼らによって、または彼らのために最初に作成された構造）へのアクセスが制限されている同じ開発者です。

開発チームとDBAチームの間に適切な作業関係が確立されると、優れた変更管理プロセスの作成が直感的になります。データベース側の変更管理の詳細と課題は、データベースの剛性と流動性であると同時に、構造は剛性であり、データは流動的です。

構造変更（つまり、データ定義言語、またはDDL）の変更管理は十分に確立されていますが、データ変更は変更管理の方法をほとんどまたはまったく持っていません。正当化は簡単です-データは常に変化します。

しかし、これをさらに詳しく見ると、どのシステムでも、すべてのデータがアプリケーションデータとユーザーデータの2つのカテゴリのいずれかに分類されることがわかります。

アプリケーションデータ は、アプリケーションの動作を定義するデータディクショナリであり、アプリケーションコードと同様にそのプロセスにとって重要です。このデータへの変更は、他のアプリケーションの変更と同様に、厳密な変更管理プロセスの下で行う必要があります。アプリケーションデータ変更の変更管理プロセスに透明性を持たせるには、アプリケーションデータとユーザーデータを明示的に分離する必要があります。

Oracleでは、アプリケーションとユーザーのデータをそれぞれ独自のスキーマに配置することで実行する必要があります。 Microsoft SQL Serverでは、それぞれを個別のスキーマに配置するか、はるかに優れた方法で個別のデータベースに配置することで実行する必要があります。これらの選択は、移行計画の一部である必要があります。Oracleには2レベルの名前解決（スキーマ/所有者–オブジェクト名）があり、SQL Serverには3レベルの名前解決（データベース–スキーマ/所有者–オブジェクト名）があります。

OracleとSQLServerの世界の間でよくある混乱の原因は、おそらく驚くべきことに、用語です。 データベース そして サーバ ：

SQLServerの用語	Oracle用語	定義
サーバ	データベース（と互換的に使用されますサーバサーバーハードウェア、OS、またはネットワーク要素を特に参照しない限り、一般的な用語で。物理/仮想サーバー上に1つ以上のデータベースが存在する可能性があります）	ネットワークポートを介して他のインスタンスと「通信」できる実行中のインスタンス
データベース（サーバーの一部であり、複数のスキーマ/所有者が含まれています）	スキーマ/所有者	最上位のグループ化

この用語の取り違えは、クロスプラットフォームの移行プロジェクトで明確に理解する必要があります。用語の誤解により、構成の決定が不正確になり、遡及的に対処することが困難になる可能性があるためです。

アプリケーションとユーザーデータを正しく分離することで、DBAチームは2番目に重要な懸念事項であるユーザーデータのセキュリティに対処できます。ユーザーデータは個別に存在するため、実装は非常に簡単です。割れ目手順必要に応じてユーザーデータにアクセスします。

結論：変更管理プロセスは、どのプロジェクトでも重要です。ソフトウェアエンジニアリングでは、データが「流動的すぎる」と見なされるため、データベース側の変更管理が無視されることがよくあります。しかし、適切に設計された変更管理プロセスが適切なデータベース環境アーキテクチャの基礎となるのは、データが「流動的」かつ「永続的」であるためです。

ギリシャの債務危機の理由

コード移行ツールの使用について

標準のファーストパーティツール、 Oracle Migration Workbench そして SQL Server Migration Assistant 、コードの移行に役立ちます。しかし、考慮に入れる必要があるのは 80/20の法則：コードが80％正しく移行される場合、残りの20％を解決すると、移行作業の80％がかかります。

移行ツールを使用する際の最大のリスクは、はるかに「銀の弾丸」の認識です。「それでうまくいくので、ちょっとした片付けと片付けをするだけでいいのです」と考えたくなるかもしれません。変換チームとその技術的リーダーシップからのそのような態度のために失敗したプロジェクトを観察しました。

一方、Notepad ++の一括置換機能をメインの編集ツールとして使用して、中規模のMicrosoft SQL Server 2008システム（約200オブジェクト）の基本的な変換を完了するには、4営業日かかりました。

これまでに取り上げた重要な移行要素はどれも、移行ツールでは解決できません。

もちろん、移行支援ツールを使用してください。ただし、これらは編集支援のみを提供することを忘れないでください。結果の出力テキストは、レビュー、変更、および場合によっては書き直して、本番環境に適したコードにする必要があります。

人工知能ツールの開発は、将来これらの移行ツールの欠陥に対処する可能性がありますが、それまでにデータベース間の違いが曖昧になり、移行プロセス自体が不要になると予想されます。したがって、これらのタイプのプロジェクトが必要である限り、昔ながらの人間の知性を使用して、古い方法でそれを行う必要があります。

結論：移行支援ツールの使用は役に立ちますが、それは「特効薬」ではなく、変換プロジェクトでは、上記の点を詳細に確認する必要があります。

Oracle / SQL Serverの移行：常に詳細を確認する

OracleとMicrosoftSQL Serverは、エンタープライズ環境で最も普及している2つのRDBMSプラットフォームです。どちらもANSISQL標準に基本的に準拠しており、コードの小さなセグメントは、ほとんど変更することなく、またはそのままで移動できます。

この類似性により、2つのプラットフォーム間での移行は単純で単純なタスクであり、同じアプリケーションを1つのRDBMSバックエンドから別のバックエンドに簡単に採用できるという欺瞞的な印象が生まれます。

実際には、このようなプラットフォームの移行は簡単なことではなく、各プラットフォームの内部動作の細かい要素、そして何よりも、データ管理の最も重要な要素であるトランザクションのサポートを実装する方法を考慮する必要があります。

私の専門知識の中核である2つのRDBMSプラットフォームについて説明しましたが、同じ警告（「似ているからといって、同じように機能するわけではありません」）は、他のSQL準拠のデータベース管理システム間でコードを移動する場合にも適用する必要があります。そして、すべての場合において、最初の注意点は、トランザクション管理の実装がソースプラットフォームとターゲットプラットフォームの間でどのように異なるかということです。