DB技術者の先輩方、よろしくお願いいたします m(__)m 0140NAME IS NULL2019/04/26(金) 06:47:20.35ID:???>>139 一時テーブルを作るとか普通にあるけど? てか、一番多いのは検索だと思うぞ 0141NAME IS NULL2019/04/26(金) 20:31:59.53ID:l8u5/4vh>>140 一時的テーブルってどんなケースでしょうか?
自分がイメージしてるのは↓みたいな感じですが、実際こんな感じでしょうか?
例えば商品を扱う時に ◆登録時 商品(+カテゴリ)のレコードを追加、 もしくは既存レコードの数量を更新 ◆検索 SELECT 〜 WHERE で商品検索。 表示されたものを並べ替える時に、上記SELECT分に ORDER BY 〜 を追加。 0142NAME IS NULL2019/05/01(水) 18:56:39.99ID:769RFL3v SQL serverをデータベースに使用している業務用アプリを Windows7+SQL server 2008R2EXPRESSの環境で動かして いましたが、今回、Windows10+SQL server 2016EXPRESSに 移行したところ、途端にアプリの動きが重くなりました。
いろいろ調べた結果、移行時に、SQL server 2016に2008R2の データベース完全バックアップを復元した際に互換性レベルを 「2016」にしたことが原因で、これを「2008」に下げるとサクサク 動くようになりました。
そこで質問ですが、SQL server 2016EXPRESSに復元したDBの 互換性レベルを「2008」で動かしても特にリスクはないでしょうか?
そもそも互換性レベルは「2016」で動かす方が望ましいのでしょうか?
よろしくお願い致します 0143NAME IS NULL2019/05/01(水) 19:41:43.69ID:TltKGa3C>>142 調べたから見たはずだけど、2016を2008互換で動かしていたら、ただの問題の先送り。 0144NAME IS NULL2019/05/01(水) 20:29:24.14ID:???>>142 暫定的にはいいけど、そのままだと次のバージョンアップの時に苦労するぞ 0145NAME IS NULL2019/05/01(水) 22:13:30.92ID:iAIhZMl0>>143 >>144 ありがとうございます さらにテストをしたら、互換性レベル2014までは正常に動きますが、 2016になった途端、動きが極端に重くなることが分かりました
それとも、2016でなければ、2008でも2014でもさほど変わりませんか? 0146NAME IS NULL2019/05/01(水) 23:57:26.78ID:Z1eUgulk>>145 本当に互換性に問題のある使い方をしているのかどうかを調べるのが基本だよ。 0147NAME IS NULL2019/05/02(木) 04:23:23.11ID:rL4gUhau>>145 便所の落書きに判断を求めるなよ 正攻法なら最新に合わせて改修するだけだし コストがかけられないなら確実に動作する状態でリプレースを待つだけだろ 0148NAME IS NULL2019/05/02(木) 20:31:31.39ID:??? そもそもそれホントに互換性レベルの問題なのか? 2016出てだいぶ立つから、メジャーな問題ならもっと話題になってると思うが 0149NAME IS NULL2019/05/02(木) 22:09:13.65ID:??? 実行プランに影響するから>>142の環境だけで発生するとかもあり得る 0150NAME IS NULL2019/05/03(金) 07:56:37.64ID:FseZSqD/ その後、同じ業務用アプリケーションで、以下のような環境移行を行い、 サーバ:Windows server 2008R2→Windows server 2016 SQL server:SQL server 2008R2→SQL server 2017 クライアント:Windows7→Windows10 互換性レベルをSQL server 2017にしたところ、やはり動きが 極端に重く(遅く)なり、互換性レベルをSQL server 2014に 下げると正常なスピードになりました
データベースがSQL server 2014までは互換性レベルなんて 意識したことなかったけど、SQL server 2016以降において 急に引っかかるようになった感じですね 0151NAME IS NULL2019/05/03(金) 08:53:54.23ID:lS9VfNzG>>150 だから製品の何が変わったのかマイクロソフトの情報を見ているのか? 0152NAME IS NULL2019/05/03(金) 09:11:40.19ID:??? 切り分けもしないような奴はスルーしてくださいな 0153NAME IS NULL2019/05/03(金) 10:15:30.90ID:FseZSqD/ 切り分け??? 0154NAME IS NULL2019/05/03(金) 12:04:10.91ID:??? どこのSQLで遅くなってるかとかの確認もしてないんだろ? 0155NAME IS NULL2019/05/03(金) 23:55:03.93ID:??? 例えばどんなSQLがどのくらい遅くなったのか、そのときの実行計画は同じなのかぐらいは調べてさらせよ 0156NAME IS NULL2019/05/04(土) 12:14:50.42ID:??? GW中に仕事のことは考えたくないなw 0157NAME IS NULL2019/05/04(土) 16:41:00.90ID:??? 確か遅いSQL一発で出せるやり方あったよな 事前にフラグ立てなきゃいけなかった気もするが 0158NAME IS NULL2019/05/05(日) 01:15:20.04ID:EcFZ4uZL 言っておくが彼はSQLが遅くなったとは一度も書いていない。 0159NAME IS NULL2019/05/05(日) 07:50:24.90ID:??? そもそも何も書いてないから切り分けろって言われてるんだが… 0160NAME IS NULL2019/05/05(日) 13:27:25.13ID:??? DBでSQL実行が遅くなる以外に何が遅くなるって言うんだ…? 0161NAME IS NULL2019/05/05(日) 13:49:54.90ID:??? バックアップとか? 0162NAME IS NULL2019/05/05(日) 14:09:42.14ID:???>>160 可能性は低いだろうけど接続に時間がかかるようになったとかメモリー足りなくてスラッシング起きてるとか 0163NAME IS NULL2019/05/05(日) 16:11:54.87ID:??? まあまずはなにがどう遅いか調べんと話にならん
あとはリストアしてからなにしたかだな ほんとに互換性レベルだけで遅くなるとは思いにくい 0164NAME IS NULL2019/05/05(日) 22:59:56.81ID:EcFZ4uZL>>160 データベースそのものも考えてくれよw 0165NAME IS NULL2019/05/06(月) 14:04:27.64ID:???>>164 DBの機能が遅い以外何があるってんだよハゲ 0166NAME IS NULL2019/05/06(月) 22:56:09.24ID:stsMt92h>>165 データベースは外部からSQLが発行されなくても、ただ動いているだけでもメモリ上のデータを定期的にファイルに書き込む。余裕があればファイルからデータを読み込む。
いっぱいあるがとにかくデータを失わない、データの整合性がとれなくならないようにする処理等があるんだよ。 0167NAME IS NULL2019/05/07(火) 18:35:52.13ID:???>>166 で? それはDBの機能じゃねえのか? 大体そんなバックグラウンド処理なんて四六時中走ってねーよこじつけんな 0168NAME IS NULL2019/05/07(火) 19:43:05.91ID:ALcLaDvG>>167 走ってますよ。 0169NAME IS NULL2019/05/08(水) 16:53:24.61ID:VbqXritb Express版でオンラインバックアップ取る技ってないの? 0170NAME IS NULL2019/05/08(水) 20:01:01.21ID:8qp+Z1yx>>169 普通にバックアップとるだけだろ 0171DBかじり始めたオープン系エンジニア2019/05/09(木) 06:15:57.71ID:Rd8XFIHD DBエンジニアの業務ってどんな感じですか? ↓みたいなイメージで合ってます?w