24

SQL Server の隠し機能に関する回答と質問を楽しみました

オラクルについて教えてください。
隠しテーブル、...の内部動作、秘密のストアド プロシージャ、優れたユーティリティを備えたパッケージ...

4

21 に答える 21

15

Apex は現在すべての Oracle データベースの一部であるため、Apex を使用していない場合でも、次の Apex ユーティリティ関数が役立ちます。

SQL> declare
  2    v_array apex_application_global.vc_arr2;
  3    v_string varchar2(2000);
  4  begin
  5  
  6    -- Convert delimited string to array
  7    v_array := apex_util.string_to_table('alpha,beta,gamma,delta', ',');
  8    for i in 1..v_array.count
  9    loop
 10      dbms_output.put_line(v_array(i));
 11    end loop;
 12  
 13    -- Convert array to delimited string
 14    v_string := apex_util.table_to_string(v_array,'|');
 15    dbms_output.put_line(v_string);
 16  end;
 17  /
alpha
beta
gamma
delta
alpha|beta|gamma|delta

PL/SQL procedure successfully completed.
于 2008-12-19T15:57:17.410 に答える
12

「全表スキャンは必ずしも悪いわけではありません。インデックスは常に良いとは限りません。」

インデックスベースのアクセス方法は、作業単位ごと(通常は論理読み取りごと)にアクセスされる行の観点から測定する場合、フルスキャンよりも行の読み取り効率が低くなります。ただし、多くのツールは、全表スキャンを非効率の兆候として解釈します。

請求書テーブルから数百の請求書を読み、小さなルックアップテーブルで支払い方法を検索している例を考えてみましょう。インデックスを使用してすべての請求書のルックアップテーブルをプローブすることは、おそらく請求書ごとに3つまたは4つの論理ioを意味します。ただし、請求書データからのハッシュ結合の準備としてルックアップテーブルを完全にスキャンするには、おそらく2、3の論理読み取りのみが必要であり、ハッシュ結合自体はほとんどコストをかけずにメモリ内で実行されます。

ただし、多くのツールはこれを調べて「全表スキャン」を確認し、インデックスを使用するように指示します。そうすると、コードのチューニングが解除された可能性があります。

ちなみに、上記の例のようにインデックスに過度に依存すると、「バッファキャッシュヒット率」が上昇します。これが、BCHRがシステム効率の予測因子としてほとんど意味をなさない理由です。

于 2008-12-19T17:34:33.673 に答える
9

カーディナリティのヒントはほとんど文書化されていません。

 explain plan for
 select /*+ cardinality(@inner 5000) */ *
 from   (select /*+ qb_name(inner) */ * from dual)
 /
 select * from table(dbms_xplan.display)
 /
 --------------------------------------------------------------------------
 | Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
 --------------------------------------------------------------------------
 |   0 | SELECT STATEMENT  |      |  5000 | 10000 |     2   (0)| 00:00:01 |
 |   1 |  TABLE ACCESS FULL| DUAL |     1 |     2 |     2   (0)| 00:00:01 |
 --------------------------------------------------------------------------
于 2008-12-19T17:32:30.587 に答える
8

バッファキャッシュヒット率は、システム効率の予測因子としては事実上無意味です

于 2008-12-23T17:40:19.727 に答える
8

フラッシュバッククエリを使用して、前回のテーブルデータを表示できますが、特定の制限があります。

Select *
  from my_table as of timestamp(timestamp '2008-12-01 15:21:13')

11gには、履歴の変更をより堅牢に保存するためのまったく新しい機能セットがあります。

于 2008-12-23T17:43:28.113 に答える
7

インデックスを頻繁に再構築することは、ほとんどの場合時間の無駄です。

于 2008-12-23T17:40:58.930 に答える
7

wm_concatは MySql の group_concat と同じように機能しますが、文書化されていません。

データ付き:

-car-   -maker-
Corvette Chevy
Taurus   Ford
Impala   Chevy
Aveo     Chevy

select wm_concat(car) Cars, maker from cars
group by maker

あなたにあげる:

-Cars-                   -maker-
Corvette, Impala, Aveo   Chevy
Taurus                   Ford
于 2010-03-26T19:10:43.460 に答える
6

OVERLAPS述部は文書化されていません。

http://oraclesponge.wordpress.com/2008/06/12/the-overlaps-predicate/

于 2008-12-19T17:33:08.167 に答える
5

疑似列Ora_rowSCNについて知りました。このためにテーブルを設定しない場合、このpcolumnはブロックSCNを提供します。これは緊急事態に非常に役立つ可能性があります。「ああ、私はこのテーブルの監査を行っていないので、昨日から誰かがデータを変更したのではないかと思います。」

ただし、Rowdependeciesをオンにしてテーブルを作成するとさらに効果的です。これにより、最後の変更のSCNがすべての行に配置されます。これにより、クエリにすべての列を含めることなく、「編集の損失」の問題を回避できます。

