Welcome Serena Central users! CLICK HERE
The migration of the Serena Central community is currently underway. Be sure to read THIS MESSAGE to get your new login set up to access your account.
Anonymous_User Absent Member.
Absent Member.
2359 views

Rebuilding operational schema

Is there any danger in running a database repair with the "Rebuild
Operational Schema" option selected? I see this as a solution in a
number of DSREPAIR errors, but I want to know if it is something that
can be run with a "normal" level of care, or if it's something that has
more impact than more typical db repair functions.

Is there any additional level of concern with rebuilding the operational
schema on the root partition?

I guess the underlying question is, what's going on in a rebuild of the
operational schema, and what concerns could there be with performing
this operation?

Thanks,

-- Geoff
Labels (2)
0 Likes
11 Replies
ataubman Absent Member.
Absent Member.

Re: Rebuilding operational schema

Like any other dsrepair operation, it should not be done unless there is a specific need to do it. Never do it just to see if it helps, only if you have a solid reason to believe it will help with the problem you are dealing with.

Andrew C Taubman (Sorry, support is not provided via e-mail) Opinions expressed above are not necessarily those of Micro Focus.
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Rebuilding operational schema

Thanks for the response. Here is why I asked this question. I am getting
ready for a migration to Linux, so first I need to get all of the
servers -- presently running NW60SP5 -- up to NW65SP8 with eDir 8.8.
When I have run database repairs I get the following notices:

* * * * * * *

Schema Attribute Definition, Object ID: 00000188, RDN: App Blurb
NOTICE: Invalid OID for : App Blurb, You need to run DSRepair on the
[Root] replica.

Schema Attribute Definition, Object ID: 00000189, RDN: App Contacts
NOTICE: Invalid OID for : App Contacts, You need to run DSRepair on the
[Root] replica.

Schema Attribute Definition, Object ID: 0000018A, RDN: App Drive Mappings
NOTICE: Invalid OID for : App Drive Mappings, You need to run DSRepair
on the [Root] replica.

Schema Attribute Definition, Object ID: 0000018B, RDN: App Flags
NOTICE: Invalid OID for : App Flags, You need to run DSRepair on the
[Root] replica.

Schema Attribute Definition, Object ID: 0000018C, RDN: App Icon
NOTICE: Invalid OID for : App Icon, You need to run DSRepair on the
[Root] replica.

Schema Attribute Definition, Object ID: 0000018D, RDN: App Parameters
NOTICE: Invalid OID for : App Parameters, You need to run DSRepair on
the [Root] replica.

Schema Attribute Definition, Object ID: 0000018E, RDN: App Path
NOTICE: Invalid OID for : App Path, You need to run DSRepair on the
[Root] replica.

Schema Attribute Definition, Object ID: 0000018F, RDN: App Printer Ports
NOTICE: Invalid OID for : App Printer Ports, You need to run DSRepair on
the [Root] replica.

Schema Attribute Definition, Object ID: 00000190, RDN: App Shutdown Script
NOTICE: Invalid OID for : App Shutdown Script, You need to run DSRepair
on the [Root] replica.

Schema Attribute Definition, Object ID: 00000191, RDN: App Startup Script
NOTICE: Invalid OID for : App Startup Script, You need to run DSRepair
on the [Root] replica.

Schema Attribute Definition, Object ID: 00000192, RDN: App Working Directory
NOTICE: Invalid OID for : App Working Directory, You need to run
DSRepair on the [Root] replica.

Schema Attribute Definition, Object ID: 00000193, RDN: Desktop
NOTICE: Invalid OID for : Desktop, You need to run DSRepair on the
[Root] replica.

Schema Attribute Definition, Object ID: 00000194, RDN: Auto Start
NOTICE: Invalid OID for : Auto Start, You need to run DSRepair on the
[Root] replica.

Schema Attribute Definition, Object ID: 00000195, RDN: Launcher Config
NOTICE: Invalid OID for : Launcher Config, You need to run DSRepair on
the [Root] replica.

