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

6列の最小値を取得したい状況です。 これを達成するためにこれまでに3つの方法を見つけましたが、これらの方法のパフォーマンスに懸念があり、どちらがパフォーマンスに優れているかを知りたいと思います。 最初の方法は、大きなcaseステートメントを使用することです。上記のリンクの例に基づいて、3列の例を次に示します。6つの列を見るので、私のcaseステートメントはもっと長くなります。 Select Id, Case When Col1 <= Col2 And Col1 <= Col3 Then Col1 When Col2 <= Col3 Then Col2 Else Col3 End As TheMin From MyTable 2番目のオプションはUNION、複数の選択ステートメントで演算子を使用することです。Idパラメーターを受け入れるUDFにこれを配置します。 select Id, dbo.GetMinimumFromMyTable(Id) from MyTable そして select min(col) from ( select col1 [col] from MyTable where Id = @id union …

29 sql-server  sql-server-2005  performance  aggregate 

SQL ServerのScalar UDFの危険性について多くのことが書かれています。カジュアル検索では、大量の結果が返されます。 ただし、スカラーUDFが唯一のオプションである場所がいくつかあります。 例として：XMLを扱う場合：XQueryは計算列定義として使用できません。Microsoftによって文書化された1つのオプションは、Scalar UDFを使用してXQueryをScalar UDFにカプセル化し、それを計算列で使用することです。 これにはさまざまな効果があり、いくつかの回避策があります。 テーブルが照会されたときに行ごとに実行します テーブルに対するすべてのクエリを強制的にシリアルに実行します 関数をスキーマバインドし、計算列を永続化するか、インデックスを作成することで、行ごとの実行を回避できます。これらのメソッドはいずれも、スカラーUDFが参照されていない場合でも、テーブルにヒットするクエリの強制シリアル化を防ぐことはできません。 それを行う既知の方法はありますか？

29 sql-server  functions  parallelism  computed-column 

Microsoftは、SQL Server 2005または2008の日以降、SQL Serverのバージョンアップグレードをより頻繁に行うため、多くの企業は、アップグレードが「必須」であるかどうかを判断するのが難しいと感じています。アップグレードが「必要なもの」である場合 以前のバージョンよりもSQL Serverのさまざまな新しいリリースを好む理由について尋ねるいくつかの以前の質問の精神で、企業が以前のバージョンからSQL Server 2016へのアップグレードを検討する客観的な技術的またはビジネス上の理由は何ですか？ SQL Server 2014などのリリース？ （この質問 SQL Server 2008の、またはそれに比べてSQL Server 2012の程度、この1 SQL Server 2005に比べてSQL Server 2012の程度それらへの回答ものためにここに理由の一部に拡大し、この質問の精神の例として、気にしています。 SQL Server 2008またはSQL Server 2005で始まる企業）

29 sql-server  sql-server-2016  upgrade 

計算列の値はいつ決定されますか？ 値が取得されるとき？ 値が変更されたとき いつか？ 私は検索で何も見つけられないので、これは初心者の質問だと思います。

29 sql-server  computed-column 

私はこのデッドロックの問題にかなりの数日取り組んでおり、私が何をしようとも、何らかの形で持続します。 まず、一般的な前提：1対多の関係でVisitItemsを使用した訪問があります。 VisitItems関連情報： CREATE TABLE [BAR].[VisitItems] ( [Id] INT IDENTITY (1, 1) NOT NULL, [VisitType] INT NOT NULL, [FeeRateType] INT NOT NULL, [Amount] DECIMAL (18, 2) NOT NULL, [GST] DECIMAL (18, 2) NOT NULL, [Quantity] INT NOT NULL, [Total] DECIMAL (18, 2) NOT NULL, [ServiceFeeType] INT NOT NULL, [ServiceText] NVARCHAR …

29 sql-server  nhibernate  deadlock 

SQL Serverのインストール時にデフォルトのパスの多くを変更できることはわかっています。一般的に、インストールを行うと、データフォルダーとログフォルダーを別々のドライブ（通常はDとE）に変更しますが、最近、デフォルト以外のインスタンス名を実行し、mdfファイルとともにDドライブ上にあるインスタンスルートディレクトリを設定しているプレインストールマシン。これは、通常はフォルダーとデータベースファイルだけが含まれる比較的クリーンなドライブに、SQL Serverバイナリも完全にインストールできるようになったことを意味します。 すなわち、私は今次のものを持っています： C:\Program Files\Microsoft SQL Server\ --Base Install D:\Microsoft SQL Server\MSSQL10_50.MyInstance --Instance Binaries D:\Microsoft SQL Server\MSSQL10_50.MyInstance\MSSQL\DATA --Data Files E:\Microsoft SQL Server\MSSQL10_50.MyInstance\MSSQL\LOGS --Log Files 通常、私は次のようなもので実行します： C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\ --Base Install & Default Instance Binaries D:\MSSQL\DATA --Data Files E:\MSSQL\LOGS --Log Files 別のインスタンスバイナリフォルダーが必要な理由は理解できますが、これらすべてのバイナリを別のドライブに配置することがなぜ役立つのかわかりません。 なぜそれが妥当なことなのか、誰にも教えてもらえますか？それとも、まったく違いはありませんか？私にはそれはひどく乱雑に見える...

29 sql-server  sql-server-2008-r2 

次のSQLステートメントを機能させようとしていますが、構文エラーが発生します。 SELECT A.*, COUNT(B.foo) FROM TABLE1 A LEFT JOIN TABLE2 B ON A.PKey = B.FKey GROUP BY A.* ここで、Aは40列の幅の広いテーブルであり、可能であればGROUP BY句に各列名をリストしないようにします。同様のクエリを実行する必要のあるこのようなテーブルが多数あるため、ストアドプロシージャを作成する必要があります。これにアプローチする最良の方法は何ですか？ MS SQL Server 2008を使用しています。

29 sql-server  sql-server-2008  t-sql  group-by 

dboスキーマに関しては： データベースオブジェクトを作成するときにdboスキーマを使用しないことはベストプラクティスですか？ なぜdboスキーマを避けるべきなのですか？ どのデータベースユーザーがdboスキーマを所有する必要がありますか？

29 sql-server  sql-server-2008  schema  best-practices 

バックアップをSQL Server Express 2008データベースに復元しようとすると、次のエラーが発生しました。 Restore failed for Server '...\SQLEXPRESS'. (Microsoft.SqlServer.SmoExtended) System.Data.SqlClient.SqlError: The database was backed up on a server running version 10.50.1600. That version is incompatible with this server, which is running version 10.00.2531. Either restore the database on a server that supports the backup, or use a backup that …

29 sql-server  sql-server-2008  backup  restore 

最終的には、PowerShellを使用して、SQLインスタンスモニターに使用する古いKornShellスクリプトを置き換えたいと思います。ただし、PowerShellが実際にSQLサーバーと通信できるさまざまな方法を頭に入れて苦労しています。これがすべてかどうかはわかりませんが、SQLサーバーのバージョンを照会できる5つのまったく異なる方法を次に示します。 1. SQLConnection .NETクラス $SqlConnection = New-Object System.Data.SqlClient.SqlConnection $SqlConnection.ConnectionString = "Server=MyServer;Database=Master;Integrated Security=True" $SqlCmd = New-Object System.Data.SqlClient.SqlCommand $SqlCmd.CommandText = "Select @@version as SQLServerVersion" $SqlCmd.Connection = $SqlConnection $SqlAdapter = New-Object System.Data.SqlClient.SqlDataAdapter $SqlAdapter.SelectCommand = $SqlCmd $DataSet = New-Object System.Data.DataSet $SqlAdapter.Fill($DataSet) $SqlConnection.Close() $DataSet.Tables[0] 2. WMIプロバイダー $sqlProperties = Get-WmiObject -computerName "MyServer" -namespace root\Microsoft\SqlServer\ComputerManagement10 -class SqlServiceAdvancedProperty …

29 sql-server  monitoring  powershell 

SQLテーブルでのINSERTには、さまざまな理由で時間がかかることがあります。 テーブル上のINSERT TRIGGERの存在 チェックする必要のある強制された制約の多く（通常は外部キー） テーブルの中央に行が挿入されると、クラスター化インデックスでページが分割される 関連するすべての非クラスター化インデックスを更新する テーブル上の他のアクティビティからのブロック 不十分なIO書き込み応答時間 ...私が見逃したものは何ですか？ 特定のケースでどちらが責任があるのか​​をどのように確認できますか？ページ分割と非クラスター化インデックスの更新と他のすべての影響を測定するにはどうすればよいですか？ （一時テーブルから）一度に約10,000行を挿入するストアドプロシージャがあり、1万行につき約90秒かかります。他のspidがタイムアウトするので、これは受け入れられないほど遅いです。 実行計画を確認しました。INSERTCLUSTERED INDEXタスクとFKルックアップからのすべてのINDEX SEEKSを確認しましたが、なぜ時間がかかるのか確かではありません。トリガーはありませんが、テーブルには少数のFKey（適切にインデックス付けされているように見える）があります。 これはSQL 2000データベースです。

29 sql-server  insert  sql-server-2000  database-tuning 

私の上司は昨日、SQL Serverデータベースのデータを削除した人を見つける方法を尋ねる顧客からの問い合わせがありました（それが重要な場合はエクスプレス版です）。 これはトランザクションログから見つけることができると思いました（切り捨てられていなかった場合）-これは正しいですか？もしそうなら、この情報を実際にどのように見つけ出しますか？

29 sql-server  transaction  delete  audit 

現在、UTC日時からローカル日時を取得するために次を使用しています。 SET @offset = DateDiff(minute, GetUTCDate(), GetDate()) SET @localDateTime = DateAdd(minute, @offset, @utcDateTime) 私の問題は、夏時間の間発生した場合GetUTCDate()や@utcDateTime、@localDateTime時間のオフされてしまいます。 現在の日付ではない日付のUTCから現地時間に変換する簡単な方法はありますか？ SQL Server 2005を使用しています

29 sql-server  sql-server-2005  utc-time  timezone 

ETLプロセスの一環として、ステージングからの行をレポートデータベースと比較して、データが最後に読み込まれてから実際に変更された列があるかどうかを確認します。 この比較は、テーブルの一意のキーと、他のすべての列のある種のハッシュに基づいています。現在HASHBYTES、このSHA2_256アルゴリズムで使用しており、多数の並行ワーカースレッドがすべて呼び出している場合、大規模サーバーではスケーリングしないことがわかりましたHASHBYTES。 96コアサーバーでテストする場合、1秒あたりのハッシュで測定されるスループットは、16を超える同時スレッドを増加させません。同時MAXDOP 8クエリの数を1〜12に変更してテストします。テストでMAXDOP 1は、同じスケーラビリティのボトルネックが示されました。 回避策として、SQL CLRソリューションを試したいと思います。要件を述べるための私の試みは次のとおりです。 関数は並列クエリに参加できる必要があります 関数は決定的でなければなりません この関数は、NVARCHARまたはVARBINARY文字列の入力を受け取る必要があります（関連するすべての列は連結されます） 文字列の一般的な入力サイズは、長さが100〜20000文字です。20000は最大値ではありません ハッシュ衝突の可能性は、MD5アルゴリズムとほぼ同等かそれ以上でなければなりません。CHECKSUM衝突が多すぎるため、機能しません。 この機能は、大規模なサーバーで適切にスケーリングする必要があります（スレッド数が増加しても、スレッドあたりのスループットが大幅に低下することはありません） Application Reasons™の場合、レポートテーブルのハッシュの値を保存できないと仮定します。これは、トリガーまたは計算列をサポートしないCCIです（他の問題もありますが、これには入りたくありません）。 HASHBYTESSQL CLR関数を使用してシミュレートするスケーラブルな方法は何ですか？私の目標は、大規模なサーバーでできる限り多くのハッシュを毎秒取得することであると表現できるため、パフォーマンスも重要です。私はCLRがひどいので、これを達成する方法がわかりません。誰かに答える動機があれば、できるだけ早くこの質問に報奨金を追加する予定です。以下は、ユースケースを非常に大まかに示すクエリの例です。 DROP TABLE IF EXISTS #CHANGED_IDS; SELECT stg.ID INTO #CHANGED_IDS FROM ( SELECT ID, CAST( HASHBYTES ('SHA2_256', CAST(FK1 AS NVARCHAR(19)) + CAST(FK2 AS NVARCHAR(19)) + CAST(FK3 AS NVARCHAR(19)) + CAST(FK4 AS NVARCHAR(19)) + CAST(FK5 …

29 sql-server  sql-server-2016  etl  sql-clr  hashing 

フルテキストインデックスを維持するには、どのガイドラインを考慮する必要がありますか？ フルテキストカタログを再構築または再編成する必要があります（BOLを参照）。合理的なメンテナンスケイデンスとは何ですか？どのようなヒューリスティック（10％および30％の断片化しきい値に類似）を使用して、メンテナンスが必要かを判断できますか？ （以下はすべて、質問について詳しく説明し、これまでに考えたことを示す追加情報です。） 追加情報：最初の調査 Bツリーインデックスのメンテナンスに関するリソースは多数あります（たとえば、この質問、Ola Hallengrenのスクリプト、および他のサイトの主題に関する多数のブログ投稿）。ただし、これらのリソースのいずれも、フルテキストインデックスを維持するための推奨事項またはスクリプトを提供していないことがわかりました。 ベーステーブルのBツリーインデックスを最適化し、フルテキストカタログでREORGANIZEを実行するとパフォーマンスが向上する可能性があることを記載したMicrosoftのドキュメントがありますが、それ以上の具体的な推奨事項については触れていません。 私もこの質問を見つけましたが、それは主に変更追跡（基になるテーブルへのデータ更新がフルテキストインデックスに伝播される方法）に焦点を当てており、インデックスの効率を最大化できるタイプの定期的なメンテナンスではありません。 追加情報：基本的なパフォーマンステスト このSQL Fiddleには、AUTO変更追跡を伴うフルテキストインデックスを作成し、テーブル内のデータが変更されたときのインデックスのサイズとクエリパフォーマンスの両方を調べるために使用できるコードが含まれています。（フィドルの人工的に製造されたデータとは対照的に）生産データのコピーでスクリプトのロジックを実行すると、各データ変更ステップの後に表示される結果の概要は次のとおりです。 このスクリプトの更新ステートメントはかなり不自然でしたが、このデータは定期的なメンテナンスによって多くのことが得られることを示しているようです。 追加情報：最初のアイデア 毎晩または毎週のタスクを作成することを考えています。このタスクは、REBUILDまたはREORGANIZEを実行できるようです。 フルテキストインデックスは非常に大きい（数千または数億行）可能性があるため、カタログ内のインデックスがREBUILD / REORGANIZEが保証されるほど十分に断片化されていることを検出できるようにしたいと思います。ヒューリスティックがそのために何を意味するのか、私には少しわかりません。

29 sql-server  full-text-search  index-maintenance