no-decrypt oracle user

If you don't want to lock user account in oracle database and nobody knows, gets, cracked password of user, you can use this command
SQL> alter user <username>identified by values 'no-decrypt';

For example:
#sqlplus / as sysdba
SQL>  create user passtest identified by passtest;
User created.
SQL> grant connect to passtest;
Grant succeeded.
#sqlplus passtest/passtest
SQL*Plus: Release 11.2.0.2.0 Production on Wed Nov 23 13:55:10 2011
Copyright (c) 1982, 2010, Oracle.  All rights reserved.


#sqlplus / as sysdba
SQL*Plus: Release 11.2.0.2.0 Production on Wed Nov 23 13:58:06 2011
Copyright (c) 1982, 2010, Oracle.  All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> alter user passtest identified by values 'no-decrypt';
User altered.


#sqlplus passtest/passtest
SQL*Plus: Release 11.2.0.2.0 Production on Wed Nov 23 13:59:08 2011
Copyright (c) 1982, 2010, Oracle.  All rights reserved.
ERROR:
ORA-01017: geçersiz kullanıcı adı/parolası; oturum açma reddedildi

Avoiding ORA-01555 errors in Oracle Active Dataguard

Queries on the standby database rely on undo generated on the primary to rollback uncommitted changes. The undo_retention period set at the primary will determine how soon undo can be overwritten and thus will also determine the length of the timing window that a standby query may avoid running into an ORA-01555 error. The occurrence of ORA-01555 is rare when the active standby is operating in realtime apply mode, because the standby recovery will keep pace with the primary.

An ORA-01555 is more likely to be encountered if real-time apply is not enabled, or in situations where a network disconnect or standby outage has resulted an archive log gap. In these cases the elapsed time to complete a redo log file at the primary database can be longer than the time spent by recovery to apply it to the standby database. Lets use as an example the case where it takes the primary 10
minutes to generate 1000MB of redo and takes a standby only 30 seconds to apply (33MB/sec apply rate). If the undo_retention on the primary is set to 10 minutes, the standby has effectively reduced the retention period to 30 seconds for the standby query workload.  If a standby query runs for more than 30 seconds, it is
likely to run into the ORA-01555 error because recovery has already applied more redo that overwrites the rollback segment. If active standby queries experience ORA-01555 errors, first make sure the standby is in real-time apply mode, and if so, also increase the undo_retention period on the primary database

Resetting/Unsetting parameters in oracle database

You can reset  parameter to default. For example, you set parameter sid wrongly when you config db. Then you can reset it with this command.

SQL> alter system set fast_start_mttr_target=1200 scope=spfile sid='wrong_sid';
System altered.
-- You will see "wrong_sid.fast_start_mttr_target=1200" in pfile.

SQL> alter system reset fast_start_mttr_target scope=spfile sid='wrong_sid';
System altered.
-- Cleaned wrong parameter in parameter file.

Output of sql is different about cursor_sharing between exact and force

DB Version: Oracle 11.2.0.2.0
OS: Linux
Problem:
If cursor_sharing parameter is FORCE and there are function based index, you would get wrong output your SQL. For example:

SQL>CREATE INDEX owner.index_name ("sdate" DESC);
SQL>@script.sql


 Process   sdate
--------- -----------
  9630571 


SQL>Drop INDEX owner.index_name;
SQL>@script.sql


 Process   sdate
--------- -----------
  9630571 11/2/2011


Solutions:
--You can set  cursor_sharing to EXACT. But you should test in test db about all problem. This parameter is so effective in database.
SQL> show parameter cursor_sharing
NAME TYPE VALUE
------------------------------------ -------------------------------- ------------------------------
cursor_sharing string FORCE


SQL> alter system set cursor_sharing=EXACT scope=both sid='*';

-- You couldn't set cursor_sharing to EXACT. download and apply patch for Bug 10259620 and test

ORA-01008: not all variables bound- RMAN-03014

RMAN tool'unda ORA-01008 hatasını alarak denk geldiğim bug'ı paylaşmak istedim.

I got  ORA-01008 error with RMAN tool. It is oracle bug. I want to share.
DB version 11.2.0.2, cursor_sharing=FORCE

DBGSQL: TARGET> select nvl(max(al.recid), '0'),nvl(max(al.recid), 0) into :txtparmvalue, :parmvalue from v$archived_log al where al.status in ('X', 'A') and al.is_recovery_dest_file = 'YES' and al.creator = 'RMAN'
DBGSQL: sqlcode = 1008
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup command at 11/02/2011 23:52:15
RMAN-03014: implicit resync of recovery catalog failed
ORA-01008: not all variables bound

For Solution:

• Flush shared pool  . It is temporary solution.         -- alter system flush shared_pool;
• Set cursor_sharing to EXACT                              -- alter system set cursor_sharing=EXACT scope=both sid='*';
• Apply patch. (Patch 9877980)