備忘録

確かに開けなかったので、ネットで見つけたよしぶろっIP: Visual Studio .NETでWebプロジェクトが開けなくなってしまうを参考にして、とりあえずプロジェクトファイルの中身を

ProjectType = "Local"
↓
ProjectType = "Web"
に変更したら開けた。ありがとうございます、よっしぃさん。

どういうことなのか、ちょっと詳細を確認しないと・・・
読む予定↓
[HOWTO] ローカル Web サーバー ASP.NET アプリケーションの作成方法
ローカル プロジェクトと Web プロジェクト

これもAsk Tomに出ていた記事。
/*+ APPEND */は、
insert /*+ APPEND */ into tab_a values .....では無効で
insert /*+ APPEND */ into tab_a SELECT ....でのみ有効。

Ask Tom "NOLOGGING AND REDOSIZE"

ここです。まだリンクしただけで実際にはインストールしてませんが。
ウェブデザイナーのための16のFirefoxのアドオン | コリス

あと、firefoxとは別件ですが、こんなのも。
第11回　PCサイトとこんなに違う！携帯サイトのフォーム設計ポイントとは | Web担当者Forum

こんな感じ。

INSERT /*+ APPEND */ INTO tab_a
SELECT * FROM tab_b

んー、速い！
こちらの環境で、600万件（平均レコード長が105バイト）ほどのテーブルのインサートで2分程度でした（通常の場合は測る気がしないほどかかります）。

注意）アーカイブログモードの場合、tab_aがNOLOGGING属性で作成されていないと、LOGGINGモードでダイレクト・ロード・インサートされます

・ダイレクトロードインサートのメリット、デメリット メリット： 通常のINSERT文とは違い、バッファキャッシュを使用しないで、ダイレクトにデータファイルへの書き込みを行うため、INSERTにかかる時間が短縮される。
パラレル度を設定している場合には、書き込み処理が並列に動作し、さらに、INSERTにかかる時間が短縮される。
デメリット：
　（１）表に対する排他ロックが取られるため、INSERTが終了するまでは、他のトランザクションによるINSERT/UPDATE/DELETE文は同時に実行できない。
　（２）非パーティション表に対するダイレクトロードインサートでは、そのテーブルの既存の空き領域にINSERTするのではなく、そのテーブルのHigh Water Markより先に新しく領域を割り当ててINSERTする。
　　(新しく割り当てた領域はINSERT中はテンポラリセグメントと呼ばれ、INSERT終了後に既存のテーブルにマージされる)。そのため、通常のINSERT文より多くの領域を使うことがある。
　→新規に作成したばかりのテーブルにのみ使ったほうがよいですね。

思うに、ダイレクト・ロード・インサートは、新規にテーブルを作成したタイミング（つまりデータが０件で、どのブロックもまだ使われた事のない状態）で実行するのが、一番ふさわしいでしょうね。

使い始めのときはちょい心配しましたが、たとえばテーブルを作成するときにNOLOGGING属性を指定したとして、
・NOLOGGINGを指定したCREATE TABLEの処理自体はロギングされない（正確には最低限のログのみ書かれる）
・NOLOGGING属性を指定したテーブルに対して、通常のupdate/insertを行った場合、普通どおりロギングされる（REDOログは普通どおり発生する）
・ただし、NOLOGGING属性を指定して作成されたテーブルは、メディアリカバリを行うために必要なログ情報を（たとえCREATE以後のDMLに対してはロギングしていても、一番最初のCREATE処理については）記録していないので、データファイルを戻して復旧するようなケースの場合、エラーとなる
　→ただし、エラーになるのはこのテーブルのみ。他のテーブルは復旧できる
・NOLOGGING属性を指定したテーブルに、ダイレクト・ロード・インサートを実行した場合、そのインサート処理はロギングされない（正確には最低限のREDOログのみ発生する）
　→LOGGING属性だと、普通にREDOが発生する。利点はバッファをバイパスするってことだけとなる
・INDEXに対するNOLOGGING指定は、INDEXに対するDDL文において有効となる。ある表に対してダイレクト・ロードインサート等が実行され、その表に設定されているINDEXがNOLOGGING指定であっても、INDEX操作に関するREDOは生成されるそうな

なので、NOLOGGING属性を指定する場合は、読み取り専用テーブルとか、一日一回バッチでデータがイチから再作成されるようなテーブルとかに限定するのが妥当だと思います。

バッファ・キャッシュ関連のラッチにはこんなのがあるそうです。

cache buffers chains
....................

