Re: SQL_FULLTEXT
From: Nenad Noveljic <nenad.noveljic_at_gmail.com>
Date: Sat, 13 May 2023 06:09:31 +0200
Message-Id: <FEBF7728-D5D1-4F59-8771-940AE9C181D3_at_gmail.com>
Sometimes it is for a single known SQL_ID, sometimes it’s a join with X$ structures underpinning V$SESSION on SQL_ID and PLAN_HASH_VALUE. On dbs like RDS w/o access to X$ we need to join with V$SESSION which doesn‘t expose the PLAN_HASH_VALUE.
Date: Sat, 13 May 2023 06:09:31 +0200
Message-Id: <FEBF7728-D5D1-4F59-8771-940AE9C181D3_at_gmail.com>
Sometimes it is for a single known SQL_ID, sometimes it’s a join with X$ structures underpinning V$SESSION on SQL_ID and PLAN_HASH_VALUE. On dbs like RDS w/o access to X$ we need to join with V$SESSION which doesn‘t expose the PLAN_HASH_VALUE.
Best regards,
Nenad
Von meinem iPhone gesendet
Am 13.05.2023 um 05:06 schrieb Tanel Poder <tanel_at_tanelpoder.com>:
Do you need the SQL full text for a single known SQL_ID? Youl could just query V$SQL.SQL_FULLTEXT WHERE rownum = 1.Note that page 20 of the 10gR2 era "Understanding Shared Pool Memory Structures" whitepaper mentions improvements to V$OPEN_CURSOR and V$SQLAREA.--Tanel PoderOn Fri, May 12, 2023 at 3:43 AM Nenad Noveljic <nenad.noveljic_at_gmail.com> wrote:What's the least disruptive view to query to obtain the full SQL text?
It should be V$SQLSTATS, but unfortunately V$SQLSTATS.SQL_FULLTEXT doesn't contain the full text. The support note "V$SQLSTATS.SQL_FULLTEXT does not show full of sql statements (Doc ID 2398100.1)" advises querying V$SQLAREA instead of V$SQLSTATS.Best regards,Nenad
-- http://www.freelists.org/webpage/oracle-lReceived on Sat May 13 2023 - 06:09:31 CEST