| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 4968.1 | WAG | svrav1.au.oracle.com::MBRADLEY | I was dropped on my head as a baby. What's your excuse? | Mon Jan 27 1997 20:16 | 5 |
| What is the value for CHANNELCOUNT?
G'day,
Mark.
|
| 4968.2 | Rocky Mountain HIGH .... ;^) | M5::BLEHLBAC | RDB: 34% better than real life | Mon Jan 27 1997 21:04 | 8 |
| <<< Note 4968.1 by svrav1.au.oracle.com::MBRADLEY "I was dropped on my head as a baby. What's your excuse?" >>>
-< WAG >-
>>What is the value for CHANNELCOUNT?
CHANNELCOUNT is set to 1200.
Thanks, Barry
|
| 4968.3 | | ORAREP::HERON::VIGIER | Philippe\Rdb Engineering | Tue Jan 28 1997 07:19 | 12 |
| From VMS doco :
IVCHAN, invalid I/O channel
Facility: SYSTEM, System ServicesExplanation: The channel number
specified in an input or output request
is not a valid channel number; the I/O operation cannot be
performed.
User Action: Check for a programming error. Verify that the request to
assign the I/O channel completed successfully and returned a
valid channel number.
What about some tricky memory corruption ???
\Philippe.
|
| 4968.4 | will take a look | VGER::BLEHLBAC | Toto, It Ain't Kansas | Tue Jan 28 1997 08:04 | 7 |
| re .3
I saw that. The problem is happening on 2 unrelated systems so I haven't
pursued a "system specific" problem. However, I will review process quotas.
It appears that the aij is involved somehow. And, perhaps, acms.
Thanks, Barry
|
| 4968.5 | | M5::LWILCOX | Chocolate in January!! | Tue Jan 28 1997 08:27 | 9 |
| <<< Note 4968.3 by ORAREP::HERON::VIGIER "Philippe\Rdb Engineering" >>>
>> User Action: Check for a programming error.
Philippe, I thought for sure this mean that there was a programming
error in the Rdb product! Silly me!
Liz :-).
|
| 4968.6 | | HOTRDB::PMEAD | Paul, [email protected], 719-577-8032 | Tue Jan 28 1997 09:49 | 4 |
| Before expending too much effort chasing down quotas and such why not
have them upgrade to the most recent kit? Since this is likely to be
caused by memory corruption (like my good buddy Dr. Philippe suggests)
then just about anything could fix it.
|
| 4968.7 | its not CHANNELCNT. | svrav1.au.oracle.com::MCHAN | | Tue Jan 28 1997 17:41 | 19 |
|
I dont believe its shortage of channelcnt.
Customer have checked it using sh proc/chan in SDA and
even reboot the machine before try RMU/RESTORE again.
I would expect "system-f-noiochan no i/o channel available"
error message if channelcnt exceed its limit.
Did the dump of AIJ file showing any sign of corruption?
Customer should verify their database before backup it up.
Regards,
Michael.
|
| 4968.8 | | M5::LWILCOX | Chocolate in January!! | Fri Jan 31 1997 17:58 | 23 |
| FWIW, I talked to this customer some more and said I would attempt to
see if there might be something she could do to try to verify that indeed,
the problem is memory corruption. Is there some way to look at the process
buffers, or whatever other structures would be involved, during the restore
operation to attempt to verify this theory?
She stated that they tried to restore from numerous RMU/BACKUP files on the
one system and ended up going back to one from some time in December. That
did not exhibit the error on restore, and she did not specify /NOAFTER.
On at least one that did exhibit the error on restore they found that using
/NOAFTER meant a successful restore (as Barry mentioned).
They could successfully RMU/DUMP/BACKUP even those that errored on the
restore. She will try to take one of the backups that errored and restore
it on a 6.0 system with a more current ECO in order to see if that makes
a difference.
I realize there is little interest in this due to the age of the version
she is running.
Thanks,
Liz
|
| 4968.9 | I think they can use their time more constructively :) | BOUVS::OAKEY | I'll take Clueless for $500, Alex | Sun Feb 02 1997 18:17 | 21 |
| ~~ <<< Note 4968.8 by M5::LWILCOX "Chocolate in January!!" >>>
~~FWIW, I talked to this customer some more and said I would attempt to
~~see if there might be something she could do to try to verify that indeed,
~~the problem is memory corruption. Is there some way to look at the process
~~buffers, or whatever other structures would be involved, during the restore
~~operation to attempt to verify this theory?
Not easily. We ship the product in such a state as to eliminate as much
information as possible about what structures someone might be looking at.
(ie, no debug information is available). As most memory corruption errors
take experienced engineers with access to sources quite a while to track
down, I doubt the customer would be able to easily determine anything.
~~They could successfully RMU/DUMP/BACKUP even those that errored on the
~~restore. She will try to take one of the backups that errored and restore
I believe the DUMP/BACKUP has been discussed before. It verifies that you
can read the backup file but doesn't really say anything about your ability
to restore a useful database.
|
| 4968.10 | Check also BYTLM | ORAREP::HERON::GODFRIND | Oracle Rdb Engineering | Wed Feb 05 1997 05:00 | 8 |
| I had a customer with a similar problem some time ago. I also started chasing
channelcount et al.
At the end someone (don't remember who) mentionned BYTLM as a possible cause.
Increasing this made the problem go away.
/albert
|
| 4968.11 | | M5::LWILCOX | Chocolate in January!! | Thu Feb 06 1997 09:46 | 3 |
| Thanks, both of you, that all helps.
Liz
|