MENU

SQL Server の最新バージョンについて解説

「SQL Server 12は以前のバージョンに比べてさらにパフォーマンスが向上しているということですね。使いやすさも向上しているので、開発者にとっては嬉しいアップデートだと思います。」
1 NAME IS NULL :2018/08/19(日) 20:52:17.03 ID:???

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

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

3 NAME IS NULL :2018/08/19(日) 22:04:19.10 ID:???

前スレの993だけど、ここにラージオブジェクト データ型はでてくる
https://msdn.microsoft.com/ja-jp/library/ms187752(v=sql.120).aspx

intやcharと同列で語るもんじゃないのはわかってるよ
なにを指摘したいのかわからん。前スレでも書いたがストアドの引数に使うことのデメリットは知らんぞ
普通のテーブルの列で使ったら1ページ8KBの話に関わるから必要な場合を除き乱用すべきじゃないのは言えるが

4 NAME IS NULL :2018/08/19(日) 22:38:57.15 ID:dJDtG65d

>>3
お前さんが「LOB型」とかいう俺様用語を使うから
みんなOracleのCLOB型/BLOB型の話かと思って話が混乱した
(「LOB型」でググったらOracleばかりだ)

最初から「ラージオブジェクト データ型」と書いていたら
混乱は避けられたかもな

6 NAME IS NULL :2018/08/20(月) 07:30:35.21 ID:???

>>4
ああ、最初にLOB型を言い出した前スレ989は俺じゃない(993や995が俺)んだけど、あれへの突っ込みって分かってて突っ込んでる的なやつだったのか
すまんすまん、LOBがなんのことか分からずに素でLOB型ってなにと聞いてるもんかとばかり思った
つかIDないと不便だ、スレ建て時のワッチョイの付け方はわかるんだけどな

>>5
知ってるということを書いたつもりだったんだけどな
そこのMSDNの内容見てそれが読み取れないほど日本語能力に不自由はしてないぞw

5 NAME IS NULL :2018/08/20(月) 05:38:33.37 ID:???

>>3
それ型じゃないよ
ちょっと上に
> SQL Server では一部のデータ型は、格納の特性に基づいて次のグループに分けられます。
ってあるようにグループの名前みたいなもんだから

22 NAME IS NULL :2018/09/11(火) 19:45:29.69 ID:???

あとスキーマいじる奴は戻らないはず

24 NAME IS NULL :2018/09/12(水) 20:28:23.90 ID:???

>>22
戻らないと言うかたいていのDBMSはDDLの前後でコミットするから

30 NAME IS NULL :2018/10/17(水) 11:08:01.26 ID:???

Accessはインデックスが壊れてしまった場合、[データベースの最適化/修復]を行うと治りますが
SQL Serverにもそういうコマンドがありますか?

31 NAME IS NULL :2018/10/17(水) 14:00:05.95 ID:UxDg84T+

>>30
一旦DROPして再作成すれば?

32 NAME IS NULL :2018/10/17(水) 14:01:02.34 ID:UxDg84T+

41 NAME IS NULL :2018/11/12(月) 13:41:10.82 ID:???

セキュリティがSQLServer自身の認証頼りになるからおススメしない
特定IPのみ接続可とかやるくらいなら素直にVPNにしとけ

42 NAME IS NULL :2018/11/12(月) 13:51:07.65 ID:HPkNogVe

>>41
なぜかあなたのようなことを言ってしまう方が大勢いますが、明確な理由を説明できないでしょう?

43 NAME IS NULL :2018/11/12(月) 13:59:37.37 ID:???

明確な理由も何もフロントの認証より危険なのはちょっと考えればわかるだろ
Webアプリの認証突破されてもまだDBまで到達されない方法はあるが
直でログインされたらもう終わりだ

44 NAME IS NULL :2018/11/12(月) 18:19:04.61 ID:HPkNogVe

>>43
それ単にWebアプリケーションサーバが挟まる構成を取る意味がわかっていないひとの理屈だよ。

58 NAME IS NULL :2018/11/20(火) 10:00:35.83 ID:WY+B3UFR

