One question I was asking is if the standby_file_management parameter is relevant in a Dbvisit environment with Oracle Standard Edition. I did some tests and I show here what I did.
We suppose that the Dbvisit is already set and that the replication is fine
[oracle@dbvisit1 trace]$ /u01/app/dbvisit/standby/dbvctl -d dbstd -i ============================================================= Dbvisit Standby Database Technology (9.0.08_0_g99a272b) (pid 19567) dbvctl started on dbvisit1: Fri Jan 17 16:48:16 2020 ============================================================= Dbvisit Standby log gap report for dbstd at 202001171648: ------------------------------------------------------------- Description | SCN | Timestamp ------------------------------------------------------------- Source 2041731 2020-01-17:16:48:18 +01:00 Destination 2041718 2020-01-17:16:48:01 +01:00 Standby database time lag (DAYS-HH:MI:SS): +00:00:17 Report for Thread 1 ------------------- SOURCE Current Sequence 8 Last Archived Sequence 7 Last Transferred Sequence 7 Last Transferred Timestamp 2020-01-17 16:48:07 DESTINATION Recovery Sequence 8 Transfer Log Gap 0 Apply Log Gap 0 ============================================================= dbvctl ended on dbvisit1: Fri Jan 17 16:48:23 2020 ============================================================= [oracle@dbvisit1 trace]$
While the standby_file_management is set to MANUAL on both servers
[oracle@dbvisit1 trace]$ sqlplus / as sysdba SQL*Plus: Release 19.0.0.0.0 - Production on Fri Jan 17 16:50:50 2020 Version 19.3.0.0.0 Copyright (c) 1982, 2019, Oracle. All rights reserved. Connected to: Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production Version 19.3.0.0.0 SQL> select open_mode from v$database; OPEN_MODE -------------------- READ WRITE SQL> show parameter standby_file_management; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ standby_file_management string MANUAL SQL> [oracle@dbvisit2 back_dbvisit]$ sqlplus / as sysdba SQL*Plus: Release 19.0.0.0.0 - Production on Fri Jan 17 16:51:15 2020 Version 19.3.0.0.0 Copyright (c) 1982, 2019, Oracle. All rights reserved. Connected to: Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production Version 19.3.0.0.0 SQL> select open_mode from v$database; OPEN_MODE -------------------- MOUNTED SQL> show parameter standby_file_management; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ standby_file_management string MANUAL SQL>
Let’s create a tablespace MYTAB on the primary database
SQL> create tablespace mytab datafile '/u01/app/oracle/oradata/DBSTD/mytab01.dbf' size 10M; Tablespace created. SQL> SQL> alter system switch logfile; System altered. SQL> select name from v$tablespace; NAME ------------------------------ SYSAUX SYSTEM UNDOTBS1 USERS TEMP MYTAB 6 rows selected. SQL> select name from v$datafile; NAME -------------------------------------------------------------------------------- /u01/app/oracle/oradata/DBSTD/system01.dbf /u01/app/oracle/oradata/DBSTD/sysaux01.dbf /u01/app/oracle/oradata/DBSTD/undotbs01.dbf /u01/app/oracle/oradata/DBSTD/mytab01.dbf /u01/app/oracle/oradata/DBSTD/users01.dbf SQL>
A few moment we can see that the new datafile is replicated on the standby
SQL> select name from v$tablespace; NAME ------------------------------ SYSAUX SYSTEM UNDOTBS1 USERS TEMP MYTAB 6 rows selected. SQL> select name from v$datafile 2 ; NAME -------------------------------------------------------------------------------- /u01/app/oracle/oradata/DBSTD/system01.dbf /u01/app/oracle/oradata/DBSTD/sysaux01.dbf /u01/app/oracle/oradata/DBSTD/undotbs01.dbf /u01/app/oracle/oradata/DBSTD/mytab01.dbf /u01/app/oracle/oradata/DBSTD/users01.dbf SQL>
Now let’s repeat the tablespace creation while the parameter is set to AUTO on both side
SQL> show parameter standby_file_management; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ standby_file_management string AUTO SQL> create tablespace mytab2 datafile '/u01/app/oracle/oradata/DBSTD/mytab201.dbf' size 10M; Tablespace created. SQL> SQL> alter system switch logfile; System altered. SQL>
A few moment later the tablespace mytab2 was also replicated on the standby
SQL> select name from v$tablespace; NAME ------------------------------ SYSAUX SYSTEM UNDOTBS1 USERS TEMP MYTAB MYTAB2 7 rows selected. SQL> select name from v$datafile; NAME -------------------------------------------------------------------------------- /u01/app/oracle/oradata/DBSTD/system01.dbf /u01/app/oracle/oradata/DBSTD/mytab201.dbf /u01/app/oracle/oradata/DBSTD/sysaux01.dbf /u01/app/oracle/oradata/DBSTD/undotbs01.dbf /u01/app/oracle/oradata/DBSTD/mytab01.dbf /u01/app/oracle/oradata/DBSTD/users01.dbf 6 rows selected.
In Dbvisit documentation we can find this
Note 2: This feature is independent of the Oracle parameter STANDBY_FILE_MANAGEMENT. Dbvisit Standby will detect if STANDBY_FILE_MANAGEMENT has added the datafile to the standby database, and if so, Dbvisit Standby will not add the datafile.
Note 3: STANDBY_FILE_MANAGEMENT can only be used in Enterprise Edition and should not be set in Standard Edition.
Dbvisit does not use STANDBY_FILE_MANAGEMENT for datafile replication. So I decide to set this value to its default value which is MANUAL.
What about adding tempfile in a dbvisit environment. In the primary I create a new temporary tablespace
SQL> show parameter standby_file_management; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ standby_file_management string MANUAL SQL> create temporary tablespace temp2 tempfile '/u01/app/oracle/oradata/DBSTD/temp2_01.dbf' size 10M; Tablespace created. SQL> alter system switch logfile; System altered. SQL>
We can see on the primary that we now have two tempfiles.
SQL> select name from v$tablespace; NAME ------------------------------ SYSAUX SYSTEM UNDOTBS1 USERS TEMP MYTAB MYTAB2 TEMP2 8 rows selected. SQL> select name from v$tempfile; NAME -------------------------------------------------------------------------------- /u01/app/oracle/oradata/DBSTD/temp01.dbf /u01/app/oracle/oradata/DBSTD/temp2_01.dbf SQL>
On standby side, the new temporary tablespace was replicated.
SQL> select name from v$tablespace; NAME ------------------------------ SYSAUX SYSTEM UNDOTBS1 USERS TEMP MYTAB MYTAB2 TEMP2 8 rows selected.
But the new tempfile is not listed on the standby
SQL> select name from v$tempfile; NAME -------------------------------------------------------------------------------- /u01/app/oracle/oradata/DBSTD/temp01.dbf SQL>
In fact it’s the expected behavior. In the documentation we can find following
If your preference is to have exactly the same number of temp files referenced in the standby control file as your current primary database, then once a new temp file has been added on the primary, you need to recreate a standby control file by running the following command from the primary server:
dbvctl -f create_standby_ctl -d DDC
So let’s recreate the standby control file
[oracle@dbvisit1 ~]$ /u01/app/dbvisit/standby/dbvctl -f create_standby_ctl -d dbstd
=>Replace current standby controfiles on dbvisit2 with new standby control
file? [No]: yes
>>> Create standby control file... done
>>> Copy standby control file to dbvisit2... done
>>> Recreate standby control file... done
>>> Standby controfile(s) on dbvisit2 recreated. To complete please run dbvctl on the
primary, then on the standby.
[oracle@dbvisit1 ~]$
And then after we can verify that the new tempfile is now visible at standby side
SQL> select name from v$tempfile; NAME -------------------------------------------------------------------------------- /u01/app/oracle/oradata/DBSTD/temp01.dbf /u01/app/oracle/oradata/DBSTD/temp2_01.dbf SQL>
Cet article Dbvisit 9: Adding datafiles and or tempfiles est apparu en premier sur Blog dbi services.