Indexes Definition Improvements - (Oracle DB) - oracle

Question

I have the following table definition and want to improve indexes:
CREATE TABLE MATE (
GUID NUMBER(38,0),
SITE_KEY NUMBER(38,0),
LAST_NAME VARCHAR2(200),
FIRST_NAME VARCHAR2(200),
BOOKING_NUM VARCHAR2(200),
RELEASE_DATE DATE,
STATUS VARCHAR2(200), -- Contains 'ACTIVE', 'RELEASED', 'DELETED', 'EXCLUDED', 'INACTIVE' and NULL
CONSTRAINT SYS_C008630 CHECK ("GUID" IS NOT NULL),
CONSTRAINT SYS_C008631 CHECK ("SITE_KEY" IS NOT NULL),
CONSTRAINT SYS_C008632 PRIMARY KEY (GUID, SITE_KEY),
CONSTRAINT FK8100EDAADECFC243 FOREIGN KEY (SITE_KEY) REFERENCES SITES<KEY>()
);
CREATE UNIQUE INDEX SYS_C008632 ON MATE (GUID, SITE_KEY); -- This is the PK (1)
CREATE INDEX IDX_STATUS ON MATE (STATUS); -- (2)
CREATE INDEX IDX_SITE_KEY ON MATE (SITE_KEY); -- (3)
CREATE INDEX IDX_BOOKING_NUMBER ON MATE (BOOKING_NUM); -- (4)
CREATE INDEX IDX_FNAME ON MATE (FIRST_NAME); -- (5)
CREATE INDEX IDX_LNAME ON MATE (LAST_NAME); -- (6)
CREATE INDEX BRIAN2_IX ON MATE (SITE_KEY,BOOKING_NUM); -- (7)
CREATE INDEX IDX_SITE_STATUS ON MATE (SITE_KEY,STATUS); -- (8)
CREATE INDEX IDX_PIN_SITEKEY ON MATE (BOOKING_NUM,SITE_KEY); -- (9)
CREATE INDEX IDX_SITE_NAME_STATUS ON MATE (SITE_KEY,LAST_NAME,STATUS); -- (10)
CREATE UNIQUE INDEX IDX_GUID_SITE_BOOKING ON MATE (GUID, SITE_KEY, BOOKING_NUM); -- (11)
CREATE UNIQUE INDEX IXU_SITE_BOOKING_GUID ON MATE (SITE_KEY, BOOKING_NUM, RELEASE_DATE, GUID); -- (12)
Is logical to:
Drop Index (7) because is already defined in (9)?
Drop Index (3) because is the left most in (8) and (10)?
Drop index (4) because is the left most in (9)?
Drop index (12) because SITE_KEY, BOOKING_NUM, GUID is already as UNIQUE Index in (11)?
Any other improvement?

Answer 1

You can't optimize indexes only by looking at their definition. You need to know how the indexes are used before you remove them.
Your Indexes Are Not Necessarily Redundant
For items #1 and #3, there are rare cases where you want to have two indexes that only differ based on the column order. For example, with the below two queries, it helps to have an index with both columns so you can avoid reading from the table. And the two different leading columns work better for each query. Having only one index is usually good enough, but maybe these are critical queries that need to be thoroughly optimized.
SELECT A, B FROM TABLE1 WHERE A = 1;
SELECT A, B FROM TABLE1 WHERE B = 2;
For items #2 and #4, the single-column indexes may be optimized for filtering, whereas the multi-column indexes may be optimized for index fast full scans (where the index acts like a skinny version of the table). For example, with the below queries, the first one runs best with an index on only column A, because that index is smaller and will be faster to read and more likely to fit in your cache. But the second query works best if there is an index on (A,B,C). Having the single, larger index is usually good enough, but not always.
SELECT * FROM TABLE1 WHERE A = 1;
SELECT A, B, C FROM TABLE1;
Which Indexes Are Necessary?
To find out which indexes are necessary, you should use index usage tracking. Fully optimizing indexes is a long, difficult process. But if you've gathered a list of suspicious indexes, and they are not used by any SQL statements, then they're probably safe to drop.
--Check that index statsitics are collected.
select * from gv$index_usage_info;
--Check which indexes are used.
select * from dba_index_usage order by last_used desc;
--Find recent SQL statements that used the index.
select * from gv$sql_plan where object_owner = 'JHELLER' and object_name = 'TEST1_IDX';
--Find historical SQL statements that used the index.
select * from dba_hist_sql_plan where object_owner = 'JHELLER' and object_name = 'TEST1_IDX';