OSTL

テーブル一覧の確認方法

SELECT * FROM tab

SQL> desc tab
名前 NULL? 型
----------------------------------------- -------- ---------------
TNAME NOT NULL VARCHAR2(30)
TABTYPE VARCHAR2(7)
CLUSTERID NUMBER

SELECT * FROM TAB WHERE TNAME LIKE 'XX%'

該当表領域に存在するテーブル確認

要確認しておく。
select * from tabs とすると多すぎる。

DBA_TABLESによる確認(要SYSDBA権限)

SELECT TABLE_NAME,STATUS FROM DBA_TABLES
WHERE TABLESPACE_NAME='TABLE_SPACE_NAME'

手っ取り早く容量を稼ぐというかWINDOWSで言うところのデフラグみたいなものらしい。

　Oracle10Gからの機能。
効果が薄いといわれているけどやらないよりはましだろう。ただその際大幅な
I/Oが持ってかれるので業務時間に実施するのは危険。
誤ってEMから即時実行してしまってえらい遅くなった、、、単純なミスとはいえ、
すみませんではすまないこともある。

特徴
メリット
ONLINEにしながら操作可能(行単位のロックになる。)
ALTER TABLE MOVE とは異なりダウンタイムがない。
容量がいらない。 ALTER TABLE MOVEと比べて。
INDEXの再構築がいらない。 ALTER TABLE MOVEと比べて。
デメリット
行移行とかの完全解決ではないらしい。
停止できるならALTER TABLE MOVEの方がHighWaterMarkを下げられるので効果が高い。

INDEXはshrink spaceのみ
ALTER INDEX "OWNER_NAME"."INDEX_NAME" SHRINK SPACE

TABLE
ALTER TABLE "OWNER_NAME"."TABLE_NAME" ENABLE ROW MOVEMENT;
行の移動処理を可能にする。
ALTER TABLE "OWNER_NAME"."TABLE_NAME" SHRINK SPACE;

ちょっと調べてみた。
10G R2からはLOBも対象になったそう。
ALTER TABLE "OWNER_NAME"."TABLE_NAME" SHRINK SPACE CASCADE;
とすると関連する索引も処理してもらえるらしい。

当然ながらアーカイブログモードなのにアーカイブを消さないとエラーがでる。
そのときにならないように定期的にバックアップとかとるべきだけど

忘れたときのメモ

ASM空き容量の確認
SELECT name,total_mb,free_mb,ROUND((free_mb/total_mb)*100,2) "FREE(%)"
FROM V$ASM_DISKGROUP;

アーカイブファイルサイズ確認
SELECT group_number ,SUM(space)/1024/1024 "ASM(MB)"
FROM V$ASM_FILE
WHERE type='ARCHVIELOG'
GROUP BY group_number

まだメモ
アーカイブログが多くなりすぎてバックアップとれなーいというときにRMANにて実行する。
というか起きたらだめだろう、、、　とほほ
アーカイブログモードだとたまりすぎるとDBが停止する。

rman target / nocatalog

七日前までを削除
delete archivelog until time 'sysdate-7';
(RMANで実行)

全削除
delete archivelog all ;
(RMANで実行)

アーカイブログのスレッド番号がわかっている場合
delete archivelog until sequence 100 thread 2;

スレット番号の確認する場合
list backup of archivelog all;
(RMANで実行)
参考　制御ファイルの番号を確認する。
SQL> select thread#,sequence#,name from v$archived_log order by thread#
,sequence#

さらに困った場合
rmで消しちゃった場合
change archivelog all crosscheck;

データベース全体でやめる場合とはじめる場合
（９までは停止が必要だったようだ。　確認中）
alter system archive log stop;
alter system archive log start;

日付指定で削除する。
RMAN> delete archivelog until time 'sysdate-7';

チャネル: ORA_DISK_1がリリースされました
チャネル: ORA_DISK_1が割り当てられました
チャネルORA_DISK_1: SID=490 インスタンス=oracle devtype=DISK