Schema Class Definition, Object ID: 000004B0, RDN: Application (DOS)
NOTICE: Invalid OID for : Application (DOS), You need to run DSRepair on
the [Root] replica.

Schema Class Definition, Object ID: 000004B1, RDN: Application (Windows
3\.x)
NOTICE: Invalid OID for : Application (Windows 3\.x), You need to run
DSRepair on the [Root] replica.

Schema Class Definition, Object ID: 000004B2, RDN: Application (Windows 95)
NOTICE: Invalid OID for : Application (Windows 95), You need to run
DSRepair on the [Root] replica.

Schema Class Definition, Object ID: 000004B3, RDN: Application (Windows NT)
NOTICE: Invalid OID for : Application (Windows NT), You need to run
DSRepair on the [Root] replica.

* * * * * * *

They all appear to be old ZFD4-related objects (no Zen version in use
any longer)...

I want to get these to go away, and I was thinking about rebuilding the
operational schema on Root, but it makes me nervous I might corrupt the
Root replica. The master of Root is still a NW60SP5 server. Should the
server holding the root replica be a NW65 server?

Any thoughts on how to clear these up, or if they're nothing to worry
about for the migration would be greatly appreciated.

Thanks,

-- Geoff
0 Likes
Marcel_Cox Absent Member.
Absent Member.

Re: Rebuilding operational schema

My guess is that at some time in the past, you had a mix of NDS7 (or
older) and eDirectory 8.x servers in your tree and at some time you
upgraded or migrated an NDS7 server to eDirectory. In such a case, it may
be required to make the upgraded server reload the schema from a root
server.
Now are you getting these messages on all servers or just on some of them?

--
Marcel Cox
http://support.novell.com/forums
------------------------------------------------------------------------
Marcel Cox's Profile: http://forums.novell.com/member.php?userid=8
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Rebuilding operational schema

It looks like it's happening on all of the NW60 servers. We have a few
NW65 servers, and it appears these NW65 servers are not exhibiting the
notices. I haven't noticed these errors until now, as we're preparing to
retire the NW60 and move to Linux. I have been digging into the
replication details, and I have started to identify this issue.

We did indeed have old servers in the tree in the past. We have brought
this network forward over the years from the NetWare 3.12 days. With the
demise of the NetWare kernel, we're preparing for Linux. We had ZENworks
4 in place for several years, but that has been phased out for many
reasons (some of which were political...).

Are these notices something I should be concerned about? What is a
strategy for eliminating these notices?

Thanks for your assistance.

Marcel Cox wrote:
> My guess is that at some time in the past, you had a mix of NDS7 (or
> older) and eDirectory 8.x servers in your tree and at some time you
> upgraded or migrated an NDS7 server to eDirectory. In such a case, it
> may be required to make the upgraded server reload the schema from a
> root server.
> Now are you getting these messages on all servers or just on some of them?
>

0 Likes
Marcel_Cox Absent Member.
Absent Member.

Re: Rebuilding operational schema

Geoff K. wrote:

>It looks like it's happening on all of the NW60 servers.


What eDirectory version are these running? 8.7.3.x, or somethign older?
If it's older, you might consider upgrading to eDir 8.7.3.x.
In any case, you might try on one server that shows the issue whether a
"reset schema" in the schema options makes a difference.

--
Marcel Cox
http://support.novell.com/forums
------------------------------------------------------------------------
Marcel Cox's Profile: http://forums.novell.com/member.php?userid=8
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Rebuilding operational schema

The NW60 servers are running 8.6.2. We're going to bring in all new
NW65SP8 servers running eDir 8.7.3.10 and decommission the NW60 aging
boxes. This will buy us support until March and extended support until
March, 2012. By then we plan to have migrated to OES2 Linux.

Should I be concerned about this issue if I plan to bring up new NW65SP8
boxes, migrate the data and then decommission the old eDir 8.6.2 boxes?

Marcel Cox wrote:
> What eDirectory version are these running? 8.7.3.x, or somethign older?
> If it's older, you might consider upgrading to eDir 8.7.3.x.
> In any case, you might try on one server that shows the issue whether a
> "reset schema" in the schema options makes a difference.
>

