<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic database locking query in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/database-locking-query/m-p/4035651#M742965</link>
    <description>this is a situation that I am facing. Hence require urgent help.&lt;BR /&gt;    two systems S1 and S2. Both of them access a raw&lt;BR /&gt;disk RD where oracle tables are present and both systems use their own&lt;BR /&gt;tablespaces. One of them is able to access the disk while the other is&lt;BR /&gt;waiting (according to the oracle guys). I ran glance and one of the&lt;BR /&gt;systems is showing 100% DISK utilization when the batch process is run.&lt;BR /&gt;The runq increases and the avwait increases and ultimately the service&lt;BR /&gt;time increases.&lt;BR /&gt;   Is there a problem like when the same raw disk is used by Oracle,&lt;BR /&gt;there is some kind of locking mechanism which prevents the other system&lt;BR /&gt;to access it? I mean is there a configuration where that locking could&lt;BR /&gt;be done? Otherwise parallel access should be possible because they are&lt;BR /&gt;using different tablespaces.&lt;BR /&gt;   Please let me know how I can proceed to debug such problem.</description>
    <pubDate>Wed, 11 Jul 2007 07:00:54 GMT</pubDate>
    <dc:creator>pavanvr</dc:creator>
    <dc:date>2007-07-11T07:00:54Z</dc:date>
    <item>
      <title>database locking query</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/database-locking-query/m-p/4035651#M742965</link>
      <description>this is a situation that I am facing. Hence require urgent help.&lt;BR /&gt;    two systems S1 and S2. Both of them access a raw&lt;BR /&gt;disk RD where oracle tables are present and both systems use their own&lt;BR /&gt;tablespaces. One of them is able to access the disk while the other is&lt;BR /&gt;waiting (according to the oracle guys). I ran glance and one of the&lt;BR /&gt;systems is showing 100% DISK utilization when the batch process is run.&lt;BR /&gt;The runq increases and the avwait increases and ultimately the service&lt;BR /&gt;time increases.&lt;BR /&gt;   Is there a problem like when the same raw disk is used by Oracle,&lt;BR /&gt;there is some kind of locking mechanism which prevents the other system&lt;BR /&gt;to access it? I mean is there a configuration where that locking could&lt;BR /&gt;be done? Otherwise parallel access should be possible because they are&lt;BR /&gt;using different tablespaces.&lt;BR /&gt;   Please let me know how I can proceed to debug such problem.</description>
      <pubDate>Wed, 11 Jul 2007 07:00:54 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/database-locking-query/m-p/4035651#M742965</guid>
      <dc:creator>pavanvr</dc:creator>
      <dc:date>2007-07-11T07:00:54Z</dc:date>
    </item>
    <item>
      <title>Re: database locking query</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/database-locking-query/m-p/4035652#M742966</link>
      <description>Shalom,&lt;BR /&gt;&lt;BR /&gt;If a volume group (disk) is on shared storage the volume group must be activated in shared mode for two database instances to access it from two different machines.&lt;BR /&gt;&lt;BR /&gt;Note that Oracle Server is not certified for this type of access. You would need RAC to successfully do this.&lt;BR /&gt;&lt;BR /&gt;LVM on HP-UX prevents access to the same disk (volume group) from two different systems unless the volume group is activated in shared mode. So, yes there is a locking mechanism and turning it off may lead to data corruption.&lt;BR /&gt;&lt;BR /&gt;SEP</description>
      <pubDate>Wed, 11 Jul 2007 07:20:08 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/database-locking-query/m-p/4035652#M742966</guid>
      <dc:creator>Steven E. Protter</dc:creator>
      <dc:date>2007-07-11T07:20:08Z</dc:date>
    </item>
  </channel>
</rss>