アーカイブ・ログ・コピーのリスト
Key Thrd Seq S Low時間 Name
------- ---- ------- - -------- ----
1148 1 765 A 07-01-23 +DG2/oracle/1_765_600370988.dbf
ずらずらずら、、、、、、
1228 2 381 A 07-01-27 +DG2/oracle/2_381_600370988.dbf

このオブジェクトを削除しますか(YESまたはNOを入力してください)。 yes
アーカイブ・ログを削除しました
アーカイブ・ログ・ファイル名=+DG2/oracle/1_765_600370988.dbf レコードID=1148 スタンプ=612619531
アーカイブ・ログを削除しました
アーカイブ・ログ・ファイル名=+DG2/oracle/1_766_600370988.dbf レコードID=1149 スタンプ=612630137
アーカイブ・ログを削除しました
---ずらずらずら----------------
81オブジェクトを削除しました

容量を増加させる場合
ALTER DATABASE DATAFILE '+DiskGroupName/SID/datafile/tbs.XXXXXXX'
RESIZE 4096M

追加の場合はデータファイル領域を指定し
ALTER TABLESPACE "TABLESPACE_NAME" ADD DATAFILE '+DiskGroupName' SIZE 2048M

データファイル領域の確認の仕方

ちなみに
サイズ指定はGとかKとか使える。ディスクストレージの管理者権限が必要。

ORACLEデータベースリンクの作成

ALTER TABLESPACE "EMPLOY" ADD DATAFILE '+DG1' SIZE 2048M

CREATE TEMPORARY TABLESPACE "EMPLOY_TMP" TEMPFILE'+DG1' SIZE 512M;

ユーザの作成から
CREATE USER EMPOLYER
IDENTIFIED BY XXXXXXX
DEFAULT TABLESPACE EMPLOY
TEMPORARY TABLESPACE EMPLOY_TMP
QUOTA 1024 ON EMPLOY ACCOUNT UNLOCK;

チェック
SELECT * FROM USER_USERS;

GRANT EXECUTE ,CREATE ANY SYNONYM,CREATE ANY SNAPSHOT ON EMPLOY TO EMPLOYER ;

接続設定データベースリンクを張る側で定義する。
tnsnames.ora の設定

ORAC10L =
(DESCRIPTION =
(ADDRESS =
(PROTOCOL = TCP)
(HOST = 192.168.0.200)
(PORT = 1521)
)
(CONNECT_DATA = (SID = ORAC10)
)
)

データベースリンクの作成
(誰でつなぐか、つながれるマスター側のユーザ、パスワードが必要)

CREATE DATABASE LINK ORAC10
CONNETC TO IDENTIFIED BY USING 'tns:ORAC10L';

マスターテーブルなどの更新がない場合のリードによる負荷分散用
スナップショットの作成（１日おきのスナップショット更新）

CREATE SNAPSHOT TABLE_NAME
REFRESH COMPLETE START WITH sysdate NEXT sysdate+1
AS SELECT * FROM TABLE_NAME@DB_LINK_NAME

更新がある場合、（アクセスしやすいようにシノニムを設定）

CREATE SYNONYM TABLE_NAME FOR USER_NAME. TABLE_NAME@DB_LINK_NAME

更新があってかつ、差分が多い場合は別に記載する。

オラクルRACにおけるインターコネクト障害に関して　メモ書き

オラクルのバックグラウンドネットワークは、以下の処理を行っている

キャッシュフュージョン管理
　この処理は、更新されたデータや構成管理情報をネットワークを通してやりとりを実施
している。
ここで特にデータの管理において、ブロック単位でデータを授受している関係から
ブロックが送受信できない場合、データの欠損に至ってしまうため障害検知が最もシビア
であり、かつ負荷(ワークロード)管理がすぐ活動する事がわかった。

