- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: "false" Oracle corruption messages
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-05-2002 09:39 AM
тАО02-05-2002 09:39 AM
Re: "false" Oracle corruption messages
Hi:
This does look very strange:
The lseek is failing on fdes 0; EBADF indicates that fdes is not open
lseek(0, 33832960, SEEK_SET) ..... ERR#9 EBADF
...
...
open("/usr/lib/nls/msg/C/strerror.cat", O_LARGEFILE, 0177777) .......... = 0
This open returns 0 as a file descriptor; open returns the lowest available file descriptor.
You need to do some more digging to find where close(0) is called before the lseek that fails.
This is looking more and more like a software bug but I would definitely set timeslice to 10 because your current setting can cause all sorts of very stange behavior. If timeslice doesn't fix this, it's probably time to call Oracle support.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-05-2002 11:13 AM
тАО02-05-2002 11:13 AM
Re: "false" Oracle corruption messages
I recall a similar message on 8.1.6 ( more or less). The is a pacth from Oracle. See oracle??s alert.log on database server.
sar -v reports that inode is on his high value. If you are using HFS filesystems you need to raise ninode kernel parameter.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-06-2002 12:03 AM
тАО02-06-2002 12:03 AM
Re: "false" Oracle corruption messages
I checked with Oracle and they recommend to "upgrade to 8.1.7.2 and than apply patch for BUG 1247796."
This is a patch related to ASYNCH_IO which we're not using however. It will be very difficult to upgrade since the product is only supported on Oracle 8.1.5 (which is no longer supported by Oracle, so I'm as usual stuck between a rock and a hard place!)
I'll try to convince our Change Control Board to give me some downtime to change the timeslice value.
many thanks,
Dirk
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-06-2002 12:29 AM
тАО02-06-2002 12:29 AM
Re: "false" Oracle corruption messages
I'm interested in your lock.sh script. Would you please post this script as attachement?
Thanks a lot
Ruediger
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-06-2002 12:49 AM
тАО02-06-2002 12:49 AM
Re: "false" Oracle corruption messages
#cp /stand/vmunix /stand/vmunix.orig
#q4pxdb /stand/vmunix
in the script change the line /usr/contrib/bin/q4 /stand/vmunix /dev/mem with /usr/contrib/Q4/bin/q4 /stand/vmunix /dev/kmem
#sh /tmp/lock.sh
#cat /tmp/outputfile
regards,
Dirk
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-06-2002 02:45 AM
тАО02-06-2002 02:45 AM
Re: "false" Oracle corruption messages
The lseek() tries to seek on a file which has gotten filedescriptor 0 from the process. The lseek() can't open the filedescriptor because the filedescriptor isn't open anymore. (in other words was closed before with the close() command) How do we know this, because the filedescriptor 0 is assigned to the first file that is opened.
The result of this EBADF is that, oracle sends to the iwserver process a message that it gets the EBADF.
The message is passed via the file "/opt/oracle/product/8.1.5/rdbms/mesg/oraus.msb".
file. The iwserver then further communicates this to the iwclientprocess on the pc.
with the following open questions:
questions :
1/ When is the filedescriptor 0 of the "oracleVANPROD" process closed ?
2/ Why is the filedescriptor closed ?
3/ Why doesnt the oracle process notice that the filedescriptor is closed and persists in doing a lseek() ?
Doing a continuous tusc on the oracle process may reveal when its closed and by who.
Dirk
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-11-2002 07:29 AM
тАО03-11-2002 07:29 AM
Re: "false" Oracle corruption messages
We implemented a workaround of this package and this solved the "false" corruptions.
Dirk
- « Previous
-
- 1
- 2
- Next »