Hi, I was wondering if the community could help my understanding of smart blob spaces.

Firstly, the problem I am actually trying to solve and why I am dabbling in this: a smart blob space (named cdr_qdata_sbspace) has been created on a primary instance to support enterprise replication and specified in the CDR_QDATA_SBSPACE parameter. We do external backups on an RSS server and the existence of an unlogged sbspace stops us blocking the RSS server. I wish to fix this.

So I need to make the space logged, right?

My understanding is that it is not the space itself which is logged or not but it is a property of every object that may be in it. The space itself has a set of attributes which gets applied to objects when they are created, once of which is "LO_LOG".

Logging can be set as an attribute on the primary like so:
onspaces -ch cdr_qdata_sbspace -Df "LOGGING=ON"
or
EXECUTE FUNCTION task("set sbspace logging on","cdr_qdata_sbspace");

Doing this seems to update all the smart large objects to reflect the new status.

If I set this on the primary the property does not get replicated to the RSS. To my surprise I can also change the logging mode on the RSS independently of the primary. Once the property has got changed on the RSS I have fixed my problem: the space no longer prevents 'onmode -c block' working.

My questions are:
* is this how it is supposed to work?
* if I can alter the logging states, am I creating a potential problem when an object tries to replicate from primary to RSS and cannot be stored without overwriting something not present on the primary?

Ben.

------------------------------
Benjamin Thompson
------------------------------

#Informix

Hi Ben,

seeing now how an sbspace can block 'onmode -c block' on an RSS if the space had been configured with either no or OFF LOGGING default.

As for 'onspaces -ch' not being replicated: that, in my impression, is not quite true, yet the way this is being replicate is not very immediate. In fact what's being replicated are the metadata changes, both for the sbspace as such and for all the LOs being modifed - and that might not immediately be reflected in those structures already resding in memory -> after a secondary restart, you'd see the changes.
It might be debatable whether this is fully satisfying....

Running 'onspaces -ch' on the secondary would, at first glance, faile with an ominous "Changing the sbspace characteristics has resulted in error: 0", and message has "Aborting changes to smartblob space (onspaces -ch command): <space_name>", yet a subsequent 'onstat -g smb s' would show the changes.
-> upon restart they'd be gone again.

So what seems to be required is:

1. running this on primary (onspaces -ch <space_name> -Df LOGGING=ON)
2. restarting secondaries, at least the RSS where you want to perform your backups

BR,
 Andreas

------------------------------
Andreas Legner
------------------------------

Original Message:
Sent: Mon January 20, 2020 11:45 AM
From: Benjamin Thompson
Subject: Help with understanding smart blob space logging

Hi, I was wondering if the community could help my understanding of smart blob spaces.

Firstly, the problem I am actually trying to solve and why I am dabbling in this: a smart blob space (named cdr_qdata_sbspace) has been created on a primary instance to support enterprise replication and specified in the CDR_QDATA_SBSPACE parameter. We do external backups on an RSS server and the existence of an unlogged sbspace stops us blocking the RSS server. I wish to fix this.

So I need to make the space logged, right?

My understanding is that it is not the space itself which is logged or not but it is a property of every object that may be in it. The space itself has a set of attributes which gets applied to objects when they are created, once of which is "LO_LOG".

Logging can be set as an attribute on the primary like so:
onspaces -ch cdr_qdata_sbspace -Df "LOGGING=ON"
or
EXECUTE FUNCTION task("set sbspace logging on","cdr_qdata_sbspace");

Doing this seems to update all the smart large objects to reflect the new status.

If I set this on the primary the property does not get replicated to the RSS. To my surprise I can also change the logging mode on the RSS independently of the primary. Once the property has got changed on the RSS I have fixed my problem: the space no longer prevents 'onmode -c block' working.

My questions are:
* is this how it is supposed to work?
* if I can alter the logging states, am I creating a potential problem when an object tries to replicate from primary to RSS and cannot be stored without overwriting something not present on the primary?

Ben.

------------------------------
Benjamin Thompson
------------------------------

#Informix

Thank you for this response Andreas which is very helpful. My little Docker test system behaves like you describe. It wasn't at all obvious to me a restart would bring the RSS in line with the primary. Without the manual describing what should happen, it's debatable whether this is a bug or feature :)

------------------------------
Benjamin Thompson
------------------------------

Original Message:
Sent: Tue January 21, 2020 12:20 PM
From: Andreas Legner
Subject: Help with understanding smart blob space logging

Hi Ben,

seeing now how an sbspace can block 'onmode -c block' on an RSS if the space had been configured with either no or OFF LOGGING default.

As for 'onspaces -ch' not being replicated: that, in my impression, is not quite true, yet the way this is being replicate is not very immediate. In fact what's being replicated are the metadata changes, both for the sbspace as such and for all the LOs being modifed - and that might not immediately be reflected in those structures already resding in memory -> after a secondary restart, you'd see the changes.
It might be debatable whether this is fully satisfying....

Running 'onspaces -ch' on the secondary would, at first glance, faile with an ominous "Changing the sbspace characteristics has resulted in error: 0", and message has "Aborting changes to smartblob space (onspaces -ch command): <space_name>", yet a subsequent 'onstat -g smb s' would show the changes.
-> upon restart they'd be gone again.

So what seems to be required is:

1. running this on primary (onspaces -ch <space_name> -Df LOGGING=ON)
2. restarting secondaries, at least the RSS where you want to perform your backups

BR,
 Andreas

------------------------------
Andreas Legner

Original Message:
Sent: Mon January 20, 2020 11:45 AM
From: Benjamin Thompson
Subject: Help with understanding smart blob space logging

Hi, I was wondering if the community could help my understanding of smart blob spaces.

Firstly, the problem I am actually trying to solve and why I am dabbling in this: a smart blob space (named cdr_qdata_sbspace) has been created on a primary instance to support enterprise replication and specified in the CDR_QDATA_SBSPACE parameter. We do external backups on an RSS server and the existence of an unlogged sbspace stops us blocking the RSS server. I wish to fix this.

So I need to make the space logged, right?

My understanding is that it is not the space itself which is logged or not but it is a property of every object that may be in it. The space itself has a set of attributes which gets applied to objects when they are created, once of which is "LO_LOG".

Logging can be set as an attribute on the primary like so:
onspaces -ch cdr_qdata_sbspace -Df "LOGGING=ON"
or
EXECUTE FUNCTION task("set sbspace logging on","cdr_qdata_sbspace");

Doing this seems to update all the smart large objects to reflect the new status.

If I set this on the primary the property does not get replicated to the RSS. To my surprise I can also change the logging mode on the RSS independently of the primary. Once the property has got changed on the RSS I have fixed my problem: the space no longer prevents 'onmode -c block' working.

My questions are:
* is this how it is supposed to work?
* if I can alter the logging states, am I creating a potential problem when an object tries to replicate from primary to RSS and cannot be stored without overwriting something not present on the primary?

Ben.

------------------------------
Benjamin Thompson
------------------------------

#Informix