Goldengate file creation error for creating Individul Partition file

[bubesh...@gmail.com]

Hi,

I am getting Goldengate error while creating an individual Partition file.

14-01-23;20:26:00.159 \NETSSEC.$GGR11 ORACLE.1.G06 103
OGG-00103 REP456 Error 10080 CREATE target file
(Abending) (source \NETSSEC.$TEST56.TRANDATA.KTRANTRK)
14-01-23;20:26:00.159 \NETSSEC.$GGR11 ORACLE.1.G06 191
OGG-00191 REP456 REPLICAT abending


Source file:
$SIT51.TRANDATA.KTRANTRK 24 Jan 2014, 15:50
ENSCRIBE
PHYSICAL FILENAME: $N5HD3.ZYS00000.A000F08C
TYPE K
FORMAT 2
EXT ( 50 PAGES, 50 PAGES )
REC 54
BLOCK 4096
KEYLEN 40
KEYOFF 0
PART ( 1, $TEST51, 3000 PAGES, 3000 PAGES, [ 0, 0 ] )
PART ( 2, $TEST52, 3000 PAGES, 3000 PAGES, "02" )
PART ( 3, $TEST53, 3000 PAGES, 3000 PAGES, "03" )
PART ( 4, $TEST54, 3000 PAGES, 3000 PAGES, "04" )
PART ( 5, $TEST56, 3000 PAGES, 3000 PAGES, "05" )
PART ( 6, $TEST57, 3000 PAGES, 3000 PAGES, "06" )
MAXEXTENTS 978
OWNER 99,2
SECURITY (RWEP): NUNU
DATA MODIF: 24 Jan 2014, 14:29
CREATION DATE: 24 Jan 2014, 14:08
LAST OPEN: 24 Jan 2014, 15:50
FILE LABEL: 486 (11.9% USED)
EOF: 0 (0.0% USED)
EXTENTS ALLOCATED: 0
INDEX LEVELS: 0

Destination file:
$SIT52.TRANDATA.KTRANTRK 24 Jan 2014, 15:51
ENSCRIBE
PHYSICAL FILENAME: $N5HD3.ZYS00000.A000E599
TYPE K
FORMAT 2
EXT ( 50 PAGES, 50 PAGES )
REC 54
BLOCK 4096
KEYLEN 40
KEYOFF 0
PART ( 1, $TEST61, 3000 PAGES, 3000 PAGES, [ 0, 0 ] )
PART ( 2, $TEST62, 3000 PAGES, 3000 PAGES, "02" )
PART ( 3, $TEST63, 3000 PAGES, 3000 PAGES, "03" )
PART ( 4, $TEST64, 3000 PAGES, 3000 PAGES, "04" )
PART ( 5, $TEST66, 3000 PAGES, 3000 PAGES, "05" )
PART ( 6, $TEST67, 3000 PAGES, 3000 PAGES, "06" )
MAXEXTENTS 978
OWNER 99,2
SECURITY (RWEP): AAAA
DATA MODIF: 24 Jan 2014, 14:30
CREATION DATE: 24 Jan 2014, 14:28
LAST OPEN: 24 Jan 2014, 15:23
FILE LABEL: 486 (11.9% USED)
EOF: 0 (0.0% USED)
EXTENTS ALLOCATED: 0
INDEX LEVELS: 0


I am replicating data from $SIT51.TRANDATA.KTRANTRK to
$SIT52.TRANDATA.KTRANTRK using Goldengate(GG).

Programatically I am renaming the below mentioned partitioned files from
$TEST51.TRANDATA.KTRANTRK to $TEST51.TRANDATA.TRYYMMDD
GG is replicating same rename changes in the destination file location
$TEST61.TRANDATA.KTRANTRK to $TEST61.TRANDATA.TRYYMMDD

When I try to create $TEST51.TRANDATA.KTRANTRK Programatically using
GPC "file_createlist_" file is created successfully, but GG failed to replicate
file creation in the destination location.

I have given the GG configuration details below, please help me to resolve
this error.

Goldengate Configuration:
--------------------------------------------------------------------------------
Logger:
LOG $UAT51.GGSLOG.GG, MEGABYTES 50, NUMFILES 20, SECURE "NNNU"
CPU 1,0
NOCOMPRESSUPDATES
GETUNSTRUCTURED
GETBULKIO
PRIORITY 190

