楽天カードのシステム障害とオラクルの誤算 - orangeitems’s diary
楽天カードのシステム障害については既報のとおりである。 これはこれで収束に向かいつつあるが、気になることがある。楽天カードのことを調べると大量にオラクルのコマーシャル記事が出てくることである。 「会員に長期に渡って安心・安全な利用環境を提供したい」 楽天カードがクラウド基盤にオラクルを選んだ理由 - ITmedia NEWS 楽天カード株式会社 Oracle Cloud at Customerの導入でビジネスのスピードアップと急成長を盤石なものに | Oracle 日本 メインフレームから全面移行--楽天カードのクレジットカード業務 - ZDNet Japan クレジットカード業務の基幹システムを全面刷新、Oracle Cloud at Customerを採用（楽天カード/日本オラクル） « ペイメントナビ - カード決済、PCI DSS、ICカード・ポイントカードの啓蒙ポータルサイト 楽
RDBとNoSQLにみるDB近現代史 データベースに破壊的イノベーションは二度起きるか？ - エンジニアHub｜若手Webエンジニアのキャリアを考える！
「ユーザー目線」のシステムを目指して RDBが従来の階層型DBに比べて優れていた点はいくつか挙げることができますが、シェアを伸ばすうえで最も大きな影響は、ユーザーが使いやすいデータ構造とインタフェースにこだわったことです。すなわち、「テーブル」と「SQL」の発明です。 RDBでは、すべてのデータを「テーブル」というただ一つのデータ形式によって表現します。テーブルは、見た目が「二次元表」に似ているため*3、Microsoft ExcelやGoogle ドキュメントなどのスプレッドシートを使い慣れた人が見ると、データを格納する方法が直観的にイメージしやすいという利点があります。実際、こうした二次元表によるデータ管理は、Excelなどのソフトウェアが登場する前から一般的な方法だったため、RDBが登場した当時の人々にとっても受け入れやすいものでした。 テーブルが画期的だった点は、もう一つあります。
怒りを通り越してあきれるOracleユーザー
「Oracle Database（DB）は信頼性や可用性が高く、当社のシステムには欠かせない。しかしここ数年、保守料が右肩上がり。IT予算に占めるOracle DBの保守料金の割合が増えて困っている」。 製造業A社のシステム部長は悩んでいた。会計や販売管理、生産管理など社内の主要なシステムは全てOracle DBを利用している。しかし開発時期はバラバラで、システム構築を依頼したITベンダーもシステムごとに異なっていた。Oracle DBのライセンスはシステム構築に合わせて、その都度購入している。システムごとに同じOracle DBとはいえ、バージョンは異なり、システム部門の保守作業も手間になっていた。 「Oracle DBを使っているシステムの維持費用を削減したい」。こう考えたシステム部長は、安定稼働していて、今後も大きな業務機能の変更もないと想定できるシステムのデータベースの保守契約を止
ANAシステム障害の原因判明、シスコ製スイッチの「世界初のバグ」でDBサーバーがダウン
同期処理が失敗した原因は、4台をつなぐスイッチの不具合。具体的には、スイッチが故障状態であるにもかからず、故障を知らせる「故障シグナル」を発信しなかった。国内線システムは故障シグナルを検知するとスイッチを予備機に切り替えるが、今回はその機能そのものを作動できなかった。 スイッチは完全に停止したわけではなく、「不安定ながらも動作していたようだ」（同）。そのため、DBサーバー間の同期は順次失敗し、停止していったと見られる。 ANA広報によると、スイッチは米シスコシステムズ製「Catalyst 4948E」という。「2010年6月の発売開始以降、世界で4万3000台、うち日本で8700台を販売しているが、今回の不具合は初めての事象と聞いている」（ANA広報）。なぜ「故障シグナル」が発信できなかったかは分かっていない。 1台での縮退運転を決断 4台の完全停止から37分後、ANAは1台のDBサーバー
IDの設計についてのさらに突っ込んだ議論
今日も前回に引き続きデータベース設計の話をする。今回の話で一旦データベース設計については筆を置くつもり（ブログ書いてないで原稿書けよ＞俺）であるが、その前に話をすっきりさせて置きたいと思う。最後を飾るテーマはIDの設計である。 数字しかないのに意味を含んだID前回のエントリを見ていただいた方から、次のような構造を持った学籍番号があるというフィードバックを頂いた。 全部数値で"入学年度下2桁"+"学科コード"+"学科内のあいうえお順の順位" このようなルールで割り当てた学籍番号を、単なる数値として扱うのであれば大きな問題はない。これは数値しか含まれていないので、SQLのデータ型としては単に数値型を使えば良いだろう。だが、学籍番号から入学年度を判断する、あるいは学科を判断するといった用途で使われるのであればやはり適切ではないといえる。リレーショナルモデルの観点だけからではなく、IDとして適切で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
本当は恐ろしい分散システムの話
