Sunday, December 13, 2015

ORACLE FAL_CLIENT and FAL_SERVER explained


FAL_CLIENT and FAL_SERVER are initialization parameters used to configure log gap detection and resolution at the standby database side of a physical database configuration. This functionality is provided by log apply services and is used by the physical standby database to manage the detection and resolution of archived redo logs.

FAL_CLIENT and FAL_SERVER only need to be defined in the initialization parameter file for the standby database(s). It is possible; however, to define these two parameters in the initialization parameter for the primary database server to ease the amount of work that would need to be performed if the primary database were required to transition its role.


Sample setup:

In Primary site:

FAL_SERVER=STANDBY
FAL_CLIENT=PRIMARY

In Standby site:

FAL_SERVER=PRIMARY
FAL_CLIENT=STANDBY

UNIX Permissions - table

Unix/Linux Permissions:

Here is the list of values and what they stand for in unix folder/directory permissions.Basically it is a simple you can count the value by using octa decimal binary numbers 421 :


See below image 



Value 0 directory listing is 000 = 0+0+0 
Value 1 directory listing is 001 = 0+0+1
Value 2 directory listing is 020 = 0+0+0  

This is where they gain their permission from :

so simple chmod 1 will give execute only permision on file/folder
so simple chmod 2 will give write only permision on file/folder
so simple chmod 3 will write & execute permision on file/folder

chmod 775 test.txt >> this mean 7 for 

UNIX Permissions

ValuePermissionDirectory Listing
0No read, no write, no execute---
1No read, no write, execute--x
2No read, write, no execute-w-
3No read, write, execute-wx
4Read, no write, no executer--
5Read, no write, executer-x
6Read, write, no executerw-
7Read, write, executerwx

Configure second physical standby database - Oracle

I know there are various cases where in we have to setup a second physical standby database in our environments to have a redundant fail over strategy. I don't think there are enough documents out there that outline the process of adding the second standby database. I though I will share these steps today.

Parameters that should be considered while setting up the 2 node (single instance) standby Database.
In my case I will explain the parameters and their usage in setup. I am not going to explain the entire setup here. I you don't know how to setup physical standby database, please refer to this Physical_standby_setup.

At this point I am considering you know how to setup physical standby database and you are looking to add additional node to your setup.

Environments:

ORCL is PRIMARY INSTANCE and is on host        LINUX01   >> Primary Instance
ORCLSTB1 is STANDBY INSTANCE and is on host LINUX02  >> Standby already exists
ORCLSTB2 is STANDBY INSTANCE and is on host LINUX03  >>>  new instance to be added

PARAMETERS to be considered :

ARCHIVE_LOG_DEST_N   >>> this needs to be set to ship your logs to the new node

This is a simple setup that can be used to makes sure all the three nodes will ship logs in case of switch over. In the below image I have configured such a way that each instance will send log files to other when they act as PRIMARY INSTANCE.



Example of Archive_Log_Dest setup

Adding Archive_log Dests:

ON DB SERVER Linux01 (ORCLPRIM):

alter system set log_archive_config='dg_config=(ORCL,ORCLSTB1,ORCLSTB2)';

ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=ORCLSTB1 NOAFFIRM ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=ORCLSTB1';

ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;

ALTER SYSTEM SET LOG_ARCHIVE_DEST_3='SERVICE=ORCLSTB2 NOAFFIRM ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=ORCLSTB2';

ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_3=ENABLE;


ON DB SERVER Linux02 (ORCLSTB1):

alter system set log_archive_config='dg_config=(ORCL,ORCLSTB1,ORCLSTB2)';

ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=ORCLPRIM NOAFFIRM ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=ORCL';

ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;

ALTER SYSTEM SET LOG_ARCHIVE_DEST_3='SERVICE=ORCLSTB2 NOAFFIRM ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=ORCLSTB2';

ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_3=ENABLE;


ON DB SERVER Linux03 (ORCLSTB2):

alter system set log_archive_config='dg_config=(ORCL,ORCLSTB1,ORCLSTB2)';

ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=ORCLPRIM NOAFFIRM ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=ORCL';

ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;

ALTER SYSTEM SET LOG_ARCHIVE_DEST_3='SERVICE=ORCLSTB1 NOAFFIRM ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=ORCLSTB1';

ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_3=ENABLE;




OTHER PARAMETER FILE SETTINGS: 

PFILE DB_* PARAMETERS on DB SERVER1 (Linux01)(ORCL): 

log_archive_config='dg_config=(ORCL,ORCLSTB1,ORCLSTB2)';  >> This is to tell oracle that what all instances are part of this config


*.db_file_name_convert='/ORCLSTB1/','/ORCL/','/ORCLSTB2/','/ORCL/'        -- > add both servers so oracle knows where to create file. 

*.db_name='ORCL'  ### same across all Databases 

*.db_unique_name='ORCL'  ### Unique across each Database 

FAL_SERVER=ORCLSTB1, ORCLSTB2-- > add both servers so oracle knows where to get the archive files from incase of switchover. 

FAL_CLIENT=ORCLThis is always the Current DB server typically standby DB. This is ignored when the DB is in Primary mode 


PFILE DB_* PARAMETERS on DB SERVER2 (Linux02)(ORCLSTB1): 

log_archive_config='dg_config=(ORCL,ORCLSTB1,ORCLSTB2)';
*.db_file_name_convert='/ORCL/','/ORCLSTB1/','/ORCLSTB2/','/ORCLSTB1/' 
*.db_name='ORCL'### same across all Databases 
*.db_unique_name='ORCLSTB1'                    ### Unique across each Database 
*.FAL_CLIENT=STANDBY_SERVER 
*.FAL_SERVER=PRIMARY_SERVERS 


PFILE DB_* PARAMETERS on DB SERVER3 (Linux03)(ORCLSTB2): 


log_archive_config='dg_config=(ORCL,ORCLSTB1,ORCLSTB2)';
*.db_file_name_convert='/ORCLSTB1/','/ORCLSTB2/','/ORCL/','/ORCLSTB2/' 
*.db_name='ORCL'### same across all Databases 
*.db_unique_name='ORCLSTB2'                 ### Unique across each Database 
*.FAL_CLIENT=STANDBY_SERVER 
*.FAL_SERVER=PRIMARY_SERVERS 

Friday, December 11, 2015

DATABASE NAME MAX SIZE in ORACLE



This is for 11gR2:
The length of DB_NAME is limited to 8 characters;
DB_UNIQUE_NAME is limited to 30 characters. DB_UNIQUE_NAME  can contain alphanumeric, underscore (_), dollar ($), and pound (#) characters, but must begin with an alphabetic character.
INSTANCE_NAME defaults to ORACLE_SID. Oracle document does not specify the limit for INSTANCE_NAME length. However if you describe V$INSTANCE view you can see that column INSTANCE_NAME  has VARCHAR2(16), indicating the  limit of 16 characters.
Because INSTANCE_NAME defaults to ORACLE_SID you need to be careful when deciding SID before creating a database. Oracle does not clearly define the limit for SID (system identifier). Following are what I found from two 11gR2 documents about ORACLE_SID.