タグ付けされた質問 「sql-server」

Microsoft SQL Serverのすべてのバージョン(MySQL以外)。sql-server-2016のようなバージョン固有のタグも追加してください。これは、質問に関連することが多いためです。

4
SQL Server評価版でSSISを開発することは可能ですか
をSQL Standard Server実装するためのの購入を検討していETL via SSISます。私たちにとっては非常に費用がかかるため、無料バージョンでSSISパッケージの開発をテストしたいと思います。エクスプレスバージョンにはSSISが統合されていないため、SQL Server 2014 の評価180 Expiresバージョンで試してみたいが、何も見つからない - Is it possible - Are there limitations. 誰か私をここで助けてもらえますか?
11 sql-server  ssis 

3
突然インデックスやクエリを変更する必要がある理由に答える方法
私は3年の経験を持つジュニアDBAです。私たちの仕事は、クエリを微調整するか、特定のコードを書き換えるか、インデックスが必要であることを開発者にアドバイスすることです。 開発チームが頻繁に尋ねる1つの簡単な質問は、「昨日は問題なく動作しましたが、何が突然変化しましたか?」です。インフラストラクチャの側面を確認するよう求められます。問題に対する最初の反応は、常に検証される最初のことであるインフラストラクチャに最大の責任を負わせることです。 開発チームからの「何が変わったのか」という質問にどのように答えればよいでしょうか?皆さんは今まで同じ状況に直面しましたか?もしそうなら、あなたの経験を共有してください。

1
HADR_SYNC_COMMITの奇妙なケースが待機する
私たちはHADR_SYNC_COMMIT、私たちの環境での待機の興味深いパターンに気づいています。3つのレプリカがあります。1つのプライマリ、1つの同期セカンダリ、および1つの非同期セカンダリがデータセンターにあり、さらに3つのASYNCレプリカを別のデータセンター(約2400マイル離れた場所)に追加しました。 それ以来、HADR_SYNC_COMMIT待機の大幅な増加に気づき始めました。アクティブなセッションを見るCOMMIT TRANSACTIONと、SYNCレプリカで待機しているクエリがたくさんあります スクリーンショットから、HADR_SYNC_COMMIT6月29日に待機が急増していることがはっきりとわかります。最終的に、7月1日の正午に、リモートデータセンターの3つの非同期レプリカのうち「2つ」をドロップしました。これにより、待ち時間も大幅に減少しました。 これまでに確認したこと–リモートレプリカのログ送信キュー、やり直しキュー、最終強化時間、最終コミット時間。営業時間中に小さなトランザクションのバーストが連続しているため、送信キューは特定のタイムスタンプ(60KBから1MBの間)でかなり小さくなっています。リモートレプリカはほぼ同期しています。レプリカ上の個々のlsnの最終コミット時刻と最終硬化時刻の差はほとんどありません。 ネットワークパイプは10Gであり、送信バッファーサイズを256 MBから2 GBに変更しました。これは、ネットワークがパケットをドロップして再送信しているという前提の下で行われました。どちらの方法でもあまり役に立たないようです。 では、ASYNCレプリカはHADR_SYNC_COMMIT待機とどう関係しているのでしょうか。SYNCレプリカはこの待機タイプに単独で依存するべきではありません。ここで何が欠けていますか?


2
SARGカーディナリティの推定、なぜフルスキャンではないのですか?
フルスキャンがないのはなぜですか(SQL 2008 R2および2012)。 テストデータ: DROP TABLE dbo.TestTable GO CREATE TABLE dbo.TestTable ( TestTableID INT IDENTITY PRIMARY KEY, VeryRandomText VarChar(50), VeryRandomText2 VarChar(50) ) Go Set NoCount ON Declare @i int Set @i = 0 While @i < 10000 Begin Insert Into dbo.TestTable(VeryRandomText, VeryRandomText2) Values(Cast(Rand()*10000000 as VarChar(50)), Cast(Rand()*10000000 as VarChar(50))); Set @i …