サーバー再起動したら、夜に2時間で終わってた処理が4時間ちょいかかるようになった
dm_exec_query_statsみてもこれだというのが特定できなかったんで、とりあえず統計情報更新とインデックス再構築かけたけどかわらん
パフォーマンスカウンタとってたんで比較すると
・CPU使用率は2時間ave80%だったのが4時間ave80%に
・ディスクIOはPhysical diskのキューも読み書きバイト数も1秒あたりの数値が半減、IO Latch waitも1秒あたりの待ち時間が半減
・メモリはmax、minで割り当てを固定(物理RAMの8割)、Buffer Managerのデータキャッシュをグラフでみると、2時間の挙動がまんま4時間に引き延ばしたかたちに変わった
・ロック待ちのカウンタみると1秒あたりの平均待ち時間が倍増←たぶんここの原因が問題

考えられること、他にみるべきところあったら教えてほしい
どう推論するか悩み中です

63 NAME IS NULL :2018/11/21(水) 07:42:47.71 ID:Vsi8ZXDt

>>58
OSを再起動したかの、SQL Serverを再起動したのか、どちらなのか?

60 NAME IS NULL :2018/11/20(火) 14:50:56.69 ID:???

リコンパイル指定掛けないと統計反映されないとかいう話なかったっけ
それでロック街増えるかはわからんが

61 NAME IS NULL :2018/11/20(火) 15:36:28.83 ID:WY+B3UFR

>>60
アドホッククエリが多すぎるのかキャッシュが1日保たないのでそれはないです
と、書いて気付いたけどプランが変わったとかは考えにくいな
ほぼ毎日コンパイルされるのは前と変わらんし・・・まじでハード絡みなのか、異常があったら通知されるはずなんだけどな、、

62 NAME IS NULL :2018/11/20(火) 21:30:17.85 ID:???

手動で止めてたサービスが再起動で動いてリソース食ってるとか

WindowsUpdateとかウィルス対策ソフトとかあやしい

64 NAME IS NULL :2018/11/21(水) 08:56:03.13 ID:ypOdLX/M

>>62
サービスの確認はしてないですが、日中は全然負荷かかってないのでリソース喰ってるとかはたぶんないです
メモリはSQLServerに固定で80%分与えてるんで空き10数パーしかないですが(とはいえ10GB前後くらいは空きあり)

>>63
OS再起動です。再起動した部隊に聞いたらOSのパッチ当てたとのこと(OSはWin2012)
そっちの確認が先だった、なに当てたか確認します。

66 NAME IS NULL :2018/12/13(木) 23:09:41.29 ID:ND4c+Iuc

SQL serverのライセンスに関する質問です。

データベースにSQL serverを使用している
業務アプリケーションソフトがあります。

本部のWindows10のパソコンにSQL server を
インストールし、スタンドアロンでアプリを
動*のですが、このパソコンで作成した
データをエクスポートし、支社のパソコンに
インポートして使用します。

支社のパソコンにもSQL serverがインストール
されており、スタンドアロンでアプリを動*
ことが出来ます。

この場合、各パソコンにインストールする
SQL serverは全て無償版で問題ないのでしょうか?
それとも、正規版が必要でしょうか?

正規版が必要な場合、CALは必要でしょうか?

各パソコンはネットワーク接続されていますが、
SQL serverの使用形態は各パソコン個別で、
他のパソコンのデータベースを参照するような
ことはありません。

よろしくお願い致します。

67 NAME IS NULL :2018/12/14(金) 02:45:52.18 ID:xTQ3pUgW

>>66
最新版なら無償版で問題ない
ファイルサイズ10Gの制限だけ気をつけろ

68 NAME IS NULL :2018/12/14(金) 09:17:04.99 ID:DAdCiiEs

>>67
ありがとうございました

74 NAME IS NULL :2018/12/15(土) 17:39:55.29 ID:???

ファイル共有なら20アクセスまでOKなのにな

75 NAME IS NULL :2018/12/15(土) 17:43:22.55 ID:???

>>74
原則ダメじゃなかった?
プリンタとかの接続は許可されてるけど

76 NAME IS NULL :2018/12/15(土) 17:49:49.70 ID:???

>>75
例外的にOK
IISもそう
データベースサーバーはダメ

IIS経由のデータベースとかは知らん

