ORA-17627: ORA-12154: TNS:could not resolve the connect identifier specified

SQL> Create pluggable database new_pdb from remote_pdb@clone_link keystore identified by my_keystore_password Create pluggable database new_pdb from remote_pdb@clone_link keystore identified by my_keystore_password * ERROR at line 1: ORA-65169: error encountered while attempting to copy file +ORADATA/REMOTE_PDB/F3B8A7FE0E57B5A6E053BB5554646F41/DATAFILE/users_dbfile. 239.2225469957 ORA-17627: ORA-12154: TNS:could not resolve the connect identifier specified ORA-17629: Cannot connect to the remote database server

ORA-01035: ORACLE only available to users with RESTRICTED SESSION privilege

Sessions are returned this error while connecting to instances(s) that are running in restricted mode. DBAs may enable restricted sessions to perform some maintenance tasks or in any other needed situation. We can query (g)v$instance to find out if an instance has restricted mode enabled.

SQL> select logins from gv$instance;   LOGINS ---------- RESTRICTED

ORA-16467: switchover target is not synchronized

 This message clearly tells that standby database that you are trying to swithover to is not fully in sync with the primary database. To solve this problem, you should make sure that all archived redo logs and redo data has fully been applied to the standby database. Sometimes it may appear that standby database is fully in sync, but in fact it is not. If you have not copied the password file from primary to the satandbay after SYS password change on primary database, you may still face this error message during switchover. Always make sure the password files are in sync on all standby site.

ARCH Process Not Working - Killing Archive Process

 If standby database is not in sync with the primary database, there could be several reasons for this. After you have identified the reason and resolved it, log shipping still may not be functional form the primary to the standby. As a last resort, you may want to kill the currently running archive processes on the standby database so that ARC processes are spawned again and could connect to the standby database. In the following I would explain how to kill the ARC process on Unix based as well as Windows based systems.

Finding Top Memory and CPU Consumers Using “top” Command

 Every now and then DBAs need to investigate memory and CPU consumption on database servers. To find out the CPU and memory consumption, “top” is the most commonly used command in Linux environments. “free” is another command to display current memory consumption. Most important part of investigation is to sort the output of ”top” command to find out the top consumers of memory or CPU. In this article I will explain the easiest and simplest way to display top consumers in descending order.

ORA-01105: mount is incompatible with mounts by other instances

 If you face ORA-01105 while starting an Oracle instance in a RAC environment, it means that there is a parameter in init file (of spfile) that is required to have an identical value across all RAC instances. But, the parameter is set differently in the init file of current instance that you are trying to start.

ORA-1105 signalled during: ALTER DATABASE

Alert log would report error similar to the specified above. Snippet from the alert log could be similar to the following

Using Oracle Database Flashback and Creating Restore Point

 Previously I wrote articles about Oracle snapshot standby database and also how to restore a failed over physical standby database back to a physical standby database.  In this article I would explain how to enable and disable oracle database flashback and how to create restore points, especially guaranteed restore points that are very handy in case we need to perform a point-in-time recovery to recover from a user failure. Database must be running in archivelog mode before flashback database feature could be enabled.

Changing Oracle Scheduler Maintenance Windows Timing and Settings

Since the advent of Oracle Scheduler, there have been maintenance windows defined with default setting to run some automatic maintenance jobs like auto gather stats job or auto space advisor job etc. There are scenarios whereby DBAs need to change the maintenance windows setting if maintenance windows span peak hours. By default, maintenance jobs run during nights and weekends as these are the off-peak hours in most of the case. However, this may not be the case for every production database. In this article I would explain how to simply change any maintenance window start time and/or duration. For12c and above, this setting is individually defined in root container and PDBs.