REASON 00C90101

Bharath Nunepalli

REASON 00C90101

We use IBM DB2 Recovery Expert for z/OS v3.2 for data migrations.
Sometimes we notice 00C90101 error message when Application team tries to access the data from the tables in target database after data migration is done.

We usually fix this by unloading the current data from the table and loading the same back into the table using LOAD REPLACE.

I would like to know whether there is any check I can do after the data migration is done to make sure we don’t get 00C90101 errors when trying to access the data.
Can someone please help me in this?


Bharath Nunepalli,

Senior DB2 DBA.

Tony Saul

REASON 00C90101
(in response to Bharath Nunepalli)
I think I would be raising a PMR with IBM. The error message says  - 
00C90101   ExplanationThe data manager detected an internal error within Db2®. Possible causes for this error include:
Improper migration or fall back procedures.The Db2 directory and Db2 catalog have been restored to different points in time.A table space was restored improperly.An error in internal Db2 control structures or code.System actionA record is written to SYS1.LOGREC, and an SVC dump is requested.

So that sounds like it isn't doing some function correctly.Is DB2 Recovery Expert at the correct version / modification level to match the DB2 /and/or operating system level? 
Regards, Tony

On Wednesday, 6 February 2019, 3:16:52 am ACDT, Bharath Nunepalli <[login to unmask email]> wrote:


We use IBM DB2 Recovery Expert for z/OS v3.2 for data migrations.
Sometimes we notice 00C90101 error message when Application team tries to access the data from the tables in target database after data migration is done.

We usually fix this by unloading the current data from the table and loading the same back into the table using LOAD REPLACE.

I would like to know whether there is any check I can do after the data migration is done to make sure we don’t get 00C90101 errors when trying to access the data.
Can someone please help me in this?




Bharath Nunepalli,

Senior DB2 DBA.

Site Links: View post online   View mailing list online   Start new thread via email   Unsubscribe from this mailing list   Manage your subscription  

This email has been sent to: [login to unmask email]
** ** ** IDUG Db2 Tech Conference in Malta 2018 ** ** **
---> St. Julian's, Malta 4-8 November 2018 <---
http://www.idug.org/emea2018



Use of this email content is governed by the terms of service at:
http://www.idug.org/p/cm/ld/fid=2

Tony Saul

REASON 00C90101
(in response to Bharath Nunepalli)
I think I would be raising a PMR with IBM. The error message says  - 
00C90101   ExplanationThe data manager detected an internal error within Db2®. Possible causes for this error include:
Improper migration or fall back procedures.The Db2 directory and Db2 catalog have been restored to different points in time.A table space was restored improperly.An error in internal Db2 control structures or code.System actionA record is written to SYS1.LOGREC, and an SVC dump is requested.

So that sounds like it isn't doing some function correctly.Is DB2 Recovery Expert at the correct version / modification level to match the DB2 /and/or operating system level? 
Regards, Tony

On Wednesday, 6 February 2019, 3:16:52 am ACDT, Bharath Nunepalli <[login to unmask email]> wrote:


We use IBM DB2 Recovery Expert for z/OS v3.2 for data migrations.
Sometimes we notice 00C90101 error message when Application team tries to access the data from the tables in target database after data migration is done.

We usually fix this by unloading the current data from the table and loading the same back into the table using LOAD REPLACE.

I would like to know whether there is any check I can do after the data migration is done to make sure we don’t get 00C90101 errors when trying to access the data.
Can someone please help me in this?




Bharath Nunepalli,

Senior DB2 DBA.

Site Links: View post online   View mailing list online   Start new thread via email   Unsubscribe from this mailing list   Manage your subscription  

This email has been sent to: [login to unmask email]
** ** ** IDUG Db2 Tech Conference in Malta 2018 ** ** **
---> St. Julian's, Malta 4-8 November 2018 <---
http://www.idug.org/emea2018



Use of this email content is governed by the terms of service at:
http://www.idug.org/p/cm/ld/fid=2

Avram Friedman

RE: REASON 00C90101
(in response to Bharath Nunepalli)

00C90101 is like the S0C4 of DB2 there are many causes.  Full message text and ajecent messages are often helpful in diagnossis

From what I can guess about your circumstances, the condition you may be suffering from is a LEVELID error.
In your recovered subsystem you may want to turnoff LEVELID checking in ZPARMs

Avram Friedman
DB2-L hall of fame contributor
DB2-L 'past' administrator

[login to unmask email]

Tom Crocker

RE: REASON 00C90101
(in response to Bharath Nunepalli)

Hi Bharath,

You mention data migrations, I presume that you are meaning that you use the redirected recovery feature ?

I have not seen this problem before but suggest that you open a PMR and we will investigate, feel free to contact me off line with any further details and questions.

Regards,

Tom Crocker

Solutions Advisor

Rocket Software UK Ltd.

6-9 The Square, Stockley Park, Uxbridge, UB11 1FW, United Kingdom

Tel:        +44 (0) 208 867 6177

Email: [login to unmask email]

All views are personal

Bharath Nunepalli

RE: REASON 00C90101
(in response to Tom Crocker)

Tom,
Yes, I use Redirected Recovery for data migrations.

We do data migration frequently. 00C90101 is noticed only in some cases.
I'm trying to figure out what would have caused 00C90101 error message.

Is there any kind of check I can run on target tables/indexes to avoid 00C90101 error before I start data migration?