78 NAME IS NULL :2018/12/17(月) 22:34:55.51 ID:Y2xIxlHH

でも小規模な会社でもなけりゃだいたいのところは買ってるんじゃないの
ファイルサーバにしたってCAL不要のWindowsStorageServerじゃスペックきついし
サーバ毎に必要なわけじゃないしユーザ分なりデバイス分なり買うもんじゃないのかな

79 NAME IS NULL :2018/12/18(火) 13:51:13.69 ID:???

>>78
お前は何の話をしてる?

80 NAME IS NULL :2018/12/18(火) 16:27:53.59 ID:w5gk3kps

>>79
すまん
Windows Server CALの話に乗っかったつもりだったがクライアントOSの話だったね

84 NAME IS NULL :2019/01/23(水) 09:05:14.47 ID:uSf5hxNs

・SQL Server Express自体の接続数は無制限
・Windows 7、8、10 OSにインスコの場合、接続数は20まで
・Windows Server OSにインスコの場合、接続数はCALに依存
らしいぞ。

sql server express 接続数 windows10 ググれ

116 NAME IS NULL :2019/03/04(月) 09:33:25.74 ID:???

>>84
ありがとう

87 NAME IS NULL :2019/01/29(火) 11:22:21.77 ID:???

select *
from テープ゛ル
where 日時>getdate()

みたいな感じに getdate() を使ったとき、
1行ごとに(その瞬間の)getdate() と日時が評価されるのか
SQLが走り始める瞬間のgetdate()を得て、その単一の値を使って評価されるのか、どっちでしょうか?

88 NAME IS NULL :2019/01/29(火) 14:05:13.47 ID:???

>>87
後者は保証されてないはずだから前者じゃね

89 NAME IS NULL :2019/01/30(水) 00:04:10.20 ID:VnIK1JFs

>>87
それは動作不明、意図が曖昧だからやらない。あらかじめ日時を取得してから条件値として用いるのが普通。

90 NAME IS NULL :2019/01/30(水) 00:09:14.90 ID:VnIK1JFs

>>87
同じ結果が返り続ける関数を延々と使うのは開発者としてありえない。時間がすぎて変わることを想定しているのかどうかもSQLから読み取れない。

91 NAME IS NULL :2019/01/30(水) 13:45:22.21 ID:???

何万行入ったテーブルに select *,getdate() from table やるとgetdate()の結果は全行同じだから後者と思われ

92 NAME IS NULL :2019/01/30(水) 13:57:21.34 ID:???

>>91
10万行でやったら違うのかもw

95 NAME IS NULL :2019/01/31(木) 15:00:17.41 ID:kxiPGIi/

ただの読み取り一貫性を保つためだと思うけどな。SELECTをし始めた時点と条件の日時が異なったら、結果のデータをみたら一貫性があるのかどうかわからなくなる。

こんなSQLを書くやつはプログラマではない。

96 NAME IS NULL :2019/02/02(土) 23:26:55.83 ID:???

>>95
読み取り一貫性ってどういう意味で使ってるんだ?
その理屈だとたとえばRAND関数で評価してもすべて同じ数値で評価されるのか?

97 NAME IS NULL :2019/02/03(日) 07:01:35.79 ID:VYE2BzFT

>>96
RAND関数そのものが常に同じ値を返す関数だとわかってる?

100 NAME IS NULL :2019/02/03(日) 19:27:12.83 ID:???

んな悪魔の証明やるより無難に1回変数に入れろよw

101 NAME IS NULL :2019/02/04(月) 15:15:47.94 ID:eS3ydgbJ

>>100
ベテランプログラマのなかにもループの中で今日の年月日を取得し続けるやつがいるからなあ。

しかもそれ日次バッチ処理w

103 NAME IS NULL :2019/02/07(木) 22:07:20.34 ID:m3XO0Yy+

カラムストアインデックスの検証したけど、単一の表にアクセスするだけのSQLだと劇的な効果出たけど、複数の表を結合した複雑なクエリには無力だった。これって常識?

105 NAME IS NULL :2019/02/08(金) 23:12:13.40 ID:ozRfEPKl

>>103
全部ひとつのテーブルにまとめてしまえばよいw

