コンテンツデータベース内のサイトコレクション数っていくつが良いの?
偉い人教えて~~~
個人的な意見ですが、どんなに詰め込んでもよいのでは?と思ってます。
とはいえ、100GBを超えないようにするのが良いようです。
100GBに近づいてきたら Move-SPSiteで一部のサイトコレクションを別のコンテンツデータベースに移動させることをお勧めします。
もし、一つのサイトコレクションのサイズが100GBを超えそうな状態なら、それ以上サイズが増えないように、何かを頑張ってください。
URLが変わってもよいという協力的なユーザーに恵まれているなら、Export-SPWeb, Import-SPWebでサブサイトを別のサイトコレクションにコピーして、サイズを減らしましょう。
とりあえず、運用中は1対1がベストだし、バージョンアップ時は、コンテンツデータベースが少ないほうが楽。だと思う。
オンプレミスSharePoint Serverのバージョンアップに備える2
データベース接続方式って素晴らしいよ。
SharePointのサイトコレクションはコンテンツデータベースに保存されていて、サーバー構成情報とは分離しているので、このサイトコレクションで新バージョンや検証サーバーしたいと思ったら、該当のコンテンツデータベースのバックアップを作成し、新環境のデータベースにリカバリして接続すれば、サーバー名が異なっても問題なく動作する。
サーバー名が異なるのでリンク切れとか発生する場合もあるけど、普通に動作する。
サイトコレクションの変更はすべてコンテンツデータベースに保存されるので、やり直したいときも、コンテンツデータベースを差し替えるだけでよい。
いろいろ試したいなぁと思ったときにすぐできるのが非常に良い。
気軽にいろいろできるデータベース接続方式だけど、ちょっと考えないといけない点がある。
SharePointのサイトコレクションはコンテンツデータベースに保存されていて、サーバー構成情報とは分離しているので、このサイトコレクションで新バージョンや検証サーバーしたいと思ったら、該当のコンテンツデータベースのバックアップを作成し、新環境のデータベースにリカバリして接続すれば、サーバー名が異なっても問題なく動作する。
サーバー名が異なるのでリンク切れとか発生する場合もあるけど、普通に動作する。
サイトコレクションの変更はすべてコンテンツデータベースに保存されるので、やり直したいときも、コンテンツデータベースを差し替えるだけでよい。
いろいろ試したいなぁと思ったときにすぐできるのが非常に良い。
(ノーツなら掲示板の設計とコンテンツが分離されていて、デザイン変更も安心だぜ!!なんて思っている人にとっては物足りないけどね~)
気軽にいろいろできるデータベース接続方式だけど、ちょっと考えないといけない点がある。
- 1つのサイトコレクションは、複数のコンテンツデータベースにまたいで保存することはできない。
- 一つのコンテンツデータベースには、複数のサイトコレクションを含むことができる。
運用中はあまり気にしなくてもいいんだけど、データベース接続方式って言葉を聞く段階では大きな問題になってることもあるから注意が必要。
例えば、一つのサイトコレクションの作業をしたいのに、1000個のサイトコレクションが同じ一つのコンテンツデータベースに保存されているとき。
別のサーバーで使うにはコンテンツデータベースのコピーを使うので、一つしかいらないのに不要な999個のサイトコレクションもおまけについてくるんだ。
データベースを接続する際には、チェックとかアップグレード処理が動くので、999個分の無駄な処理が動き、当然待ち時間も増えてしまう。
だから、一つのコンテンツデータベースには一つのサイトコレクションが無駄がなくてよいよね。
でも、全部バージョンアップするときは、1000個のコンテンツデータベースのバックアップを取って、接続してって処理が必要になるので、多すぎるのも面倒。1個のコンテンツデータベースのほうが接続時の処理が1度に終わるので、実質こっちのほうが時間は短いのかな?どうなんだろうね。
オンプレミスSharePoint Serverのバージョンアップに備える1
もう経験した?いまだに2007使ってる?
準備は大変だし、待ち時間ながいし、停止時間長いと怒られるし・・・
私はWSS3.0から使い始めて、今は2016だよ。
うん、頑張った。
WSS3.0から2016にバージョンアップした際は、なんて無茶するんだろう?なんて思ったし、スキップしちゃだめだとかその時は思ったけど、結局2010から2016に2013スキップしちゃう自分がいる。実は2019まで行っちゃおうか?なんて本気で考えていたけどね。(さすがにMicrosoft Docsで日本語翻訳されていないタイミングは早すぎると)
正直に言うと2013は運用したことない。あれは2016への通過点だから動けばよかった・・・2010から2013にバージョンアップして何が変わるか細かくは知らないんだよね・・・通過点だからどうでもよかったし~
SharePointのバージョンアップってテータベース接続方式だから、スキップしたとしてもそんなに難易度が上がるってことはなくて、単純に作業量が一気に来るだけなんだよね~
WSS3.0からだと、コンテンツデータベースをSharePoint2010に接続して切断、つぎに2013に接続して切断、さらに2016に接続するだけで作業が終わる。途中のバージョンに合わせて修正する必要がないのでトータル的には作業量は少なく済む。複雑なことしてなければほんと簡単なんだよなぁ~
はっきりいって、メンテナンス中のコンテンツ更新禁止時間に文句が出なければバージョンアップしない理由なんてない。
作業を始めたら終わるまでコンテンツ更新できないんだよね~
だから、とりあえず、テスト環境でバージョンアップ時間を計って、許容範囲か確認したらよいと思うよ。
準備は大変だし、待ち時間ながいし、停止時間長いと怒られるし・・・
私はWSS3.0から使い始めて、今は2016だよ。
うん、頑張った。
WSS3.0から2016にバージョンアップした際は、なんて無茶するんだろう?なんて思ったし、スキップしちゃだめだとかその時は思ったけど、結局2010から2016に2013スキップしちゃう自分がいる。実は2019まで行っちゃおうか?なんて本気で考えていたけどね。(さすがにMicrosoft Docsで日本語翻訳されていないタイミングは早すぎると)
正直に言うと2013は運用したことない。あれは2016への通過点だから動けばよかった・・・2010から2013にバージョンアップして何が変わるか細かくは知らないんだよね・・・通過点だからどうでもよかったし~
SharePointのバージョンアップってテータベース接続方式だから、スキップしたとしてもそんなに難易度が上がるってことはなくて、単純に作業量が一気に来るだけなんだよね~
WSS3.0からだと、コンテンツデータベースをSharePoint2010に接続して切断、つぎに2013に接続して切断、さらに2016に接続するだけで作業が終わる。途中のバージョンに合わせて修正する必要がないのでトータル的には作業量は少なく済む。複雑なことしてなければほんと簡単なんだよなぁ~
はっきりいって、メンテナンス中のコンテンツ更新禁止時間に文句が出なければバージョンアップしない理由なんてない。
作業を始めたら終わるまでコンテンツ更新できないんだよね~
だから、とりあえず、テスト環境でバージョンアップ時間を計って、許容範囲か確認したらよいと思うよ。
仮想ホスト管理で困ること
容量固定で作ればよいのでは?
はい、そうですね、ブルジョアいねっ!!
使った分だけしか占有しないよ!!っていう容量可変VHDさんは礼儀をわきまえ謙虚で素晴らしいです。
ついでに重複除去も動かしましょうかね。
相席大歓迎!!みんなで幸せになろうよ!!
ストレージの仮想化って素晴らしい!!譲り合いの精神、相席、共有、ほんとお前は謙虚でいいやつだ。
って思ってるんですけどね~~
どうせ使わないから物理領域より大きな容量可変VHD作ってもいいよね~
って、はじめは問題なく始めるし、それで結構何年も運用できるんですよ。
物理容量が足らなくなるまでは・・・
仮想化ってホント、トラブルが発生しなければすごく便利。
トラブル出てても、VMには普通に動いているってことも多いし。
リソース不足以外は・・・
リソースについて考え始めると、ほんと答えがなくて困る。
計画的に増強すればいいじゃない?、はいはい、ブルジョアされ!!
リソース不足することには保守契約も更新できない時期に近いんですよ。
保守契約できないサーバーに新品追加してどうすんの。
保守契約できないサーバーに新品追加してどうすんの。
リソース不足は困るけど、できるだけ利用効率は高めたい。
利用効率高めたいから仮想化してるんだよねぇ~
簡単なんだけど難しい重複除去
アプリケーションの対応可否を気にせずストレージの圧縮ができ、メリットの多い重複除去は、本当に素晴らしい技術です。
ファイル単位の圧縮と異なり、同じファイルが複数保存されているとき、1つのファイル分の容量しか消費しません。ファイル名は異なるけど、同じデータが存在する場合も同じく、一つ分のデータにまとめられるので、ファイル共有サーバーなどでは非常に大きな効果が期待できます。
ただ、いくつか注意が必要です。
1.非対応のアプリケーションが存在する。
冒頭にアプリケーションの対応可否をきにせずと言っておきながら何言っての?って感じですが、アプリケーションのデータを重複除去するとうまくアクセスできない経験がありました。可否を気にせずというのは、HYPER-Vの仮想ディスク保存領域を重複除去するって意味です。こうすれば、VM内では重複除去を意識しない状態になります。
2.急激な大容量保存や編集には対応できない。
空き領域が十分にあれば問題ないし、リアルタイム重複除去機能を持ったH/Wでは問題ありません。Windows標準の重複除去などは、バックグラウンド処理を行うので、重複除去処理されるまでは、そのままのデータが記録されるため、一時的には無圧縮で保存できる領域が必要です。
3.空き領域と使用領域がよくわからない
重複除去を行ったボリュームは、重複除去処理が動くと空き領域が変化します。
データ量を積み上げていくとディスクの容量を超えていることもあります。
もういっぱいだ~と思っても次の日には余裕があるなんてこともあります。
4.ファイルを削除しても空き領域が増えない
重複除去はファイル単位ではなく、データレベルの重複除去を行っているため、100GBのファイルを削除したとしても、そのうち70GBが重複除去領域に保管されていれば、30GBしか解放されません。では、70GBはいつ解放されるのか?というと、ガベージコレクション処理によって、未使用ということが確認された後に解放されるため、ファイルを消しても、消しても、空き領域が全く増えないと感じます。
上の注意点を理解していれば、ほぼ問題なく運用できます。
でも、空き領域が少なくなった時に、ディスク増設できない場合、非常に苦しむことになります。4で上げた空き領域がすぐに増えない問題です。
しかも、利用者からみると、どのファイルが重複除去されていないのか分からないため、頑張って削除や退避したファイルがほぼ重複除去されていて、一所懸命頑張って作業したのに全く空き領域が増えないってこともよくあります。
設備増強に時間がかかるしコストにうるさいって方は、はっきり言って使わないほうが よい技術かもしれません。
10TBのNASで運用していて、容量が不足したので10TBのNASを買い足すことはなんとかできても、20TBのNASを買うのは絶対に無理って方は、10TBのNASに15TBのデータが保管されていると、10TB追加した直後に空き領域5TBになって、「なんでこんなに増えるの?お前たち無駄遣いしすぎ!!二度と買わないぞ!!」なんて言われかねません。
重複していること前提の圧縮方法なので起こりえるのです。
でもさ、一度この圧縮を見てしまうと、使いたくなってしまうんですよね~
ファイル単位の圧縮と異なり、同じファイルが複数保存されているとき、1つのファイル分の容量しか消費しません。ファイル名は異なるけど、同じデータが存在する場合も同じく、一つ分のデータにまとめられるので、ファイル共有サーバーなどでは非常に大きな効果が期待できます。
ただ、いくつか注意が必要です。
1.非対応のアプリケーションが存在する。
冒頭にアプリケーションの対応可否をきにせずと言っておきながら何言っての?って感じですが、アプリケーションのデータを重複除去するとうまくアクセスできない経験がありました。可否を気にせずというのは、HYPER-Vの仮想ディスク保存領域を重複除去するって意味です。こうすれば、VM内では重複除去を意識しない状態になります。
2.急激な大容量保存や編集には対応できない。
空き領域が十分にあれば問題ないし、リアルタイム重複除去機能を持ったH/Wでは問題ありません。Windows標準の重複除去などは、バックグラウンド処理を行うので、重複除去処理されるまでは、そのままのデータが記録されるため、一時的には無圧縮で保存できる領域が必要です。
3.空き領域と使用領域がよくわからない
重複除去を行ったボリュームは、重複除去処理が動くと空き領域が変化します。
データ量を積み上げていくとディスクの容量を超えていることもあります。
もういっぱいだ~と思っても次の日には余裕があるなんてこともあります。
4.ファイルを削除しても空き領域が増えない
重複除去はファイル単位ではなく、データレベルの重複除去を行っているため、100GBのファイルを削除したとしても、そのうち70GBが重複除去領域に保管されていれば、30GBしか解放されません。では、70GBはいつ解放されるのか?というと、ガベージコレクション処理によって、未使用ということが確認された後に解放されるため、ファイルを消しても、消しても、空き領域が全く増えないと感じます。
上の注意点を理解していれば、ほぼ問題なく運用できます。
でも、空き領域が少なくなった時に、ディスク増設できない場合、非常に苦しむことになります。4で上げた空き領域がすぐに増えない問題です。
しかも、利用者からみると、どのファイルが重複除去されていないのか分からないため、頑張って削除や退避したファイルがほぼ重複除去されていて、一所懸命頑張って作業したのに全く空き領域が増えないってこともよくあります。
設備増強に時間がかかるしコストにうるさいって方は、はっきり言って使わないほうが よい技術かもしれません。
10TBのNASで運用していて、容量が不足したので10TBのNASを買い足すことはなんとかできても、20TBのNASを買うのは絶対に無理って方は、10TBのNASに15TBのデータが保管されていると、10TB追加した直後に空き領域5TBになって、「なんでこんなに増えるの?お前たち無駄遣いしすぎ!!二度と買わないぞ!!」なんて言われかねません。
重複していること前提の圧縮方法なので起こりえるのです。
でもさ、一度この圧縮を見てしまうと、使いたくなってしまうんですよね~
盲目的に見れば安く手に入る
私はOCNモバイルOne音声対応SIM。
パートナーはNTT docomo。
私が機種変をするときは安売りでもない限り定価だ。
エントリーモデルのASUS Zenfone Live(L1)ですら16,000円は必要。
格安SIMの欠点は機種編の際に大きな支出を感じてしまうことです。
トータルのランニングjコストを考慮すると支出は確実に抑えられているはずなんですけどね、機種変では2万円以上をほぼ一括支払いする必要があり、日ごろ2000円程度しか払っていないのですごく目立つんですよね。
そこで考え付いた答えが、パートナーに機種変させて、御下がりをもらう。
誰が使っているのか、使用状況が不明な中古品よりも安心安全。
入手元も利用期間も完ぺきに把握しているのでほんと安心だ。
この度の機種変ではiPhone XR 64GBを選択したわけで、実質負担は35,000円程度なので、
私はiPhone6s 64GBを、パートナーはiPhone XR 64GBの2台を手に入れたと言える。
そして、支払いは無利息24回払いなので、月額負担は1,500円程度となる。
2台機種変するのに1台当たり月額700円なのだ。
安いのだ。
ASUS Zenfone2 LaserからiPhone6sに変えた私は処理能力向上と最新OSによる最高のセキュリティーを手に入れたのである。
しかし、あれだ・・・OS変更はなかなかのストレスである。
パートナーはNTT docomo。
私が機種変をするときは安売りでもない限り定価だ。
エントリーモデルのASUS Zenfone Live(L1)ですら16,000円は必要。
格安SIMの欠点は機種編の際に大きな支出を感じてしまうことです。
トータルのランニングjコストを考慮すると支出は確実に抑えられているはずなんですけどね、機種変では2万円以上をほぼ一括支払いする必要があり、日ごろ2000円程度しか払っていないのですごく目立つんですよね。
そこで考え付いた答えが、パートナーに機種変させて、御下がりをもらう。
誰が使っているのか、使用状況が不明な中古品よりも安心安全。
入手元も利用期間も完ぺきに把握しているのでほんと安心だ。
この度の機種変ではiPhone XR 64GBを選択したわけで、実質負担は35,000円程度なので、
私はiPhone6s 64GBを、パートナーはiPhone XR 64GBの2台を手に入れたと言える。
そして、支払いは無利息24回払いなので、月額負担は1,500円程度となる。
2台機種変するのに1台当たり月額700円なのだ。
安いのだ。
ASUS Zenfone2 LaserからiPhone6sに変えた私は処理能力向上と最新OSによる最高のセキュリティーを手に入れたのである。
しかし、あれだ・・・OS変更はなかなかのストレスである。
3000円で売ったけど、手元には990円
先日買っていただいた3000円の品物の経費を支払うと990円になったって話。
販売手数料 10%(300円)
らくらくメルカリ便 1,500円
振込手数料 210円
残り 990円(出品発送に伴う労務費含む)
どう受け取るかは自由だけど、結構コスト高な取引だなぁ~と。
まぁ、どの方法をとっても似たようなもんですけどね。
粗大ごみが990円に化けて、買った相手は市場価格より安く手に入る。
Win, Winな関係でしかも、メルカリ、ヤマト運輸、銀行にもお金が回る素晴らしい仕組みですね。
そして、なぜ現金化を忘れて没収されるのかがわかりました。
10,000円以下の振込だと210円の手数料が発生する。
出品した合計価格が1万円を超えていれば、1万円まで保留して
210円を浮かせようと考えますよね。
でも、思ったように売れないので時間だけが過ぎていく。
よく考えてある仕組みです。
210円をけちると0円になるのです。
ケチは損です。
販売手数料 10%(300円)
らくらくメルカリ便 1,500円
振込手数料 210円
残り 990円(出品発送に伴う労務費含む)
どう受け取るかは自由だけど、結構コスト高な取引だなぁ~と。
まぁ、どの方法をとっても似たようなもんですけどね。
粗大ごみが990円に化けて、買った相手は市場価格より安く手に入る。
Win, Winな関係でしかも、メルカリ、ヤマト運輸、銀行にもお金が回る素晴らしい仕組みですね。
そして、なぜ現金化を忘れて没収されるのかがわかりました。
10,000円以下の振込だと210円の手数料が発生する。
出品した合計価格が1万円を超えていれば、1万円まで保留して
210円を浮かせようと考えますよね。
でも、思ったように売れないので時間だけが過ぎていく。
よく考えてある仕組みです。
210円をけちると0円になるのです。
ケチは損です。
登録:
投稿 (Atom)
SharePoint アイテム保管ライブラリをのぞいてみよう(2025年12月改訂)
※2025年コンテンツ検索等の機能がリニューアルされましたので修正しました。 ※2023年アカウント移行に失敗し画像を失ったので再度取得し改訂しました。 Office 365 Advent Calendar 2021 の12月16日投稿です。 警告: 個人的な理解に基づく内容、...