KK@IB です。

この処理に、インデックスは不要なように見えますね。
DBすらいらない。シークエンシャルファイルをCOBOLで
バッチ処理、みたいな感じの処理ですね。

インデックスをとったテーブルでやってみたらいかがでしょうか？


----- Original Message ----- 
From: ""浅山雄三"" <ALCYONE@xxxxxxxxxx>
To: <ml@xxxxxxxxxx>
Sent: Friday, June 05, 2009 12:16 PM
Subject: [mysql 14892] Re: バッチ処理のUPDATEでmysqld got signal 11が発生する 
 【再発】他に類似事象？有り


>  浅山です。いつもお世話になります。
>
>  下記のような処理をしています。
>
> (1)Aテーブルを順に読み出し、レコード毎に全VARCHARフィールドとTEXT
> フィールドの値を連結し、それをBテーブルのXフィールドにINSERT。件数は
> 約20万件。
>
> (2)上記(1)を全件処理した後、BテーブルのXフィールドを順に読み出し、
> Ngramデータを生成。そのデータをYフィールド（LONG TEXT属性）に
> UPDATE。UPDATEは1件当たり十キロバイト〜数十キロバイト。
>
>
>  UPDATEのSQL文は、
>
> update Bテーブル
> set Yフィールド = '〜〜Ngramデータ〜〜'
> where PRI_KEY = PRI_KEY_DATA
>
> です。
>
>  類似事象にもあるように、FULL TEXT INDEXが絡んでいるかと・・・。
>
>
>
>
> In message "[mysql 14891] Re: バッチ処理のUPDATEでmysqld got signal
> 11が発生する  【再発】他に類似事象？有り",
> Kaname Kuji(Y7)様wrote...
> >KK@IB です。
> >
> >実行環境の性能ももう少し知りたいところですが
> >補助のテーブルや処理を使って、
> >複数処理に分けるとか、SQLやINDEXの見直しが
> >貢献する状況のように感じられます。
> >
> >ロールバックが必要なのですね？
> >処理をexplainにかけるとどこが総なめ処理になっているかなどが
> >わかるかと思いますが、いかがでしょうか。
> >
> >----- Original Message ----- 
> >From: ""浅山雄三"" <ALCYONE@xxxxxxxxxx>
> >To: <ml@xxxxxxxxxx>
> >Sent: Friday, June 05, 2009 10:49 AM
> >Subject: [mysql 14890] Re: バッチ処理のUPDATEでmysqld got signal
> 11が発生する
> > 【再発】他に類似事象？有り
> >
> >
> >>  浅山です。いつもお世話になります。
> >>
> >>  その後メモリ量をどんどん減らしていっても発生してしまいます。
> >>
> >>  環境は少し違いますが類似事象を下記URLで見つけました。
> >> 【URL】
> >> http://sourceforge.jp/projects/senna/lists/archive/dev/2005-August/000117.html
> >> （DELETEでもUPDATEでもダメ）
> >>
> >>  上記はバージョン4.1ですがこのバグが改修されていないとか、5.1.32
> で
> >> Bug#42634に対処したけど実はちゃんと改修されていない？というよう
> なこ
> >> とはないでしょうか。
> >>
> >>
> >>
> >>
> >> In message "[mysql 14889] Re: バッチ処理のUPDATEでmysqld got
> signal
> >> 11が発生する  【再発】",
> >> 浅山雄三様wrote...
> >> >  浅山です。いつもお世話になります。
> >> >
> >> >  一旦は解決したと思ったんですが、また発生してしまいました。
> >> >  メモリ使用量を減らす方向で考えていますが、それ以外に何か手立
> てが
> >> あ
> >> >りましたら教えてください。
> >> >
> >> >
> >> >【エラー・ログ】
> >> >090528  6:46:26 - mysqld got signal 11 ;
> >> >This could be because you hit a bug. It is also possible that
> this
> >> >binary
> >> >or one of the libraries it was linked against is corrupt,
> >> improperly
> >> >built,
> >> >or misconfigured. This error can also be caused by
> malfunctioning
> >> >hardware.
> >> >We will try our best to scrape up some info that will hopefully
> >> help
> >> >diagnose
> >> >the problem, but since we have already crashed, something is
> >> >definitely wrong
> >> >and this may fail.
> >> >
> >> >key_buffer_size=536870912
> >> >read_buffer_size=2097152
> >> >max_used_connections=27
> >> >max_threads=200
> >> >threads_connected=2
> >> >It is possible that mysqld could use up to
> >> >key_buffer_size + (read_buffer_size + sort_buffer_size)
> >> *max_threads =
> >> >1344758 K
> >> >bytes of memory
> >> >Hope that's ok; if not, decrease some variables in the
> equation.
> >> >
> >> >thd: 0x7ec0c220
> >> >Attempting backtrace. You can use the following information to
> >> find
> >> >out
> >> >where mysqld died. If you see no messages after this, something
> >> went
> >> >terribly wrong...
> >> >stack_bottom = 0x804563b8 thread_stack 0x30000
> >> >Trying to get some variables.
> >> >Some pointers may be invalid and cause the dump to abort...
> >> >thd->query at 0x7eb7f2c0 is an invalid pointer
> >> >thd->thread_id=723
> >> >thd->killed=NOT_KILLED
> >> >The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html
> >> >contains
> >> >information that should help you find out what is causing the
> >> crash.
> >> >090528 06:46:26 mysqld_safe Number of processes running now: 0
> >> >090528 06:46:26 mysqld_safe mysqld restarted
> >> >InnoDB: The log sequence number in ibdata files does not match
> >> >InnoDB: the log sequence number in the ib_logfiles!
> >> >090528  6:46:28  InnoDB: Database was not shut down normally!
> >> >InnoDB: Starting crash recovery.
> >> >InnoDB: Reading tablespace information from the .ibd files...
> >> >InnoDB: Restoring possible half-written data pages from the
> >> >doublewrite
> >> >InnoDB: buffer...
> >> >090528  6:46:29  InnoDB: Started; log sequence number 0
> 468460087
> >> >090528  6:46:29 [Note] Event Scheduler: Loaded 0 events
> >> >090528  6:46:29 [Note] /opac/pp/mysql/bin/bin/mysqld: ready for
> >> >connections.
> >> >Version: '5.1.32'  socket: '/tmp/mysql.sock'  port: 3306  MySQL
> >> >Community Server (GPL)
> >> >
> >> >
> >> >In message "[mysql 14888] Re: バッチ処理のUPDATEでmysqld got
> >> signal
> >> >11が発生する",
> >> >浅山雄三様wrote...
> >> > >  浅山です。いつもお世話になります。
> >> > >
> >> > > >key_buffer_size=2147483648　←2GB
> >> > > >
> >> > > >このkey_buffer_sizeを1.5GBあるいは1GBくらいに減らして
> >> > > >見てはどうでしょう。
> >> > >
> >> > >  512MBにしてみたところ、SIGNAL11は発生しませんでした。
> >> > >
> >> > >  ということで解決しました。皆様ありがとうございました。
> >> > >
> >> > >（※バッチを何本もはしらせたので返事がおそくなってしまいまし
> >> た。）
> >> > >
> >> > >
> >> > > 2009年5月27日 09:19:43 (^o^)浅山雄三
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> >
> >> >
> >> > 2009年5月28日 12:46:16 (^o^)浅山雄三
> >> >
> >> >
> >> >
> >> >
> >> >
> >>
> >>
> >> 2009年6月5日 10:37:42 (^o^)浅山雄三
> >>
> >>
> >>
> >>
> >> __________  ESET NOD32 Antivirus からの情報, ウイルス定義データ
> ベースのバージョン 4132 (20090604) __________
> >>
> >> このメッセージは ESET NOD32 Antivirus によって検査済みです。
> >>
> >> http://canon-its.jp
> >>
> >>
> >>
> >
> >
> >
> >
> >
>
>
> 2009年6月5日 11:57:45 (^o^)浅山雄三
>
>
>
>
> __________  ESET NOD32 Antivirus からの情報, ウイルス定義データベースのバージョン 4132 (20090604) __________
>
> このメッセージは ESET NOD32 Antivirus によって検査済みです。
>
> http://canon-its.jp
>
>
>