Drop database; SQL*Plus command

This command was introduced in Oracle10g and is very efficient.
The command will clean up all datafiles, online redo log files, controlfiles and spfile. It will not touch pfile & password file. On windows server, the service need to be deleted manually.
In case, one wants to remove archivelogs & backups execute this command from RMAN using the 'Including backups' option.
Word of caution here:::All RMAN backups associated with target database will be deleted from all configured device types.
Steps:

shutdown abort;  
startup mount exclusive restrict;   
drop database;  

Oracle mentions in it's document... that user must have SYSDBA system privilege to issue this statement. The database must be mounted in exclusive and restricted mode, and it must be closed.

Link::

http://download.oracle.com/docs/cd/E11882_01/server.112/e17118/statements_8009.htm#i215798

Logical Standby SQL apply not re-starting

Errors ORA-00604 & ORA-01425 while restarting SQL apply for logical standby.
When one starts the SQL apply on the database...

SQL>Alter database start logical standby apply immediate;  
Database altered 

Oracle starts the SQL apply but subsequently it fails. In the alert log one would find the following errors..

Errors detected in process 16, role LOGICAL STANDBY COORDINATOR.  
krvsqn2s: unhandled failure 604:  
ORA-00604: error occurred at recursive SQL level 1  
ORA-01425: escape character must be character string of length 1  

There would be an associated trace file, which would show...

*** SERVICE NAME:(SYS$BACKGROUND) 2011-03-08 12:21:04.572  
*** SESSION ID:(632.180) 2011-03-08 12:21:04.572  
ORA-00604: error occurred at recursive SQL level 1  
ORA-01425: escape character must be character string of length 1  
knahcapplymain: encountered error=604  
*** 2011-03-08 12:21:04.619  
ksedmp: internal or fatal error  
ORA-00604: error occurred at recursive SQL level 1  
ORA-01425: escape character must be character string of length 1  

This is due to a Bug: 5108158 which is fixed in Oracle11g. Well!! I have heard that this is when we set logical standby to skip some schemas. Anyhow, this was not the case in our standby database neither could I find this skip schemas reason documented by Oracle !! :)
There is a workaround which would get the SQL apply to re-start. The workaround is documented in metalink 748208.1

SQL>--Ensure SQL apply is stopped  
SQL> Alter database stop logical standby apply;  
SQL>set echo on   
SQL>set pagesize 100   
SQL>spool workaround.log   
SQL>select * from system.logstdby$skip;   
SQL>select distinct nvl(esc, 'NULL') from system.logstdby$skip;   
SQL>select * from system.logstdby$skip where esc is null;   
SQL>update system.logstdby$skip set esc = '\'  where esc is NULL;  
-- Following should return no rows (due to update above)   
SQL>select * from system.logstdby$skip where esc is null;   
-- should no longer see any NULL in output   
SQL>select distinct nvl(esc, 'NULL') from system.logstdby$skip;   
-- Capture a snapshot of the final results   
SQL>select * from system.logstdby$skip;   
-- commit changes   
SQL>commit;   
--Restart the SQL apply and check the alert log.  
SQL> Alter database start logical standby apply immediate;  
SQL>Spool Off;  

In case, still SQL apply does not start, then immediately contact oracle support.