Learn Database Concepts

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/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 Value Permission Directory Listing 0 No read, no write, no execute --- 1 No read, no write, execute --x 2 No read, write, no execute -w- 3 No read, write, execute -wx 4 Read, no write, no execute r-- 5 Read, no write, execute r-x 6 Read, write, no execute rw- 7 Read, write, execute rwx

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 ...

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 ...