From the docs:

"When you issue this statement, the primary database must at least be mounted (and it can also be open)."


Connor - When you say "From the docs" followed by the list of statements, do share the documentation link along with that.

that inturn help us to understand from which manuals are they been listed.

Requested this in past too. Please help us.

https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:9529339800346302436#9529361800346187478
https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:9524161800346321232#9524179800346572419

As we have discuss the sr. oracle suggest to enable to force logging on primary and recreate the dr database .

1.If i will enable force logging on primary why dr database needs to recreate ?
2.We can do the force logging in primary in live then why they ask for downtime ?
3.We can do the same force logging enable on physical standby also.


Thanks

My database is in force logging and I cant change this. However I need to do some huge inserts into a staging table . What is the best solution to do this in direct load with no redo generation?
I precise that this insert is not ahead to the fact tables and could be rerun if failure or error.

Is for instance creating a dedicate temp tablesspace and put my working table into do the trick?
In any solution you may suggest please provide the ddl and dml or a brief example.
Thank you.

SQL> @mystat
Enter value for statname: redo size

NAME                                                              VALUE
------------------------------------------------------------ ----------
redo size                                                         32816
redo size for lost write detection                                    0
redo size for direct writes                                           0

SQL>
SQL> create global temporary table t on commit preserve rows
  2  as select d.* from dba_objects d, ( select 1 from dual connect by level <= 20 );

Table created.

SQL>
SQL> @mystat
Enter value for statname: redo size

NAME                                                              VALUE
------------------------------------------------------------ ----------
redo size                                                         93816
redo size for lost write detection                                    0
redo size for direct writes                                           0

Thank you.
No loading in my staging table should be used by another session after the load.
This is a really painful situation I can't understand why oracle make it with no workaround. I explain : since we are obliged to preserve force logging because of dataguard and thus we are obliged to bulk load in conventional!!
So all the benefits from the good feature called direct load on nologging table are impossible.
I think this is a week conception and oracle should work on it.

Thank you for reply.
Force logging is *not* really an *option* when it comes to preserve sync in dataguard architecture.
It is an oracle recommendation otherwise *its upon tu us".

It is a onetask load where session 1 load in staging table since a java non db server and session 2 uses staging table to load fact ones via plsql procs. So I cant emagine how transportable Tbs will help.
It would be better if force logging could be smarter by being aware of such nologging needed case why not a force nologging keyword on table definition. Or other workarround. There must be something to tell that this load is not to be logged. Although the entire db is in force logging in order to make the primary and the standby reliably sync.
Or maybe another type of tablespaces that are temp for nologging purpose but persistent for multi session use.well I am not oracle arch decider but this situation is a not good point for the software.
Bests.

Cannot find session about the force logging.

What happen is I insert append into a table of primary db that is force logging?
Does it still called direct path?

Hi,

We are not sure how exactly is Oracle behaving since 12c on multitenat architecture if we just set alter database force logging
at CDB level and not at PDB level, per Oracle definitions:

We understand all versions should be behaving as it states for 19c, which we understand it is if you set force logging at cdb level, all pdb will be on force logging mode even if they are not since CDB takes precedence (but we are not sure)




19c and 20:
CDB-wide force logging mode takes precedence over any other setting.
12r1,12r2,18:
CDB-wide force logging mode takes precedence over PDB-level force nologging mode.

We understand all should have 19c behaviour but we need to be sure.

19c states:

https://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/ALTER-PLUGGABLE-DATABASE.html#GUID-A29491AD-8F0F-4E52-9D94-57FC3FF8FBC7

CDB-wide force logging mode takes precedence over any other setting.
PDB-level force logging mode and force nologging mode take precedence over and are independent of any LOGGING, NOLOGGING, or FORCE LOGGING settings you specify for individual tablespaces in the PDB and any LOGGING or NOLOGGING settings you specify for individual database objects in the PDB.

18c states:

CDB-wide force logging mode supersedes PDB-level force nologging mode.
PDB-level force nologging mode takes precedence over and is independent of any LOGGING or FORCE LOGGING settings you specify for individual tablespaces in the PDB and any LOGGING settings you specify for individual database objects in the PDB.

12.2:

https://docs.oracle.com/en/database/oracle/oracle-database/12.2/sqlrf/ALTER-PLUGGABLE-DATABASE.html#GUID-A29491AD-8F0F-4E52-9D94-57FC3FF8FBC7

CDB-wide force logging mode takes precedence over PDB-level force nologging mode.
PDB-level force logging mode and force nologging mode take precedence over and are independent of any LOGGING, NOLOGGING, or FORCE LOGGING settings you specify for individual tablespaces in the PDB and any LOGGING or NOLOGGING settings you specify for individual database objects in the PDB.

12.1:

https://docs.oracle.com/database/121/SQLRF/statements_2008.htm#SQLRF55667

CDB-wide force logging mode takes precedence over PDB-level force nologging mode.
PDB-level force logging mode and force nologging mode take precedence over and are independent of any LOGGING, NOLOGGING, or FORCE LOGGING settings you specify for individual tablespaces in the PDB and any LOGGING or NOLOGGING settings you specify for individual database objects in the PDB.