■SI Object Browser 掲示板
|
ユーザの皆様、開発者、サポート担当者の交流のための掲示板です！ ユーザーの皆様同士で教え合ったりもできる交流の場にしたいと思っていますので、相互協力をよろしくお願いします。 なお、過去に同じようなQ&Aがあるケースも多いので、投稿前にキーワード検索してみてください。 |
 |
| ※各投稿のカラーは対象となる製品に対応しています。【■…OB ■…OBER ■…全般 ■…その他】 ※ライセンスに関するお問合せにつきましては、お問い合わせページよりご連絡いただきますようお願いいたします。 ※誹謗中傷や公序良俗に反する書き込みはご遠慮ください。運営側の判断によりメッセージを削除する場合があります。 ※環境依存や技術的調査が必要な問題については掲示板上ではお答えしかねます。ご了承ください。 | |
よくある質問（FAQ）
検索オプション
後迫＠SI
こんにちは
後迫＠SIです。
情報をいただきありがとうございます。
ご指摘いただいたとおり、
投稿No.1356は'redo buffer allocation retries'の誤りです。
現在は'redo log space requests'の値を表示しておりますので、
次回バージョンアップで'redo buffer allocation retries'を表示するよう
修正させていただきます。
どうぞよろしくお願いいたします。
後迫＠SIです。
情報をいただきありがとうございます。
ご指摘いただいたとおり、
投稿No.1356は'redo buffer allocation retries'の誤りです。
現在は'redo log space requests'の値を表示しておりますので、
次回バージョンアップで'redo buffer allocation retries'を表示するよう
修正させていただきます。
どうぞよろしくお願いいたします。
返信を投稿
OB
後迫＠SI
こんにちは
後迫＠SIです。
このたびは返信が遅れてしまい誠に申し訳ございませんでした。
スクリプトをいただきありがとうございます。
弊社で現象を再現いたしました。
列数が多いテーブルをリバースエンジニアリングした場合に、
順番が不正になるようです。
Object Browser ERの不具合です。
ご迷惑をお掛けしてしまい、大変申し訳ございません。
この不具合につきましては、
次回マイナーバージョンアップで修正させていただきますので、
どうぞよろしくお願いいたします。
後迫＠SIです。
このたびは返信が遅れてしまい誠に申し訳ございませんでした。
スクリプトをいただきありがとうございます。
弊社で現象を再現いたしました。
列数が多いテーブルをリバースエンジニアリングした場合に、
順番が不正になるようです。
Object Browser ERの不具合です。
ご迷惑をお掛けしてしまい、大変申し訳ございません。
この不具合につきましては、
次回マイナーバージョンアップで修正させていただきますので、
どうぞよろしくお願いいたします。
返信を投稿
OBER
s_koike
過去の投稿No.1356に関連した内容なのですが、
データベース情報表示のREDOログバッファの空き待機回数の値は
'redo log space requests'を表示しているとのことなんですが
そこのコメントのところに「回数が多い、または定期的に値が増える場合→LOG BUFFERを
拡大」と書いてあるので、'redo buffer allocation retries'が正しいような
気がするのですが。
オラクル9iパフォーマンスチューニングガイドに
「REDO ログ領域要求統計V$SYSSTAT 統計のredo log space requests は、
サーバー・プロセスがREDOログ・バッファ内の領域を待機するのではなく、
オンラインREDO ログ内の領域を待機する必要があった回数を示します。
この統計と待機イベントの大きい値は、LGWR ではなく、チェックポイント、
DBWR、アーカイバ・アクティビティをチューニングする必要があることの
標識として使用する必要があります。
ログ・バッファのサイズを増やしても効果がありません。」
といった記述がありました。
長々とすみません。よろしくお願いします。
データベース情報表示のREDOログバッファの空き待機回数の値は
'redo log space requests'を表示しているとのことなんですが
そこのコメントのところに「回数が多い、または定期的に値が増える場合→LOG BUFFERを
拡大」と書いてあるので、'redo buffer allocation retries'が正しいような
気がするのですが。
オラクル9iパフォーマンスチューニングガイドに
「REDO ログ領域要求統計V$SYSSTAT 統計のredo log space requests は、
サーバー・プロセスがREDOログ・バッファ内の領域を待機するのではなく、
オンラインREDO ログ内の領域を待機する必要があった回数を示します。
この統計と待機イベントの大きい値は、LGWR ではなく、チェックポイント、
DBWR、アーカイバ・アクティビティをチューニングする必要があることの
標識として使用する必要があります。
ログ・バッファのサイズを増やしても効果がありません。」
といった記述がありました。
長々とすみません。よろしくお願いします。
返信を投稿
OB
402
VARRAY 型のカラムを含むテーブルを「データ」タブで表示すると
“変数 にセットした値 0 が無効です。”というエラーが発生します．
手元の以下の環境で再現します．
Oracle 8.1.5.1 + OB 8.0.1.5
Oracle 9.0.1.4 + OB 8.0.4.10
本掲示板の投稿No.1196 1197 1208 のツリーで既に話題になった件ですが
更新履歴のページを見ても VARRAY に関する更新情報が無かったため
対応済みとなっているのかが判断できません．
(そのため環境依存の問題なのか OB の問題なのか切り分けができません．)
環境依存の問題でしたら改めて情報を報告いたしますので
上記ツリーで話題になった現象の対応結果をお知らせください．
“変数 にセットした値 0 が無効です。”というエラーが発生します．
手元の以下の環境で再現します．
Oracle 8.1.5.1 + OB 8.0.1.5
Oracle 9.0.1.4 + OB 8.0.4.10
本掲示板の投稿No.1196 1197 1208 のツリーで既に話題になった件ですが
更新履歴のページを見ても VARRAY に関する更新情報が無かったため
対応済みとなっているのかが判断できません．
(そのため環境依存の問題なのか OB の問題なのか切り分けができません．)
環境依存の問題でしたら改めて情報を報告いたしますので
上記ツリーで話題になった現象の対応結果をお知らせください．
返信を投稿
OB
けいた
すみません。
ＯＢの質問ではないので今後いたしません。
ＯＢでリカバリってできないのかなって思ったのですが、無理でしょうか。
ＯＢの質問ではないので今後いたしません。
ＯＢでリカバリってできないのかなって思ったのですが、無理でしょうか。
返信を投稿
OB
後迫＠SI
こんにちは
後迫＠SIです。
お問い合わせいただきました件ですが、
規模の大きい(数千行程度の)プログラムを実行した場合、
デバッグセッションとターゲットセッションの同期が取れなくなる場合があります。
この場合、セッションの切断を行ってもKILLEDのまま切断されない状態になります。
クライアント側から切断してもKILLEDのままである場合、サーバ側から切断することで正常に切断されることがあります。
逆に、サーバ側から切断してもKILLEDのままである場合、クライアント側から切断することで正常に切断されることがありますので、試していただけますでしょうか。
(切断するには、Object Browser、OEMの他、
SQL*PlusからALTER SYSTEM KILL SESSIONでも切断可能です。)
どうぞよろしくお願いいたします。
後迫＠SIです。
お問い合わせいただきました件ですが、
規模の大きい(数千行程度の)プログラムを実行した場合、
デバッグセッションとターゲットセッションの同期が取れなくなる場合があります。
この場合、セッションの切断を行ってもKILLEDのまま切断されない状態になります。
クライアント側から切断してもKILLEDのままである場合、サーバ側から切断することで正常に切断されることがあります。
逆に、サーバ側から切断してもKILLEDのままである場合、クライアント側から切断することで正常に切断されることがありますので、試していただけますでしょうか。
(切断するには、Object Browser、OEMの他、
SQL*PlusからALTER SYSTEM KILL SESSIONでも切断可能です。)
どうぞよろしくお願いいたします。
返信を投稿
OB
キメイラ
[けいた]
>初心者なので不躾な質問をお許しください。
基本的に、OBのサポート用の掲示板での話題としては、不適切かと思います。
まずは、質問する場所を考えた方が良いと思います。
>あと話は変わりますが、リカバリーの時リスナーというのは気にしないで作業すればいいのでしょう
>か。startup mountしても関係ないと考えてよろしいのでしょうか。
実際に、リカバリの邪魔になるような行為をしなければ、リスナの生死は関係ありません。
邪魔が入る可能性があるなら、考慮すべきです。
返信を投稿
OB
茶パ王
再現しました。
以下のCreate文で調査をお願いします。
EnterpriseManagerで確認したものと、リバースエンジニアリングしたもので、項目の順番が異なってしまいます。
CREATE TABLE t2
(
IDIDIDID001 VARCHAR(10),
IDIDIDID002 INT,
IDIDIDID003 INT,
IDIDIDID004 VARCHAR(255),
IDIDIDID005 INT,
IDIDIDID006 VARCHAR(100),
IDIDIDID007 INT,
IDIDIDID008 INT,
IDIDIDID009 INT,
IDIDIDID010 INT,
IDIDIDID011 INT,
IDIDIDID012 VARCHAR(50),
IDIDIDID013 INT,
IDIDIDID014 VARCHAR(50),
IDIDIDID015 INT,
IDIDIDID016 VARCHAR(50),
IDIDIDID017 INT,
IDIDIDID018 VARCHAR(50),
IDIDIDID019 VARCHAR(100),
IDIDIDID020 INT,
IDIDIDID021 INT,
IDIDIDID022 VARCHAR(50),
IDIDIDID023 INT,
IDIDIDID024 INT,
IDIDIDID025 INT,
IDIDIDID026 VARCHAR(50),
IDIDIDID027 VARCHAR(200),
IDIDIDID028 SMALLINT,
IDIDIDID029 VARCHAR(255),
IDIDIDID030 VARCHAR(10),
IDIDIDID031 TEXT,
IDIDIDID032 VARCHAR(60),
IDIDIDID033 SMALLINT,
IDIDIDID034 INT,
IDIDIDID035 CHAR(5),
IDIDIDID036 INT,
IDIDIDID037 INT,
IDIDIDID038 VARCHAR(10),
IDIDIDID039 VARCHAR(10),
IDIDIDID040 INT,
IDIDIDID041 INT,
IDIDIDID042 VARCHAR(30),
IDIDIDID043 VARCHAR(20),
IDIDIDID044 VARCHAR(30),
IDIDIDID045 VARCHAR(20),
IDIDIDID046 VARCHAR(10),
IDIDIDID047 INT,
IDIDIDID048 INT,
IDIDIDID049 VARCHAR(10),
IDIDIDID050 VARCHAR(24),
IDIDIDID051 VARCHAR(24),
IDIDIDID052 VARCHAR(50),
IDIDIDID053 INT,
IDIDIDID054 VARCHAR(20),
IDIDIDID055 VARCHAR(20),
IDIDIDID056 VARCHAR(20),
IDIDIDID057 VARCHAR(50),
IDIDIDID058 INT,
IDIDIDID059 VARCHAR(20),
IDIDIDID060 INT,
IDIDIDID061 INT,
IDIDIDID062 VARCHAR(10),
IDIDIDID063 VARCHAR(24),
IDIDIDID064 VARCHAR(24),
IDIDIDID065 VARCHAR(20),
IDIDIDID066 VARCHAR(20),
IDIDIDID067 INT,
IDIDIDID068 VARCHAR(20),
IDIDIDID069 VARCHAR(10),
IDIDIDID070 VARCHAR(10),
IDIDIDID071 INT,
IDIDIDID072 INT,
IDIDIDID073 INT,
IDIDIDID074 VARCHAR(50),
IDIDIDID075 VARCHAR(50),
IDIDIDID076 VARCHAR(50),
IDIDIDID077 VARCHAR(50),
IDIDIDID078 VARCHAR(50),
IDIDIDID079 VARCHAR(50),
IDIDIDID080 INT,
IDIDIDID081 INT,
IDIDIDID082 VARCHAR(20),
IDIDIDID083 VARCHAR(15),
IDIDIDID084 INT,
IDIDIDID085 VARCHAR(10),
IDIDIDID086 VARCHAR(10),
IDIDIDID087 INT,
IDIDIDID088 INT,
IDIDIDID089 INT,
IDIDIDID090 INT,
IDIDIDID091 INT,
IDIDIDID092 INT,
IDIDIDID093 INT,
IDIDIDID094 INT,
IDIDIDID095 INT,
IDIDIDID096 INT,
IDIDIDID097 VARCHAR(50),
IDIDIDID098 INT,
IDIDIDID099 VARCHAR(20),
IDIDIDID100 INT,
IDIDIDID101 INT
)
go
以下のCreate文で調査をお願いします。
EnterpriseManagerで確認したものと、リバースエンジニアリングしたもので、項目の順番が異なってしまいます。
CREATE TABLE t2
(
IDIDIDID001 VARCHAR(10),
IDIDIDID002 INT,
IDIDIDID003 INT,
IDIDIDID004 VARCHAR(255),
IDIDIDID005 INT,
IDIDIDID006 VARCHAR(100),
IDIDIDID007 INT,
IDIDIDID008 INT,
IDIDIDID009 INT,
IDIDIDID010 INT,
IDIDIDID011 INT,
IDIDIDID012 VARCHAR(50),
IDIDIDID013 INT,
IDIDIDID014 VARCHAR(50),
IDIDIDID015 INT,
IDIDIDID016 VARCHAR(50),
IDIDIDID017 INT,
IDIDIDID018 VARCHAR(50),
IDIDIDID019 VARCHAR(100),
IDIDIDID020 INT,
IDIDIDID021 INT,
IDIDIDID022 VARCHAR(50),
IDIDIDID023 INT,
IDIDIDID024 INT,
IDIDIDID025 INT,
IDIDIDID026 VARCHAR(50),
IDIDIDID027 VARCHAR(200),
IDIDIDID028 SMALLINT,
IDIDIDID029 VARCHAR(255),
IDIDIDID030 VARCHAR(10),
IDIDIDID031 TEXT,
IDIDIDID032 VARCHAR(60),
IDIDIDID033 SMALLINT,
IDIDIDID034 INT,
IDIDIDID035 CHAR(5),
IDIDIDID036 INT,
IDIDIDID037 INT,
IDIDIDID038 VARCHAR(10),
IDIDIDID039 VARCHAR(10),
IDIDIDID040 INT,
IDIDIDID041 INT,
IDIDIDID042 VARCHAR(30),
IDIDIDID043 VARCHAR(20),
IDIDIDID044 VARCHAR(30),
IDIDIDID045 VARCHAR(20),
IDIDIDID046 VARCHAR(10),
IDIDIDID047 INT,
IDIDIDID048 INT,
IDIDIDID049 VARCHAR(10),
IDIDIDID050 VARCHAR(24),
IDIDIDID051 VARCHAR(24),
IDIDIDID052 VARCHAR(50),
IDIDIDID053 INT,
IDIDIDID054 VARCHAR(20),
IDIDIDID055 VARCHAR(20),
IDIDIDID056 VARCHAR(20),
IDIDIDID057 VARCHAR(50),
IDIDIDID058 INT,
IDIDIDID059 VARCHAR(20),
IDIDIDID060 INT,
IDIDIDID061 INT,
IDIDIDID062 VARCHAR(10),
IDIDIDID063 VARCHAR(24),
IDIDIDID064 VARCHAR(24),
IDIDIDID065 VARCHAR(20),
IDIDIDID066 VARCHAR(20),
IDIDIDID067 INT,
IDIDIDID068 VARCHAR(20),
IDIDIDID069 VARCHAR(10),
IDIDIDID070 VARCHAR(10),
IDIDIDID071 INT,
IDIDIDID072 INT,
IDIDIDID073 INT,
IDIDIDID074 VARCHAR(50),
IDIDIDID075 VARCHAR(50),
IDIDIDID076 VARCHAR(50),
IDIDIDID077 VARCHAR(50),
IDIDIDID078 VARCHAR(50),
IDIDIDID079 VARCHAR(50),
IDIDIDID080 INT,
IDIDIDID081 INT,
IDIDIDID082 VARCHAR(20),
IDIDIDID083 VARCHAR(15),
IDIDIDID084 INT,
IDIDIDID085 VARCHAR(10),
IDIDIDID086 VARCHAR(10),
IDIDIDID087 INT,
IDIDIDID088 INT,
IDIDIDID089 INT,
IDIDIDID090 INT,
IDIDIDID091 INT,
IDIDIDID092 INT,
IDIDIDID093 INT,
IDIDIDID094 INT,
IDIDIDID095 INT,
IDIDIDID096 INT,
IDIDIDID097 VARCHAR(50),
IDIDIDID098 INT,
IDIDIDID099 VARCHAR(20),
IDIDIDID100 INT,
IDIDIDID101 INT
)
go
返信を投稿
OBER
けいた
ご回答ありがとうございます。
初心者なので不躾な質問をお許しください。
あと話は変わりますが、リカバリーの時リスナーというのは気にしないで作業すればいいのでしょう
か。startup mountしても関係ないと考えてよろしいのでしょうか。
どうかお願いいたします。
初心者なので不躾な質問をお許しください。
あと話は変わりますが、リカバリーの時リスナーというのは気にしないで作業すればいいのでしょう
か。startup mountしても関係ないと考えてよろしいのでしょうか。
どうかお願いいたします。
返信を投稿
OB
キメイラ <-通りすがりの人
オラクル君は、定義順にREDOを使っていくので、現在のREDOの使われる順番が
気に入らなければ、REDOを削除して、再度、使って欲しい順番に、作り直す必要があります。
いつでも変更できますが、REDOがガンガン出力されているようなタイミングだと、かなり作業がしにくいので、データベースアクセスの少ない時を狙って、作業しましょう。
気に入らなければ、REDOを削除して、再度、使って欲しい順番に、作り直す必要があります。
いつでも変更できますが、REDOがガンガン出力されているようなタイミングだと、かなり作業がしにくいので、データベースアクセスの少ない時を狙って、作業しましょう。
返信を投稿
OB