This query will return the session IDs of both the blocking session and the blocked session(s), based on the ID1 and ID2 columns which identify the specific resources that are locked.

SELECT

    blocking.session_id AS "Blocking Session",

    waiting.session_id AS "Blocked Session",

    blocking.id1,

    blocking.id2

FROM v$lock blocking

JOIN v$lock waiting 

    ON (blocking.id1 = waiting.id1 AND blocking.id2 = waiting.id2)

WHERE blocking.session_id != waiting.session_id

    AND waiting.request > 0;

After identifying the blocking session, you can further investigate to find the SQL being executed by that session using a query like this:

SELECT sql_fulltext 

FROM v$sql 

WHERE sql_id = (

    SELECT sql_id 

    FROM v$session 

    WHERE session_id = 'YOUR_BLOCKING_SESSION_ID'

);

Replace `'YOUR_BLOCKING_SESSION_ID'` with the session ID you identified as the blocking session from the first query.

Once you've gathered this information, you can decide on the appropriate action to take, such as waiting for the blocking session to complete its transaction, or, if necessary and safe to do so, terminating the blocking session to release the lock. To terminate a session, use a command like the one below:

ALTER SYSTEM KILL SESSION 'sid,serial#' IMMEDIATE;

Replace `sid,serial#` with the SID and SERIAL# of the blocking session, which you can obtain from the `V$SESSION` view. 

CHECK FOR BLOCKS

SELECT

    l1.sid AS blocking_session,

    l2.sid AS blocked_session,

    l1.id1,

    l1.id2

FROM v$lock l1

JOIN v$lock l2 ON l1.id1 = l2.id1 AND l1.id2 = l2.id2

WHERE l1.block = 1 AND l2.request > 0;

Dropping a context index in Oracle is generally a straightforward process, and typically doesn't require running additional scripts. You can use the `DROP INDEX` statement to drop a context index just like any other index. Here's how you can do it:

DROP INDEX index_name;

Replace `index_name` with the name of the index you want to drop.

However, there are considerations and steps you might want to follow especially if the context index is being used in a production environment:

1. **Backup**: 

   Before dropping the index, ensure that you have a complete backup of your database, or at least the relevant tables and indexes, to prevent accidental data loss.

2. **Check Dependencies**:

   Make sure that no application code or database procedures depend on the index. Some applications might expect the index to be present and might fail if it's dropped.

3. **Check Performance Implications**:

   Understand the performance implications of dropping the index. Dropping an index can significantly affect query performance. You may want to analyze the queries that use the index to ensure they will perform acceptably without it.

4. **Monitor**: 

   After dropping the index, monitor the performance of your system to ensure there are no adverse effects.

5. **Consider Rebuilding Instead of Dropping**:

   If you are dropping the index to get rid of fragmentation or to update it, you might want to consider rebuilding the index instead of dropping it. Rebuilding can often be done online, without blocking DML operations.

ALTER INDEX index_name REBUILD;

6. **Permissions**:

   Ensure that you have the necessary permissions to drop the index. You will need the `DROP ANY INDEX` system privilege, or the `ALTER` object privilege on the table to which the index belongs.

In a development or testing environment, dropping an index is usually a straightforward operation. In a production environment, the additional steps and considerations outlined above are highly advisable to prevent disruptions and data loss.

If there are specific scripts associated with managing your indexes, they would be particular to your system or organization and would not be part of the standard Oracle toolset.