4 Replies Latest reply: Apr 15, 2013 9:46 PM by 1002387 RSS

    テーブル分割

    1002387
      初めてこちらを利用します。よろしくお願いいたします。

      現在、お客様のシステム環境のデータメンテナンスを担当しています。
      システムは社内から業務の進捗状況を管理するWEBサーバを介してOracle 11gを利用おります。
      昨年のサーバ保守期限切れに伴うサーバ乗せ換えにより、11g on windows server 2003 から11g solaris に切り替わり、レスポンス上は申し分がなく発揮できております。

      まもなく10年となるこのシステムも、一見パフォーマンス上などは全く問題がないのですが、ユーザが管理画面上から項目を増やせるような設計になっており、どんどんカラムが追加されるというシステムになっておりました。

      いまではもう項目追加は年に1,2回あるかないか程度ですが、過去に追加した項目がどっさりあり、現在1テーブル400近くものカラムがあります。(レコード数は100万超。年間10万超増加。)
      これらの項目は全て業務上必要な項目ですので、カラムを削除することはできませんが、カラム数が多く、行チェーンがどっさり発生しております。(50%超)

      マシンスペックに助けられていることもあって、ユーザレスポンス上は全く問題ないのですが、今後のためにテーブルを分割しようか悩んでおります。

      まとめ(+α)
      ・アプリ上からカラムを追加できるシステム
      ・カラムが膨大になっているため行チェーンが発生しているため、テーブル分割を検討している。
      ・分割した場合、画面上からアプリ上からカラムを追加できる機能は利用できなくなるが問題ない。
      ・ただ、テーブルを更新する機能が多いため、これらをできる限り改修せずにテーブル分割を実現したい。
      ・試したこととして、GYOUMUTBL→GYOUMUTBL_1、GYOUMUTBL_2とわけて更新可能VIEWを作成したが、
       更新が複数項目に及ぶため、[ ORA-01776: 結合ビューを介して複数の実表を変更できません。] が発生する。


      アプリ影響をなるべく避けるようにテーブル分割をスムーズに実現するには、どのような方法が考えられるでしょうか?
      またはパフォーマンス上は問題ない以上、テーブル分割を実施しないというのもありでしょうか?

      とても抽象的な質問ですが、ご意見よろしくお願いいたします。

      Edited by: 999384 on 2013/04/10 19:43
        • 1. Re: テーブル分割
          asahide
          ユーザが管理画面上から項目を増やせるような設計になっており、どんどんカラムが追加されるというシステム
          仕様・設計思想としては微妙ですね。
          ・カラムが膨大になっているため行チェーンが発生しているため、テーブル分割を検討している。
          こちらは行チェーン自体はテーブル分割をしないでも、例えばExp/ImpとかMOVEとかでも解消できると考えてます。
          400列は確かに多いですが、性能に即影響が出るほどとは思わないです。(勿論列の属性にもよりますけど)

          アプリ影響をなるべく避けるようにテーブル分割をスムーズに実現するには、どのような方法が考えられるでしょうか?
          またはパフォーマンス上は問題ない以上、テーブル分割を実施しないというのもありでしょうか?
          気にされているのはパフォーマンスだけでしょうか?
          でしたら現時点で問題なくても、将来的にも問題がないのかは確認してから進めた方が良いと思います。

          パーティションが利用できるなら、パーティションも一つの解にはなると思いますが、今回の状況で適用するのは(もう利用されているなら別ですが)勿体なさそうです。
          • 2. Re: テーブル分割
            sabotage
            +・試したこととして、GYOUMUTBL→GYOUMUTBL_1、GYOUMUTBL_2とわけて更新可能VIEWを作成したが、+
            + 更新が複数項目に及ぶため、[ ORA-01776: 結合ビューを介して複数の実表を変更できません。] が発生する。+

            instead of trigger で実装できませんか?
            ビューの更新列によって元表へのUPDATE文を条件分岐させるようには出来るでしょう。
            列が多いそうなので大変でしょうか…。
            • 3. Re: テーブル分割
              1002387
              ご意見、ありがとうございます。
              仕様・設計思想としては微妙ですね。
              そうなんですよね。いまさら当時の開発者を攻めても仕方ないですが、想定が甘かったといわざるを得ないですね。
              400列は確かに多いですが、性能に即影響が出るほどとは思わないです。(勿論列の属性にもよりますけど)
              殆どがVARCHAR2です。頻度の多い可変長レコードで、このレコード数ではExp/Impによる解消も一時対処程度にしか済まない気がしています。
              将来的にも問題がないのかは確認してから進めた方が良いと思います。
              パーティションが利用できるなら、パーティションも一つの解にはなると思いますが、今回の状況で適用するのは(もう利用されているなら別ですが)勿体なさそうです。
              現在の仕様のままであれば、将来的には問題ないと思っておりますが、
              今後の仕様変更などを考慮して、パーティション適用を選択肢に加えて改善検討を行います。

              ご意見ありがとうございました。¥
              • 4. Re: テーブル分割
                1002387
                ご意見ありがとうございます。
                instead of trigger で実装できませんか?
                選択肢のひとつではありましたが、やはりこの方法になりますかね。
                シンプルな方法ではあるのですが、項目数が多いので少々判断に悩んでおりました。