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

SQL Server 2014（メジャービルドバージョン12.0.xxxx）。sql-serverにもタグを付けてください。

1
SQL Server 2014はバッチモードで正確に何を実行できますか？
クエリで列ストアインデックスが使用されている場合、SQL Serverはバッチモードを使用できます。ドキュメントは、バッチモードで実行できるものとできないものについては薄い。バッチモード（緑色）で驚くほど多くのことが実行される、次の（動機付けの）クエリプランをご覧ください。 （これは推定プランです。実際のプランを使用して、実際の実行モードが実際にバッチであることを確認しました。） T1のビルド側のみが列ストアインデックスを使用することに注意してください。すべてのプローブ入力（T2およびT3）は行ストアです。彼らのデータはバッチモードに移行しているようです。プローブ側のみで実行されるデータストリームにはバッチモードが使用されていると常に考えていました。 列ストアインデックスに由来しない場合でも、データはバッチモードに移行できるようです。それは疑問を提起します：なぜSQL Serverは行ストアのみのクエリにもバッチモードを使用しないのですか？それらのいくつかのために有益である可能性があります。列ストアインデックスの使用は、SQL Serverでバッチモードを考慮するために必要な正式な要件ですか？列ストアインデックスを持つゼロ行のダミーテーブルを追加して、バッチモードを導入し、パフォーマンスの向上を実現できますか？ SQL Server 2014の時点でバッチモードで正確に実行できるものは何ですか？
1
SQL Server 2014 ExpressのSQLCMD.EXEはどこにありますか？
「SQLCMD.EXE」を使用してSQL Server Expressデータベースを何年もバックアップしていましたが、2014バージョンをインストールした後、SQLCMD.EXEがなくなったことを発見しました。 以前のバージョンでは、次の場所にありました。 C：\ Program Files \ Microsoft SQL Server \ 110 \ Tools \ Binn \ SQLCMD.EXE しかし、2014年のインストールでは、SQLCMD.EXEは存在しません C：\ Program Files \ Microsoft SQL Server \ 120 \ Tools \ Binn 私の質問： SQLCMD.EXEをSQL Server Express 2014に取り込むチャンスはありますか？
2
連結演算子が入力よりも少ない行を推定するのはなぜですか？
次のクエリプランスニペットでは、Concatenation演算子の行推定値はである必要があること~4.3 billion rows、またはその2つの入力の行推定値の合計であることは明らかです。 しかし、の推定値は~238 million rows、最適につながる、生成されるSort/ Stream AggregatetempdbのにデータのGB数百をこぼし戦略。この場合の論理的に一貫した推定は、を生成しHash Aggregate、流出を除去し、クエリパフォーマンスを劇的に改善します。 これはSQL Server 2014のバグですか？入力よりも低い見積もりが合理的である有効な状況はありますか？どのような回避策が利用可能ですか？ ここで完全なクエリプラン（匿名化）が。出力QUERYTRACEON 2363または類似のトレースフラグを提供するためにこのサーバーにsysadminアクセスすることはできませんが、役立つ場合は管理者からこれらの出力を取得できる場合があります。 データベースは互換性レベル120にあるため、新しいSQL Server 2014 Cardinality Estimatorを使用しています。 統計は、データがロードされるたびに手動で更新されます。データ量を考えると、現在デフォルトのサンプリングレートを使用しています。より高いサンプリングレート（またはFULLSCAN）が影響を与える可能性があります。
1
GUIを使用したデータベースの復元-復元するファイルが間違っています
SSMSのグラフィックインターフェイスをいじり、「復元」タスクのオプションを検討しています。 「スクリプトを生成する」をクリックすると、クエリの最初の行が次のようになります。 RESTORE DATABASE [MyDatabase] FROM DISK = N'Server_Patch\Database_name_LOGSHIPPING.BKP' WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 5 ( and a lot of log backups for point in time ) OK、問題ありませんが、このデータベースの毎日のバックアップを行っています。これDatabase_name_LOGSHIPPING.BKPは、1か月前にログ配布用に作成したファイルの名前でした。 SSMSグラフィックインターフェイスを使用してバックアップを復元しようとすると、このバックアップファイルを指すのはなぜですか？このファイルはもうありません。 MSSQLTIPSのこのクエリを使用すると、このデータベースのすべてのバックアップを確認できます。 SELECT CONVERT(CHAR(100), SERVERPROPERTY('Servername')) AS Server, msdb.dbo.backupset.database_name, msdb.dbo.backupset.backup_start_date, msdb.dbo.backupset.backup_finish_date, msdb.dbo.backupset.expiration_date, CASE msdb..backupset.type WHEN 'D' THEN 'Database' WHEN 'L' …
3
SQL Serverの膨大なデータとパフォーマンス
非常に大量のレコードを収集して保存するSQL Serverバックエンドを使用してアプリケーションを作成しました。ピーク時の平均レコード量は、1日あたり30〜40億（20時間の操作）の範囲にあると計算しました。 私の元の解決策（データの実際の計算を行う前）は、クライアントが照会する同じテーブルにアプリケーションがレコードを挿入することでした。明らかに、多くのレコードが挿入されているテーブルをクエリすることは不可能だからです。 2番目のソリューションは、2つのデータベースを使用することでした。1つはアプリケーションが受信したデータ用で、もう1つはクライアント対応データ用です。 私のアプリケーションはデータを受け取り、それを〜10万レコードのバッチにチャンクし、ステージングテーブルに一括挿入します。〜100kの記録後、アプリケーションはその場で、以前と同じスキーマで別のステージングテーブルを作成し、そのテーブルへの挿入を開始します。それは、100kレコードを持つテーブルの名前でジョブテーブルにレコードを作成し、SQL Server側のストアドプロシージャは、ステージングテーブルからクライアント対応の本番テーブルにデータを移動してから、アプリケーションによって作成された一時テーブル。 両方のデータベースには、同じスキーマを持つ5つのテーブルの同じセットがありますが、ジョブテーブルがあるステージングデータベースは例外です。ステージングデータベースには、大量のレコードが存在するテーブルに整合性の制約、キー、インデックスなどがありません。以下に示すように、テーブル名はSignalValues_stagingです。目標は、できるだけ早くデータをSQL Serverにバタンと置くことでした。簡単に移行できるようにテーブルをオンザフライで作成するワークフローは非常にうまく機能します。 以下は、ステージングデータベースからの5つの関連テーブルと、jobsテーブルです。 私が作成したストアドプロシージャは、すべてのステージングテーブルからのデータの移動と本番環境への挿入を処理します。以下は、ステージングテーブルからプロダクションに挿入するストアドプロシージャの一部です。 -- Signalvalues jobs table. SELECT * ,ROW_NUMBER() OVER (ORDER BY JobId) AS 'RowIndex' INTO #JobsToProcess FROM ( SELECT JobId ,ProcessingComplete ,SignalValueStagingTableName AS 'TableName' ,(DATEDIFF(SECOND, (SELECT last_user_update FROM sys.dm_db_index_usage_stats WHERE database_id = DB_ID(DB_NAME()) AND OBJECT_ID = OBJECT_ID(SignalValueStagingTableName)) ,GETUTCDATE())) SecondsSinceLastUpdate FROM SignalValueJobs …
2
すべてのレコードを選択し、結合が存在する場合はテーブルAと結合し、存在しない場合はテーブルBと結合します
だからここに私のシナリオがあります： 私は私のプロジェクトのローカリゼーションに取り組んでおり、通常はC＃コードでこれを行いますが、SQLを少し強化しようとしているので、SQLでこれをもう少しやりたいと思っています。 環境：SQL Server 2014 Standard、C＃（.NET 4.5.1） 注：プログラミング言語自体は無関係である必要があります。完全を期すためだけに含めています。 それで、私は自分が望むものをやや達成しましたが、私が望んでいた程度ではありませんでした。JOIN基本的なもの以外のSQLを実行してからしばらく（少なくとも1年）経ちましたが、これは非常に複雑JOINです。 データベースの関連テーブルの図を次に示します。（他にもたくさんありますが、この部分には必要ありません。） 画像に記述されているすべての関係はデータベースで完全です- PKとFK制約はすべて設定および操作されています。説明されている列はどれもnullできません。すべてのテーブルにはスキーマがありますdbo。 今、私はほとんど私がしたいことをするクエリを持っています：つまり、ANY Id of SupportCategoriesとANY Id of が与えられるとLanguages、それは次のいずれかを返します： その文字列のためにその言語の右適切な翻訳がある場合（IeはStringKeyId- > StringKeys.Id存在し、中LanguageStringTranslations StringKeyId、LanguageIdとStringTranslationIdの組み合わせが存在し、それはロードStringTranslations.TextそのためStringTranslationId。 場合はLanguageStringTranslations StringKeyId、LanguageIdとStringTranslationIdの組み合わせがなかったしない存在し、それはロードStringKeys.Name値を。Languages.Id与えられていますinteger。 私のクエリは、それが混乱であっても、次のとおりです。 SELECT CASE WHEN T.x IS NOT NULL THEN T.x ELSE (SELECT CASE WHEN dbo.StringTranslations.Text IS NULL THEN dbo.StringKeys.Name ELSE dbo.StringTranslations.Text END AS Result FROM …
3
明確なフローの強制
このようなテーブルがあります： CREATE TABLE Updates ( UpdateId INT NOT NULL IDENTITY(1,1) PRIMARY KEY, ObjectId INT NOT NULL ) 基本的に、IDが増加するオブジェクトの更新を追跡します。 このテーブルのコンシューマーはUpdateId、特定のから順に特定の100個のオブジェクトIDのチャンクを選択しますUpdateId。基本的に、中断した場所を追跡し、更新をクエリします。 私はクエリのみ書き込むことによって最大限に最適なクエリプランを生成することができましたので、これは興味深い最適化問題であることがわかってきましたが起こる私はインデックスのためにやりたいが、ないが保証する私が欲しいもの： SELECT DISTINCT TOP 100 ObjectId FROM Updates WHERE UpdateId > @fromUpdateId @fromUpdateIdストアドプロシージャのパラメーターはどこにありますか。 次の計画： SELECT <- TOP <- Hash match (flow distinct, 100 rows touched) <- Index seek UpdateId使用されているインデックスのシークにより、結果は既に素晴らしく、必要な更新IDの最低から最高まで並べられています。そして、これはフロー別の計画を生成します。それは私が望むものです。しかし、順序は明らかに動作を保証するものではないため、使用したくありません。 このトリックにより、同じクエリプランが得られます（ただし、冗長なTOPがあります）。 WITH …
6
常に単一の整数列を主キーとして持つことの欠点は何ですか？
私が取り組んでいる1つのWebアプリケーション内で、すべてのデータベース操作は、Entity Framework ORMで定義されたいくつかの汎用リポジトリを使用して抽象化されています。 ただし、汎用リポジトリのシンプルなデザインを実現するには、関連するすべてのテーブルで一意の整数（Int32C＃、intSQL）を定義する必要があります。これまで、これは常にテーブルのPKであり、IDENTITY。 外部キーは頻繁に使用され、これらの整数列を参照します。これらは、一貫性とORMによるナビゲーションプロパティの生成の両方に必要です。 通常、アプリケーション層は次の操作を実行します。 テーブルからの初期データロード（*）-SELECT * FROM table 更新 -UPDATE table SET Col1 = Val1 WHERE Id = IdVal 削除 -DELETE FROM table WHERE Id = IdVal 挿入 -INSERT INTO table (cols) VALUES (...) 頻度の低い操作： 一括挿入 - BULK INSERT ... into tableその後に（*）すべてのデータロード（生成された識別子を取得するため） 一括削除 -これは通常の削除操作ですが、ORMの観点からは「一括」です。DELETE FROM table where OtherThanIdCol …
12
SQL Serverの各文の各単語の最初の文字のみを大文字にする
SQL列の各文の各単語の最初の文字のみを大文字にします。 たとえば、文が次の場合： '私は映画が好き' 次に出力が必要です： '私は映画が好き' クエリ： declare @a varchar(15) set @a = 'qWeRtY kEyBoArD' select @a as [Normal text], upper(@a) as [Uppercase text], lower(@a) as [Lowercase text], upper(left(@a,1)) + lower(substring(@a,2,len(@a))) as [Capitalize first letter only] ここでは、自分の列でのみ最初の文字を大文字、小文字、大文字にしました（ここではランダムな単語を入力しています）。 私の結果は次のとおりです。 それを行う可能性はありますか？ ユーザー定義関数を使用せずに結果を取得する可能性はありますか？ 出力が必要です Qwerty Keyboard
3
クラスター化された列ストアインデックスと外部キー
インデックスを使用してデータウェアハウスのパフォーマンスをチューニングしています。私はSQL Server 2014を初めて使用します。Microsoftは次のように説明しています。 「クラスター化された列ストアインデックスは、大規模なデータウェアハウジングファクトテーブルを格納するための標準であり、ほとんどのデータウェアハウジングシナリオで使用されることを期待しています。操作を削除します。」 http://msdn.microsoft.com/en-us/library/gg492088.aspx ただし、ドキュメントをさらに読むと、制限と制限があります。 「一意の制約、主キーの制約、または外部キーの制約を持つことはできません。」 これは私をとても混乱させます！さまざまな理由（データの整合性、セマンティックレイヤーに表示される関係など）のために、データウェアハウスに外部キーを配置することをお勧めします（必須ではありません）。 そのため、Microsoftはデータウェアハウスシナリオのクラスター化列ストアインデックスを推奨しています。ただし、外部キー関係を処理できませんか？！ これは正しいですか？他にどのアプローチをお勧めしますか？過去には、データウェアハウスのシナリオで、クラスター化されていない列ストアインデックスを使用して、データロードのドロップと再構築を行いました。しかし、SQL Server 2014はデータウェアハウスに新しい価値を追加しませんか？
4
メモリ最適化テーブル-メンテナンスが本当に難しいのでしょうか？
私は、MS SQL 2012から2014へのアップグレードの利点を調査しています。SQL2014の大きなセールスポイントの1つは、クエリを超高速にするメモリ最適化テーブルです。 メモリ最適化テーブルには、次のようないくつかの制限があることがわかりました。 いいえ(max)サイズのフィールドありません 行ごとに最大1 KB timestampフィールドなし 計算列はありません UNIQUE制約なし これらはすべて迷惑と見なされますが、パフォーマンス上のメリットを得るために本当に回避したい場合は、計画を立てることができます。 実際のキッカーは、ALTER TABLEステートメントを実行できないという事実であり、インデックスのリストにフィールドを追加するたびに、このリマロールを実行する必要がINCLUDEあります。さらに、ライブDBのMOテーブルにスキーマを変更するには、ユーザーをシステムから締め出す必要があるようです。 マイクロソフトがこの機能にこれほど多くの開発資金を投資したとは信じられないほど、これはまったくとんでもないことであり、維持するのは非常に実用的ではありません。これは、私がスティックの間違った終わりを得たに違いないという結論に私を導きます。メモリを最適化したテーブルについて誤解していたため、実際よりも保守がはるかに困難であると思われました。 それで、私は何を誤解しましたか？MOテーブルを使用しましたか？それらを使用および保守するのに実用的な何らかの種類の秘密のスイッチまたはプロセスがありますか？
4
OVERを使用したウィンドウ関数でのDISTINCTの使用
OracleからSQL Server 2014にクエリを移行しようとしています。 Oracleでうまく機能するクエリを次に示します。 select count(distinct A) over (partition by B) / count(*) over() as A_B from MyTable これは、SQL Server 2014でこのクエリを実行しようとした後に取得したエラーです。 Use of DISTINCT is not allowed with the OVER clause 誰が問題を知っていますか？SQL Serverではこのような種類のクエリが可能ですか？お知らせ下さい。
2
SQL Server UniqueIdentifier / GUID内部表現
私の同僚が私に興味深い質問を送ってきたが、それは完全には説明できない。 彼はいくつかのコード（以下を含む）を実行し、それからやや予期しない結果を得ました。 本質的に、UniqueIdentifier（これから私が参照するGuid）をbinary（またはvarbinary）タイプに変換するとき、結果の前半の順序は逆になりますが、後半はそうではありません。 私の最初の考えは、システムのエンディアンが原因であり、Guidディスプレイは保存されているが、binaryフォームは保証されていないということでした。 明らかにこれは実装の詳細ですが、それについて適切な説明があったのではないかと思っていました。 コード： declare @guid uniqueidentifier = '8A737954-CBEC-40CE-A534-2AFFB5A0E207'; declare @binary binary(16) = (select convert(binary(16), @guid)); select @guid as [GUID], @binary as [Binary]; 結果： GUID Binary 8A737954-CBEC-40CE-A534-2AFFB5A0E207 0x5479738AECCBCE40A5342AFFB5A0E207 ご覧のとおり、Guid（の最後まで40CE）の前半は各セクションごとに逆方向に保存されています。つまり、の最初のセクションGuidは後方に、次に2番目のセクション、次に3番目のセクションになりますが、セクションの順序は保持されます。その後、最後の2つのセクションは、に表示される正確な順序で保存されGuidます。 誰でもこれを説明できますか？（より大きなテストセットを以下に示します。） コード： declare @guid_to_binary table ( [id] int identity(1,1), [guid] uniqueidentifier, [binary_conversion] binary(16) ); declare @i int = 1; …
5
計算列にフィルター選択されたインデックスを作成できません
私の前の質問で、テーブルに新しい計算列を追加するときにロックエスカレーションを無効にすることは良い考えですか？、計算列を作成しています： ALTER TABLE dbo.tblBGiftVoucherItem ADD isUsGift AS CAST ( ISNULL( CASE WHEN sintMarketID = 2 AND strType = 'CARD' AND strTier1 LIKE 'GG%' THEN 1 ELSE 0 END , 0) AS BIT ) PERSISTED; 計算列はPERSISTEDであり、compute_column_definition（Transact-SQL）によると： 執着 データベースエンジンがテーブルに計算値を物理的に格納し、計算列が依存する他の列が更新されたときに値を更新することを指定します。計算列にPERSISTEDのマークを付けると、確定的ではあるが正確ではない計算列にインデックスを作成できます。詳細については、計算列のインデックスを参照してください。パーティションテーブルのパーティション列として使用される計算列には、明示的にPERSISTEDのマークを付ける必要があります。PERSISTEDが指定されている場合、compute_column_expressionは確定的でなければなりません。 しかし、列にインデックスを作成しようとすると、次のエラーが表示されます。 CREATE INDEX FIX_tblBGiftVoucherItem_incl ON dbo.tblBGiftVoucherItem (strItemNo) INCLUDE (strTier3) WHERE isUsGift = 1; …
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.