2
概念的なERDマルチテーブル多対多、またはおそらく再帰?
概念図を作成しています[そうです、属性とキーが含まれていることは知っていますが、これは、学習中に行っていることを統合するためだけのものです]-したがって、関係と図表の方法ではなく表;) 私の心のハードルは次のとおりです。 私は、プロファイル、場所、および組織の関係をモデル化する最良の方法を確認しようとしています。 まず、ルール: 1つ以上のプロファイルは、1つ以上の組織のメンバー/友達になることができます。およびその逆。 1つまたは複数のプロフィールを他のプロフィールのメンバー/友達にすることができます。 1つ以上の組織が他の組織のメンバー/フレンドになることができます。 FriendとMemberは異なります。Friendsは読み取り専用のようなものであり、[レベルに応じて]メンバーは変更するためのフルアクセス権を持っています。 さらに複雑なことに、ロケーションには独自の「さらに」洗練されたルールのセットがあります。たとえば、組織は2つのロケーションを所有しますが、ロケーションルールによっては、その組織のメンバー[ プロファイル ]が1つのロケーションでフルアクセスできますが、その他。[申し訳ありませんが、表示サイズを上げるには、別のウィンドウで画像を開く必要があります。] ご覧のように、プロファイルと組織の概念はほとんど同じです。これは、モデル化されていない友達とメンバーの概念です。[...オーナー/レコード内の管理者/メンバー/友達など]。したがって、なぜ私は次の概念を考えているのですか? 上の画像のOption.2を参照してください。これは、現在の組織とOrganization_Locationsテーブルとそれらの関係を削除し、プロファイルとのやや再帰的な関係としてOption.2組織テーブルに置き換えます。 問題の核心は、私が多態性をプログラム的に気にしすぎて、単純さと柔軟性を損ない、プロセスで完全に混乱しているのかどうかだと思います;) 事前にあなたの考えをありがとう、大いに感謝-M :)。 改訂された図: MDCCLの質問への回答: はい、プロフィールは1人の人物で構成され、同じ意味を持っています-あなたの理論的根拠が向かっているところに-私はあなたが正しいと信じています:組織と人物はプロフィールのサブタイプである可能性があります。したがって、プロファイルは1人または1つの組織で構成されます。 プロファイルごとに1つのメールアドレス。 はい。上記のように、組織には少なくともメールアドレスが必要です。 正しい、1つの固定アドレス。 それは可能性ですが、まれです-私が学んでいることから-したがって、将来の寿命などのためにそのようなモデルを作成する必要があります。したがって、確認のために、ロケーションは複数の人が所有することができます。 場所は間違いなく他のほとんどの間の不可欠なエンティティです。おそらく私はここで簡潔に何ができるかを明確にし、次にこの質問への有益な追加にうまくいけば私の他の答えを最初に読んでみましょう[ そして最後に#6への私の答えを見てください ];)Re:役割の所有者 An **Organization** can be an Owner of zero or more **Locations**. A Person can be an owner of zero of more Locations[したがって、以前に推測したとおり。簡単に言えば、プロファイルは0個以上のロケーションの所有者になることができます。 はい、ロケーションの所有者であるプロファイルは、すべてのロール権限[スーパーユーザー]を想定しています。プロファイルで管理者は、特定の細部修正できる場所が、主に他のすべてを介して供給された詳細/データ編集/助けプロファイルを/ S …

1
実際にインストールする前に、利用可能なセットアップからSQL Serverのバージョンとエディションを確認してください。
SQL Server 2008 R2 EnterpriseからStandardエディションへのダウングレードプロセスを行っています。 上記のアクティビティを開始するために、SQL Serverの利用可能なStandard Editionを探していました。見つけましたが、以下の点で混乱しました: セットアップファイル(以前のチームメンバーによって保存された)は、SQL Server 2008 R2であると言うフォルダーにありますが、インストールを開始する前にクロスチェックするために、default.iniファイルを調べました。 SQLSERVER2008 Configuration File [SQLSERVER2008] これは、これが必要なSQL Serverの正しいバージョンであるかどうか疑問を投げかけました。それで、実際に先に進んでインストールを試みる前に、上記の方法がバージョンを決定するのに正しくない場合、他の方法はありますか? 使用可能なSQL Serverのエディションも確認できますか?セットアップでは、それが本当にStandard Editionであるかどうかほとんどわかりません。 セキュリティポリシーに従って、新しいメディアを単にダウンロードすることはできません。また、ダウンロードする権利もありません。

6
2005または2008のインスタンスなしでSQL Server 2000から2012に移行する
SQL Server 2000にある3つの古いデータベースに遭遇しました。これらは2012年に移動する必要があります。標準的なアプローチは、2005または2008インスタンスに復元し、更新、再エクスポートして、最後に2012年に復元することです。 申し訳ありませんが、2005年または2008年のインスタンスはありません。 試してみる価値のある回避策やその他の方法はありますか? ちなみに、データベースには15〜20のテーブルといくつかのビューしか含まれておらず、非常にシンプルに見え、バックアップのサイズは100〜200 MBしかありません。

1
SSDTスキーマ比較は、BULK INSERTの進行中は機能しません
私は、SFSとSSDTの両方と一緒にTFS /ソース管理を使用する大規模なETLおよびDWプロジェクトで働いています。 今日、SSISパッケージがデータベーステーブルへの一括挿入を実行している間、そのデータベースに対してSSDTスキーマ比較を実行できないことがわかりました。一部のパッケージの完了には非常に長い時間がかかるため、これは残念です。データベースのバージョン管理のためにSSDTプロジェクトに保存するために、スキーマ比較機能を使用してデータベース構造への変更を検出します。 これについてもう少し詳しく見てみると、SSDTのスキーマ比較関数OBJECTPROPERTY()が、データベースのテーブルでシステム関数を呼び出すSQLスクリプトを実行していることがわかりました。特に私の場合、が現在一括挿入されているテーブルを参照する場合、への呼び出しはすべてOBJECTPROPERTY(<object_id>, N'IsEncrypted')ブロックされているよう<object_id>です。 Visual Studioでは、SSDTスキーマ比較はしばらくするとタイムアウトし、違いが検出されなかったと主張します。 SSDTでこの問題の回避策はありますか、それともMS Connectバグレポートを提出する必要がありますか? または、BULK INSERTはSSISパッケージからOBJECTPROPERTY行われるので、テーブルの呼び出しをロックせずにこの挿入を行う方法はありますか?編集: SSIS OLE DB宛先では、「テーブルのロック」からチェックマークを削除できます。チェックマークはそれを実行しますが、状況によってはパフォーマンスが低下する可能性があります。一部のオブジェクトがロックされている場合でも、SSDTスキーマ比較でその機能を実行できるようにするソリューションの方がはるかに興味があります。
11 sql-server  ssis  ssdt 

3
既存のユーザーのパスワードポリシーの確認
最近、多くのデータベースログインでenforce_password_policyフラグが有効になっていない環境に入りました。 次の監査では、これらのログインのパスワードの検証が必要です。 次のクエリを使用して、ログインのリストとフラグがオンかオフかを取得しました。 select @@SERVERNAME as servername, name, IS_SRVROLEMEMBER('sysadmin', name) as SYSADMIN, type_desc, create_date, is_policy_checked, is_disabled, password_hash, PWDCOMPARE(name, password_hash) as UsernameAsPassword FROM sys.sql_logins ただし、フラグはユーザーの作成時にのみ関連するため、パスワードが実際にパスワードポリシーに準拠しているかどうかはわかりません。 パスワードポリシーのコンプライアンスについて既存のユーザーをテストする既知の方法はありますか? 私は古いパスワードにアクセスできず、それらを必要としない方法を好みます。

2
IPアドレスの保存-varchar(45)とvarbinary(16)
2つのフィールド(IDas BIGINTおよびIPAddressas varchar(45)またはor)を持つテーブルを作成しますvarbinary(16)。アイデアは、すべての一意のIPアドレスを保存し、他のテーブルのID実際のIPアドレスの代わりに参照を使用することIP addressです。 一般的に、ID与えられたforを返す、IP addressまたは(アドレスが見つからなかった場合は)アドレスを挿入して生成されたを返すストアドプロシージャを作成しますID。 多くのレコードがあることを期待しています(正確な数はわかりません)が、上記のストアドプロシージャをできるだけ速く実行する必要があります。それで、実際のIPアドレスをテキストまたはバイト形式で保存する方法を知りたいです。どっちがいいの? SQL CLRIPアドレスのバイトを文字列に変換したり、その逆を行ったりするための関数をすでに作成しているため、変換は問題ではありません(IPv4およびの両方で機能しますIPv6)。 検索を最適化するためにインデックスを作成する必要があると思いIP addressますが、クラスター化インデックスにフィールドを含める必要があるのか、または別のインデックスを作成し、どのタイプで検索を高速化するのかわかりませんか?

1
高PAGELATCH_ *およびWRITELOG待機。それらは関連していますか?
非常に高いPAGELATCH_EXおよびPAGELATCH_SH待機タイプと、高いWRITELOG待機が発生しています。PAGELATCH待機の原因となっているクエリを診断しました。IDENTITY値で定義されたビジーなクラスター化された主キーへの挿入率を下げることで、それらを排除できます。この現象は最終ページ挿入ラッチ競合として知られていると理解しています。 ただし、私の質問は、新しいレコードが挿入されたとき、SQL Serverがバッファーページで排他的なPAGELATCH_EXを取得し、レコードをバッファーページに挿入して、トランザクションログにレコードを書き込み、詳細なhttps://として排他的なPAGELATCH_EXを解放することです。 www.microsoft.com/en-ie/download/details.aspx?id=26665ページ24.または、詳細な「高度に同時実行されているINSERTワークロードでのPAGELATCH競合の解決-背景情報SQLCATのガイド:リレーショナルエンジン レコードがラッチメカニズムの外部のログに書き込まれる場合、PAGELATCH待機が高くなる原因として、ディスクへの遅い書き込みを除外できます。しかし、レコードがログに記録されるまで強化されるまでラッチが保持されている場合は、おそらくWRITELOGを考慮する必要があります。 また、複数の非クラスター化インデックスがあると、PAGELATCH_ *ラッチがより長く保持されます。つまり、テーブルにクラスター化されており、複数の非クラスター化インデックスがラッチに追加され、各インデックスバッファーページに同時に解放されますか? 更新1 confio-sql-server-writelog-waitスライド2と一般的なWALアーキテクチャを 読んだ後。両方のホワイトペーパーで説明されている「行が変更されたログエントリを記録する」手順は、SQL Serverがディスクではなくトランザクションログキャッシュに変更を記録することを指していることを理解しました。トランザクションが完了するか、バッファがいっぱいになると、すべてのレコードがすぐにディスクにフラッシュされます。

3
トリガーを使用せずにSQL Serverでクエリを実行するクライアントのIDを見つけますか?
現在Change Data Capture(CDC)を使用してデータの変更を追跡しています。変更を行ったクエリを送信するクライアントのホスト名とIPアドレスを追跡したいと考えています。同じユーザー名でログインしている5つの異なるクライアントがある場合、5つのうちどれがクエリを起動したかを追跡するという難題に直面します。私が見つけた他の疑わしい解決策には、次のコマンドでCDCテーブルを変更することが含まれます。 ALTER TABLE cdc.schema_table_CT ADD HostName nvarchar(50) NULL DEFAULT(HOST_NAME()) ただし、これは、クエリが起動されたサーバーのホスト名を返し、クエリを起動したクライアントのホスト名は返しません。 この問題を回避する方法はありますか?クライアントのホスト名またはIPアドレス(または他の種類の一意のID)をログに記録するのに役立つもの。トリガーを使用したくありません。システムが遅くなるだけでなく、CDCがシステムテーブルを生成するため、トリガーを設定することは明らかに不可能です。

3
SQL Server:ビューではなく、テーブル内のユーザーに選択アクセスを許可します
データベースがいくつかあるSQL Server 2012インスタンスがあります。それらの1つで、データベース以外のテーブルを選択するビューを作成しました。 ユーザーがそのビューを選択できるようにしたいのですが、そのテーブルを選択してはなりません。ユーザーがテーブルを選択できないため、ビューが作成されました。 /programming/368414/grant-select-on-a-view-not-base-tableおよびhttp://msdn.microsoft.com/en-us/library/ms188676を読みました。 aspx、それでも動作しません。 GRANT SELECT TABLE TO USERすべてのテーブルに対してaを実行すると、ユーザーはビューを選択できます。しかし、いずれかのテーブルを取り消すと、失敗します。 これは簡単な手順ですが、機能させるのに苦労しています。以前にそれが発生するのを見たことがありますが(インスタンスの所有者がビューへのアクセスを許可し、テーブルへのアクセスを許可しませんでした)、それを実行したり、方法を知っている人を見つけることができません。 誰かがそれを行う方法についてのチュートリアル、またはコード例を私に提供できますか? ユーザーSELECTsがビューを受け取ると、次のメッセージが表示されます。 オブジェクト<TABLE>、データベース<DB>、スキーマに対するSELECT権限が拒否されましたdbo。 そのテーブルに選択を許可すると、エラーメッセージにより、テーブル名がビューが読み取る別のテーブルに変更されます。

1
クエリプランをステートメントで分割して再利用できるようにした方がよいでしょうか。
クエリによってクエリプランがどのようにコンパイル、格納、および取得されるかについての限られた知識から、複数ステートメントクエリまたはストアドプロシージャがクエリプランを生成し、クエリプランキャッシュに格納されて、今後の実行でクエリによって使用されることを理解しています。 このプランは、クエリハッシュを使用してクエリプランキャッシュから取得されると思います。つまり、クエリを編集して実行すると、ハッシュが異なり、クエリプランキャッシュで一致するハッシュが見つからないため、新しいプランが生成されます。 私の質問は次のとおりです。ユーザーがマルチステートメントクエリのステートメントの1つであるステートメントを実行した場合、マルチステートメントクエリのキャッシュに既にあるクエリプランの関連部分を使用できますか?ハッシュ値が明らかに一致しないため、答えはノーだと思いますが、マルチステートメントクエリの各ステートメントをハッシュして、クエリから個々のステートメントを実行しているユーザーが使用できるようにした方がよいでしょうか? 私は考慮していない複雑な問題があると思います(そして、私が本当に知りたいのはこれらです)が、より多くのスペースを使用し、さらに多くのクエリプランに同じ「ステートメントプラン」を格納することができるようです生成するCPUと時間。 私の無知を示​​しているだけかもしれません。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.