Which four database parameters might be affected by or …

G:
The STANDBY_ARCHIVE_DEST parameter is deprecated. It is retained for backward compatibility only.
Use STANDBY_ARCHIVE_DEST to specify where archived logs received from a primary database are stored on a standby database. It is no longer necessary to set this parameter, because an appropriate location is automatically chosen.
Reference:
http://oradb-srv.wlv.ac.uk/E50529_01/REFRN/refrn10211.htm#REFRN10211

A,C,D,E,F

A – This is true! If you modify the DB_NAME for the standby database, you will get a error and the database will be not created
B – This is wrong! ARCHIVE_LAG_TARGET limits the amount of data that can be lost and effectively increases the availability of the standby database by forcing a log switch after the specified amount of time elapses. This not affect the standby database creation.
C – This is true! The COMPATIBLE database initialization parameter must be set to the same value on all databases in an Oracle Data Guard configuration, except when using a logical standby database, which can have a higher COMPATIBLE setting than the primary database.
D – This is true! This can make easy to create a standby database, for example, when you install in the same server the primary and standby database.
E – This is true! The DB_UNIQUE_NAME doesn’t need to be specified, in this case, they will be inherited from DBNAME. They just be needed to be specified if you are configuring a standby database in the same database server.
F – This is true! You will need set this to cascade the standby database, for example.
G – This is wrong! This parameter is deprecated.

Oracle Data Guard 11gR2 Administration Beginner’s Guide
——————————————————-

DB_NAME – The DB_NAME parameter specifies the database identifier up to eight characters. This parameter must be the same in all the instances of the RAC database and also in the physical standby database. This parameter is validated at MOUNT status when the instance reads the control file; if the DB_NAME parameter does not match the name of the database mentioned in the control file, you will get the following error:
“ORA-01504: database name ‘Dummy’ does not match parameter db_name ‘orcl'”
You don’t need to configure or change this parameter in the Data Guard physical standby configuration.

DB_UNIQUE_NAME – This parameter specifies a unique name for each database having the same DB_NAME parameter. This parameter must be different on the primary, standby, or logical standby database. The DB_UNIQUE_NAME parameter is limited to 30 characters. It can contain alphanumeric, underscore (_), dollar ($), and pound (#) characters but must begin with an alphabetic character. This parameter is static, so it requires bouncing the database in order to change this parameter. If this parameter is not set explicitly, its value will be the same as that of the DB_NAME parameter.

FAL_SERVER – This parameter specifies from where the standby database should request missing archived logs if there is a gap in the logs. It is used only when the database is in the standby role and has a gap in the received archived logs. A redo gap occurs when the redo transport doesn’t run for a while. A maintenance operation on the standby server or a network interruption may cause this. Setting this parameter allows the standby to find the missing redo and have it transported. On the standby database, you need to set the Oracle Net Service name of the primary database as the value of this parameter. Also, taking account of a possible switchover, don’t forget to set FAL_SERVER on the primary database with the value of the standby database service name.

The FAL_CLIENT parameter is no longer required in 11g. In earlier releases, you set the FAL_CLIENT parameter on the standby database, and the value is the Oracle Net Service name that the primary database uses to connect the standby database. In 11g, when it’s not set, the primary database will obtain the client service name from the related LOG_ARCHIVE_DEST_n parameter.

Oracle® Data Guard – Concepts and Administration 12c Release 1 (12.1) – E48552-07
———————————————————————————

The COMPATIBLE database initialization parameter must be set to the same value on all databases in an Oracle Data Guard configuration, except when using a logical standby database, which can have a higher COMPATIBLE setting than the primary database.

DB_NAME – On a primary database, specify the name used when the database was created. On a physical standby database, use the DB_NAME of the primary database.

DB_UNIQUE_NAME – Specify a unique name for each database. This name stays with the database and does not change, even if the primary and standby databases reverse roles.

FAL_SERVER – Specify the Oracle Net service name of the FAL server (typically this is the database running in the primary role). When the Chicago database is running in the standby role, it uses the Boston database as the FAL server from which to fetch (request) missing archived redo log files if Boston is unable to automatically send the missing log files.

DB_FILE_NAME_CONVERT – Specify the path name and filename location of the standby database data files followed by the primary location. This parameter converts the path names of the primary database data files to the standby data file path names. Note that this parameter is used only to convert path names for physical standby databases. Multiple pairs of paths may be specified by this parameter.

Oracle Data Guard 11g Handbook
DB_UNIQUE_NAME This parameter defines the unique name for a database. Since the DB_NAME parameter must be the same for a physical standby database and different for a logical standby database, this was introduced in 10g to provide a way to identify each database in a Data Guard configuration. You need to set this on all of your databases, but it does require a bounce. If the parameter is not defined, it is defaulted to the DB_NAME, which means you do not have to take an outage on production to create a standby
…
Ensure the COMPATIBLE initialization parameter is set to the same value on both the primary and standby databases. If the values differ, redo transport services may be unable to transmit redo data from the primary database to the standby databases.