106 NAME IS NULL :2019/02/09(土) 01:21:00.30 ID:Wx+/pMSK

>>105
リレーショナルデータベース完全否定やん

107 NAME IS NULL :2019/02/09(土) 01:49:59.75 ID:IrWvKIY/

>>106
皮肉だから

113 NAME IS NULL :2019/02/10(日) 18:34:29.82 ID:???

>>103
ビュー作っても同じだよねきっと

114 NAME IS NULL :2019/02/11(月) 04:33:48.44 ID:XERbxblT

>>113
ただのインデックス付きビューではたいして変わらないだろう。

SQL Serverはマテリアライズドビューが最新版でもないのかな?

そのときの最新の一貫性のとれたデータが必要でないなら、更新がかからない時間にでもコピーを作っておけばよい。

または目的のSQLを更新がかからない時間に実行して結果を取得しておく。

110 NAME IS NULL :2019/02/10(日) 05:03:07.85 ID:NAb/MghI

VPSにSQLServerをインストールして、外部接続可能な設定はしました。(パワーシェルでポート指定で疎通確認済み)
また、SQLServer認証も設定済みです。

@@servernameで取得した名前が db1
VPSのアドレスが1.1.1.1
開放したportが1433
だとして、自宅のPCのSSMSからVPS上のdb1に接続するには、サーバー名にはどのような記入をすれば良いのでしょうか?

111 NAME IS NULL :2019/02/10(日) 17:11:56.88 ID:3nFQ3NJJ

>>110
デフォルトインスタンス(MSSQLSERVER)なら
VPSの外向けグローバルIPだけでOK
VPS側のファイヤーウォールで自宅側ルータのIPに絞っとかないと
アタック受けるから注意しろ

112 NAME IS NULL :2019/02/10(日) 17:48:12.24 ID:???

>>111
無事、接続出来ました。セキュリティの件もアドバイスありがとうございます。

118 NAME IS NULL :2019/03/21(木) 10:20:07.65 ID:???

not exists句とexcept演算子ってほぼ同じものでしょうか?
どちらかがあればもう片方は無くても特に困らないですかね?

119 NAME IS NULL :2019/03/21(木) 12:31:44.60 ID:zHKJlC0U

>>118
求める結果が同じあればまだいいが、2つはまったくの別物。

123 NAME IS NULL :2019/04/19(金) 14:36:17.03 ID:???

SQL Server で SSD 使ってる方おられますか?
書き換え可能回数も随分と伸びたと聞くので、そろそろ大丈夫なのかなぁと。

HDD も併用するんなら、トランザクションだけ HDD に逃がしたほうがいいですかね?

124 NAME IS NULL :2019/04/19(金) 16:03:23.95 ID:omXBRiX9

>>123
SSDの寿命って突然*るのか?
なんにしてもデータ保護考えたら単一ディスクはあり得んし

125 NAME IS NULL :2019/04/20(土) 00:55:57.88 ID:5u+C7Ddr

>>123
なぜ目的を書かないのか?

131 123 :2019/04/23(火) 16:32:56.95 ID:???

>>125
目的は高速化しかないと思いますが・・・
投資の優先順位は
メモリー>ストレージ>CPU だと思ってます。

メモリーマンタンなので、次はストレージをと

126 NAME IS NULL :2019/04/20(土) 19:44:10.44 ID:5u+C7Ddr

>>123 は単にSSDを使ってもよいのかどうかという質問なんだろうね。スマートフォンのストレージがHDDでないことに疑問を持たないのかね?

127 NAME IS NULL :2019/04/20(土) 22:30:41.11 ID:???

スマートフォンはSSDだったのか?
てっきりメモリかと思っていた

128 NAME IS NULL :2019/04/20(土) 22:32:59.90 ID:5u+C7Ddr

>>127
あんたIT技術者か?

133 NAME IS NULL :2019/04/23(火) 17:01:51.96 ID:???

データベース丸ごとキャッシュに乗るべきと思って
96GB まで積み増したのですが、最近はストレージへのアクセスが増えてしまったので。

134 NAME IS NULL :2019/04/23(火) 18:31:02.93 ID:zLlBW4oP

