Microsoft SQL Server 総合スレ 12

**NAME IS NULL** · 2018/08/19(日) 20:52:17.03

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

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

**NAME IS NULL** · 2018/12/18(火) 16:27:53.59

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

**NAME IS NULL** · 2018/12/19(水) 16:52:40.40

【悔日企業ヘイトバンク】　父は犬、兄は黒人、白戸は白洲、私たちはあのCMを見るたびに侮辱されていた
http://rosie.5ch.net/test/read.cgi/liveplus/1545098183/l50

　Ｉ　Ｔ　業　界　の　Ｂ　Ｔ　Ｓ　問　題　浮　上　！

**NAME IS NULL** · 2018/12/24(月) 00:32:48.07

DECLARE @TABLE TABLE = TABLE01;
SELECT * FROM @TABLE;

みたいなことは出来ないです？
同じ構成のテーブルを条件で切り替えて使えないかなと。

sp_executesql を使って SQL を文字列で合成する方法は知っていますが、正直めんどくさい。。

**NAME IS NULL** · 2018/12/28(金) 17:16:15.43

ままｗｗｗ

http://twicas.x.fc2.com/

**NAME IS NULL** · 2019/01/23(水) 09:05:14.47

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

sql server express 接続数 windows10　ググれ

**NAME IS NULL** · 2019/01/24(木) 21:21:27.41

システムエグゼ
苦情申し立てダイレクト窓口

代表取締役社長酒井博文
h-sakai@system-exe.co.jp

専務取締役大場康次
yohba@system-exe.co.jp
専務取締役後藤清孝
kgotou@system-exe.co.jp

取締役藤林隆司
rfujiba@system-exe.co.jp
rfujiba2@system-exe.co.jp
取締役荻野弘昭
h-ogino@system-exe.co.jp
取締役新船幸広
arafune@system-exe.co.jp
arafune_PJ@system-exe.co.jp

監査役白銀亨
sirokane@system-exe.co.jp

**NAME IS NULL** · 2019/01/28(月) 05:18:49.81

LDHから新発売の「EXSUPPLI BLOCK」「EXSUPPLI PARTY」ゼビオ・ヴィクトリアの全店舗で11月29日（木）発売開始！

**NAME IS NULL** · 2019/01/29(火) 11:22:21.77

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

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

**NAME IS NULL** · 2019/01/29(火) 14:05:13.47

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

**NAME IS NULL** · 2019/01/30(水) 00:04:10.20

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

**NAME IS NULL** · 2019/01/30(水) 00:09:14.90

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

**NAME IS NULL** · 2019/01/30(水) 13:45:22.21

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

**NAME IS NULL** · 2019/01/30(水) 13:57:21.34

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

**NAME IS NULL** · 2019/01/30(水) 15:10:50.14

一応1300万行超のテーブルで確認したけどgetdate()の結果は全行同一でしたw

**NAME IS NULL** · 2019/01/31(木) 01:57:55.73

getdateは非決定的関数のはずだが、実行計画次第で１回しか評価されてないのかも

**NAME IS NULL** · 2019/01/31(木) 15:00:17.41

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

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

**NAME IS NULL** · 2019/02/02(土) 23:26:55.83

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

**NAME IS NULL** · 2019/02/03(日) 07:01:35.79

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

**NAME IS NULL** · 2019/02/03(日) 17:39:28.72

RANDは評価するたびに違う値を返す
select RAND(),RAND() とかやればあきらか
GETDATEも同じ値を返すとは限らない非決定的関数

ただ手元で試した範囲では、>>91のようなSQLだとComputeScalarの実行回数が1回になる
つまり、関数が１回しか評価されていないから、同じ値なのは当然

これは保障された動作じゃないはずだから、それらの関数が同じ値を使う保証はないと思うが

ないとは言えないはずだが、実際に複数回評価される状況があるかどうかわからんな
パーティション分割されたテーブルとかでパラで評価されるような状況だと違う結果にならないか誰か実験してみれくれ

**NAME IS NULL** · 2019/02/03(日) 19:21:46.44

乱数表の値が順番に返るだけ。

**NAME IS NULL** · 2019/02/03(日) 19:27:12.83

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

**NAME IS NULL** · 2019/02/04(月) 15:15:47.94

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

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

**NAME IS NULL** · 2019/02/04(月) 18:59:45.28

そりゃベテランにもアホはいるだろ
たいてい淘汰されるんだけどお前ん所が生き残れる環境だっただけ

**NAME IS NULL** · 2019/02/07(木) 22:07:20.34

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

**NAME IS NULL** · 2019/02/07(木) 22:42:59.22

列から表に戻す操作が入るからまあ当たり前だな

**NAME IS NULL** · 2019/02/08(金) 23:12:13.40

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

**NAME IS NULL** · 2019/02/09(土) 01:21:00.30

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

**NAME IS NULL** · 2019/02/09(土) 01:49:59.75

