Microsoft SQL Server 総合スレ 12

0001NAME IS NULL

2023/09/21(木) 08:50:54.98ID:???

Microsoft SQL Server (Transact-SQL) の総合スレッドです。

・Microsoft 公式サイト
http://www.microsoft.com/japan/sql/

0002NAME IS NULL

2023/09/29(金) 10:19:10.16ID:???

どなたかご存知の方、ご教授お願いします。
SQLSERVER2014を2019(共にSTD)にインプレースアップグレードしました。
その後2014のDBバックアップを2019にリストアしようとすると、以前の数倍掛かる時が出てきました。
また互換性レベルを120に合わせているにも関わらず、2014の時より倍以上遅くなるSQL(ストアド)が見つかり、困っております。
有識者の方、解消のアドバイス宜しくお願い致します。

0003NAME IS NULL

2023/09/29(金) 12:27:56.66ID:???

統計情報に一票

ストアドが遅い原因を推測するには
SQL文、テーブル/インデックス構造、2014/2019それぞれでの実行計画と計測した処理時間が必要

0004NAME IS NULL

2023/09/29(金) 18:12:42.79ID:???

>>3
コメントありがとうございます！
ストアドについては2014と2019、同じバックアップを復元したあと、全く同じ操作をさせたのですが、統計情報が違って実行プランが変わる可能性があるのですね…確認してみます！

0005NAME IS NULL

2023/10/16(月) 13:06:47.40ID:???

これはうれしい誤算だね！

0006NAME IS NULL

2023/12/03(日) 23:55:20.02ID:???

tes

0007NAME IS NULL

2024/01/26(金) 00:10:54.07ID:???

板ふっとんだんだ
こちらも2014から2019にあげたけど倍速になった
2016？で改善されたinsertスレッドマルチ化がめっちゃ効いてる
統計情報更新とか処理時間7割減で終わるようになってもう俺ごときのエンジニアいらんようになった感、、トラックドライバーにでも転職するかなあ

0008NAME IS NULL

2024/03/26(火) 08:14:29.04ID:ZBkiQq/P

すんません、教えて

declare @Kijunbi datetime;
set @Kijunbi = '2024/03/31';

select Jininbi, Shimei from SampleTable where ( Jininbi is null or Jininbi>@Kijunbi );

Jininbi のデータ型はdatetime ですが、上記のSQLだとJininbiが2024/03/31 のデータが取得出来ないです。

@Kijunbiも、取得したいデータのJininbi列の値も
'2024-03-31 00:00:00.000' とかだと思うのですが…

0009NAME IS NULL

2024/03/26(火) 08:35:04.38ID:???

ああなんか勘違いしておりました…

0010NAME IS NULL

2024/04/06(土) 14:14:49.98ID:???

test