>>133
メモリ上のバッファキャッシュが多ければ、ストレージのIOデータ量も増える。

データ量が大きくなって遅くなっていることをハードウェアでどうにかしようとするのは根本的な解決になっていない。

135 NAME IS NULL :2019/04/23(火) 22:12:52.29 ID:???

データ量が増えてメモリを食うようになった⇒ストレージへの I/O が増えた状態への有効な対処法ってどんなのがあるんだろう。
素人な自分としてはこれは本気で知りたい。

まえに環境の検討をやってたときに、 tempdb を SSD 上に置いたことはあった。
結構かなり速かったよ。本番環境でやっていいかどうかは知らないけど。

136 NAME IS NULL :2019/04/24(水) 12:34:42.09 ID:???

>>135
まずは無駄な検索とか更新をしてないかとか
インデックスがちゃんと効いてるかの確認
あとは物理的に複数のデバイスに分割してI/O処理を分散する
そのとき各デバイスで片寄らないように配置するキーを上手く選ぶとか

138 NAME IS NULL :2019/04/25(木) 22:05:51.41 ID:???

>>136
ああなるほど。
ひとつのストレージの上でなんと*ることしか考えてなかったよ。
参考にします。ありがとう。

139 NAME IS NULL :2019/04/26(金) 04:54:39.91 ID:l8u5/4vh

DB初心者なんですが、質問させてください。

最初のSQL Serverをインストールし、DB・テーブルの作成、レコードの挿入・更新・削除までやってみました。
次にプログラムからSQL Sv.を操作してみようと思い、C#からレコードやテーブルの操作をしてみました。
ここで気づいたのですが、実運用においてプログラムからDBを操作するケースって、基本的にはレコードの操作くらいでしょうか?

というのも、DB・テーブルの作成はシステムを構築する際には技術者がSSMSなどで行いうと思いますが、

プログラムがやることってシステムが稼働する段階になって、
ユーザーの操作に従ってレコードの挿入・更新・削除くらいかなと思いましたので。

DB技術者の先輩方、よろしくお願いいたします m(__)m

140 NAME IS NULL :2019/04/26(金) 06:47:20.35 ID:???

>>139
一時テーブルを作るとか普通にあるけど?
てか、一番多いのは検索だと思うぞ

141 NAME IS NULL :2019/04/26(金) 20:31:59.53 ID:l8u5/4vh

>>140
一時的テーブルってどんなケースでしょうか?

自分がイメージしてるのは↓みたいな感じですが、実際こんな感じでしょうか?

例えば商品を扱う時に
◆登録時
 商品(+カテゴリ)のレコードを追加、
 もしくは既存レコードの数量を更新
◆検索
 SELECT ~ WHERE で商品検索。
 表示されたものを並べ替える時に、上記SELECT分に ORDER BY ~ を追加。

142 NAME IS NULL :2019/05/01(水) 18:56:39.99 ID:769RFL3v

SQL serverをデータベースに使用している業務用アプリを
Windows7+SQL server 2008R2EXPRESSの環境で動かして
いましたが、今回、Windows10+SQL server 2016EXPRESSに
移行したところ、途端にアプリの動きが重くなりました。

いろいろ調べた結果、移行時に、SQL server 2016に2008R2の
データベース完全バックアップを復元した際に互換性レベルを
「2016」にしたことが原因で、これを「2008」に下げるとサクサク
動くようになりました。

そこで質問ですが、SQL server 2016EXPRESSに復元したDBの
互換性レベルを「2008」で動かしても特にリスクはないでしょうか?

そもそも互換性レベルは「2016」で動*方が望ましいのでしょうか?

よろしくお願い致します

143 NAME IS NULL :2019/05/01(水) 19:41:43.69 ID:TltKGa3C

>>142
調べたから見たはずだけど、2016を2008互換で動かしていたら、ただの問題の先送り。

145 NAME IS NULL :2019/05/01(水) 22:13:30.92 ID:iAIhZMl0

>>143
>>144
ありがとうございます
さらにテストをしたら、互換性レベル2014までは正常に動きますが、
2016になった途端、動きが極端に重くなることが分かりました

問題の先送りにしかならないにしても、暫定措置としては、
なるべく互換性レベルは高い方がいいでしょうか?