FILE $SIT51.PTDF2.PTDF ;
FILE $SIT51.TRANDATA.KTRANTRK ;
FILE $TEST51.TRANDATA.KTRANTRK;
FILE $TEST52.TRANDATA.KTRANTRK;
FILE $TEST53.TRANDATA.KTRANTRK;
FILE $TEST54.TRANDATA.KTRANTRK;
FILE $TEST56.TRANDATA.KTRANTRK;
FILE $TEST57.TRANDATA.KTRANTRK;


Replicator:
REPLICAT REP456
GETFILEOPS
ASSUMETARGETDEFS
FASTREADS
-- HANDLECOLLISIONS
DISCARDFILE $UAT51.GGSDISC.REP456 , append
ENTRYSEQUPDATES
--OPENTIMEOUTMINUTES 4320
--MAP $*.*.*,TARGET $*.*.*;
MAP $SIT51.PTDF2.PTDF, TARGET $SIT51.PTDF2DR.PTDF;
MAP $SIT51.TRANDATA.KTRANTRK , TARGET $SIT52.TRANDATA.KTRANTRK ;
MAP $TEST51.TRANDATA.KTRANTRK, TARGET $TEST61.TRANDATA.KTRANTRK;
MAP $TEST52.TRANDATA.KTRANTRK, TARGET $TEST62.TRANDATA.KTRANTRK;
MAP $TEST53.TRANDATA.KTRANTRK, TARGET $TEST63.TRANDATA.KTRANTRK;
MAP $TEST54.TRANDATA.KTRANTRK, TARGET $TEST64.TRANDATA.KTRANTRK;
MAP $TEST56.TRANDATA.KTRANTRK, TARGET $TEST66.TRANDATA.KTRANTRK;
MAP $TEST57.TRANDATA.KTRANTRK, TARGET $TEST67.TRANDATA.KTRANTRK;

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

Thanks

[Keith Dick]

Fair warning: I know almost nothing about Golden Gate, so I'm just guessing in what I'm about to tell you.

The error message seems to say that the error occured when attempting to create the target. The actual error code, 10080, is, according to the Oracle documentation I found, not a Guardian filesystem error, but a code made up by Golden Gate for file create errors to say which attribute of the create got the error. In this case, it would be attribute 80, which the NonStop documentation says tells whether the file being created is a primary or secondary partition. Without knowing important things, such as the file name it was trying to create and the actual Guardian error number, that doesn't tell us much. Golden Gate's error message should include a lot more information about the error.

I see that you gave FUP INFO DETAIL output for the target file. Did you create that file yourself? If so, could that, itself, be the problem, since Golden Gate seems to be trying to create it? Maybe you need to let Golden Gate create the file.

I notice the file security shown for the target is AAAA. If the Golden Gate software is not logged on locally, that would prevent it from accessing the file. If the Golden Gate software is logged on locally, then that is not likely to be the problem.

None of what I just mentioned might be relevant, but since you haven't had any other response yet, I thought I would point out those things, in case they help.

[Bubesh K.M]

Hi Keith,

Thanks.
I have logged in Goldengate locally.


Program opens the individual secondary partition in unstructred mode and renaming it. Golden gate replicated the same changes in the destination location (Secondary partition in destination location also got renamed).
$TEST51.TRANDATA.KTRANTRK(secondary partition) -> $TEST51.TRANDATA.TRYYMMDD
$TEST61.TRANDATA.KTRANTRK(secondary partition) -> $TEST61.TRANDATA.TRYYMMDD

now file $TEST51.TRANDATA.KTRANTRK won't exist,
Then I create secondary partition $TEST51.TRANDATA.KTRANTRK using attribute "80", file $TEST51.TRANDATA.KTRANTRK has got created sucessfully in the source location, GG didn't replicate file secondary partition file changes in the destination location $TEST61.TRANDATA.KTRANTRK.

GG can replicate file rename changes for secondary partiton but could not replicate file create changes for secondary partition.

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

I have also tried same changes in FUP with Goldengate library file, there also GG replicates secondary partition file rename changes, fails to replicate secondary partition file create changes.

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

[Keith Dick]

