A bug about database restart in Oracle

A bug about database restart in Oracle

The drop database operation is a fatal operation in Oracle. This operation has been experienced in the test environment and will completely delete data files. Therefore, this operation is very sensitive but not practical, this operation cannot be executed at will. In addition to the sensitive permissions, there are still some prerequisites.
In the database open state, you cannot run this command.
SQL> drop database TEST;
Drop database TEST
*
ERROR at line 1:
ORA-00933: SQL command not properly ended

Restart to mount.
SQL> alter database mount exclusive;
Database altered.

SQL> drop database TEST;
Drop database TEST
*
ERROR at line 1:
ORA-00933: SQL command not properly ended
Make sure that the instance is in exclustrict mode.
SQL> drop database; -- it is not easy to execute.
Drop database
*
ERROR at line 1:
ORA-12719: operation requires database is in RESTRICTED mode
SQL> alter system enable restricted session;
System altered.
SQL> drop database;
Database dropped.

Today, a netizen provides two simple commands. Stop the database, restart to Mount, set the restrict mode, and drop the database.
I also tried it in the local test database to see if it can be started in restrict mode. When the result is run, a ORA error is reported and the system exits.
Idle> startup force mount restrict;
ORA-00000: normal, successful completion

In fact, the explanation of oerr is somewhat far-fetched, at least unacceptable to me.
$ Oerr ora 1, 00000
00000,000 00, "normal, successful completion"
// * Cause: Normal exit.
// * Action: None.
After reading this problem on metalink, a post suddenly caught my attention, that is, a wallet setting.
For more information about wallet settings, see my previous cases of MySQL and Oracle password-less logon. Http://blog.itpub.net/23718752/viewspace-1659551/
Related Articles in metalink are Bug 11706168-ORA-00000 during STARTUP with SQLNET. WALLET_OVERRIDE = TRUE (Doc ID 11706168.8)
This is probably the bug I encountered.
Let's simply verify and reproduce it.
If the wallet override feature is enabled, a problem may occur.
Sys @ TEST11G> startup force
ORA-00000: normal, successful completion
Sys @ TEST11G>! Cat sqlnet. ora | grep SQLNET
SQLNET. WALLET_OVERRIDE = true
If disabled, you will find that the instance can be restarted normally.
Idle> startup force
ORACLE instance started.
Total System Global Area 435224576 bytes
Fixed Size 1337044 bytes
Variable Size 272632108 bytes
Database Buffers 155189248 bytes
Redo Buffers 6066176 bytes
Database mounted.
Database opened.
Idle>! Cat sqlnet. ora | grep SQLNET
# SQLNET. WALLET_OVERRIDE = true

The test of this problem is not complete yet. Let's take a deeper look at the scenarios in which this problem will occur.
In fact, restarting the database in the same session also causes problems.
We restart and stop the database in the same session.
Idle> startup
ORACLE instance started.
Total System Global Area 435224576 bytes
Fixed Size 1337044 bytes
Variable Size 272632108 bytes
Database Buffers 155189248 bytes
Redo Buffers 6066176 bytes
Database mounted.
Database opened.
Idle> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
This problem occurs when you restart the instance again. Of course, this problem is related to the wallet.
Idle> startup
ORA-00000: normal, successful completion

Idle>! Cat sqlnet. ora | grep SQLNET
SQLNET. WALLET_OVERRIDE = true

Finally, display the streamlined command to see the effect.
Sys @ TEST11G> startup force mount restrict;
ORACLE instance started.
Total System Global Area 435224576 bytes
Fixed Size 1337044 bytes
Variable Size 272632108 bytes
Database Buffers 155189248 bytes
Redo Buffers 6066176 bytes
Database mounted.
We can see that the database can be quickly restarted to the Mount phase, and then set to restrict mode.
Of course, startup force is a personal local test environment. In the work environment, the relationship is clear, because the consequences are very serious, not to mention destructive operations, even if the use of new features is both cautious and cautious, this is also a significance and value for the existence of our DBA.