＠IT：Databaseフォーラム全記事インデックス オラクルパーティショニングDatabaseフォーラムに掲載されている全記事にアクセスできるインデックスです。また、＠ITの各フォーラムにあるデータベース関連記事も掲載しています。インデックスは記事の追加とともに拡充していきます。
おら! オラ! Oracle｜技術情報｜株式会社インサイトテクノロジー
メールマガジン登録/解除 このメールマガジンを購読ご希望の方、または購読の解除をご希望の方は、会員制『Club Insight』へのご入会、既会員の方はログイン後「会員情報の編集」にて購読および解除できます。 ※Club Insightへは下記からご登録もしくはログインください。 バックナンバー
キャッシュの大きいRDB vs インメモリデータベース、性能がどれだけ違うのか調べてみると
2週間ほど前に「インメモリデータベースがクラウド時代の主流になるという期待」というエントリを書きました。ハードディスクに代わり、メモリをデータベースの永続化手段とするインメモリデータベースは、超高速なアクセスとスケールアウトを実現する、クラウド時代のデータベースの主役になるのではないか、という内容です。 この記事に関して、TechVisorの栗原さんと次のようなやりとりをしました。 確かに、Oracle Real Application Cluster（以下、Oracle RAC）でデータベースが全部載るくらい十分にキャッシュ用のメモリを割り当てれば、メモリ上でデータベースを操作するインメモリデータベースと同じことではないのか、とも思います。 両者の違いは何かあるのでしょうか？ 調べてみることにしました。 インメモリデータベースは1000倍速い 調べてみるとすぐに、両者には明確な性能差があ
SQL ServerとOracleの一番大きな違い：ベンチャー社長で技術者で：エンジニアライフ
株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 ぶっちゃけて、SQL Serverも、Oracleも、フリーのPostgreSQLも、RDBMSとしての本質的な性能差は本当に小さい。そのためRDBMSのベンダーを選択するのは、バックアップとか、レプリケーションとか、クラスタリングなどの機能や関連ツールのできと、IDEとの相性などを検討するのが良いでしょう。 しかし、一般的にあまり検討の対象になってない部分が、実は一番大きな違いだったりします。わたしは、SQL ServerとOracleの差で、もっとも大きいのはストアドプログラム（プロシージャ・ファンクション）の書き方（構文）の違いだと思います。 単純なロジックはOracleの方が書きやすい。SQL ServerのIfなどのステートメントブロックにBEGIN
Oracle の B*Tree インデックスの内部構造についてお勉強中（その１）
お仕事のデータベース一式のリース切れ間近ということで、リース延長で耐えることができるのか、それともシステム更改が必要なのかを見極めるため、最近はデータベース周りのチューニングばかりやってます。 当初設計時に、５年間持つ設計をしたのですが、流石に５年目にもなると予定とはそれなりに乖離が発生するものです。テーブル＆インデックス設計をユーザ向けの処理をとにかく高速に処理できるように設計したので、ユーザ向けの処理は速度的に全然大丈夫なのですが、データの肥大化によるバッチ処理のパフォーマンス劣化が顕著です。単純にストレージと CPU パワーが足りていないのでしょう。 しかしながらチューニングの余地はまだまだ十分にありそうです。バッチ向けの最適化を図ることにしました。うまくいけば来年度どころか、後数年はリース延長で延命できるかもしれません。 今回実施したチューニングの１つのポイントとして、バッチ処理向
Oracleデータベースの深層（３）−BBEDでデータファイルをハッキング - /* Grid Thinking */
今回利用するサンプルデータは最初からサンプルスキーマとして インストールしたHRスキーマのJOBSテーブルです。 ご覧の通り１９件データが存在する。 sys@O11G2> select * from hr.jobs; JOB_ID JOB_TITLE MIN_SALARY MAX_SALARY ---------- ----------------------------------- ---------- ---------- AD_PRES President 20080 40000 AD_VP Administration Vice President 15000 30000 AD_ASST Administration Assistant 3000 6000 FI_MGR Finance Manager 8200 16000 FI_ACCOUNT Accountant 4200 9
[速報]サンの27年間の歴史にさよなら。SPARC、Java、MySQLはオラクルが引き継ぐ。米Oracle OpenWorld基調講演 － Publickey
[速報]サンの27年間の歴史にさよなら。SPARC、Java、MySQLはオラクルが引き継ぐ。米Oracle OpenWorld基調講演 サンフランシスコで開催されている米オラクルのOracle OpenWorld 2009。初日となる10月11日（日本時間10月12日午前）に行われた基調講演には、サン・マイクロシステムズ会長 スコット・マクニーリ氏が登場。1982年に創業された同社の27年間の歴史を振り返るシーンで幕が開けました。ライブストリーミング配信された内容を基に紹介します。 マクニーリ氏は、「オラクルカラーに近い色に合わせてきたんだ」と、赤い服で登場。サン・マイクロシステムズは27年間イノベーションを続けてきたと、まもなくオラクルによる買収が完了する見通しの同社の歴史をやや感傷的に振り返ります。リストの1番にあがったのは、最初のオープンソースとなったNFS。
Oracle
日本のオラクル・コミュニティが一堂に会するプレミア・イベントにぜひご参加ください。新しいスキルを身に付け、業界エキスパートと交流し、複雑なビジネス課題を解決するためのソリューションを発見しましょう。
『[Oracle] UNDO表領域の必要容量見積もり方法』
UNDO表領域に必要な容量は以下の公式で見積もることができます。 UNDO表領域必要容量(byte) = UNDO保存期間(秒) × 1秒あたりUNDOブロック生成数 × ブロックサイズ ＋ オーバーヘッド(byte) 例えば、UNDO保存期間が900秒で、1秒あたりのUNDOブロック生成数が100で、ブロックサイズが8192バイトの場合、 900×100×8192＝737280000 つまり約703MB＋オーバーヘッドということになります。 この計算に必要な情報はV$UNDOSTATまたはDBA_HIST_UNDOSTATから得ることができます。 これらのビューにはUNDO統計情報が10分ごとに記録されています。 SQL> SELECT TO_CHAR(BEGIN_TIME,'MM/DD HH24:MI') AS BEGIN_TIME, TO_CHAR(END_TIME, 'MM/DD
![『[Oracle] UNDO表領域の必要容量見積もり方法』](https://cdn-ak-scissors.b.st-hatena.com/image/square/ed239427f781d723ae5cf65616a522073f68d378/height=288;version=1;width=512/https%3A%2F%2Fstat.profile.ameba.jp%2Fprofile_images%2F31%2Farchive-redo-blog%2F1180840362506.jpg)
UNDOに関する検証 その５ - InsightTechnology 旧ブログ
＜UNDOに関する検証その５＞ ペンネーム：クレイジーボーダー 前回は、UNDO表領域を変更する際の注意点を説明した。 さて、今回はUNDO情報を保存するのに必要な領域の算出方法からその問題点、 また逆に、ディスクのサイズ制限があるなどのUNDO領域割当てにおいて、仕様 要求がある時の保存期間の指定や問題について検証していきたい。 UNDO領域の必要なサイズを算出する前に、実際にファイルのサイズ制限のため に使用できる領域がない場合、どのようにUNDO表領域が動作するのか試してみ る。もちろん、この際はUNDO_RETENTIONの値は関係ない。 UNDO領域を作成する際に、AUTO EXTEND属性を含めず、ファイルのサイズを小 さめに作成する。その後、UNDO領域を使うような処理（インポート）を行なっ た。 ＜インポート結果一部抜粋＞ . importing TPC's objects
OTN Japan - Oracle9i 物理設計：第2部 表領域の設計
OracleDirectではインターネットと電話を利用した自席で受講できるセミナー、iSeminarを定期的に実施しております。iSeminarの内容は主に製品の紹介や、製品の有効な利用法の解説などです。2003年9月には本連載の3回目、4回目の内容を先取りしたiSeminarを実施する予定ですので、奮ってご参加ください。 表領域分割・配置の際の観点 データベースは複数の表領域で構成されます。表領域の分割を検討する際には、主に３つの観点があります。 管理性 耐障害性 パフォーマンス 次項以降でこれらの各観点について解説します。 管理性の観点 データベース管理を容易にするために、以下列挙する点に留意してください。 断片化などパフォーマンスの問題が発生しにくくなる ディスクの追加など表領域の再編成に伴う工数が削減できる 管理者にとってわかりやすい 等のメリットが得られます。 （1）システム表領
実践 !! Statspack 解析 Tips (Oracle Direct)
日本のオラクル・コミュニティが一堂に会するプレミア・イベントにぜひご参加ください。新しいスキルを身に付け、業界エキスパートと交流し、複雑なビジネス課題を解決するためのソリューションを発見しましょう。
「Linux-DBシステム構築／運用入門」がすごい - あなたのシステム、ガラパゴス化していませんか？ - kazuhoのメモ置き場
松信さんがやってくれました。 ずいぶん前からデータベースの「正しい」構築と運用方法についてまとめた本はないかなーと思ってました。自分はこれまで、様々なネットワークアプリケーションのプログラミングやデータベースの設計、チューニングを行ってきています*1が、問題が解決できたようには見えても、果たしてそれが最適な解決策だったのか不安に感じることがありました。それは、体系的な知識に欠けているからです。だから、網羅的な教科書がほしいなぁって思ってたんです。 とあるインターネットでこの前、松信さんから「いま書いてる」って話を聞いて、一部を見せていただいたりしたんですが、つい昨日、手元に届きました。やったね☆ 名前は「Linux-DBシステム構築／運用入門」。「入門」と銘打たれているものの、基礎的な知識から、なぜそうなるのか、どう応用すればいいのか、といった点まで広くカバーしている*2、全方位的な隙のな
門外不出のOracle現場ワザ 第１章
皆さんの中にも、このような説明を見た方が多いかもしれません。特にチューニング経験が豊富な方は、この説は大体正しいと感じると思います。私の感覚では10回中7回か8回程度正しいのではないでしょうか。 しかし、この説を信じてチューニングしても、思うように効果を得られなかったケースがあるはずです。 まず誤解を解いておきたいのは、「待機イベント＝“悪”」という図式です。待機イベントはある状態を示しているに過ぎません。そして、待機イベントはアプリケーションまで含めた、システムのアーキテクチャの観点から捉えるべきものです。 詳しい理由については後述します。ここは“急がば回れ”で、基礎知識を再確認するためにも、アーキテクチャの説明から始めます。 なお、本稿では、一時的な性能悪化を調査する方法など、ほかの書籍や記事では紹介されていないノウハウの解説を多くしました。また、内容をノウハウの紹介に集中して
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Insight Technology, Inc. - メールマガジン＆書籍
http://www.oracle.com/technology/global/jp/pub/jp/db_magazine/mongai/chapter1_3.html
http://www.oracle.com/technology/global/jp/pub/jp/articles/db_structuring/index.html