隨筆-25  評論-6  文章-0  trackbacks-0

          Question:
          The restore command works fine, but while attempting the rolforward of the sql logs, it complains about database falling short on bufferpool,and then terminates the rollforward process. One close look at the db2diag.log file, I noticed that db2 tried to start the database with the hidden bufferpool. But, apparently, that hidden bufferpool was pretty small to rollforward the logs and bring it online.

          I cannot reduce the bufferpool size as the database cannot be connected to.I cannot connect to the database as it is in rollforward pending state. I cannot rollforward the database, as it's not happy with the size of the *hidden* bufferpool and terminates.

          Answer:

          db2set DB2_OVERRIDE_BPF=50000

          This will bring up all configured bufferpools using 50000 pages each. You
          can choose a smaller/larger value that is suitable for your number of
          bufferpools and available system memory. You can also configure each
          bufferpool individually if you want

          値: 正數のページ數
          ???? OR
          ?<entry>[;<entry>...] (<entry>=<バッファー?プール ID>,<ページ數> )

          There is sitiuation that above solution does not work.

          				When you try to create a bufferpool or alter a bufferpool to a
          very large size and there is not enough memory in the system
          , DB2 may occupies all pagespace and overrall performance of
          the system become slow and may get hang at last because no
          pagespace is available. Then after you connect the database
          next time, DB2 will do crash recovery and still try to
          allocate memory for this big bufferpool and occupy all
          pagespace again. when you specify DB2_OVERRIDE_BPF parameter
          to override bufferpool size, it doesn't take effect in this
          situation. This is becasue DB2_OVERRIDE_BPF only applies for
          bufferpools that already exist at startup, and not to
          bufferpools that are created during crash recovery or roll
          forward. We will fix this problem and check DB2_OVERRIDE_BPF
          registry when creating bufferpools during crash recovery or
          roll forward. This problem only occurs in a 64 bit instance.
          
          		

          Local fix

          				You can use db2iupdt -w 32 <INSTNAME> to update the instance to
          a 32 bit instance, then you can connect to the database
          succefully. After that, use db2iupdt -w 64 <INSTNAME> to update
          the instance to 64 bit again. Please take a backup at this
          point, so we don't have to roll forward through bufferpool
          creation that fails if we need restore and roll forward
          database.
          
          		

          Problem summary

          				Users Affected:
          All users using 64 bit instance
          Problem Description:
          When you try to create a bufferpool or alter a bufferpool to a
          very large size and there is not enough memory in the system
          , DB2 may occupies all pagespace and overrall performance
          of the system become slow and may get hang at last
          because no pagespace is available. Then after you connect the
          database at next time, DB2 will do crash recovery and still try
          to allocate
          memory for this big bufferpool and occupy all pagespace again.
          In this situation, when you specify DB2_OVERRIDE_BPF parameter
          to override bufferpool size, it doesn't take effect in this
          situation. This
          is becasue DB2_OVERRIDE_BPF only applies for bufferpools that
          already exist at startup, and not to bufferpools that are
          created during crash recovery or roll forward. We will fix
          this problem and check
          DB2_OVERRIDE_BPF registry when creating bufferpools during crash
          recovery or roll forward. This problem only occurs in 64 bit
          instance.
          Problem Summary:
          This problem is caused by a misoperation, when you create or alt
          er a bufferpool, the size is too large to allocated from OS and
          cause overrall performance of the system is very slow and seems
          hang. Another problem is that DB2_OVERRIDE_BPF registry only app
          lies to bufferpools that already exists, and not bufferpools wil
          l be created in crash recovery or roll forward. So DB2 will try
          to create this big bufferpool again when doing crash recovery or
           roll forward. We will fix this problem and check DB2_OVERRIDE_B
          PF registry in our crash recovery and roll forward code.
          
          		

          Problem conclusion

          				
          				
          		

          Temporary fix

          				You can use db2iupdt -w 32 <INSTNAME> to update the instance to
          a 32 bit instance, then you can connect to the database
          succefully. After that, use db2iupdt -w 64 <INSTNAME> to update
          the instance to 64 bit again. Please take a backup at this
          point, so we don't have to roll forward through bufferpool
          creation that fails if we need restore and roll
          forward database.Please also notice that be careful when creati
          ng bufferpool, don't specify a too large value.
          
          		


          posted on 2007-03-15 15:21 MyJavaWorld 閱讀(745) 評論(0)  編輯  收藏

          只有注冊用戶登錄后才能發表評論。


          網站導航:
           
          主站蜘蛛池模板: 易门县| 合阳县| 张家界市| 延吉市| 芮城县| 寿阳县| 庄浪县| 马尔康县| 呼和浩特市| 肇东市| 崇州市| 大同县| 政和县| 双峰县| 南雄市| 钟山县| 叙永县| 东宁县| 竹溪县| 蓬莱市| 三门县| 昆山市| 襄汾县| 罗城| 高平市| 康定县| 大方县| 寻乌县| 徐汇区| 乳源| 平江县| 吕梁市| 茶陵县| 怀安县| 马山县| 陕西省| 南岸区| 华池县| 肥西县| 涟源市| 天柱县|