0 Likes
Marcel_Cox Absent Member.
Absent Member.

Re: Rebuilding operational schema

Geoff K. wrote:

>Should I be concerned about this issue if I plan to bring up new NW65SP8
>boxes, migrate the data and then decommission the old eDir 8.6.2 boxes?


If you just do a data migration, it should not be a big issue. However if
you do a full server migration, you don't want your new server to inherit
the old problem.

BTW independently of your problem, you might also consider doing to
eDirectory 8.8.x on your new servers right away. I consider it a bit of a
waste of time to go to eDirectoryx 8.7.3.x now if sooner or later you will
be forced to move to eDirectory 8.8.x anyway. Novell seems to be eager to
drop support for eDirectory 8.7.3.x as soon as possible in order to limit
the number of eDirectory versions to support.

--
Marcel Cox
http://support.novell.com/forums
------------------------------------------------------------------------
Marcel Cox's Profile: http://forums.novell.com/member.php?userid=8
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Rebuilding operational schema

I've been told directly by a senior Novell consultant that there could
be issues with getting support if we're running 8.6.2 with 8.8.x. I was
told this combo is not supported and to make sure the new NW65SP8
servers all had 8.7.3.10 installed, and once all of the 8.6.2 was gone
to then upgrade all to 8.8.x. Our migration could take several months,
and if we need support during that time we need to make sure we've got a
supported version combination in operation.

Is this concern about getting support during our migration true? I would
love not to have to follow the migration with an eDir upgrade of 50
servers...

> BTW independently of your problem, you might also consider doing to
> eDirectory 8.8.x on your new servers right away. I consider it a bit of
> a waste of time to go to eDirectoryx 8.7.3.x now if sooner or later you
> will be forced to move to eDirectory 8.8.x anyway. Novell seems to be
> eager to drop support for eDirectory 8.7.3.x as soon as possible in
> order to limit the number of eDirectory versions to support.
>

0 Likes
Marcel_Cox Absent Member.
Absent Member.

Re: Rebuilding operational schema

eDirectory 8.6.x is not supported in any combination. If you want to get
into a somewhat more supported area, you could consider upgrading your NW
6.0 servers to eDirectory 8.7.3.x. Of course NetWare 6.0 itself still
remains unsupported.

--
Marcel Cox
http://support.novell.com/forums
------------------------------------------------------------------------
Marcel Cox's Profile: http://forums.novell.com/member.php?userid=8
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Rebuilding operational schema

The problem with this is that eDir 8.7.3.10 has not been certified to
run on NW60, so I have a catch 22 situation. I think I would rather
upgrade all new hardware running the latest OS than try to upgrade aging
hardware with an outdated OS and varying states of patching. I feel much
better leaving the old machines alone and just migrating the data off
them. Trying to apply eDir patches to these old machines makes me
nervous. They're running, and I need them to run only long enough more
to get the data off them...

Marcel Cox wrote:
> eDirectory 8.6.x is not supported in any combination. If you want to get
> into a somewhat more supported area, you could consider upgrading your
> NW 6.0 servers to eDirectory 8.7.3.x. Of course NetWare 6.0 itself still
> remains unsupported.
>

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Rebuilding operational schema

So, I've decided not to upgrade eDir on the NW60 servers, install the
NW65SP8 servers with 8.7.3.10 and then upgrade all of the NW65 servers
to eDir 8.8.x once all of the NW60 servers have been decommissioned.

Is there any concern about having these notices in the DSREPAIR logs for
the NW60 servers? Should I try to get rid of these notices or can I just
not worry about them and let them disappear as the NW60 servers get
decommissioned? There are no actual errors, only these notices...