アクセスしたいブロックがバッファ・キャッシュ上に存在するかどうかを確認する
際に必要とするラッチです。
競合の発生はバッファ・キャッシュのサイズにも影響を受けますが、特定のブロック
へのアクセスが集中すると、そのブロックのバッファを保護しているラッチに対する
負荷が高くなります。

cache buffers lru chain
.......................

バッファ・キャッシュに新しいブロックをディスクから読み込むために再利用可能な
バッファを探す場合や、DBWRプロセスが古くなったダーティ・バッファを書き出そうと
する場合に必要とするラッチです。
Oracle8iまでのバージョンでは、db_block_lru_latchesパラメータを調整すること
によってこのラッチでの競合をチューニングできますが、Oracle9iではこのパラメータ
は廃止されています。

- ログ・バッファ関連

redo allocation
...............

redoログ・バッファにredoエントリを書き込むための領域確保を行う場合に必要とする
ラッチです。
NOLOGGINGオペレーションを活用することによって競合を回避することができます。

redo copy
.........

redo allocationラッチのもとで確保したログ・バッファ領域に実際にredoエントリを
書き込む場合に必要とするラッチです。
CPU数に合わせて自動的に適切な数のラッチが確保されます。

- 共有プール関連

row cache objects
.................

ディクショナリ・キャッシュにアクセスする場合に必要とするラッチです。
競合を低減するには、SHARED_POOL_SIZEパラメータを調整して下さい。

library ｃache
..............

ライブラリ・キャッシュへのアクセスを直列化するためのラッチです。
SQL文やPL/SQLブロック、ストアド・ファンクション等が実行される度に、
このラッチを必要とします。
競合を低減するには、バインド変数の使用やSQL記法の統一によって、できるだけ
ライブラリ・キャッシュ上の情報を共有できるようにします。

shared pool
...........

共有プール内でのメモリ割り当てで必要とするラッチです。
library cacheラッチと同様にSQLのチューニングを行った上で、必要に応じて
SHARED_POOL_SIZEパラメータの調整を行います。

あぁ、確かにそういうやり方がありますね。

何度も色の設定を行う必要のある人向け↓
カラーパレットを“出しっぱなし”にして，文字色の指定を効率良く行う：ITpro

Vol.14　メディアよ、「私」を発見できるか？：NBonline(日経ビジネス オンライン)

Business Media 誠：ロサンゼルスMBA留学日記：あえて言う「新聞に未来はない」

DBサーバーのRAIDをどれにすればよいのかと言うことで

選択肢としてあげられるタイプは

1. RAID0+1(RAID01)：ストライプドミラー
2. RAID1+0(RAID10)：ミラードストライプ
3. RAID5
4. RAID50（RAID5+0）
5. RAID6
6. RAID60（RAID6+0）

推奨順位はこんな感じでしょうか。
　　RAID1+0 > (RAID0+1) > RAID50 > RAID5 > RAID6
　　※多分、今はRAID0+1はなくて主にRAID1+0でしょうね。サイトによっては一緒にしてたり別に分けたりしてましたが

昔から教科書的回答としてよく言われているのがRAID5は避けたほうがいいとうことでした。
ただし、
・費用対効果
・選択したアレイ装置の機能（RAID5やRAID6以外ダメってのもありますし、メーカー推奨の設定があったりします）
により、RAID5/RAID6を選択するということも当然ありえます（昔は、PCサーバーだと通常RAID5が選択されていたわけだし）。
ギガバイトを超えるキャッシュをつみ、ライトバックで書き込みを行うなど、RAID5特有の書込時ペナルティーを軽減させているので神経質なまでにRAID5とその系統を避けるという必要はなくなっていると言えるでしょう。
※ただし、あくまでRAID5/RAID6はハードウェアRAIDで実装することが前提ですが

RAID - Wikipedia
AOL Q&A広場 RAID 1+0とRAID 0+1の違いについて
RAID Level
sanonosa　システム管理コラム集: RAID0+1とRAID1+0の違い
特集 ： RAIDの基礎知識－RAIDレベルを理解しよう－
RAID01とRAID10の違い：佐野裕のサーバ管理者日記：ITpro
DiskとRAIDの知識： RAID10こそ最良のRAIDポリシー
仕様詳細：RAIDとは？

これもリモートのテーブルと表結合したSQLを実行したときに発生した問題。とりあえずバグとのことで以下の回避方法があるとのこと。

セッションレベル：
  - 該当セッションに event 10176 を設定する
     alter session set events '10176 trace name context forever, level 1';

インスタンスレベル
  - 初期化パラメータファイルに以下のパラメータを設定後、
    データベースを再起動

     event="10176 trace name context forever, level 1"

