Search this blog

Showing posts with label DBA. Show all posts
Showing posts with label DBA. Show all posts

Monday, March 22, 2010

checking sessions to an Oracle database

Checking the maximum number of sessions:
SQL> select name, value from v$parameter where name='sessions';

Checking the number of currently active sessions:
SQL> select count(*) from v$session;

Looking for blocking sessions:
SQL> select blocking_session from v$session where blocking_session is not NULL;

Looking for idle sessions (more than 24 hours in this example):
SQL> select username from v$session where username is not NULL and status='inactive' and last_call_et/60/60>=24;

Please note that you'll need to be connected as sysdba!

Useful links:
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:209412348074#tom26247484939076

Saturday, March 13, 2010

connecting to a database with sqlplus

Here are some examples:

sqlplus user/password@alias
Here the alias has to be resolved into the full name. This can be done with the tnsnames.ora file or by contacting an LDAP directory. Alternative is to provide all the connect details in line.

sqlplus sys/oracle@orcl as sysdba
While this is handy it's also a potential security risk. In Linux/Unix it might show up in show processes. Before 10g you could use quotes like sqlplus "/ as sysdba", now you safely login with sqlplus / as sysdba

sqlplus /nologon
This prevents the immediate login prompt. Afterwards you connect from the SQL prompt:
SQL> connect sys/oracle@orcl as sysdba
Please note that it's not always necessary to specify the sid.

Tuesday, March 9, 2010

listener.ora – tnsnames.ora – alert log

listener.ora
The listener is a server-side process that listens for database connection requests from user processes and launches dedicated server processes to establish sessions. The sessions become the connections between the user process and the database unless shared servers are in use, in which case a dispatcher process is used to share time to shared server processes.

With local naming the user supplies an Oracle Net service alias for the connect string and this is resolved by a local file into the full network address. This local file is the tnsnames.ora file. There's no need for any relationship between the alias, service name and the instance name - it's recommended to keep them the same! The Service Naming branch of the Net Manager creates or edits the Local Naming tnsnames.ora file that resides in ORACLE_HOME/network/admin directory.

You can configure several listeners in the listener.ora file but they must all have different names and addresses. Under Windows the listener will run as a Windows service, but there's no need to create the service explicitly; it'll be created implicitly the first time the listener is started.

A listener finds out about instances by the process of "registration". For static registration, you hard-code a list of instances in the listener.ora file. Dynamic registration means that the instance itself, at startup time, locates a listener and registers with it.

You can start and stop listeners through Database Control, but there's also a command-line utility lsnrctl.
 
The tnsnames.ora file is a client-side file used for name resolution. It is used by user processes to locate database listeners. It may also be used the instance itself, to locate a listener with which to register.

TNS stands for Transparent Network Substrate

The heart of Oracle Net, a proprietary layered protocol running on top of whatever underlying network transport protocol you choose to use - probably TCP/IP.

The Oracle Net files by default exist in the directory ORACLE_HOME/network/admin. It's possible to relocate them with an environment variable: TNSADMIN. Mainly on systems that have several Oracle Homes. Example on Windows:

set TNSADMIN=c:\oracle\net

alert_.log

The standard Oracle alert log location defined by the initialization parameter DIAGNOSTIC_DEST or USER_DUMP_DEST.

The alert log file, located in the directory specified by the initialization parameter BACKGROUND_DUMP_DEST, contains the most significant routine status messages as well as critical error conditions. When the database is started up or shut down, a message is recorded in the alert log, along with a list of initialization parameters that are different from their default values. In addition, any ALTER DATABASE or ALTER SYSTEM commands issued by the DBA are recorded. Operations involving tablespaces and their datafiles are also recorded here. All error/critical conditions are recorded. The alert log file can be deleted or renamed at any time; it's re-created the next time an alert log message is generated. The trace files for the Oracle instance background processes are also located in BACKGROUND_DUMP_DEST. Trace files are also created for individual user sessions or connections to the database; these are located in the directory specified by the initialization parameter USER_DUMP_DEST. As of Oracle Database 11g Release 1, the diagnostics for an instance are centralized in a single directory specified by the initialization parameter DIAGNOSTIC_DEST.

The DBA will often set up a daily batch job to rename and archive the alert log on a daily basis.

The alert log is a continuous record of critical operations applied to the instance and the database. Its location is determined by the instance parameter BACKGROUND_DUMP_DEST, and its name is alert_SID.log where SID is the name of the instance. The alert log entry for a startup shows all the non-default initialization parameters. Locate the file with this command:

SQL> select value from v$parameter where name='background_dump_dest';

Thursday, March 4, 2010

starting up an instance in different states

NOMOUNT
startup nomount  
Start the instance without mounting a database. This does not allow access to the database and usually would be done only for database creation or the re-creation of control files. The database instance has been started using initialization file, processes are started and memory is allocated.

MOUNT
alter database mount
Start the instance and mount the database, but leave it closed. This state allows for certain DBA activities, but does not allow general access to the database. The instance is started and the control file is opened, read but it's contents are not validated.
 
OPEN
alter database open
startup force restrict 
Start the instance, and mount and open the database. Normal database operation means that an instance is started and the database is mounted and open. This mode allows any valid user to connect to the database and perform data access operations. This can be done in unrestricted mode, allowing access to all users, or in restricted mode, allowing access for database administrators only. Normal database operation means that an instance is started and the database is mounted and open. This mode allows any valid user to connect to the database and perform data access operations. If the database is opened then control file is validated against the physical structure of database. The database is verified that all of it's file are in consistent state. If any of the file is not in consistent state, we may need some sort of recovery.
 
