IDS 9.4 on HP-UX 11.11

We have been trying to get HDR running, and we have blobs located in
blob pages. The following pages from the Admin Guide make it clear
that blobs in blob pages will not be replicated. It does not seem to
say that you can't use HDR, simply that the blobs won't get sent to
the secondary.

Page 19-4:
Type of Data Replicated
HDR replicates data in dbspaces and sbspaces. HDR does not replicate
data in
blobspaces.



Page 20-5

The data must reside in dbspaces or sbspaces
If your primary database server has simple large objects stored in
blobspaces, **modifications to the data within those blobspaces is not
replicated** as part of normal HDR processing. However,
simple-largeobject
data within dbspaces is replicated.
Smart large objects, which are stored in sbspaces, are replicated. The
sbspaces must be logged. User-defined types (UDTs) are replicated,
unless they have out-of-row data stored in operating system files.
Data types with out-of-row data are replicated if the data is stored
in
an sbspace or in a different table on the same database server.

To me the "**" sentence seems to indicate an HDR pair up and running,
but the blobs from the primary are not getting replicated.

We have managed to get HDR up and running, but when we make a
modification to a blob the secondary creates an assert failure and
marks the chunks in the blobspace as offline. This is fine with me,
the secondary keeps going along as if nothing happened. However if we
take the secondary down and bring it back up, it refuses to come back
up complaining that the blobspaces are offline and a level zero
restore is required to get the secondary back up.

The questions I have (finally) are:

Is anyone out there successfully running HDR with blobs in blobspaces?
What does HDR tell you about blobs? Do you get assert failures on
your blobspaces? Can you bring the secondary down and back up without
having to restore from tape (basically starting HDR up again from
scratch).

Thank you in advance
--Scott

HDR is a replication based on the transaction records in the logical
logs. The transaction records are copied to the secondary server, which
makes "roll forward" operations.

When blobs (of data type BYTE or TEXT) are stored in blobspaces, the
blobs are not in the transaction records. Thus the secondary server
cannot insert the blob. Having blobs in blobspaces reduces the logical
log usage significantly.

If blobs are stored in the standard dbspaces the content of the blobs
are written to the transaction records, and HDR can replicate the blobs.

You can change the table layout, so blobs are stored within the
tablespace in order to make HDR work. Besides the increased sizes of
tablespaces you might also see a degradation of performance.

Alternatively you can change the blobs to smart large objects (data type
CLOB or BLOB) and store the blobs in smart blob spaces. The blobs will
then be replicated with HDR. Unfortunately with a change like this, you
will also have to make changes in your applications.

Scott Black wrote:
> IDS 9.4 on HP-UX 11.11
>
> We have been trying to get HDR running, and we have blobs located in
> blob pages. The following pages from the Admin Guide make it clear
> that blobs in blob pages will not be replicated. It does not seem to
> say that you can't use HDR, simply that the blobs won't get sent to
> the secondary.
>
> Page 19-4:
> Type of Data Replicated
> HDR replicates data in dbspaces and sbspaces. HDR does not replicate
> data in
> blobspaces.
>
>
>
> Page 20-5
>
The data must reside in dbspaces or sbspaces
> If your primary database server has simple large objects stored in
> blobspaces, **modifications to the data within those blobspaces is not
> replicated** as part of normal HDR processing. However,
> simple-largeobject
> data within dbspaces is replicated.
> Smart large objects, which are stored in sbspaces, are replicated. The
> sbspaces must be logged. User-defined types (UDTs) are replicated,
> unless they have out-of-row data stored in operating system files.
> Data types with out-of-row data are replicated if the data is stored
> in
> an sbspace or in a different table on the same database server.
>
> To me the "**" sentence seems to indicate an HDR pair up and running,
> but the blobs from the primary are not getting replicated.
>
> We have managed to get HDR up and running, but when we make a
> modification to a blob the secondary creates an assert failure and
> marks the chunks in the blobspace as offline. This is fine with me,
> the secondary keeps going along as if nothing happened. However if we
> take the secondary down and bring it back up, it refuses to come back
> up complaining that the blobspaces are offline and a level zero
> restore is required to get the secondary back up.
>
> The questions I have (finally) are:
>
> Is anyone out there successfully running HDR with blobs in blobspaces?
> What does HDR tell you about blobs? Do you get assert failures on
> your blobspaces? Can you bring the secondary down and back up without
> having to restore from tape (basically starting HDR up again from
> scratch).
>
> Thank you in advance
> --Scott