一旦エラーがでてしまうと、SHEARED POOL上のキャッシュをクリアしないと、上記イベントの指定をしてもエラーが出てしまう。

Ask Tom "Difference between DB_NAME and Instance_..."
Tom Kyteの回答によると、

A database is a set of files (data, redo, ctl and so on)

An instance is a set of processes (SMON, PMON, DBWR, etc) and a shared memory segment 
(SGA).


A database may be mounted and opened by many INSTANCES (Parallel Server) concurrently.

An instance may mount and open ANY database -- however it may only open a single database 
at any time.

Therefore -- you need a unique database name (for the sets of files).  The db_name is 
burned into these files.  thats how it knows.

と言うようにDB NAME(db_name、database name)とINSTANCE NAME(instance_name)の違いを語り、さらに

A sid is "sort of" the same as the instance name -- if you:

$ echo $ORACLE_SID
ora8i

ops$tkyte@ORA8I.WORLD> select instance_name from v$instance;

INSTANCE_NAME
----------------
ora8i


you'll see them as the same. I would go a step further -- the combination of:

o ORACLE_HOME plus
o ORACLE_SID plus
o HOSTNAME 

identifies the instance (i can have two instances in different homes on a single machine with the 
same sid). 

と、SIDとinstance_nameの違いを語っている。

纏めると、

• databaseは、各種ファイルの集合体。database名はそのファイルセットにつけられた名前
• instanceは、SGAとオラクルのプロセスの集合体。instance名は、そのプロセスセットにつけられた名前
• instance > ORACLE_SID。instanceは、ホストマシン・ORACLE_HOME・ORACLE_SIDによって識別される

データベースリンクを経由してリモートテーブルにアクセスするSQLを実行すると発生するエラーの一つ。

BugNo. 4257473 障害内容:ORA-920 can occur for SQL over a database link
　→10.1.0.5のPSRで解消

データベースリンク経由のテーブルへアクセスするSQLを実行した際、Oracleのほうで適当にSQLを変更してLNNVL()という関数を使用して実行するようにしてしまうケースがある（多分、WHERE句にOR条件とかいろいろ組み合わせるとそうなるのかも）。そして、そのLNNVL()関数でバインド変数が利用されるように変更されてると、このエラーが起こるそうな。
→tkprofでみると、自分が実行したSQLがどのように変換されたかがわかる

パッチ以外の回避方法は
・リモートのテーブルをローカルに持ってくる
・driving_site ヒント（/*+ driving_site(<リモート表>) */ ）を利用する
　　このヒントを使うと、ローカル表の検索結果をリモートに渡し、表結合をリモートで実行させその結果を受け取るようにできるらしい

select /*+ driving_site(b) */ a.deptno  from (select deptno from emp@dblink where empno<9000) b, dept a
where b.deptno = a.deptno and a.deptno < 30 ;

↓上記SQLがこんなふうになるそうな

select /*+ driving_site(b) */ a.deptno from emp@dblink b, dept a
where b.deptno = a.deptno and a.deptno < 30 and b.empno < 9000;

だけど、バインド変数が使われてると無効らしい。

話はWindows Server 2003にのみ限定。

すごくアバウトに話をまとめると
（１）Windows OS自体4GBまでしか物理メモリを認識しない
　　・実態は4GBよりももっと小さいらしいけど
　　・PAEを使うと、４ＧＢ以上の物理メモリを認識できるようになる
（２）Windows上で動く個々のプロセスは４ＧＢまで使える／最大４ＧＢ割り当てられる
　　・これも２ＧＢ、/3GB or /4GTオプションを使えば3GBまで使えるようになる

詳細な議論としては↓
なんでもＦＡＱ

/PAEを使っても、個々のプロセスが４ＧＢ以上つかえるわけではないとうことは以下のページに書かれている↓
The 4GB Windows Memory Limit: What does it really mean? - From BrianMadden.com

で、（１）で４ＧＢ以上の物理メモリを認識できることのメリットは、より多くのプロセスを実メモリ上に乗っけておく事ができるってことでしょうかね（ページングやスワッピングを減らすことにある？）。

・朝臣と宿禰
　　吾妻鏡に引用されていた公文書にｘｘ宿禰ｘｘ、ｘｘ朝臣ｘｘというふうに名前が書いてあったので
　　関連して、八色の姓（やくさのかばね）、真人（まひと）

・日本国王、日本国主、大君
　　これは、新井白石の「折りたく柴の記」に書いてあった件
　　関連して、「日本国王」改修事件（柳川一件）、大君一件
・マチュピチュ
　　「インカ帝国地誌」にはでてなかったもんで、なぜかなと。