Geoff K. wrote:
> Thanks for the response. Here is why I asked this question. I am getting
> ready for a migration to Linux, so first I need to get all of the
> servers -- presently running NW60SP5 -- up to NW65SP8 with eDir 8.8.
> When I have run database repairs I get the following notices:
>
> * * * * * * *
>
> Schema Attribute Definition, Object ID: 00000188, RDN: App Blurb
> NOTICE: Invalid OID for : App Blurb, You need to run DSRepair on the
> [Root] replica.
>
> Schema Attribute Definition, Object ID: 00000189, RDN: App Contacts
> NOTICE: Invalid OID for : App Contacts, You need to run DSRepair on the
> [Root] replica.
>
> Schema Attribute Definition, Object ID: 0000018A, RDN: App Drive Mappings
> NOTICE: Invalid OID for : App Drive Mappings, You need to run DSRepair
> on the [Root] replica.
>
> Schema Attribute Definition, Object ID: 0000018B, RDN: App Flags
> NOTICE: Invalid OID for : App Flags, You need to run DSRepair on the
> [Root] replica.
>
> Schema Attribute Definition, Object ID: 0000018C, RDN: App Icon
> NOTICE: Invalid OID for : App Icon, You need to run DSRepair on the
> [Root] replica.
>
> Schema Attribute Definition, Object ID: 0000018D, RDN: App Parameters
> NOTICE: Invalid OID for : App Parameters, You need to run DSRepair on
> the [Root] replica.
>
> Schema Attribute Definition, Object ID: 0000018E, RDN: App Path
> NOTICE: Invalid OID for : App Path, You need to run DSRepair on the
> [Root] replica.
>
> Schema Attribute Definition, Object ID: 0000018F, RDN: App Printer Ports
> NOTICE: Invalid OID for : App Printer Ports, You need to run DSRepair on
> the [Root] replica.
>
> Schema Attribute Definition, Object ID: 00000190, RDN: App Shutdown Script
> NOTICE: Invalid OID for : App Shutdown Script, You need to run DSRepair
> on the [Root] replica.
>
> Schema Attribute Definition, Object ID: 00000191, RDN: App Startup Script
> NOTICE: Invalid OID for : App Startup Script, You need to run DSRepair
> on the [Root] replica.
>
> Schema Attribute Definition, Object ID: 00000192, RDN: App Working
> Directory
> NOTICE: Invalid OID for : App Working Directory, You need to run
> DSRepair on the [Root] replica.
>
> Schema Attribute Definition, Object ID: 00000193, RDN: Desktop
> NOTICE: Invalid OID for : Desktop, You need to run DSRepair on the
> [Root] replica.
>
> Schema Attribute Definition, Object ID: 00000194, RDN: Auto Start
> NOTICE: Invalid OID for : Auto Start, You need to run DSRepair on the
> [Root] replica.
>
> Schema Attribute Definition, Object ID: 00000195, RDN: Launcher Config
> NOTICE: Invalid OID for : Launcher Config, You need to run DSRepair on
> the [Root] replica.
>
> Schema Class Definition, Object ID: 000004B0, RDN: Application (DOS)
> NOTICE: Invalid OID for : Application (DOS), You need to run DSRepair on
> the [Root] replica.
>
> Schema Class Definition, Object ID: 000004B1, RDN: Application (Windows
> 3\.x)
> NOTICE: Invalid OID for : Application (Windows 3\.x), You need to run
> DSRepair on the [Root] replica.
>
> Schema Class Definition, Object ID: 000004B2, RDN: Application (Windows 95)
> NOTICE: Invalid OID for : Application (Windows 95), You need to run
> DSRepair on the [Root] replica.
>
> Schema Class Definition, Object ID: 000004B3, RDN: Application (Windows NT)
> NOTICE: Invalid OID for : Application (Windows NT), You need to run
> DSRepair on the [Root] replica.
>
> * * * * * * *
>
> They all appear to be old ZFD4-related objects (no Zen version in use
> any longer)...
>
> I want to get these to go away, and I was thinking about rebuilding the
> operational schema on Root, but it makes me nervous I might corrupt the
> Root replica. The master of Root is still a NW60SP5 server. Should the
> server holding the root replica be a NW65 server?
>
> Any thoughts on how to clear these up, or if they're nothing to worry
> about for the migration would be greatly appreciated.
>
> Thanks,
>
> -- Geoff

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.