昨年12月10日、楽天モバイルがMNOとして提供する携帯電話サービスにて一時回線が利用できなくなるトラブルがあったが（過去記事）、このトラブルは課金制御機器におけるデータベースのデッドロックが原因だったそうだ（ケータイWatch、楽天モバイルの発表）。対策として、「データベースロック処理が遅延してもデッドロックを発生させない対処」を行ったほか、ソフトウェアベンダーに対し調査依頼も行ったとのこと。
処理が遅延 (スコア:1)
処理が完了していないに、処理中のファイルのロックが開放されて別のプロセスから書き換えられてしまったらデータの整合性がわやになる気がするけど大丈夫なんすかね。
対策として、「データベースロック処理が遅延してもデッドロックを発生させない対処」を行ったほか、ソフトウェアベンダーに対し調査依頼も行ったとのこと。
遅延原因を探して対処するのにはまだまだ時間がかかりそうで、とりあえずの処置なんでしょうけど。
Re: (スコア:0)
次のトラブルは決まったな。整合性とれなくなって「DBが破壊された」
Re: (スコア:0)
人類には並列処理はまだ早すぎるんだ。
Re: (スコア:0)
ナメック星にいけばなんとかなる！
Re: (スコア:0)
互換性がない(出来ることもあれば出来ないこともある)ので、
結局、スタッフをヘッドハンティングしてDBの作り直しだろ。でんで話にならないな。
Re: (スコア:0)
次は三木谷さんがスタッフをヘッドロックでお願いしたい
Re: (スコア:0)
＞でんで話にならないな。
？？？「ボクだっていろいろ工夫して頑張ってるんですよ！」
＞「どんな願いも」から「可能な限り」と口上も少し変化している。この新しい神龍で叶えられる願いの数は2つだったが、その後魔人ブウ編においては叶えられる願いの数が3つに強化され、多くの人を生き返らせた場合、叶えられる願いは2つに減少する。願いを叶えた後は姿を消し、ドラゴンボールはドラゴンレーダーにも反応しない石ころとなって世界中に散らばり、基本は1年間願いを叶えられない条件だが、魔人ブウ編において、3つの願いのうち1つ叶えただけなら4ヶ月後に再び神龍を呼び出すことができるという特例も示された
Re: (スコア:0)
最長老にできてデンデにできないことあったかなと考えてみて、最長老は潜在能力を引き出す事ができたなと思い出す。データベースの潜在能力を引き出せないデンデはやっぱりだめか？
Re: (スコア:0)
精神と時の部屋（サーバールーム）にこもって修行（修正）すればいいのでは？
Re: (スコア:0)
多分、無駄にロックされている所でも有ったのだろ。
電話関連だとパターンが決まって居るので、そこを考えれば相当最適化できたりするぞ。
よーく考えれば判るが、接続や通話するのに必須な管理するモノってそんなに無いだろ。
Re: (スコア:0)
無駄にロックしてても、ロック/アンロックの順序さえ統一されてればデッドロックにはならない。
Re:処理が遅延 (スコア:1)
ロックの仕組みはRDBMSによって異なるからちゃんと勉強したほうがいいぞ。
順序だけ合わせたところでデッドロックは回避出来なかったりする。
Re: (スコア:0)
「簡単だろ。一段FIFOを挟むだけでいいじゃん」
これくらいの発想でやってくれないかなw
Re: (スコア:0)
ＦＩＦＯは、一般のロック制御では有効だけど・・・。
そうではなく、ＲＤＢＭＳのロック制御には、一般的に粒（塊）度の違いがある。
行ロックと表ロックが混在しているとき、行ロック要求が油断無く実行されると、表ロック要求はスキありになるまで待機させられる。
デッドロック回避策は、表ロックで統一する。（お手軽）
タスク（ロック）スケジューラを経由してロックを行う。（スケジューラ設計に手間暇かかる。パフォーマンスは前者よりも良い）
Re: (スコア:0)
>油断無く
間断なく？
Re: (スコア:0)
筈なんだよな。
だからまあ三木谷が出来るって言っていたことが、自社の手に余った可能性が。
まさかとは思うが、
「もっと複雑なEC関連の技術者がいれば、パターンだけで処理できる電話なんて簡単」
とか思ってたんじゃないだろうな。
SQLServerなら (スコア:1)
https://qiita.com/sashim1343/items/fe0b978fb8d6ea7e73a1 [qiita.com]
これだったり。
Re:SQLServerなら (スコア:1)
そもそも論だがSQL Serverってロックは必ずしも行単位とはならず理屈上はエスカレーションするものなのでOracleとか他のRDBMSしかやってこなかった人はよくSQLServer的に間違ったコード書いてデッドロック発生させますね。
で、SQLServerのせいにするところまでがテンプレ。
勿論ちゃんとした人はちゃんとしたコードを書くのでデッドロックなんて起きず問題にならんのですが、案外そんなのかもね。
Re: (スコア:0)
コードというかテーブル設計の問題だよね。
ちゃんと必要なインデックスは付けましょう的な
Re: (スコア:0)
制約だよ
Re: (スコア:0)
ページロックは普通に筋悪でしょ…
Re: (スコア:0)
知らんなら調べるくらいすりゃいいのに。
ホントこういう人はシステム開発に関わらないでほしい。
Re: (スコア:0)
有能に見せかけるが上手い無能の典型だわ。
「俺の信奉する〇〇と違うからクソ」「俺が嫌いなメーカーだからクソ」
別に個人の自由だけど、だったらそれで仕事して金もらうなよっての。
Re: (スコア:0)
リンク先読んだけど、・・・。
>SQL Serverでは、テーブルに主キーが未設定かつトランザクション分離レベルが「SERIALIZABLE」な場合に、テーブルに排他（X）ロックがかかる
インテントロックの制御ミスなのは明らかだが、
重箱の隅を楊枝でほじくる様なことをしている印象がある。
絶滅したはずの伝染病に感染した感じ (スコア:0)
どんなDBシステム使ったら今さらそんな事になるんだよと
ミッキー自慢の最新鋭システムじゃなかったのかよ