PC不調
2台のマシンが不調なんです。
どちらも似たような症状。
プライベートマシン。
突然リブート。そして立ち上がりません。
BIOSの画面すら出てこない。
ハードディスクが動いてないみたい。
しばーらく(2日くらい)ほっとくと、HDDがにゅい〜んって動いて、
BIOSも出てくる。
おそらく、
1:USBの接続しすぎで電源が足りない
2:温度が上がりすぎ
のどちらかと思われます。
現在構築中の新サーバもBIOS画面が出てこない。
でもこちらはHDDは動いてる。CDも動いてる。
なので、各ドライブには問題なさそう。
怪しいのはグラフィックボード?
正常に動くときはBIOSの画面の前に
グラフィックボードの画面がちらりと出るんですよ。
それが出ない。
なので、中古でもなんでもグラフィックボードを買って
かつメモリも増設しようと思案中。
同時期にうごかなくなるもんなぁ。
[コメント読む(0)]
新サーバの構築をはじめました。
ということで。
大掃除に譲り受けた、奥さんの元PC。
新しいサーバにするために、各種インストールをはじめました。
とりあえず、OSはFreeBSD6.2を採用。
自分のプライベートマシンで、isoイメージをCDに焼いて
それを使ってインストール。
特に変わったことはしてません。
OSインストール後すぐにfreebsd-updateをいれて、パッチは適用してあります。
あとは、
7月10日分記事にあるうちのsambaのインストールまで、
それと、
7月11日分記事を参考にしつつ
MySQLの5.0.27をインストール。コンフィグオプションは同じです。
で、現行サーバのデータをimportしましたが、時間的には問題なさそう。
なんですが、DB「information_schema」で「Access Denied」になってしまいます。
現行4.1.27ではmysqldumpで--all-databasesオプションを使ってexportしたファイルを
そのままimportできるんですが。。。
バージョン違うからかな?
ここはもう少し調査が必要ですね。
とりあえず、今週はここまで。
平日はなかなか時間が取れないので、
また週末に続きをやります。
[コメント読む(0)]
テーブルの分割(昨日の続き)。
MySQLのMERGEテーブルには
primary keyが定義できないということで。
一応パフォーマンス測定はしてみたものの、
そりゃ、一意にできないんだもの。遅くなるわな。
という結果でした。
MERGEテーブル案、却下。
別な方法として、ビューを使ってみました。
分割したテーブルは昨日のまま。
結果1996〜結果2006です。
で、
create (or replace) view 結果 as
select * from 結果1996
union
select * from 結果1997
…
union
select * from 結果2006
という感じ。
「こりゃ、unionだから遅いだろ」
というのは重々承知。
実際にパフォーマンスを測ってみたら
何十倍?何百倍の違いが出ました。
しかも、
分割テーブルのcharがビューだとすべてvarcharになってるし。
intがすべて11バイトになってるし。
doubleがすべて22,1になってるし。
show create view を見たら、大変なことになってるし。
ビューはもっと賢い使い方しましょう(失)
-------------
とりあえず、今のところ
テーブルを分割することによるパフォーマンス向上は
期待できませんという結論で。
元テーブルがもっとでかかったりすれば
多少は期待できるのではないでしょうか。
ちなみに、MySQL5.1では
パーティショニングの機能が搭載されています。
が、まだ5.1系はベータ版。
実際に導入するのはもう少し時間がいるかと思われます。
[コメント読む(0)]
テーブルの分割。
「どの馬が何のレースで何着だったか」というデータを
持っているテーブルがあります。
ちょろっとみたら、50万件のデータが入ってました。
パフォーマンスも落ちてきたので、そろそろ
テーブルを分割してみようと思います。
MySQLではMERGEテーブルというのがありますので、
これを使ってみます。
元のテーブルは「結果」というテーブル。
これを
「結果1996」〜「結果2006」
という具合に、年単位で分けます。
create table 結果1996 select * from 結果 where 日付 like '1996%';
create table 結果1997 select * from 結果 where 日付 like '1997%';
…
create table 結果2006 select * from 結果 where 日付 like '2006%';
という具合に。
そして、古いテーブルは削除。
drop table 結果;
MERGEテーブルを作ります。
create table 結果 (各列の定義)
type=MERGE UNION=(結果1996,結果1997,…結果2006)
INSERT_METHOD=LAST;
これで一応完了です。
パフォーマンスを測定してみます。
…と思ったのですが。
エラーが出ちゃって、select できませんね。
Got error 124 from storage engineこれじゃわからんって。
あれこれ調べていますが、
Bug #6853とか
Bug #8053あたりが怪しそう。
英語が読めずに困っています(失)
わかり次第、ここにも書きます。
-----
意外とあっさりわかった。
MERGEテーブルのcreate table分から
primary key、indexに関する記述を抜いたら、selectできた。
そのあと、create indexを使って、INDEXを作る分には問題なし。
そのあと、alter table でprimary keyを追加したあとだと、同じエラーが出てselect できない。
要するに、
MERGEテーブルに対して、データが一意になるような設定(primary key とか unique index)をすると
Got error 124 from storage engineが返ってくる。
MySQLのマニュアルには、これしか書いていない。
--------
MERGE テーブルでは、テーブル全体で UNIQUE 制約を保持できない。
(中略)
このような方法で MERGE をテーブルを使用していると、高い確率で未知の問題が発生する。
--------
なので、今までprimary keyにしていた部分については、
indexに変更して代用するしかない?
何言ってるかわかんない?わかんないねぇ。
[コメント読む(0)]