ハートビート管理(VoteingDisk管理)
　スピリットブレイン（どちらが親になり管理するかわからなくなる状態）の管理のために
VoteingDiskを利用して、上位サーバのとり決めを実施している。
ここで、VoteingDiskは1秒単位での管理を実施しているため、障害検知がもっとも高速で
あるため、こちらのネットワークに障害が発生した場合クラスター管理構成が安全のため
上位サーバを選出し下位サーバをダウンさせることがわかった

うちの場合は、ハートビート管理もこのネットワークを通して行っている。

そのため、このネットワークがダウンした場合、最も大きな障害が発生する可能性が最短で
あるため、このキャッシュフュージョン用のスイッチを落とすと大きな障害になるようだ。

オラクルのセミナーを聞いてきた。

Grid Evening RACを導入する際の注意点解説

8時からと思って大遅刻。
話はほとんど終わっていたけれど、おおむね何を話したかはわかった。ちょっと気になったのが
新人さんでセミナーの講師になってたけどあれ結構つらいだろうなぁって思う。
たぶん、来てるのはほとんどプロだろうし、初心者への説明じゃないんだから厳しいんじゃないかと。
たぶん聞きたかったの、注意点といっても裏の話だから、べつに推奨しませんとかそんな話じゃ
ないと思う。

RACのおさらいから

　Shared Everytingのデータベース構造。　つまり共有ディスクを買いなさい。
　だからできる構成もある。
　A/Aで利用できる　つまり死に資産がない。

これにするのは、現状のオラクル構成を変更しないでも、可用性、拡張性を担保できるからだ。

可用性としては
コネクションフェイルオーバ
　これは、tnsに書きかえるだけでオラクルの層でカバーしてくれる。
　
　Aがこけたら、Bに　接続しなさいという指示。

拡張性としては
A,Bでそれぞれ処理したりできるので、水平方向の拡張である、サーバを増やせば逃げられるという
機能が使える。

あとはキャッシュフュージョンとかノード別の処理とかの解説。
他の優秀なWEBサイトの解説によるかな。この辺は。

オラクルの構成要素

CRS
Cluster Ready Services
処理量を調整（ワークロード）
IPの管理をする。　ちなみに運用している経験からいえば、RAC構成にした場合IPはフロント側に最低4つ必要
　ひとつを共有するのでなくて、それぞれに仮想を持たせる構成になっている。

CSS
Cluster-Synchronaization Services
サーバ情報を管理
　一貫性管理を行う。（VoteingDiskとか　どれがやりますかを管理するディスク領域。
　スピリットブレインと呼ばれる俺やるよ　が判定できなくなった場合にだれがこれやりますかを　投票形式で
　管理しているから。）
障害管理をする。

EM
エンタープライズマネジャーのほうではなくEventManger
アプリケーションの管理
　高速フェイルオーバとかはここの管理。

質問が相次いでいた。

Oracle Database ストレージ管理 Weekendセミナーに参加してきたので記録

そもそも
　WeekEndセミナーって？
　　オラクルが平日以外で実施しているセミナーで、13時半とかから4時間くらいやる。
もともと10月末だったんだけど、なんだか延期になってしまって、3連休の初日という困ったときに
開催している。なかなか参加、難しいんじゃないのかな。

場所はオラクル本社のセミナールーム

内容は4本
　ストレージの話　60分
　ASMの概要説明　60分
　ASMの障害に対する内部説明　40分
　ASMのバックアップに関して　60分

詳細は以下に記載する。

RAC ONE NODEに関して

セミナーを受けてきたので、まとめ。この機能自体エンタープライズ版(EE)の機能に
なるので、安いかと言われるとそうでもない。保守も含めると微妙なので調整が必要
になると考えられる。

というのも、
　プロセッサーライセンス　 \1,087,000(標準価格 2010/01, +保守\239,140)

　->これでRACが組める。あとはハード代。
SEONEなら、80*2 で160万で組めるし、冗長になるからだ。

で、メリットは

知らなかった。。。

