This week, I was teaching an 11g Data Guard course in Duesseldorf – my home location. One question that arose in that course was, whether it is possible to run a Logical Standby Database not beeing in archive mode.

Brief explanation: Unlike Physical Standby Databases, the Logical Standby is a quite independent Database that tries to do the same SQL Statements that arose at the Primary to keep up to date with it. In order to be able to do so, it gets the redo protocol transmitted from the primary and analyzes it (with Logminer technique). That redo protocol is stored in Archive Logs on the Logical Standby, which can’t be turned off, of course.

But also, when the SQL Apply on the standby changes blocks, it writes its own redo protocol into its own Online Logfiles and (by default) archives them. Sometimes, this is not needed, because customers use their Logical Standby as kind of „cheap replication“ and do not use it for HA purpose. So can we turn off Archive Logging on the Logical Standby? I saw that in place already at a (not reference, unfortunately) customer site, so the short answer was:  Yes, we can 🙂

I tested it then myself and it really works. We can turn off archivelogging on the Logical Standby even with usage of the Data Guard Broker and with no warnings from it. But it seems, as if that is only possible with archiver transmission from the Primary to the Logical Standby. Otherwise (with LogXptMode async or sync), the transmission to the Logical Standby stops.

Being in Norway this week, I have again the pleasure to teach an 11g Data Guard course. I always try to get a hotel close to the education center to be able to walk over there, but I didn’t get the right direction on the first day and had to use a taxi instead. Fortunately, the Norwegians are friendly and helpful and like to explain to a stranger where to find the next taxi stand 🙂

One of the student asked how we can handle the situation, if we have a Logical Standby Database and want to add datafiles to the primary, while the Logical Standby DB uses an other directory structure than the Primary. Putting the parameter standby_file_management to auto and also setting db_file_name_convert appropriately is not sufficient in this case, as it is for a Physical Standby Database. Well, I searched through the documentation and found the following remedy:

Connect to the Logical Standby DB as sys and then

create or replace procedure sys.handle_tbs_ddl
(
  old_stmt  in  varchar2,
  stmt_typ  in  varchar2,
  schema    in  varchar2,
  name      in  varchar2,
  xidusn    in  number,
  xidslt    in  number,
  xidsqn    in  number,
  action    out number,
  new_stmt  out varchar2
) as
begin
  new_stmt := replace(old_stmt,
                     '/home/oracle/prima',
                     '/home/oracle/logst');

  action := dbms_logstdby.skip_action_replace;

exception
  when others then
    action := dbms_logstdby.skip_action_error;
    new_stmt := null;
end;
/

--------------------------------------------------------------------

-- LSP has to be stopped before we can do the next step

--------------------------------------------------------------------

alter database stop logical standby apply;

begin
dbms_logstdby.skip (stmt=>'tablespace',proc_name=>'sys.handle_tbs_ddl');
end;
/

alter database start logical standby apply immediate;

You can now create Tablespaces and/or add Datafiles on the Primary and they are automatically created on the Logical Standby as well.

You could also take an reactive approach and let the create tablespace action on the Primary crash the SQl Apply on the Logical Standby and then skip that DDL and create the tablespace manually on the Logical SB. But this approach above seems to be more elegant and leaves you with less administrative tasks to do. Thanks to Cecilie Sander for asking that question!

This week, I am in Kista (Sweden, near Stockholm) teaching an 11g Data Guard course. Boy, I love my job! Not only does it give me the opportunity to talk to intelligent, open minded people, I can also travel through the world and visit interesting countries  -not to mention, that I can make a living from it 🙂

One of the students asked, whether a resize of a datafile on the primary database would also be reproduced at the standby database – and then simply tested it live to see that it is actually done. That is the good thing about having courses with practices: You can simply try out things and don’t have to speculate about it.

Thanks to Niklas Isaksson for pointing out, that a resize of datafiles on the primary is reproduced on the standby! To be honest, I wasn’t sure about that, but now I am 🙂