Speed up All Spatial Operations with SPATIAL_VECTOR_ACCELERATION parameter

100's of times faster Spatial operators and functions

I’ve moved my blog from https://insanedba.blogspot.com to https://dincosman.com Please update your bookmarks and follow/subscribe at the new address for all the latest updates and content. More up-to-date content of this post may be available there.

Last week, I tried to diagnose an application problem which mostly consisted of queries related to spatial operators. When I delved into the issue, I discovered that the SPATIAL_VECTOR_ACCELERATION parameter was set to false on my mission-critical databases, despite the spatial component being used effectively.

Although many bloggers had written about it, I was not aware of this parameter. So I wanted to draw everyone's attention to this parameter.

 

According to the Vector Performance Acceleration in Oracle Spatial and Graph (Doc ID 1506885.1), In Oracle Database versions 12c and above, significant enhancements have been made to improve vector operations through the utilization of new vector performance acceleration capabilities. These enhancements lead to better index performance, increased efficiency of the geometry engine, optimized secondary filter optimizations for spatial operators, and enhanced CPU and memory utilization for numerous advanced vector functions. 

Leveraging vector performance acceleration proves particularly advantageous when utilizing Oracle Exadata Database Machine and similar high-scale systems.

Q.  Does Oracle Spatial and Graph require a license in addition to the Oracle Database license?

A.  As of December 2019, Oracle Spatial and Graph is included with the Oracle database license with no additional cost.  

Starting with 23c SPATIAL_VECTOR_ACCELERATION will default to TRUE.  Use of the parameter set to FALSE is deprecated. Since my databases were upgraded from 11g, the parameter was set to FALSE by default.

If you're upgrading a database that effectively uses SPATIAL to 12c or above, ensure to set it. Include this step in the upgrade process.

Parameter can be changed dynamically with the command provided below.

SQL> ALTER SYSTEM SET SPATIAL_VECTOR_ACCELERATION = TRUE;

view raw set_parameter_spatial_accelerate.sql hosted with ❤ by GitHub

Daniel Geringer, Spatial Solutions Specialist from Oracle Corporation advises that with the usage SPATIAL_VECTOR_ACCELERATION parameter, New faster algorithms will be available for spatial operators and functions (100’s of times faster - Best Practices, Tips and Tricks With Oracle Spatial and Graph)

Also According to the Oracle® Spatial and Graph Developer's Guide, Effective with Release 12.2, spatial indexes can be system-managed by specifying INDEXTYPE=MDSYS.SPATIAL_INDEX_V2 at index creation. You are strongly encouraged to use this index type for all new spatial indexes you create, regardless of whether the spatial table or the spatial index is partitioned, and you may also want to use it if you decide to re-create legacy spatial indexes. 

The main benefit is simplified spatial index management. This is most beneficial in cases of partitioning, because this new index type eliminates the need for most, if not all, index partitioning management operations.

I dropped all my existing spatial indexes and recreated them with the INDEXTYPE=MDSYS.SPATIAL_INDEX_V2 attribute. Additionally, I utilized the cbtree_index=true parameter for some point data to leverage composite binary indexes with the aim of improving DML and query performance. 

Measuring the effects:

I used the following query to measure performance and determine if it executes hundreds of times faster or not. You can employ this query for general purposes to measure before and after performance metrics; just restructure the CTE section according to your criteria.

	SQL> WITH queries_to_measure AS (
	SELECT DISTINCT
	sql_id
	FROM
	gv$sql
	WHERE
	parsing_schema_name = :app_user
	AND upper(sql_fulltext) LIKE '%SDO\_%' ESCAPE '\'
	), before_performance AS (
	SELECT
	a.sql_id,
	SUM(buffer_gets_total) / SUM(executions_total) AS gets_per_exec_before,
	SUM(rows_processed_total) / SUM(executions_total) AS rows_per_exec_before,
	SUM(elapsed_time_total) / SUM(executions_total) / 1000000 AS time_per_exec_before,
	SUM(executions_total) AS execs_total_before
	FROM
	dba_hist_sqlstat a,
	queries_to_measure
	WHERE
	a.sql_id = queries_to_measure.sql_id
	AND executions_total > 0
	AND snap_id < (
	SELECT
	MAX(snap_id)
	FROM
	dba_hist_snapshot
	WHERE
	begin_interval_time < to_date(:p_change_time, 'DD/MM/YYYY HH24:MI:SS')
	)
	GROUP BY
	a.sql_id
	ORDER BY
	a.sql_id
	), after_performance AS (
	SELECT
	b.sql_id,
	SUM(buffer_gets_total) / SUM(executions_total) AS gets_per_after,
	SUM(rows_processed_total) / SUM(executions_total) AS rows_per_after,
	SUM(elapsed_time_total) / SUM(executions_total) / 1000000 AS time_per_after,
	SUM(executions_total) AS execs_total_after
	FROM
	dba_hist_sqlstat b,
	queries_to_measure
	WHERE
	b.sql_id = queries_to_measure.sql_id
	AND executions_total > 0
	AND snap_id > (
	SELECT
	MAX(snap_id)
	FROM
	dba_hist_snapshot
	WHERE
	begin_interval_time < to_date(:p_change_time, 'DD/MM/YYYY HH24:MI:SS')
	)
	GROUP BY
	b.sql_id
	ORDER BY
	b.sql_id
	)
	SELECT
	before_performance.*,
	after_performance.*
	FROM
	before_performance,
	after_performance
	WHERE
	before_performance.sql_id = after_performance.sql_id (+);

view raw query_performance_beforeafter.sql hosted with ❤ by GitHub

In my environment, there were almost 500 SQL statements subject to measurement. Most of them were already performing in milliseconds, so I did not observe an improvement worth mentioning; however, 5 to 10 SQL statements performed 50-70 times better.

Hope it helps.