In Oracle, there's no built-in mechanism that explicitly records when a row is deleted from a table unless you've specifically set up auditing or implemented custom tracking. However, there are a few approaches to find out when data might have been deleted:

### 1. **Flashback Query**:

If the deletion was recent, and if your database has flashback query enabled, you can use Oracle's Flashback Query feature to see a past state of the data. This allows you to see the table's data as it existed at a specific point in time. However, this won't directly tell you the deletion timestamp, but it can help confirm if data existed at one point and not at another.

Example:

```sql

SELECT * FROM your_table AS OF TIMESTAMP (SYSTIMESTAMP - INTERVAL '10' MINUTE);

```

### 2. **Oracle Auditing**:

If auditing was enabled on the table, you would be able to see when delete operations occurred. Oracle provides a comprehensive auditing mechanism that can track DML (INSERT, UPDATE, DELETE) on specific tables if set up correctly.

Example to enable auditing on a table:

```sql

AUDIT DELETE ON your_schema.your_table BY ACCESS;

```

After it's enabled, you can query the `DBA_AUDIT_TRAIL` view to see the audit records.

### 3. **Triggers**:

If you had a trigger on the table that recorded deletions (e.g., into an audit log table), you could refer to that log. This would require prior setup, where a trigger would capture the delete action and log necessary details to another table.

Example of a simple trigger that logs deletions:

```sql

CREATE OR REPLACE TRIGGER trg_after_delete

AFTER DELETE ON your_table

FOR EACH ROW

BEGIN

   INSERT INTO audit_log (action, table_name, timestamp) VALUES ('DELETE', 'your_table', SYSDATE);

END;

/

```

### 4. **Redo Logs / Archived Logs**:

In extreme cases, if the data is crucial, and none of the above methods are feasible, you can consider diving into the redo logs or archived logs using log miners. This is a more complex approach and usually requires assistance from a DBA.

### 5. **Backup Data**:

If you regularly back up your database, you might be able to identify the deletion by comparing the data between backups.

### Conclusion:

The above methods mostly require pre-emptive measures to track deletions. It's a good practice to set up some level of auditing or logging if you anticipate needing this kind of information in the future. If none of these measures were in place at the time of deletion, recovering the exact time of deletion can be very challenging.