You’re a busy Oracle DBA. Your phone rings. It’s your most troublesome user, once again complaining that her query is running slow. You take a quick look at the execution plan, find a possible choice for a new index to improve its performance, and drop it in place: Problem solved. Or is it? Even an experienced DBA may not immediately realize the impact that new index will have on the performance of dozens of other queries and DML statements.
Finally, there’s a better way: Let the database decide.
I'll show you how Automatic Indexing (AI) - one of the newest features of Oracle Database 19c – provides an intriguing alternative to reactive performance tuning methodologies for index creation. We’ll look at how AIC reacts to a heavy hybrid application workload and then holistically builds, tests, and implements the most appropriate secondary indexes needed to improve database performance.
One Less Thing For DBAs to Worry About: Automatic Indexing
1. One Less Thing For DBAs
to Worry About:
Automatic Indexing
Jim Czuprynski
@JimTheWhyGuy
2. April 2-6, 2017 in Las Vegas, NV USA #C17LV
Who Am I, and How Did I Get Here?
E-mail me at jczuprynski@zerodefectcomputing.com
Follow me on Twitter (@JimTheWhyGuy)
Connect with me on LinkedIn (Jim Czuprynski)
Traveler & public speaker Summers:
Wisconsin
Winters:
Illinois
Cyclist
XC skier
Avid
amateur
bird
watcher
Oldest dude in
Krav Maga class
3. April 2-6, 2017 in Las Vegas, NV USA #C17LV
Our Agenda
•Automatic Indexing: Evolutionary, Not Revolutionary!
•TPC-E, the Perfect Hybrid Workload for Automatic Indexing
•Activating, Controlling, and Monitoring Automatic Indexing
•Reviewing the Fruits of Automatic Indexing’s Labour
•A Demonstration: Automatic Indexing in Action
4. April 2-6, 2017 in Las Vegas, NV USA #C17LV
Automatic Indexing: Why Bother?
• Exadata leverages Smart Scan technology and techniques to quickly filter only needed data from
large datasets, often leveraging parallel processing, partitioning, and storage indexes
• Online Transaction Processing (OLTP) operations cannot always leverage Smart Scan due to
transaction scope (which tends to be quite small)
• Hybrid workloads – i.e. OLTP transactions accompanied by real-time reporting activity – may be
able to benefit from Smart Scan STORAGE ACCESS FULL operations …
• … but often the reporting activity may focus on much smaller result sets that partitioning,
parallelism, or storage indexes may be of little help in retrieving
• Therefore, secondary indexes may be immensely helpful for these queries …
• … but for RAC databases, too many indexes may contribute to incessant GCS messaging and waits
Exadata technology - the same hardware that underlies all Autonomous Database
services – has proven itself as an extremely scalable and highly available platform for
not only reporting and analytics, but OLTP / hybrid workloads as well
Therefore, be it Resolved:
Not all secondary indexes are evil!
(As long as they’re the right
secondary indexes.)
5. April 2-6, 2017 in Las Vegas, NV USA #C17LV
Automatic Indexing: Evolutionary, Not Revolutionary!
SQL Tuning Advisor
SQL Access Advisor
SQL Profiles
SQL Plan Baselines
Automatic SQL Tuning
SQL Performance Analyzer
Autonomous Health Framework
Integrated SPA and Database
Replay
Automatic In-Memory Population
SPA Result Set Validation
Improved Exadata SQL Tuning
High-Frequency Statistics
Real-Time Statistics
SQL Quarantine
Automatic Indexing
6. April 2-6, 2017 in Las Vegas, NV USA #C17LV
Automatic Indexing: Methodology
8. April 2-6, 2017 in Las Vegas, NV USA #C17LV
TPC-E’s Complex Schema
The 33-table
TPC-E data model is
definitely
non-trivial…
In short, TPC-E implements an
OLTP-oriented schema that’s
focused on huge numbers of
Trades performed for
Customers, either at the
request of a Broker or the
Customer herself
9. April 2-6, 2017 in Las Vegas, NV USA #C17LV
TPC-E’s Application Workload Simulation
… and neither is its
functional implementation
via PL/SQL in Swingbench
Five OLTP transactions encompass Trade
Request activity, including determination
of how each sale or purchase will be
settled and how it affects the Holdings
retained in each Customer’s Account …
…while five other transactions reflect
hybrid report activities, from simple
(show a current Customer’s Account
Balance) to complex (list the most active
n Securities across all portfolios)
11. April 2-6, 2017 in Las Vegas, NV USA #C17LV
Automatic Indexing: Leveraging DBMS_AUTO_INDEX
Procedure Purpose
CONFIGURE
Controls AI configuration settings, including:
• Mode (IMPLEMENT, REPORT ONLY, OFF)
• Report and logging retention
• Index retention period for auto and manual secondary indexes
• Default tablespace for indexes and how much space to
allocate
• Denying schemas from leveraging AI implementation
DROP_SECONDARY_INDEXES
Remove AI and secondary indexes for entire database, specific
schema(s), or specific table(s) within a schema
REPORT_ACTIVITY
Generate reporting at various summary and detail levels about AI
activity, including impacts of each AI index that’s been made
VISIBLE
REPORT_LAST_ACTIVITY
Generate reporting at various summary and detail levels about AI
activity during the immediately last evaluation period
12. April 2-6, 2017 in Las Vegas, NV USA #C17LV
What If I Don’t Have Access To an Exadata Platform?
How to simulate an Exadata environment for AI evaluation:
1
SQL> ALTER SYSTEM
SET "_exadata_feature_on” = true
SCOPE=SPFILE;
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP;
SQL> EXEC DBMS_AUTO_INDEX.CONFIGURE(
parameter_name => 'AUTO_INDEX_MODE’
,parameter_value => ‘IMPLEMENT’);
Here’s a neat trick to fake out your Oracle
19c test environment into thinking it’s
actually an Exadata platform!
(Provenance: @JulianDontcheff)
Choose either:
• IMPLEMENT (activates AI fully)
• REPORT ONLY (activates AI analyses only – no
indexes created)
• OFF (deactivates AI completely)
After a successful instance bounce, activate Automatic
Indexing via DBMS_AUTO_INDEX.CONFIGURE:
2
Note: This is intended only for evaluation purposes only – not ever for production implementation!
13. April 2-6, 2017 in Las Vegas, NV USA #C17LV
Activating and Controlling Automatic Indexing
SQL> EXEC DBMS_AUTO_INDEX.CONFIGURE(
parameter_name => ‘AUTO_INDEX_RETENTION_FOR_AUTO’
,parameter_value => 373);
SQL> EXEC DBMS_AUTO_INDEX.CONFIGURE(
parameter_name => ‘AUTO_INDEX_RETENTION_FOR_MANUAL’
,parameter_value => 181);
. . .
AI Parameter Setting
-------------------------------- ---------
AUTO_INDEX_COMPRESSION OFF
AUTO_INDEX_DEFAULT_TABLESPACE
AUTO_INDEX_MODE IMPLEMENT
AUTO_INDEX_REPORT_RETENTION 31
AUTO_INDEX_RETENTION_FOR_AUTO 373
AUTO_INDEX_RETENTION_FOR_MANUAL
AUTO_INDEX_SCHEMA
AUTO_INDEX_SPACE_BUDGET 50
Parameter Description
AUTO_INDEX_COMPRESSION Controls whether secondary indexes are compressed
(default: OFF)
AUTO_INDEX_DEFAULT_TABLESPACE Defines default tablespace in which Automatic Indexing
will instantiate secondary indexes (by default, the default
PERMANENT tablespace)
AUTO_INDEX_MODE Controls level of Automatic Indexing applied
AUTO_INDEX_REPORT_RETENTION Limits retention of Automatic Indexing reports to specified
number of days (default: 31)
AUTO_INDEX_RETENTION_FOR_AUTO Limits how long (in days) an unused secondary index
created by Automatic Indexing will be kept (default: 373)
AUTO_INDEX_RETENTION_FOR_MANUAL Limits how long (in days) an unused secondary index not
created by Automatic Indexing will be kept (default: NULL)
AUTO_INDEX_SCHEMA Defines which schemas are included or excluded from
Automatic Indexing (default: all non-SYS schemas included)
AUTO_INDEX_SPACE_BUDGET Controls how much space is allocated to secondary indexes
created by Automatic Indexing (default: 50%)
14. April 2-6, 2017 in Las Vegas, NV USA #C17LV
How Is Automatic Indexing Configured Right Now?
SQL> SELECT parameter_name, parameter_value
FROM dba_auto_index_config;
AI Parameter Setting
-------------------------------- ---------
AUTO_INDEX_COMPRESSION OFF
AUTO_INDEX_DEFAULT_TABLESPACE
AUTO_INDEX_MODE IMPLEMENT
AUTO_INDEX_REPORT_RETENTION 31
AUTO_INDEX_RETENTION_FOR_AUTO 373
AUTO_INDEX_RETENTION_FOR_MANUAL
AUTO_INDEX_SCHEMA
AUTO_INDEX_SPACE_BUDGET 50
It is already activated and it’s running in fully
automatic mode. It can also be set to only gather
intelligence for later index implementation
(REPORT ONLY) or even deactivated (OFF)
Logging will be retained for 31 days; any
automatically-created indexes will be
retained for at least 373 days …
… and up to 50% of the default
tablespace can be allocated for
automatically–created indexes
16. April 2-6, 2017 in Las Vegas, NV USA #C17LV
Automatic Indexing: Accessing Its Metadata
View Description
DBA_AUTO_INDEX_CONFIG Shows all current standard configuration parameters and settings
DBA_AUTO_INDEX_STATISTICS Describes detailed statistics of operations performed during a
Automatic Index task execution
DBA_AUTO_INDEX_VERIFICATIONS Captures “before and after” performance statistics for SQL
statements evaluated for Automatic Indexing improvement
DBA_AUTO_INDEX_IND_ACTIONS Lists the commands issued to create and instantiate secondary
indexes automatically
DBA_AUTO_INDEX_SQL_ACTIONS Identifies any specific SQL plan baselines that were created to
improve SQL statement performance
DBA_ADVISOR_EXECUTIONS
DBA_ADVISOR_FINDINGS
DBA_ADVISOR _OBJECTS
Contain details about AI task executions, related AI advisor
findings (including errors during task executions), and database
objects used during / impacted by task executions
DBA_INDEXES
DBA_INDEX_COLUMNS
Lists the indexes created through AI tasks and their related
columns, including current index status (INVISIBLE vs. VISIBLE)
17. April 2-6, 2017 in Las Vegas, NV USA #C17LV
So … Has Automatic Indexing Been Doing Anything?
SQL> SELECT
execution_id
,TO_CHAR(execution_start,
'yyyy-mm-dd.hh24:mi:ss') exec_dtm
,status
,advisor_name
FROM dba_advisor_executions
WHERE task_name='SYS_AUTO_INDEX_TASK'
AND execution_start >= (SYSDATE - 6/24)
ORDER BY execution_id DESC;
In this case, Automatic Indexing has been
tirelessly executing every 15 minutes
since it was activated
SQL> SELECT type, attr17, adv_sql_id
FROM dba_advisor_objects
WHERE task_name = 'SYS_AUTO_INDEX_TASK'
AND type = 'SQL’
ORDER BY attr17 DESC, object_id;
It’s even possible to see which individual SQL
statements have been (re-)evaluated during
each Automatic Indexing advisor execution
18. April 2-6, 2017 in Las Vegas, NV USA #C17LV
Are There Any Automatic Indexes Already?
SQL> SELECT owner, table_name, index_name, visibility
FROM dba_indexes
WHERE auto = 'YES'
ORDER BY 1,2,3;
OWNER TABLE_NAME INDEX_NAME VISIBILITY
----- -------------------------------- -------------------------------- ------------
TPCE ADDRESS SYS_AI_c3s7r26pujqyw INVISIBLE
TPCE COMPANY SYS_AI_5bz560x7mkmm5 INVISIBLE
TPCE COMPANY SYS_AI_8m4x6f5kzagpk INVISIBLE
TPCE COMPANY_COMPETITOR SYS_AI_g16pbfxkcvndg INVISIBLE
TPCE CUSTOMER_ACCOUNT SYS_AI_2nq8gbwuzdb6j INVISIBLE
TPCE CUSTOMER_ACCOUNT SYS_AI_d3kmzk12banrf VISIBLE
TPCE DAILY_MARKET SYS_AI_804nrthjdbw65 INVISIBLE
TPCE FINANCIAL SYS_AI_f48n5gfuab5xd INVISIBLE
TPCE HOLDING_HISTORY SYS_AI_c2vqkp1cnaynt INVISIBLE
TPCE HOLDING_SUMMARY SYS_AI_5unr1rda8j36j INVISIBLE
TPCE NEWS_XREF SYS_AI_8v3ttavnf0607 INVISIBLE
TPCE SECURITY SYS_AI_2gm9u3nyxkwcu INVISIBLE
TPCE SECURITY SYS_AI_4qyqwxyvbn1ut INVISIBLE
TPCE TRADE SYS_AI_1hjwdmk5q4mkz VISIBLE
TPCE TRADE SYS_AI_385rjxyamg6nd VISIBLE
TPCE TRADE SYS_AI_a8805thkfs7ua VISIBLE
TPCE TRADE SYS_AI_f03t41rg8f49c INVISIBLE
TPCE TRADE_HISTORY SYS_AI_cbcn2hcywmvcb INVISIBLE
TPCE WATCH_ITEM SYS_AI_cz35y7a104y79 INVISIBLE
TPCE WATCH_LIST SYS_AI_3h68gvvm1cmvr INVISIBLE
The SYS_AI prefix is proof that Automatic
Indexing has been hard at work …
… but even
though Automatic
Indexing created
these indexes
automatically,
some are still
INVISIBLE because
they’re not yet
valuable enough
to improve
workload
performance
19. April 2-6, 2017 in Las Vegas, NV USA #C17LV
Automatic Indexing: Peeking Under the Covers?
SQL> SELECT *
FROM sys.smb$config
WHERE parameter_name LIKE '%_AUTO_INDEX%’
ORDER BY 1;
PARAMETER_NAME PARAMETER_VALUE
---------------------------------- ---------------
_AUTO_INDEX_ABSDIFF_THRESHOLD 100
_AUTO_INDEX_CONCURRENCY 1
_AUTO_INDEX_CONTROL 0
_AUTO_INDEX_DERIVE_STATISTICS 0
_AUTO_INDEX_IMPROVEMENT_THRESHOLD 20
_AUTO_INDEX_REBUILD_COUNT_LIMIT 5
_AUTO_INDEX_REBUILD_TIME_LIMIT 30
_AUTO_INDEX_REGRESSION_THRESHOLD 10
_AUTO_INDEX_REVERIFY_TIME 30
_AUTO_INDEX_SPA_CONCURRENCY 1
_AUTO_INDEX_STS_CAPTURE_TASK 0
_AUTO_INDEX_TASK_INTERVAL 900
_AUTO_INDEX_TASK_MAX_RUNTIME 3600
_AUTO_INDEX_TRACE 0
Parameter [Probably] Controls …
_AUTO_INDEX_IMPROVEMENT_THRESHOLD Minimum performance improvement to consider before
activating a secondary index (???)
_AUTO_INDEX_REBUILD_COUNT_LIMIT Maximum number of times permitted to retry instantiating
a secondary index via REBUILD ONLINE
_AUTO_INDEX_REBUILD_TIME_LIMIT Maximum time allotted to instantiate a secondary index
can be instantiated as VISIBLE (which requires REBUILD
ONLINE)
_AUTO_INDEX_TASK_MAX_RUNTIME Longest permitted advisor task run time (in seconds)
_AUTO_INDEX_TRACE Activates tracing (0 = off, 1 = high-level, 2 = detailed)
20. April 2-6, 2017 in Las Vegas, NV USA #C17LV
Automatic Indexing in Action: Leveraging REPORT ONLY Mode
In this small-scale test in REPORT ONLY mode, 20
index candidates are identified and overall
performance improvement is forecasted at 91X:
1
This statement improved
respectably, by almost 9X …
2
… because of the addition of a single
new secondary index, reducing
estimated cost significantly
3
Here’s a bit more impressive
performance improvement, projected
to be 22,460X!
4
Here’s the original plan …
5
… and the new plan
6
In this latest release of Automatic
Indexing, note that it can also identify a
SQL Plan Baseline that might be
beneficial for performance
improvement
7
21. April 2-6, 2017 in Las Vegas, NV USA #C17LV
Automatic Indexing in Action: Switching to IMPLEMENT Mode
Here’s a look at what Automatic Indexing
projected for the indexes it had already
created in REPORT ONLY mode …
1
… and here’s some details under the
covers on what Automatic Indexing
actually did during each executions
2
Here’s a look at the
SwingBench sessions and
their corresponding SQL
statements hammering
the database
3
Here, we’ll drill into just
one of the queries
positively affected by a
newly-instantiated
secondary index
4 Finally, here’s a reflection of how
activating Automatic Indexing in
IMPLEMENT mode improved
performance for several queries
5
22. April 2-6, 2017 in Las Vegas, NV USA #C17LV
Check Out Our White Paper on ATP-D and Automatic Indexing!
• Shows implementation of intense Swingbench
simulated TPC-E workload against an ATP-D instance
• Explains how Automatic Indexing improved
workload performance by over two orders of
magnitude … without any DBA intervention
Download the free white paper now!
https://viscosityna.com/resources/whitepapers/atp-19c/
23. April 2-6, 2017 in Las Vegas, NV USA #C17LV
Useful Resources and Documentation
• Automatic Indexing Documentation:
https://docs.oracle.com/en/database/oracle/oracle-database/19/admin/managing-indexes.html#GUID-D1285CD5-
95C0-4E74-8F26-A02018EA7999
• DBMS_AUTO_INDEX Package Documentation:
https://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/DBMS_AUTO_INDEX.html#GUID-78C59A20-
2F92-448F-96F7-6C4FBB355E42
• Julian Dontcheff’s Blog Posts on Automatic Indexing:
https://juliandontcheff.wordpress.com/2019/02/18/automatic-indexing-in-19c/
https://juliandontcheff.wordpress.com/2019/03/07/ai-in-ai-artificial-intelligence-in-automatic-indexing/
• Franck Pachot’s Blog Post on Automatic Indexing:
https://medium.com/@FranckPachot/19c-auto-index-the-dictionary-views-ea2927a9786
Hinweis der Redaktion
Package DBMS_AUTO_INDEX and its procedures provides command and control capabilities for implementing AI, including generation of detailed reports of prior AI evaluations and explanations of why a particular AI secondary index has been made VISIBLE.
The DBA_AUTO_INDEX_CONFIG data dictionary view contains full information on which aspects and features of AI are currently activated.
The DBA_AUTO_INDEX_CONFIG data dictionary view contains full information on which aspects and features of AI are currently activated.
The DBA_AUTO_INDEX_CONFIG data dictionary view contains full information on which aspects and features of AI are currently activated.
Package DBMS_AUTO_INDEX and its procedures provides command and control capabilities for implementing AI, including generation of detailed reports of prior AI evaluations and explanations of why a particular AI secondary index has been made VISIBLE.
Any secondary index created by AI is prefixed with SYS_AI, so they’re easy to identify.
However, in this example, note that only four of the nearly 20 AI indexes created are actually VISIBLE because they have been determined via AI and ML to be of definite benefit to application workloads. The other indexes will be retained up to the threshold defined by AUTO_INDEX_RETENTION_FOR_AUTO and if they have not been used after that threshold expires, they will be automatically purged.
Any secondary index created by AI is prefixed with SYS_AI, so they’re easy to identify.
However, in this example, note that only four of the nearly 20 AI indexes created are actually VISIBLE because they have been determined via AI and ML to be of definite benefit to application workloads. The other indexes will be retained up to the threshold defined by AUTO_INDEX_RETENTION_FOR_AUTO and if they have not been used after that threshold expires, they will be automatically purged.
The DBA_AUTO_INDEX_CONFIG data dictionary view contains full information on which aspects and features of AI are currently activated.