それとも、2016でなければ、2008でも2014でもさほど変わりませんか?

146 NAME IS NULL :2019/05/01(水) 23:57:26.78 ID:Z1eUgulk

>>145
本当に互換性に問題のある使い方をしているのかどうかを調べるのが基本だよ。

147 NAME IS NULL :2019/05/02(木) 04:23:23.11 ID:rL4gUhau

>>145
便所の落書きに判断を求めるなよ
正攻法なら最新に合わせて改修するだけだし
コストがかけられないなら確実に動作する状態でリプレースを待つだけだろ

144 NAME IS NULL :2019/05/01(水) 20:29:24.14 ID:???

>>142
暫定的にはいいけど、そのままだと次のバージョンアップの時に苦労するぞ

150 NAME IS NULL :2019/05/03(金) 07:56:37.64 ID: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以降において
急に引っかかるようになった感じですね

151 NAME IS NULL :2019/05/03(金) 08:53:54.23 ID:lS9VfNzG

>>150
だから製品の何が変わったのかマイクロソフトの情報を見ているのか?

187 NAME IS NULL :2019/09/20(金) 23:47:02.97 ID:isalmAv1

>>150
リプレース時の互換性レベルの変更は危険。
チューニング済みの SQLほど実行計画ボロボロになる。

160 NAME IS NULL :2019/05/05(日) 13:27:25.13 ID:???

DBでSQL実行が遅くなる以外に何が遅くなるって言うんだ…?

162 NAME IS NULL :2019/05/05(日) 14:09:42.14 ID:???

>>160
可能性は低いだろうけど接続に時間がかかるようになったとかメモリー足りなくてスラッシング起きてるとか

164 NAME IS NULL :2019/05/05(日) 22:59:56.81 ID:EcFZ4uZL

>>160
データベースそのものも考えてくれよw

165 NAME IS NULL :2019/05/06(月) 14:04:27.64 ID:???

>>164
DBの機能が遅い以外何があるってんだよハゲ

166 NAME IS NULL :2019/05/06(月) 22:56:09.24 ID:stsMt92h

>>165
データベースは外部からSQLが発行されなくても、ただ動いているだけでもメモリ上のデータを定期的にファイルに書き込む。余裕があればファイルからデータを読み込む。

いっぱいあるがとにかくデータを失わない、データの整合性がとれなくならないようにする処理等があるんだよ。

167 NAME IS NULL :2019/05/07(火) 18:35:52.13 ID:???

>>166
で?
それはDBの機能じゃねえのか?
大体そんなバックグラウンド処理なんて四六時中走ってねーよこじつけんな

168 NAME IS NULL :2019/05/07(火) 19:43:05.91 ID:ALcLaDvG

>>167
走ってますよ。

169 NAME IS NULL :2019/05/08(水) 16:53:24.61 ID:VbqXritb

Express版でオンラインバックアップ取る技ってないの?

170 NAME IS NULL :2019/05/08(水) 20:01:01.21 ID:8qp+Z1yx

>>169
普通にバックアップとるだけだろ

171 DBかじり始めたオープン系エンジニア :2019/05/09(木) 06:15:57.71 ID:Rd8XFIHD

DBエンジニアの業務ってどんな感じですか?
↓みたいなイメージで合ってます?w

設計時:忙しい。責任重大。
開発中:DBのインストールやテーブルの作成が済めば、トラブルなければ特にやることない。
※開発中はC系のエンジニアなどがPG内にSQL文を書いてあれこれやるのをイメージしてます。
運用時:トラブルなければ特にやることない。

よろしくお願いいたします。

173 NAME IS NULL :2019/05/10(金) 23:34:22.83 ID:kyiAxM67

>>171
インフラ寄りなのか、アプリ寄りなのかでまったく違う。

ただ本来はどちらにも深く関わるのがまっとうなデータベースエンジニア。

175 NAME IS NULL :2019/05/11(土) 03:26:52.97 ID:EnWh/KFP

>>173
そういう区別もあるんすね。ありがとうございます。
ちと調べてみまふ。

174 NAME IS NULL :2019/05/11(土) 00:51:45.46 ID:???