>>106
皮肉だから

**NAME IS NULL** · 2019/02/09(土) 07:59:02.61

リレーショナルデータベース

**NAME IS NULL** · 2019/02/09(土) 13:53:06.86

実際縦集計速くするための仕組みだから
そういうテーブル設計が正解でしょ
必要な項目が全て存在する集計用データマート

**NAME IS NULL** · 2019/02/10(日) 05:03:07.85

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

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

**NAME IS NULL** · 2019/02/10(日) 17:11:56.88

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

**NAME IS NULL** · 2019/02/10(日) 17:48:12.24

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

**NAME IS NULL** · 2019/02/10(日) 18:34:29.82

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

**NAME IS NULL** · 2019/02/11(月) 04:33:48.44

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

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

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

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

**NAME IS NULL** · 2019/02/20(水) 11:53:44.29

いったん対象範囲を#テーブルに切り出して、それにインデックス張って・・・ってのは時々やる

**NAME IS NULL** · 2019/03/04(月) 09:33:25.74

>>84
ありがとう

**NAME IS NULL** · 2019/03/15(金) 09:07:22.82

ツイッターやネットでテクノロジー犯罪と検索して、まじでやばいことを四代目澄田会の幹部がやってる（アメリカではMKウルトラ計画）
被害者に対して暴力団以外にタゲそらしをしてるがやってるのは暴力団で普段外に出ることが少ないため遊びで公共の電波と同じような電波を使って殺人をしてる
統失はほとんどが作られた病気で実際は電波によって音声送信や思考盗聴ができることが最近明らかになりつつある
警察や病院では病気としてマニュアル化されてしまっているのが現状で被害者は泣き寝入りしてる
被害者がリアルタイムで多い現状を知って、被害者間でしか本当の事だと認知できていない
実際にできると思われていない事だから、ただの幻聴ではない実際に頭の中で会話ができる
できないことだと思われているからこそ真面目に被害を訴えてる
海外でも周知されつつあることを知ってほしい。
このままだとどんどん被害が広がる一方

#テクノロジー犯罪
#四代目澄田会
#拡散希望

[参考]
https://black.ap.teacup.com/yamisiougn01/6.html
https://tekunoroji-hanzaihigai.jimdo.com
https://blogs.yahoo.co.jp/patentcom
https://twitter.com/celesty_cs 👀
Rock54: Caution(BBR-MD5:f70dfdc711a7c6ae6accccb939f27fbf)
https://twitter.com/5chan_nel (5ch newer account)

**NAME IS NULL** · 2019/03/21(木) 10:20:07.65

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

**NAME IS NULL** · 2019/03/21(木) 12:31:44.60

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

**NAME IS NULL** · 2019/03/29(金) 11:48:07.44

「ユーザー定義データ型」ってのがあると思うんですが、
そいつを含んだものを C# 側から ExecuteReader() とかで SELECT 取得したとき
各列のユーザー定義データ型を調べる手段ないでしょうか。

CREATE TYPE [dbo].[JAN13] FROM [char](13) NOT NULL

みたいにして、この列を含んだ行を SELECT したとき
char[13] じゃなくて [dbo].[JAN13] という定義名を得たいのです。

**NAME IS NULL** · 2019/04/05(金) 09:42:17.48

同じバージョン間でバックアップ、復元を行っていますが
何故かバックアップを作成した時点ではなく少し前の状態で復元されてしまいます
フルバックアップしたものと聞いているので最新の状態で復元されるものと考えていますが
バックアップの取り方に問題があるのでしょうか？
ちなみに復元する側はDBを一旦削除してから復元しています

**NAME IS NULL** · 2019/04/05(金) 17:53:14.62

自己解決しました

復元の際にタイムラインでバックアップポイントを最新に指定していなかったことが原因でした
デフォルトで最新になるものだと思い込んでいました

**NAME IS NULL** · 2019/04/19(金) 14:36:17.03

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

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

**NAME IS NULL** · 2019/04/19(金) 16:03:23.95

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

**NAME IS NULL** · 2019/04/20(土) 00:55:57.88

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

**NAME IS NULL** · 2019/04/20(土) 19:44:10.44

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

**NAME IS NULL** · 2019/04/20(土) 22:30:41.11

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

**NAME IS NULL** · 2019/04/20(土) 22:32:59.90

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

**NAME IS NULL** · 2019/04/21(日) 15:50:33.08

コンシューマー向けのTLC/QLCを使うなんてことがなければいいんじゃないかとは思うが
3DXpoint高いお…

**123** · 2019/04/23(火) 16:31:41.28

ここの住人では実績なさそうですね

**123** · 2019/04/23(火) 16:32:56.95

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

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

**NAME IS NULL** · 2019/04/23(火) 16:52:14.50

やはり素人か。

**NAME IS NULL** · 2019/04/23(火) 17:01:51.96

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

**NAME IS NULL** · 2019/04/23(火) 18:31:02.93

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

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

