「できるかな？」とふと思ったのでチャレンジしてみた阿呆な事。
仮想化環境上に仮想化環境の構築。
全くもって意味はないのだけど、やってみました。今回は Windows Server 2008 R2 with Hyper-V 環境に、Hyper-V Server 2008 R2 を導入。結果はご覧の通り、特に問題なくインストールは行えています。ただ一つ問題があって、ゲスト OS のHyper-V Server 側からはネットワークを認識できていないんだよね。ひょっとしたらゲスト OS として Windows 2008 とか R2 で Hyper-V を構築すると話は変わるのかもしれないけど、そこまではさすがに試していません。
これを踏まえると
「完全に分離した Hyper-V 環境」
を構築したいのであれば・・・と思ったけど、内部ネットワークとして設定すれば普通に同じことができるので本当に意味がなかったｗ
忘れないようにメモメモ。
SQL Server を利用していて大量にデータを削除しサイズを圧縮しようとした場合、単純に削除を行っても小さくならないケースがある。
その場合、プライマリキーを再編成（または再構築）を行うことによってデフラグっぽい事が行われて、未使用領域として設定されるのでその後に圧縮を行うことによりようやくサイズを縮小できる。
消しただけでは圧縮できないケースがある、てのを覚えておかないとねー。
イメージとして単純モデル＝ログを使わないという感覚だったので、間違いを忘れないためのメモ。
実際に作業としてやってみたのが次のような内容。
「データ量が多くなってきたので余分なデータを削除する」
今回は全体として6000万件ほどためこんでいるテーブルから削除を行おうと思ったので、まずは1000万件ほどDELETEしてみる事に。そうするとログファイルが徐々に徐々に大きくなっていくのが目に見えたｗ
削除が終わってからしばらくしてもldfファイルのサイズが大きくなったままだったので、恐らくの動作はこのような感じだろうか？
「単純モデルでもldfにログを記載する。ただしどこかのタイミングで自動的に切り捨て処理が行われる」
今回は時間があまりなかったので自動的に～という部分は確認できていないけど、これであれば単純モデルでldfはそうそう肥大しない、という状態にはなるのかなぁ、などと思ってみた。
とりあえず、単純モデルだろうと完全モデルだろうとたくさん処理するときはldfやディスクの空き容量は注意しておきなさいよ、という事で・・・。
＠ＩＴにて書かせてもらっているエンジニアライフのコラム。6/10にて公開された同タイトルのコラムの原文です。比較してもらえると、どのような点に注意しどのような方向性に持っていけばよいか、編集の方々と色々考えたというのが見えるかと思います。
Oracle社が恐らくは2007年８月頃から始めている都市伝説キャンペーンというのがあります。「間違った認識や古い認識を改めたい」という思いで始められたと思われるこのキャンペーンですが、ある時期を境に対抗商品に対するネガティブキャンペーン的な内容が増えてきているようにも思えます。
最近シーズン３という形で新しい連載が始まっていますが、その内容については残念ながら好ましいとは言えない記載が見受けられる、悪く言えばゴシップ誌的なものへと強化されている様子です。
私は業務としてOracleもSQL Server も利用していますので、ある程度双方のメリットデメリットも、レベルは低いにしても理解しているつもりです。そのようなポジションである私が見ても、明らかに誤っている記述が見受けられたり、意図的にイメージ操作を行っている箇所が見受けられたのは、非常に残念でなりません。
最も残念なのは、この都市伝説シリーズで扱われている内容、その殆どがデータベース製品の性能に関わる部分ではなく、それを設計しているシステムエンジニアやソフトウェア企業のレベルが原因だと思える点です。穿った見方かも知れませんが、更新処理でテーブルレベルのロックが長時間にわたり行われているような事は、どう考えてもデータベース製品が原因ではなくそれを利用しているシステム側の問題です。簡潔に言えば「レベルの低いエンジニアや企業が作成したシステム」であるから発生している現象です。このような企業が作成したのであれば、Oracleを利用したところで同じ現象がほぼ間違いなく発生してしまうでしょう。
更に穿った見方をすれば、「あの」データベース製品を利用するシステム会社にはその程度のエンジニアしかいない、という見方にすら成り得ます。さすがにそこまでの意識はないと信じたい所ですが。
個人的に比較広告的手法を用いたセールス・マーケティングを否定するつもりはありません。ですが、そうであるならば「正しいデータ」に基づいた「正しい情報」を記載した上で行ってほしいと思います。誤った情報を基にしたコマーシャルというのは、開発者としてもユーザーとしても何の利益もありません。
「PowerPivotではダーティリードを利用できない」は素人が見てもわかる程の誤りです。またOracleでのUNDOセグメント、SQL ServerでのREAD_COMMITED_SNAPSHOTオプション利用時のtempdbは似ている挙動だ、という事をご存じの方も多いでしょう。公のデータとしてREAD_COMMITED_SNAPSHOTオプション利用時のレスポンスについては見あたりませんでしたが、このあたりも適切にハードウェア構成を設計されているのであれば「使えない」レベルではないと思われます。
またロックがかかりすぎている事が問題としていたとしても、適切な記載がされているとは思えません。SQL Server にて多く叫ばれている「ロックエスカレーション」が原因だとしても、2005以降では結構調整することが可能になり、その方法もMSDN等で公開されています。
コストパフォーマンスについてTPC-Cベンチマークの結果を用いている点はイメージ操作と思える内容です。TPC-Cベンチマークは極大構成における処理性能を測る為のベンチーマークですので、この結果だけを用いて「Oracleが早い」と言い切ることはできないのは、技術者であれば当然の事かと思います。
むしろ普段関わるような規模であればTPC-Cベンチマークの結果等とは無縁でしょう。レスポンスがあがらない原因の大半は、テーブル設計やハードウェア構成、またはアプリケーションからのSQLが原因だというのも、殆どの方はご存じだと思います。同じ設計でデータベース製品を変更したらレスポンスが向上した、等という話は殆ど聞かないのではないでしょうか。
少々不思議に思えるのはOracleにて勤められている方々は、この都市伝説シリーズを見てどのように感じられているのでしょう。このコーナーは間もなく３年を迎えようとしている事を考えると、何かしら意見を抱えている方の数は少ないのでしょうか。それとも社内で声をあげても届かないような状況なのでしょうか。
実際に掲載された内容と比較すると、原文ではかなりOracleに対する攻撃的な箇所が見えていると思います。一番考えたのはこの部分でして、できるだけ直接的な攻撃を行うのではなく、こういった噂話が多いけど惑わされるなよ！、という方向で書くことが有益なのではないか、というのが編集者さんと私との間で決めた方向性でした。
実際には私も「その通りだ」という認識でして、変に攻撃するよりも騙されないようにという周知の方が、私も含めた技術者にとって一番有益なのだろうと思います。
UNLHA32.dllの作者であるmicco氏が発表している内容。
非常にわかりやすく問題点を記述してあるので是非一度目を通しておいてほしい。
ただ。
結構企業や団体、というか業界内部にlzh形式の圧縮は入り込んでしまっているので、そう簡単に切り替えるのは無理だろうな。自分が関わっている流通系では、当然のようにlzh形式でのEDIデータ送受信が行われているし。
これがJX手順に切り替われば・・・lzhから卒業できるんだけどねぇ。
使われるようになるのは早くても、JCAプロトコル撤廃に向けて動き出す再来年くらいからかな。
色々あってBPOSパートナー企業登録しようと思ったので調べていると、携帯（ iMode とか ezWeb とか）からアクセスというのでちょっとわからなくなったのでメモ。
一般的な携帯からアクセスできる事は恐らくBPOSをユーザーに話すにあたって、確実に出てくる話題なのでちょっと押さえておきたかったのだけど、残念ながらスクリーンショットなどの類はなし。ただ、Exchange Online 自体が通常のブラウザアクセスに対応（Outlook Web Access → Outlook Web App に名称変更）しているので、これを利用するか外部ソリューションを利用するかという流れになる。
Outlook Web Access 自体はアクセス用のアドレスが公開されているのでそこにアクセスする形なのかな？