http://www.oracle.co.jp/iSeminars/080802_1100/id_001653.pdf

33ページあたりから
　Ｂツリーインデックスのリーフ分離を以下で算出

ー＞ 事前に統計情報が最新であることが望ましい
SELECT LF_ROWS AS "リーフ行の数",
LF_BLKS AS リーフブロック数,
DEL_LF_ROWS AS "削除リーフ行の数",
TO_CHAR(DEL_LF_ROWS/LF_ROWS * 100,'999.9') || '%' AS "削除リーフ行の割合"
FROM INDEX_STATS;

MySQL セミナーを受けてきたので記載。
機密保持には当たらないと思うけど問題があるようだったら、エントリーの公開は中止
したい。

受けてきたところ
　Oracle 青山本社セミナールーム
場所
　1月31日　14時より17時予定が、解説と質問で、17時半過ぎまで上がっていた。

3部構成で、MySQLの最新機能を踏まえて解説している。
　○新機能に関して
　○エンタープライズ版に関して
　○MySQL Clusterに関して

総括
　新機能に関しては、MySQL本社の資料と同様で、以下の3点と細かい修正内容。
　○InnoDB周りの修正について
　○ロック機構の改善
　○レプリケーションに関して

2，3部に関しては、商用製品の説明会の内容として実施されている。ただし、MySQLCLUSTER
に関しての関心の高さは感じ取れた。やはりまだ認知が少ない部分と、Oracle参入によりどうな
るかが不透明だからだと言えそう。また、OracleInMemoryDatabaseとの差が大きいためこのあた
りにも関心は高かった。
個人的には、エンタープライズ版のサポートのゆくえが気になったので、もう少し実際的な
話があってもよかったかなぁと感じました。

以下詳細

NDB cluster のアップグレード
今回実施するのは、無停止アップグレードで、バージョンを上げる。

前提から
　先日より、バグによる全停止に悩まされる。
全停止というか、Dataノードがシャットダウンされるのだ。この要因だが

ndb_mgm> Node 4: Forced node shutdown completed.
Caused by error 1217: 'No message slogan found (please report a bug if you get this error code)(Unknown). Unknown'.
Node 3: Forced node shutdown completed. Caused by error 1217: 'No message slogan found
(please report a bug if you get this error code)(Unknown). Unknown'.
Node 4: Start initiated (version 7.1.8)

エラーレポートを報告して欲しいという旨で、トレースしか追う方法がなさそうだ。

バグレポートも確認してみたけれど、レポートできるのは最新版だけだよと、ちょっと手厳しい。
なので、この回避策としては最も有効と思われるアップグレードの対応を行う。

Ndb-cluster 7.1.8 -> 7.1.10

操作方法としては、

検証環境でテスト。2台構成なので、片寄、イニシャル、片寄　でアップグレード対応。
本番では4台。

ファイルを配備
serverA
scp ./*-7.1.10-1.rhel5.x86_64.rpm serverB:/usr/local/src/

それぞれの管理ノードをダウンさせる。その後更新処理。

NDBCLUSTERが頻繁に落ちる。

おそらく設定の問題か機器的な問題だとは思うのだけど。
今のところ週に2，3回片側データノードが落ちる。そして復旧時に全落ちしたりする。
要因不明で、いつも似たようなエラーナンバーがでる。あとは、トレースファイルしかなさそうだ。。。

7.1.8から継続的に発生。
ローリングバージョンアップで、mysql-5.1.51 ndb-7.1.10に更新した。

構成は
　物理4台構成で
DataNode 2式
SQLNode 兼　ManagemnetNode 2式

メモ書き

7.1.13が５月末にリリース
大きな変更点は無いが、nowaitの調整機能と、5.1.56ベースになった
あと、バグフィックス。
5.1.56ベースはinnodb系の修正がたくさん入っていたのでNDB系の点はSQLとかのようだ
後で確認しておこう。
http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-news-5-1-56-ndb-7-1-13.html