**NAME IS NULL** · 2019/04/23(火) 22:12:52.29

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

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

**NAME IS NULL** · 2019/04/24(水) 12:34:42.09

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

**NAME IS NULL** · 2019/04/24(水) 18:00:35.24

データが増え続けても性能問題は起こらないという発想がおかしい。

性能問題が発生してSSDにするというのは、その場しのぎでしかない。

**NAME IS NULL** · 2019/04/25(木) 22:05:51.41

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

**NAME IS NULL** · 2019/04/26(金) 04:54:39.91

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

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

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

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

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

**NAME IS NULL** · 2019/04/26(金) 06:47:20.35

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

**NAME IS NULL** · 2019/04/26(金) 20:31:59.53

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

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

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

**NAME IS NULL** · 2019/05/01(水) 18:56:39.99

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

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

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

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

よろしくお願い致します

**NAME IS NULL** · 2019/05/01(水) 19:41:43.69

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

**NAME IS NULL** · 2019/05/01(水) 20:29:24.14

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

**NAME IS NULL** · 2019/05/01(水) 22:13:30.92

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

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

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

**NAME IS NULL** · 2019/05/01(水) 23:57:26.78

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

**NAME IS NULL** · 2019/05/02(木) 04:23:23.11

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

**NAME IS NULL** · 2019/05/02(木) 20:31:31.39

そもそもそれホントに互換性レベルの問題なのか？
2016出てだいぶ立つから、メジャーな問題ならもっと話題になってると思うが

**NAME IS NULL** · 2019/05/02(木) 22:09:13.65

実行プランに影響するから>>142の環境だけで発生するとかもあり得る

**NAME IS NULL** · 2019/05/03(金) 07:56:37.64

その後、同じ業務用アプリケーションで、以下のような環境移行を行い、
サーバ：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以降において
急に引っかかるようになった感じですね

**NAME IS NULL** · 2019/05/03(金) 08:53:54.23

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

**NAME IS NULL** · 2019/05/03(金) 09:11:40.19

切り分けもしないような奴はスルーしてくださいな

**NAME IS NULL** · 2019/05/03(金) 10:15:30.90

切り分け？？？

**NAME IS NULL** · 2019/05/03(金) 12:04:10.91

どこのSQLで遅くなってるかとかの確認もしてないんだろ？

**NAME IS NULL** · 2019/05/03(金) 23:55:03.93

例えばどんなＳＱＬがどのくらい遅くなったのか、そのときの実行計画は同じなのかぐらいは調べてさらせよ

**NAME IS NULL** · 2019/05/04(土) 12:14:50.42

GW中に仕事のことは考えたくないなｗ

**NAME IS NULL** · 2019/05/04(土) 16:41:00.90

確か遅いSQL一発で出せるやり方あったよな
事前にフラグ立てなきゃいけなかった気もするが

**NAME IS NULL** · 2019/05/05(日) 01:15:20.04

言っておくが彼はSQLが遅くなったとは一度も書いていない。

**NAME IS NULL** · 2019/05/05(日) 07:50:24.90

そもそも何も書いてないから切り分けろって言われてるんだが…

**NAME IS NULL** · 2019/05/05(日) 13:27:25.13

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

**NAME IS NULL** · 2019/05/05(日) 13:49:54.90

バックアップとか?

**NAME IS NULL** · 2019/05/05(日) 14:09:42.14

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

**NAME IS NULL** · 2019/05/05(日) 16:11:54.87

まあまずはなにがどう遅いか調べんと話にならん

あとはリストアしてからなにしたかだな
ほんとに互換性レベルだけで遅くなるとは思いにくい

**NAME IS NULL** · 2019/05/05(日) 22:59:56.81

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

**NAME IS NULL** · 2019/05/06(月) 14:04:27.64

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

**NAME IS NULL** · 2019/05/06(月) 22:56:09.24

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

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

**NAME IS NULL** · 2019/05/07(火) 18:35:52.13

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

**NAME IS NULL** · 2019/05/07(火) 19:43:05.91

>>167
走ってますよ。

**NAME IS NULL** · 2019/05/08(水) 16:53:24.61

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

**NAME IS NULL** · 2019/05/08(水) 20:01:01.21

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

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

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

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

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

**NAME IS NULL** · 2019/05/09(木) 14:48:34.81

会社によってやり方が違うよ

**NAME IS NULL** · 2019/05/10(金) 23:34:22.83

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

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

**NAME IS NULL** · 2019/05/11(土) 00:51:45.46

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

**NAME IS NULL** · 2019/05/11(土) 03:26:52.97

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

**NAME IS NULL** · 2019/05/12(日) 01:00:26.24

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

**NAME IS NULL** · 2019/06/06(木) 13:16:03.50

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

**NAME IS NULL** · 2019/06/15(土) 11:22:01.07

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

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

**NAME IS NULL** · 2019/06/15(土) 11:25:06.40

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

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