It seems like you have analyzed the problem pretty well. I don't know whether the Golden Gate software is supposed to be able to replicate the creation of a secondary partition as you are doing it. If their documentation says it should be able to replicate it, you apparently have found a bug. If their documentation says that is a case their software cannot handle, then you are trying to do something it wasn't designed to do, and you'll probably have to find another approach to accomplishing whatever overall result you are trying to reach. If their documentation is not clear whether that situation should work, you might have to ask your Oracle support contact whether that scenario is supported.

If you create a completely new partitioned file on the main system (primary partition, then one or more secondary partitions), does Golden Gate successfully replicate all parts of the partitioned file onto the backup system? If that works correctly, I think that would indicate that the failure you encountered is a bug in Golden Gate's software, but that is just a guess on my part. As I said before, I know next to nothing about Golden Gate's software.

[Gustavo Martinez]

Hello Bubesh,

Could you please provide the records inside the logtrails analized by logdump (both sites)?
I want to see how many operations were captured. In addition to that:

1) Your primary file is:

$SIT51
Sec Partition: $TEST51, 52 .. 57

2) Your destination file is:

$SIT61
Sec Partition: $TEST61, 62 .. 67

3) I suppose GG is capturing on the primary site every file creation: $SIT51, $TEST51 .. 57 . Please confirm it watching the logtrails.

4) Let's suppose 3) works. Now, on the destination, you have to replicate the first file creation operation $SIT51 which is mapped to $SIT61. So far, so good. But what about their partitions ? Their are supposed to be $TEST51 .. 57, not $TEST61 .. 67.
Which is the operation that is failing ? The first file creation ($SIT51), or the following one ?
Also send the replicat report file.

[Keith Dick]

I did not study the original post again, but if I remember correctly from when I looked at it a couple of weeks ago, only one of the secondary partitions was renamed, then a new secondary partition was created to take its place. My guess was that GG has some, perhaps accidental, assumption that a creation of a secondary partition will always come shortly after creation of the primary partition, and when that is not the case, it doesn't work correctly. That is just a guess on my part. I have zero experience with GG software, so that guess could be completely wrong and off the point. I'm posting here again to point out that I believe your assumption is wrong that the error occurred when there were a series of creates that created the primary and some secondary partitions. I think the error occurred when there was an isolated creation of a secondary partition.

[Gustavo Martinez]

Hi Keith,

I understood that the OP only showed an example of a rename, but my assumption is that all of the secondary partitions were renamed correctly. Please correct me (Bubesh) if I'm wrong.
I have experience on GG, and never tried this kind of configuration. But the first thing to do (in general with GG) is watching the trails to understand what operation is failing.
Whenever GG capture a file creation (with secondary partitions), those secondary partitions are stored inside the trail. See below:

2014-02-08 10:40:29.797.700 GGSCreateFile Len 404 RBA 568143
Name: \PEPE4.$NOMI8.DDDDDATA.NEWFILE
After Image: Partition 0 s
001e 5c4c 494e 4b35 2e24 4441 5441 382e 4c4e 4b31 | ..\PEPE4.$NOMI8.DDDD
4441 5441 2e4e 3030 3131 5356 0000 0000 0000 0000 | DATA.NEWFILE........
0000 0000 0000 0000 0000 0014 0128 0000 ffff ffff | .............(......
d2ff 0492 0032 002a 0033 0029 0047 002b 002c 0034 | .....2.*.3.).G.+.,.4
0049 004a 0048 0043 002e 002d 005a 005b 005c 005d | .I.J.H.C...-.Z.[.\.]
005e 005f 05dc 0000 05dc 0003 0000 04aa 1000 01f4 | .^._................
0000 0000 0000 0000 0019 0006 0007 05dc 05dc 05dc | ....................
05dc 05dc 05dc 05dc 05dc 05dc 05dc 05dc 05dc 05dc | ....................
05dc 000d 000d 000e 000e 000e 000e 000e 5c4c 494e | ................\PEP
4b35 2e24 4441 5441 375c 4c49 4e4b 352e 2444 4154 | E4.$DATA7\PEPE4.$DAT
4139 5c4c 494e 4b35 2e24 4441 5441 3138 5c4c 494e | A9\PEPE4.$DATA18\PEP
4b35 2e24 4441 5441 3139 5c4c 494e 4b35 2e24 4441 | E4.$DATA19\PEPE4.$DA
5441 3230 5c4c 494e 4b35 2e24 4441 5441 3231 5c4c | TA20\PEPE4.$DATA21\P
494e 4b35 2e24 4441 5441 3232 0012 3030 3131 3131 | EPE4.$DATA22..001111
3330 3133 3038 3332 3635 3135 3030 3131 3136 3130 | 30130832651500111610
3231 3831 3030 3831 3332 3030 3131 3230 3435 3632 | 21810081320011204562
3230 3235 3137 3239 3030 3131 3234 3030 3335 3631 | 20251729001124003561
3533 3937 3934 3030 3131 3237 3834 3431 3537 3833 | 53979400112784415783
3239 3033 3030 3131 3331 3630 3436 3736 3031 3632 | 29030011316046760162
3036 3030 3131 3333 3632 3439 3830 3539 3636 3736 | 06001133624980596676
0000 0000 | ....