Bharath Nunepalli,

Senior DB2 DBA.

Anguraj Rathinasamy

REASON 00C90101
(in response to Tony Saul)
We are not using Recovery expert; Just suggestion, Frequently we do refresh the data between environments. We have in-house REXX routine process by passing the schema name and environment; the program will collect the list of all tables and check individual row count all tables and generate the report. This kind of process spot check the tables which encounter "00C90101 " internal error.

Regards,
Anguraj

> On Feb 5, 2019, at 5:27 PM, Tony Saul <[login to unmask email]> wrote:
>
> I think I would be raising a PMR with IBM. The error message says -
>
> 00C90101
> Explanation
> The data manager detected an internal error within Db2®. Possible causes for this error include:
>
> Improper migration or fall back procedures.
> The Db2 directory and Db2 catalog have been restored to different points in time.
> A table space was restored improperly.
> An error in internal Db2 control structures or code.
> System action
> A record is written to SYS1.LOGREC, and an SVC dump is requested.
>
>
> So that sounds like it isn't doing some function correctly.
> Is DB2 Recovery Expert at the correct version / modification level to match the DB2 /and/or operating system level?
>
> Regards, Tony
>
>
> On Wednesday, 6 February 2019, 3:16:52 am ACDT, Bharath Nunepalli <[login to unmask email]> wrote:
>
>
> We use IBM DB2 Recovery Expert for z/OS v3.2 for data migrations.
> Sometimes we notice 00C90101 error message when Application team tries to access the data from the tables in target database after data migration is done.
>
> We usually fix this by unloading the current data from the table and loading the same back into the table using LOAD REPLACE.
>
> I would like to know whether there is any check I can do after the data migration is done to make sure we don’t get 00C90101 errors when trying to access the data.
> Can someone please help me in this?
>
>
>
> Bharath Nunepalli,
>
> Senior DB2 DBA.
>
>
> Site Links: View post online View mailing list online Start new thread via email Unsubscribe from this mailing list Manage your subscription
>
> This email has been sent to: [login to unmask email]
> ** ** ** IDUG Db2 Tech Conference in Malta 2018 ** ** **
> ---> St. Julian's, Malta 4-8 November 2018 <---
> http://www.idug.org/emea2018
>
>
> Use of this email content is governed by the terms of service at:
> http://www.idug.org/p/cm/ld/fid=2
>
>
> Site Links: View post online View mailing list online Start new thread via email Unsubscribe from this mailing list Manage your subscription
>
> This email has been sent to: [login to unmask email]
> ** ** ** IDUG Db2 Tech Conference in Malta 2018 ** ** **
> ---> St. Julian's, Malta 4-8 November 2018 <---
> http://www.idug.org/emea2018
>
>
> Use of this email content is governed by the terms of service at:
> http://www.idug.org/p/cm/ld/fid=2
>

Bharath Nunepalli

RE: REASON 00C90101
(in response to Anguraj Rathinasamy)

Anguraj,
That's a good idea. Thanks.

 

Bharath Nunepalli,

Senior DB2 DBA.

Kai Stroh

RE: REASON 00C90101
(in response to Bharath Nunepalli)

Hello Bharath,

00C90101 occurs when Db2 cannot interpret the binary representation of a row. There are several possible reasons for this, and it can occur for tablespaces and for indexes.

When you get this error, look for ERQUAL, CSECT and resource name. That combination tells you what Db2 was trying to do when the error occurred. Here's a list of possible reasons:

https://www.ibm.com/support/knowledgecenter/en/SSEPEK_11.0.0/codes/src/tpc/db2z_abendcodesdsn1copy.html

Note that the list is by no means exhaustive. I have encountered many combinations that are not documented.

In 9 out of 10 cases, the problem has to do with versioning, i.e. the source table has been ALTERed and a required REORG has not been done afterwards. When such an object is copied on VSAM level, there is a high chance that the target Db2 will not accept it. Another possible reason is that a non-partitioned source object had multiple VSAMs, but not all of them were copied, or the OBID translation was not done properly.

Note that an object does not necessarily have to be in AREO state after an ALTER TABLE. For example, adding a column to a table that is currently version 0 and uses the basic row format will not introduce a new version (at least it didn't in older Db2 versions, haven't checked V12).

If you haven't already, you should definitely adopt a change management strategy where every ALTER TABLE is followed by a REORG during the next maintenance window. This dramatically reduces the likelihood of this problem appearing.

It's the reason why we have added tons of plausibility checks into our own copy product, BCV5, and we even double check the target version numbers after running REPAIR CATLOG in the target. Db2 versioning is one of the ugliest parts of Db2 in my opinion and it is a continuous source of trouble. That's because you have a description of your tables in your Db2 catalog, and also in the DBD, and also in the page sets (system pages). If these three do not agree, you are going to get these errors.

Best regards

Kai

--
Kai Stroh
UBS Hainer
Fast, efficient Db2 z/OS data migrations and renewals. That’s BCV5.
Learn how the Test Data Management Field Guide can help you to improve your own process.

Bharath Nunepalli

RE: REASON 00C90101
(in response to Kai Stroh)

Kai,

"Db2 versioning is one of the ugliest parts of Db2 in my opinion and it is a continuous source of trouble."
I totally agree with this.

 

Bharath Nunepalli,

Senior DB2 DBA.