Beginning with Oracle Database 11g Release 2, the preferred (and platform-independent) method of configuring automatic startup of a database is Oracle Restart. Oracle Restart improves the availability of your Oracle database. When you install Oracle Restart, various Oracle components can be automatically restarted after a hardware or software failure or whenever your database host computer restarts.  

References:

Thursday, January 21, 2010

RMAN error – Use CROSSCHECK command to fix status

Our RMAN backup control mail gave an error: x objects could not be deleted for DISK channel(s) due to mismatched status. Use CROSSCHECK command to fix status.

CROSSCHECK is a check to determine whether files on disk or in the media management catalog correspond to the data in the RMAN repository. Because the media manager can mark tapes as expired or unusable, and because files can be deleted from disk or otherwise become corrupted, the RMAN repository can contain outdated information about backups. Crosschecks update outdated RMAN repository information about backups whose repository records do not match their physical status. For example, if a user removes archived logs from disk with an operating system command, the repository still indicates that the logs are on disk, when in fact they are not. The crosscheck command is used to validate RMAN records in the database control file and the recovery catalog against what is physically on the backup media. The crosscheck command can be used on both disk backups and tape backups. You can cross-check the gambit of backups, from database backups and archive-log backups to image copies, the crosscheck command covers them all.

When you run the crosscheck command, any missing backup files will be marked as EXPIRED, meaning that they are no longer on the media where they are expected to be. The list expired command will show you the backups that are expired. You can review this list and then use the delete command to mark the backup files as deleted in the control file and the recovery catalog. The CROSSCHECK command does not delete any files that it is unable to find, but updates their repository records to EXPIRED. Then, you can run DELETE EXPIRED to remove the repository records for all expired files as well as any existing physical files whose records show the status EXPIRED. Expired backups will not show up on this report until the crosscheck command detects they are missing.

Oracle SID should be correctly set, so we'll log on directly.

F:\oracle\rman>rman target =/

We use show all to get the backup retention policy to determine how long backups and archived logs need to be retained for media recovery. You can define a retention policy in terms of backup redundancy or a recovery window. RMAN retains the datafile backups required to satisfy the current retention policy, and any archived redo logs required for complete recovery of those datafile backups. In our case I got RETENTION POLICY TO REDUNDANCY 1 and ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1.

RMAN> show all;

RMAN> delete noprompt obsolete;

Will give the same errors as in our control mail, so let’s do what it wants.

    RMAN> crosscheck archivelog all;

RMAN is not removing all of the files because some of them may still be needed for a full recovery!  It's all about how RMAN defines an obsolete file.  Generally, an obsolete file is one that supplements a full backup that will never be used for a recovery and roll-forward. The Oracle docs note the rules for a file becoming obsolete:
DELETE OBSOLETE does not delete backups required to satisfy the specified retention policy, even if some backups have KEEP UNTIL times set which have passed to override the retention policy.
Backups are never obsolete if they are still needed to meet the retention policy, regardless of any KEEP UNTIL time. With a recovery window-based retention policy, even if the specified KEEP UNTIL time has expired, the backup is retained if the backup is needed to satisfy the recovery window.

With a redundancy-based retention policy, even if the specified KEEP UNTIL time has expired, the backup is retained as long as it is required to satisfy the redundancy requirement. 
You can also use the REDUNDANCY or RECOVERY WINDOW clauses with DELETE to delete backups obsolete under a specific retention policy instead of the configured default:
DELETE OBSOLETE REDUNDANCY = 3;
DELETE OBSOLETE RECOVERY WINDOW OF 7 DAYS;

RMAN> delete noprompt obsolete;

I got a similar error as in the controlemail, this time for the controlefilecopy (32 is here the key):

RMAN> crosscheck controlfilecopy 32;

Now we can delete them:

RMAN> delete noprompt obsolete;

And rerun the last delete to verify if anything’s left:

References:
http://download.oracle.com/docs/cd/B19306_01/backup.102/b14192/maint002.htm
http://users.telenet.be/oraguy.be/rman1.htm
http://download.oracle.com/docs/cd/E11882_01/backup.112/e10643/toc.htm

Wednesday, January 20, 2010

Oracle DBA - managing listener.log

As the listener.log file grows, we'll want to remove or rename it. This will fail as it's "being used by another process".
The DBA can simply stop the service, rename/remove the file and restart the service. This can be problematic for users attempting to connect while the listener's down.

Here's a good way to do this without stopping the TNS listener process. This'll work on Windows and with some small changes on Linux as well (ren = mv):
C:\cd \oracle\product\10.2.0\db_1\NETWORK\log
C:\oracle\product\10.2.0\db_1\NETWORK\log\lsnrctl set log_status off
C:\oracle\product\10.2.0\db_1\NETWORK\log\ren listener.log listener.old
C:\oracle\product\10.2.0\db_1\NETWORK\log\lsnrctl set log_status on

In Oracle 11g, the listener log files by default are located in /diag/tnslsnr/product_name/listener. The nice feature about listener log file in this version is, whenever the size of log file grow to 10MB, Oracle starts to writes to a new file. So the log file will not be too large to open for troubleshooting. Overtime, you will have a lot of 10MB log file in the directory. An Oracle DBA needs to manage the listener log files regularly so the log files will not take too much space on the server.

This is a great link with DBA Tips: http://www.idevelopment.info/