The secondary partitions of the above file creation I/O are:

$DATA7
$DATA9
$DATA18
$DATA19
$DATA20
$DATA21
$DATA22

So if you MAP \PEPE4.$NOMI8 (primary volume) to \PEPE5.$MI8 (destination site) the file will be created on \PEPE5.$MI8 but using $DATA7, $DATA9 ... and $DATA22 as secondary partitions. I don´t remember if it is possible to change those secondary partitions volumes (I have to re-read manuals).
If those volumes don´t exist on the destination, the Replicat (process that is in charge of replicate changes in the destination site after reading what is called "Extract trails") should fail with an error. If it is succeed, I would like to have a FUP INFO DETAIL of the file after that operation took place.

I guess the first file creation is failing and GG is emitting to EMS some confusing information. But I'm just guessing.
It is not clear for me, how the file is created initially on the destination. You asked if he created himself. I suppose he did, but it is not confirmed.

Regarding renames, perhaps it works but with some warnings on the EMS Collector.

[Bubesh K.M]

Hi Keith,

If I create completely new partitioned file( Primary + Secondary files) using FUP with GG Library, all parts of the Primary and Secondary files are Created in the Destination location by GoldenGate replicator.

We have raised a case with Oracle, Oracle is yet to reply.

Thanks
KM Bubesh

[Bubesh K.M]

Hi Gustavo Martinez,

I am renaming single Individual partition file alone in the source location programatically, GG has replicated the individual partition file rename changes in destination location.

Source:
\NETSSEC.$TEST56.TRANDATA.KTRANTRK renamed to \NETSSEC.$TEST56.TRANDATA.TRYYMMDD

Destination:
\NETSSEC.$TEST66.TRANDATA.KTRANTRK renamed to \NETSSEC.$TEST66.TRANDATA.TRYYMMDD

files \NETSSEC.$TEST56.TRANDATA.KTRANTRK and \NETSSEC.$TEST66.TRANDATA.KTRANTRK does not exist now, now I am creating single individual partition file \NETSSEC.$TEST56.TRANDATA.KTRANTRK programatically GG is not replicating this change in Destination location.

I am manipulating with single individual partition file alone.


Sorry my EMS message says file name is \NETSSEC.$TEST56.TRANDATA.KTRANTRK
but I have explained the case with file name $TEST51.TRANDATA.KTRANTRK.

I will change the file name and post it again.

Thanks
KM Bubesh.

[Bubesh K.M]

Re-Post: The file name in the EMS message and Case explained will match now.
Thanks

$TEST56.TRANDATA.KTRANTRK to $TEST56.TRANDATA.TRYYMMDD

GG is replicating same rename changes in the destination file location

$TEST66.TRANDATA.KTRANTRK to $TEST66.TRANDATA.TRYYMMDD

When I try to create $TEST56.TRANDATA.KTRANTRK Programatically using

GPC "file_createlist_" file is created successfully, but GG failed to replicate

file creation in the destination location $TEST66.TRANDATA.KTRANTRK.

[Bubesh K.M]

Oracle has indicated that reason for not supporting replication of individual Partition file creation is because $system.zsysdefs.zsystal does not have parameter similar to CONSTANT ZSYS_VAL_FCREAT_SECNDPRTN VALUE 80.

Oracle said they will FIX it in the next release.

Thanks Keith and Gustavo Martinez for your suggestions.