Scott,

I agree that secondary should not crash with blobspace blob update on
primary. If you have a test case, you should open a case with IBM
support. I tried couple of simple scenario and could not reproduce it.

Having said that, I am not sure how are you going to handle your
failure if blob data is not available on secondary. Are you using HDR
for some other purpose? Since high availability requirement is not
met, it will be difficult to find people using blobspace blob with
HDR.

-ajay

Claus Samuelsen <csa@eye-bee-em.com> wrote in message news:<41679cd6$0$59395$14726298@news.sunsite.dk>.. .
> HDR is a replication based on the transaction records in the logical
> logs. The transaction records are copied to the secondary server, which
> makes "roll forward" operations.
>
> When blobs (of data type BYTE or TEXT) are stored in blobspaces, the
> blobs are not in the transaction records. Thus the secondary server
> cannot insert the blob. Having blobs in blobspaces reduces the logical
> log usage significantly.
>
> If blobs are stored in the standard dbspaces the content of the blobs
> are written to the transaction records, and HDR can replicate the blobs.
>
> You can change the table layout, so blobs are stored within the
> tablespace in order to make HDR work. Besides the increased sizes of
> tablespaces you might also see a degradation of performance.
>
> Alternatively you can change the blobs to smart large objects (data type
> CLOB or BLOB) and store the blobs in smart blob spaces. The blobs will
> then be replicated with HDR. Unfortunately with a change like this, you
> will also have to make changes in your applications.
>
> Scott Black wrote:
> > IDS 9.4 on HP-UX 11.11
> >
> > We have been trying to get HDR running, and we have blobs located in
> > blob pages. The following pages from the Admin Guide make it clear
> > that blobs in blob pages will not be replicated. It does not seem to
> > say that you can't use HDR, simply that the blobs won't get sent to
> > the secondary.
> >
> > Page 19-4:
> > Type of Data Replicated
> > HDR replicates data in dbspaces and sbspaces. HDR does not replicate
> > data in
> > blobspaces.
> >
> >
> >
> > Page 20-5
> > The data must reside in dbspaces or sbspaces
> > If your primary database server has simple large objects stored in
> > blobspaces, **modifications to the data within those blobspaces is not
> > replicated** as part of normal HDR processing. However,
> > simple-largeobject
> > data within dbspaces is replicated.
> > Smart large objects, which are stored in sbspaces, are replicated. The
> > sbspaces must be logged. User-defined types (UDTs) are replicated,
> > unless they have out-of-row data stored in operating system files.
> > Data types with out-of-row data are replicated if the data is stored
> > in
> > an sbspace or in a different table on the same database server.
> >
> > To me the "**" sentence seems to indicate an HDR pair up and running,
> > but the blobs from the primary are not getting replicated.
> >
> > We have managed to get HDR up and running, but when we make a
> > modification to a blob the secondary creates an assert failure and
> > marks the chunks in the blobspace as offline. This is fine with me,
> > the secondary keeps going along as if nothing happened. However if we
> > take the secondary down and bring it back up, it refuses to come back
> > up complaining that the blobspaces are offline and a level zero
> > restore is required to get the secondary back up.
> >
> > The questions I have (finally) are:
> >
> > Is anyone out there successfully running HDR with blobs in blobspaces?
> > What does HDR tell you about blobs? Do you get assert failures on
> > your blobspaces? Can you bring the secondary down and back up without
> > having to restore from tape (basically starting HDR up again from
> > scratch).
> >
> > Thank you in advance
> > --Scott