IOW、アプリがユーザー変更のために行を取得するときは、Ora_rowscnも選択します。次に、ユーザーの編集を投稿するときに、where句の一意キーに加えてOra_rowscn=v_rscnを含めます。あなたがそれをつかんだ後に誰かが行に触れた場合、別名編集を失った場合、ora_rowscnが変更されたため、更新はゼロ行に一致します。

とてもクール。

于 2008-12-23T17:25:11.973 に答える
4

PASSWORD列 の値を取得すると、DBA_USERSパスワードを知らなくてもパスワードをバックアップ/復元できます。

 ALTER USER xxx IDENTIFIED BY VALUES 'xxxx';
于 2009-02-26T23:50:46.073 に答える
3

バッファキャッシュをバイパスし、ダイレクトパス読み取りを使用してディスクから直接読み取ります。

alter session set "_serial_direct_read"=true;

表領域(9i)または高速オブジェクト(10g +)チェックポイントが発生するため、ビジー状態のOLTPシステムでは注意が必要です。

于 2008-12-19T17:27:57.960 に答える
3

WITH句

于 2010-01-02T10:11:02.273 に答える
3

非表示の機能ではありませんが、Finegrained-access-control (FGAC) (行レベル セキュリティとも呼ばれます) は、私が過去に使用したことがある機能であり、その実装の効率性に感銘を受けました。データの表示に使用されるアプリケーション (SQL*Plus と Web アプリ) に関係なく、異なる権限を持つユーザーに行を公開する方法の粒度を制御できることを保証するものを探しているなら、これは宝石です。 .

組み込みのフルテキスト インデックス作成はより広く文書化されていますが、その安定性のために依然として際立っています (MS-SQL と Oracle の同様のデータ サンプルでフルテキスト インデックスが作成された列の完全な再インデックス作成を実行してみてください。速度の違いがわかります。 )。

于 2009-11-02T20:03:59.300 に答える
3

これが非表示と見なされるかどうかはわかりませんが、チューニングしている SQL ステートメントで何が起こったのかをすばやく確認できるこの方法を見たときは、とてもうれしかったです。

SELECT /*+ GATHER_PLAN_STATISTICS */ * FROM DUAL;

SELECT * FROM TABLE(dbms_xplan.display_cursor( NULL, NULL, 'RUNSTATS_LAST'))
;

PLAN_TABLE_OUTPUT
-----------------------------------------------------
SQL_ID  5z36y0tq909a8, child number 0
-------------------------------------
SELECT /*+ GATHER_PLAN_STATISTICS */ * FROM DUAL

Plan hash value: 272002086

---------------------------------------------------------------------------------------------
| Id  | Operation         | Name | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads  |
---------------------------------------------------------------------------------------------
|   1 |  TABLE ACCESS FULL| DUAL |      1 |      1 |      1 |00:00:00.02 |       3 |      2 |
---------------------------------------------------------------------------------------------


12 rows selected.

どこ:

  • E-Rows は推定行数です。
  • A-Rows は実際の行です。
  • A-Time は実際の時間です。
  • Buffers は実際のバッファーです。

見積もられた計画が実際の実行と桁違いに異なる場合、問題があることがわかります。

于 2009-07-27T23:03:13.613 に答える
3

http://awads.net/wp/tag/undocumented/の文書化されていないもの

警告: 自己責任で使用してください。

于 2008-12-19T18:44:55.293 に答える
2

スナップショットテーブル。Oracle Liteにもあり、独自のレプリケーションメカニズムをローリングするのに非常に役立ちます。

于 2008-12-19T15:35:33.520 に答える
2

@ピーター

TOAD で「Cursor」タイプの変数を実際にバインドし、それをステートメントで使用すると、結果グリッドに結果が表示されます。

exec open :cur for select * from dual;
于 2009-02-16T03:23:30.677 に答える
1

Q:TOADからカーソルで保存されたものを呼び出す方法は?

A:例、カーソル、パッケージ名、ストアドプロシージャ名に変更します

declare cursor PCK_UTILS.typ_cursor;  

begin   
    PCK_UTILS.spc_get_encodedstring(  
        'U',  
        10000002,  
        null,  
        'none',  
        cursor);  
end;
于 2008-12-19T15:25:56.817 に答える
1

スカラー サブクエリ キャッシングは、Oracle の最も驚くべき機能の 1 つです。

-- my_function is NOT deterministic but it is cached!
select t.x, t.y, (select my_function(t.x) from dual)
from t

-- logically equivalent to this, uncached
select t.x, t.y, my_function(t.x) from t

上記の「キャッシング」サブクエリmy_function(t.x)は、 の一意の値ごとに 1 回だけ評価されますt.x。同じ値の大きなパーティションがある場合、 が宣言されていなくt.xても、これによりクエリが大幅に高速化されます。たとえそれが.my_functionDETERMINISTICDETERMINISTIC

もちろん、my_functionが決定論的な関数でない場合は、間違った結果になる可能性があるので注意してください!

于 2012-04-18T12:02:45.567 に答える
1

文字列集計の WM_CONCAT

于 2011-10-19T02:33:06.727 に答える
1

モデル句( Oracle 10g 以降で使用可能)

于 2010-01-20T15:25:18.490 に答える