ソフトの応答時間って結構重要なのに後回しにされがちなのね。
最後の最後で死にそうな顔して調整しまくってる DB エンジニアさんて結構ありがちと言うか。。。

176 NAME IS NULL :2019/05/12(日) 01:00:26.24 ID:DtTEN3xu

>>174
開発の上流から下流までチェックし続けないと、クソみたいなDB設計とクソSQLのてんこ盛りで、データ量が多いシステムだと*。

177 NAME IS NULL :2019/06/06(木) 13:16:03.50 ID:XVcXsSEI

メンテナンスプランによる、インデックス再構築、統計の更新、完全バックアップあたりの
処理は毎日やってますか?
毎日やるのはバックアップだけですか?

179 NAME IS NULL :2019/06/15(土) 11:25:06.40 ID:???

>>177
完全バックアップ以外は週一でいいんじゃないの?
もちろん、DBのサイズや用途にもよるけど。たしか、ウィザードはそんな(週一)がデフォルトだったと思う。

うちは完全バックアップを毎日とっている。

178 NAME IS NULL :2019/06/15(土) 11:22:01.07 ID:cf7Yx71E

SSIS使いたいんだけど、SSDTをインストールしないといけない。
これは手持ちのクライアントPCにできないのかな?SSMSみたいに。

インストーラ立ち上げると「SQLServer データベース」が必須になっているよ。

180 NAME IS NULL :2019/06/15(土) 11:28:47.86 ID:BUxyU7ss

>>178
SSISはSQL Serverが必要というよりは、Visual Studioが必要なんだよ。

Visual Studioは入ってるのか?

181 NAME IS NULL :2019/06/15(土) 11:43:43.61 ID:BUxyU7ss

>>178
SQL Serverは伝統的にサーバーソフトウェア、クライアントソフトウェアを作り分けていない。

183 NAME IS NULL :2019/06/15(土) 18:20:20.58 ID:cf7Yx71E

>>180-181
サーバのリソース食うのは避けたいので、クライアントでパッケージ作成したかったの。

慌ててVS2019のCommunityインストールしてSSDT入れたら
要求されたメタファイル操作はサポートされていません。 (0x800707D3)
(涙)

185 NAME IS NULL :2019/07/30(火) 11:24:47.61 ID:???

最近VSCodeでSQL書いてるけどこれすげえいいな
補完もするし複数列にCASTだのISNULLだのつけるとき
マルチカーソルが便利すぎる

SQL発行の結果が帰ってくるのはManagement Studio
のが速いけどVSCodeのが起動速いし
実行計画見るときぐらいしかSSMS使わんくなった

186 NAME IS NULL :2019/07/30(火) 20:04:11.92 ID:???

>>185
拡張はなになに入れてる?

195 NAME IS NULL :2019/11/21(木) 02:11:24.95 ID:cBCqHARp

189ですが、1台のPCにSQL serverと弥生会計いれて、もう一台のPCに弥生会計を入れて、
2個の弥生会計からSQL serverをつつく作りになってるんだけど、
こういう場合て、ネットワークて同一セグメントで使うもの?
弥生会計の取説だと「同一セグメントで」て書いてあるんだが、ためにしもう一台をVPN接続越しで接続してみたり
SQL serverをAWSに置いてみたら激重になったんだが、DBてそういう使い方しないもの?

196 NAME IS NULL :2019/11/21(木) 10:52:04.04 ID:QmN8bdJf

>>195
今時の回線事情考えたら
DBの問題じゃなくアプリの設計の問題の可能性のが高い

200 NAME IS NULL :2019/11/21(木) 16:01:11.96 ID:cBCqHARp

>>196
アプリ設計の問題みたい。
https://yayoi-k.jp/yayoi-network/vpn/
DBを1拠点だけで突く設計みたい。複数拠点の場合はリモートデスクトップだ。

197 NAME IS NULL :2019/11/21(木) 13:01:05.46 ID:???

>>195
実際にできるできないはあなたの会社のセキュリティポリシーによるけど、
vpnで直接連携なんて怖くてやらない

同一セグメントでないとダメかといえばそんな事はない
しかし、FW、L3SWの設定はもちろん必須

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!
目次