Loading ...
Sorry, an error occurred while loading the content.
 

Re: PeopleSoft DBA Forum Digest Number 1223

Expand Messages
  • SP
    To make it very simple,  my take would be (assumption  no tools upgrade is involved here)  for Oracle upgrade  you do not need to change any thing on
    Message 1 of 1 , May 29, 2009
      To make it very simple,  my take would be (assumption  no tools upgrade is involved here)  for Oracle upgrade  you do not need to change any thing on application server side.
      (Just reconfigure the application server)
       
      On the process scheduler side - relink psrun and sqrmake files.
       
      Thanks - SP
       

      --- On Fri, 5/29/09, psftdba@yahoogroups.com <psftdba@yahoogroups.com> wrote:

      From: psftdba@yahoogroups.com <psftdba@yahoogroups.com>
      Subject: PeopleSoft DBA Forum Digest Number 1223
      To: psftdba@yahoogroups.com
      Date: Friday, May 29, 2009, 3:20 PM

      Messages In This Digest (5 Messages)

      1a.
      DbFlags From: Brian Thompson
      1b.
      Re: DbFlags From: David Kurtz
      1c.
      Re: DbFlags From: Brian Thompson
      1d.
      Re: DbFlags From: David Kurtz
      1e.
      Re: DbFlags From: Brian Thompson

      Messages

      1a.

      DbFlags

      Posted by: "Brian Thompson" brian_thompson@...   bt4psftdba

      Fri May 29, 2009 12:38 am (PDT)



      Hello everyone,

      We are upgrading our Oracle database from version 9.2.0.8 to 10.2.0.4.

      Our Tools version is 8.49.13

      One of the changes that PeopleSoft recommend, on upgrading to 10g,

      is to set DbFlags = 8.

      This parameter is found in both psprcs.cfg and psappsrv.cfg.

      In 9i we have this set to zero.

      Has anybody got any views on this ?

      On the internet I've found arguments in favour of both 8 and zero !

      Thanks in advance,

      Brian Thompson

      Diodes Zetex Semiconductors Ltd.

      ____________ _________ _________ _________ _________ _________

      Diodes Incorporated

      http://www.zetex. com
      http://www.zetexcn


      E-MAILS are susceptible to interference. You should not assume that
      the contents originated from the sender or the Diodes Incorporated or that they have been accurately reproduced from their original form.
      Diodes Incorporated accepts no responsibility for information, errors or omissions in this e-mail nor for its use or misuse nor for any act committed or omitted in connection with this communication.
      If in doubt, please verify the authenticity with the sender.
      ____________ _________ _________ _________ _________ _________


      1b.

      Re: DbFlags

      Posted by: "David Kurtz" david.kurtz@...   davidkurtz

      Fri May 29, 2009 1:23 am (PDT)



      dbflags=8 diables the secondary session in App server.

      This second database session is used for sequence number generation.
      Conceptually, It is similar to using an autonomous transaction or using an
      Oracle Sequence without a cache.
      The increment of the table with the sequence number is done in a secondary
      connection so that it can be committed immediately, thus reducing row lock
      contention.

      PeopleSoft uses tables to provide sequence numbers, the operations to
      increment these numbers serialise on row level locks.
      They don't use the Oracle database sequence object because that would be
      platform specific.

      There are some new PeopleCode functions provided to get the new sequence
      number value (see
      http://blog. psftdba.com/ 2008/07/sequence -number-allocati on-in.html)
      The PeopleTools manual warns that it is possible to have the primary session
      locked by the secondary session. So it depends on how your application is
      coded.
      "PeopleSoft does not recommend Using both the GetNextNumberWithGa psCommit
      function and the GetNextNumber function in the same application, on the same
      table, in the same unit of work. This can lead to lock contention or
      deadlocking. "
      I think this risk is behind the recommendation to set it to 8. So it
      depends upon your application.

      My guess is that if you have done a tools upgrade on an older application it
      might not use the new GetNextNumberWithGa psCommit function. Hence the
      recommendation. However, I can't see how this relates to the Oracle
      version. I thought this behaviour was independent of Oracle version.

      This feature is aimed at larger, more active systems with very frequent
      increments to version numbers.
      If you disable this feature watch for row level lock contention on the
      sequence number tables.
      On smaller systems you are unlikely to be able to see much difference.

      regards
      ____________ _________ ____
      David Kurtz
      Go-Faster Consultancy Ltd.
      tel: +44 (0)7771 760660
      fax: +44 (0)7092 348865
      mailto:david.kurtz@ go-faster. co.uk
      web: www.go-faster. co.uk
      Book: PeopleSoft for the Oracle DBA: http://www.psftdba. com
      <http://www.psftdba. com/>
      DBA Blogs: PeopleSoft: http://blog. psftdba.com <http://blog. psftdba.com/> ,
      Oracle: http://blog. go-faster. co.uk <http://blog. go-faster. co.uk/>
      PeopleSoft DBA Forum: http://groups. yahoo.com/ group/psftdba

      _____

      From: psftdba@yahoogroups .com [mailto:psftdba@yahoogroups .com] On Behalf Of
      Brian Thompson
      Sent: Friday, May 29, 2009 8:37 AM
      To: psftdba@yahoogroups .com
      Subject: PeopleSoft DBA Forum DbFlags

      Hello everyone,

      We are upgrading our Oracle database from version 9.2.0.8 to 10.2.0.4.

      Our Tools version is 8.49.13

      One of the changes that PeopleSoft recommend, on upgrading to 10g,

      is to set DbFlags = 8.

      This parameter is found in both psprcs.cfg and psappsrv.cfg.

      In 9i we have this set to zero.

      Has anybody got any views on this ?

      On the internet I've found arguments in favour of both 8 and zero !

      Thanks in advance,

      Brian Thompson

      Diodes Zetex Semiconductors Ltd.

      ____________ _________ _________ _________ _________ _________ _

      Diodes Incorporated

      <http://www.zetex. com/> www.zetex.com
      <http://www.diodes. com/> www.diodes.com

      E-MAILS are susceptible to interference. You should not assume that
      the contents originated from the sender or Diodes Incorporated or that they
      have been accurately reproduced from their original form.
      Diodes Incorporated accepts no responsibility for information, errors or
      omissions in
      this e-mail nor for its use or misuse nor for any act committed or omitted
      in connection with this communication.
      If in doubt, please verify the authenticity with the sender.
      ____________ _________ _________ _________ _________ _________

      1c.

      Re: DbFlags

      Posted by: "Brian Thompson" brian_thompson@...   bt4psftdba

      Fri May 29, 2009 1:49 am (PDT)



      Hi David,

      Thanks very much for that clarification.

      As you know we don't have a large numbers of users on our PeopleSoft
      system

      so it would seem likely that we wouldn't see much improvement by setting
      DbFlags to 8 ?

      Having said that is there any particular down-side in our case of
      setting DbFlags to 8 ?

      However there a second issue around the value of DbFlags which is
      related to the calculation

      of statistics. This is my understanding of how it works :-

      When DbFlags=0 the App Engine programs (and some Cobol programs as well
      I believe),

      calculate statistics for temporary tables (e.g. _TAO tables) at
      run-time, i.e. when the temporary

      tables have representative amounts of data in them.

      Hopefully this will encourage the Oracle optimizer to pick a better
      execution plan than would otherwise

      have been the case without the statistics.

      When DbFlags=1 this 'on-the-fly' statistics calculation is disabled.

      So if DbFlags=8 how does this effect the statistics calculation :?

      Do we still get the 'on-the-fly' statistics calculation or not ?

      Best Regards,

      Brian

      ____________ _________ _________ __

      From: psftdba@yahoogroups .com [mailto:psftdba@yahoogroups .com] On Behalf
      Of David Kurtz
      Sent: 29 May 2009 09:22
      To: psftdba@yahoogroups .com
      Subject: RE: PeopleSoft DBA Forum DbFlags

      dbflags=8 diables the secondary session in App server.

      This second database session is used for sequence number generation.

      Conceptually, It is similar to using an autonomous transaction or using
      an Oracle Sequence without a cache.

      The increment of the table with the sequence number is done in a
      secondary connection so that it can be committed immediately, thus
      reducing row lock contention.

      PeopleSoft uses tables to provide sequence numbers, the operations to
      increment these numbers serialise on row level locks.

      They don't use the Oracle database sequence object because that would be
      platform specific.

      There are some new PeopleCode functions provided to get the new sequence
      number value (see
      http://blog. psftdba.com/ 2008/07/sequence -number-allocati on-in.html
      <http://blog. psftdba.com/ 2008/07/sequence -number-allocati on-in.html> )

      The PeopleTools manual warns that it is possible to have the primary
      session locked by the secondary session. So it depends on how your
      application is coded.

      "PeopleSoft does not recommend Using both the
      GetNextNumberWithGa psCommit function and the GetNextNumber function in
      the same application, on the same table, in the same unit of work. This
      can lead to lock contention or deadlocking. "

      I think this risk is behind the recommendation to set it to 8. So it
      depends upon your application.

      My guess is that if you have done a tools upgrade on an older
      application it might not use the new GetNextNumberWithGa psCommit
      function. Hence the recommendation. However, I can't see how this
      relates to the Oracle version. I thought this behaviour was independent
      of Oracle version.

      This feature is aimed at larger, more active systems with very frequent
      increments to version numbers.

      If you disable this feature watch for row level lock contention on the
      sequence number tables.

      On smaller systems you are unlikely to be able to see much difference.

      regards
      ____________ _________ ____
      David Kurtz
      Go-Faster Consultancy Ltd.
      tel: +44 (0)7771 760660
      fax: +44 (0)7092 348865
      mailto:david.kurtz@ go-faster. co.uk <mailto:david.kurtz@ go-faster. co.uk>
      web: www.go-faster. co.uk
      Book: PeopleSoft for the Oracle DBA: http://www.psftdba. com
      <http://www.psftdba. com/>
      DBA Blogs: PeopleSoft: http://blog. psftdba.com
      <http://blog. psftdba.com/> , Oracle: http://blog. go-faster. co.uk
      <http://blog. go-faster. co.uk/>
      PeopleSoft DBA Forum: http://groups. yahoo.com/ group/psftdba
      <http://groups. yahoo.com/ group/psftdba>




      ____________ _________ _________ __

      From: psftdba@yahoogroups .com [mailto:psftdba@yahoogroups .com]
      On Behalf Of Brian Thompson
      Sent: Friday, May 29, 2009 8:37 AM
      To: psftdba@yahoogroups .com
      Subject: PeopleSoft DBA Forum DbFlags

      Hello everyone,



      We are upgrading our Oracle database from version 9.2.0.8 to
      10.2.0.4.

      Our Tools version is 8.49.13



      One of the changes that PeopleSoft recommend, on upgrading to
      10g,

      is to set DbFlags = 8.

      This parameter is found in both psprcs.cfg and psappsrv.cfg.



      In 9i we have this set to zero.



      Has anybody got any views on this ?

      On the internet I've found arguments in favour of both 8 and
      zero !



      Thanks in advance,

      Brian Thompson

      Diodes Zetex Semiconductors Ltd.




      ____________ _________ _________ _________ _________ _________ _

      Diodes Incorporated

      www.zetex.com <http://www.zetex. com/>
      www.diodes.com <http://www.diodes. com/>

      E-MAILS are susceptible to interference. You should not assume
      that
      the contents originated from the sender or Diodes Incorporated
      or that they
      have been accurately reproduced from their original form.
      Diodes Incorporated accepts no responsibility for information,
      errors or omissions in
      this e-mail nor for its use or misuse nor for any act committed
      or omitted in connection with this communication.
      If in doubt, please verify the authenticity with the sender.
      ____________ _________ _________ _________ _________ _________

      ____________ _________ _________ _________ _________ _________

      Diodes Incorporated

      http://www.zetex. com
      http://www.zetexcn


      E-MAILS are susceptible to interference. You should not assume that
      the contents originated from the sender or the Diodes Incorporated or that they have been accurately reproduced from their original form.
      Diodes Incorporated accepts no responsibility for information, errors or omissions in this e-mail nor for its use or misuse nor for any act committed or omitted in connection with this communication.
      If in doubt, please verify the authenticity with the sender.
      ____________ _________ _________ _________ _________ _________


      1d.

      Re: DbFlags

      Posted by: "David Kurtz" david.kurtz@...   davidkurtz

      Fri May 29, 2009 3:46 am (PDT)



      I have just realised that I was slightly misleading in my previous post.
      These are the bits defined in the app server config file. They can be set
      indepently.

      ; DbFlags Bitfield
      ;
      ; Bit Flag
      ; --- ----
      ; 1 - Ignore metaSQL to update database statistics(shared with
      COBOL)
      ; 2 - Ignore Truncate command for DB2Unix, use Delete instead
      ; 4 - Disable Second DB Connection
      ; 8 - Disable Persistent Secondary DB Connection

      Setting Bit 8 makes the second connection temporary. So you secondary
      sessions are created on demand, and then they are shut down, so this helps
      to prevent locking and deadlocking. However, if you create connections very
      frequently that can also create a significant overhead.

      Bit 4 disables the the second session completely - and you don't want to do
      that.

      Bit 1 is independent of these.



      regards
      ____________ _________ ____
      David Kurtz
      Go-Faster Consultancy Ltd.
      tel: +44 (0)7771 760660
      fax: +44 (0)7092 348865
      mailto:david.kurtz@ go-faster. co.uk
      web: www.go-faster. co.uk
      Book: PeopleSoft for the Oracle DBA: http://www.psftdba. com
      <http://www.psftdba. com/>
      DBA Blogs: PeopleSoft: http://blog. psftdba.com <http://blog. psftdba.com/> ,
      Oracle: http://blog. go-faster. co.uk <http://blog. go-faster. co.uk/>
      PeopleSoft DBA Forum: http://groups. yahoo.com/ group/psftdba


      _____

      From: psftdba@yahoogroups .com [mailto:psftdba@yahoogroups .com] On Behalf Of
      Brian Thompson
      Sent: Friday, May 29, 2009 9:49 AM
      To: psftdba@yahoogroups .com
      Subject: RE: PeopleSoft DBA Forum DbFlags

      Hi David,

      Thanks very much for that clarification.

      As you know we don't have a large numbers of users on our PeopleSoft system

      so it would seem likely that we wouldn't see much improvement by setting
      DbFlags to 8 ?

      Having said that is there any particular down-side in our case of setting
      DbFlags to 8 ?

      However there a second issue around the value of DbFlags which is related to
      the calculation

      of statistics. This is my understanding of how it works :-

      When DbFlags=0 the App Engine programs (and some Cobol programs as well I
      believe),

      calculate statistics for temporary tables (e.g. _TAO tables) at run-time,
      i.e. when the temporary

      tables have representative amounts of data in them.

      Hopefully this will encourage the Oracle optimizer to pick a better
      execution plan than would otherwise

      have been the case without the statistics.

      When DbFlags=1 this 'on-the-fly' statistics calculation is disabled.

      So if DbFlags=8 how does this effect the statistics calculation :?

      Do we still get the 'on-the-fly' statistics calculation or not ?

      Best Regards,

      Brian

      _____

      From: psftdba@yahoogroups .com [mailto:psftdba@yahoogroups .com] On Behalf Of
      David Kurtz
      Sent: 29 May 2009 09:22
      To: psftdba@yahoogroups .com
      Subject: RE: PeopleSoft DBA Forum DbFlags

      dbflags=8 diables the secondary session in App server.

      This second database session is used for sequence number generation.

      Conceptually, It is similar to using an autonomous transaction or using an
      Oracle Sequence without a cache.

      The increment of the table with the sequence number is done in a secondary
      connection so that it can be committed immediately, thus reducing row lock
      contention.

      PeopleSoft uses tables to provide sequence numbers, the operations to
      increment these numbers serialise on row level locks.

      They don't use the Oracle database sequence object because that would be
      platform specific.

      There are some new PeopleCode functions provided to get the new sequence
      number value (see http://blog.
      <http://blog. psftdba.com/ 2008/07/sequence -number-allocati on-in.html>
      psftdba.com/ 2008/07/sequence -number-allocati on-in.html)

      The PeopleTools manual warns that it is possible to have the primary session
      locked by the secondary session. So it depends on how your application is
      coded.

      "PeopleSoft does not recommend Using both the GetNextNumberWithGa psCommit
      function and the GetNextNumber function in the same application, on the same
      table, in the same unit of work. This can lead to lock contention or
      deadlocking. "

      I think this risk is behind the recommendation to set it to 8. So it
      depends upon your application.

      My guess is that if you have done a tools upgrade on an older application it
      might not use the new GetNextNumberWithGa psCommit function. Hence the
      recommendation. However, I can't see how this relates to the Oracle
      version. I thought this behaviour was independent of Oracle version.

      This feature is aimed at larger, more active systems with very frequent
      increments to version numbers.

      If you disable this feature watch for row level lock contention on the
      sequence number tables.

      On smaller systems you are unlikely to be able to see much difference.

      regards
      ____________ _________ ____
      David Kurtz
      Go-Faster Consultancy Ltd.
      tel: +44 (0)7771 760660
      fax: +44 (0)7092 348865
      mailto:david. <mailto:david.kurtz@ go-faster. co.uk> kurtz@go-faster. co.uk
      web: www.go-faster. co.uk
      Book: PeopleSoft for the Oracle DBA: http://www.psftdba.
      <http://www.psftdba. com/> com
      DBA Blogs: PeopleSoft: http://blog. <http://blog. psftdba.com/> psftdba.com,
      Oracle: http://blog. <http://blog. go-faster. co.uk/> go-faster.co. uk
      PeopleSoft DBA Forum: http://groups. <http://groups. yahoo.com/ group/psftdba>
      yahoo.com/group/ psftdba

      _____

      From: psftdba@yahoogroups .com [mailto:psftdba@yahoogroups .com] On Behalf Of
      Brian Thompson
      Sent: Friday, May 29, 2009 8:37 AM
      To: psftdba@yahoogroups .com
      Subject: PeopleSoft DBA Forum DbFlags

      Hello everyone,

      We are upgrading our Oracle database from version 9.2.0.8 to 10.2.0.4.

      Our Tools version is 8.49.13

      One of the changes that PeopleSoft recommend, on upgrading to 10g,

      is to set DbFlags = 8.

      This parameter is found in both psprcs.cfg and psappsrv.cfg.

      In 9i we have this set to zero.

      Has anybody got any views on this ?

      On the internet I've found arguments in favour of both 8 and zero !

      Thanks in advance,

      Brian Thompson

      Diodes Zetex Semiconductors Ltd.

      ____________ _________ _________ _________ _________ _________ _

      Diodes Incorporated

      <http://www.zetex. com/> www.zetex.com
      <http://www.diodes. com/> www.diodes.com

      E-MAILS are susceptible to interference. You should not assume that
      the contents originated from the sender or Diodes Incorporated or that they
      have been accurately reproduced from their original form.
      Diodes Incorporated accepts no responsibility for information, errors or
      omissions in
      this e-mail nor for its use or misuse nor for any act committed or omitted
      in connection with this communication.
      If in doubt, please verify the authenticity with the sender.
      ____________ _________ _________ _________ _________ _________

      ____________ _________ _________ _________ _________ _________ _

      Diodes Incorporated

      <http://www.zetex. com/> www.zetex.com
      <http://www.diodes. com/> www.diodes.com

      E-MAILS are susceptible to interference. You should not assume that
      the contents originated from the sender or Diodes Incorporated or that they
      have been accurately reproduced from their original form.
      Diodes Incorporated accepts no responsibility for information, errors or
      omissions in
      this e-mail nor for its use or misuse nor for any act committed or omitted
      in connection with this communication.
      If in doubt, please verify the authenticity with the sender.
      ____________ _________ _________ _________ _________ _________

      1e.

      Re: DbFlags

      Posted by: "Brian Thompson" brian_thompson@...   bt4psftdba

      Fri May 29, 2009 3:55 am (PDT)



      Hi David,

      I hoped it might be something like that.

      So, if I have understood this correctly, it seems to me that setting
      DbFlags=8 will be

      ok for us, as we don't create secondary connections very frequently,

      as we don't have a large user-base,

      so we won't be incurring much of an overhead, and setting to 8 will help
      prevent

      deadlocking.

      Plus we will still get the 'on-the-fly' statistics calculated.

      Hope I've got that right !

      Thanks very much (as always) for your help,

      Best Regards,

      Brian

      ____________ _________ _________ __

      From: psftdba@yahoogroups .com [mailto:psftdba@yahoogroups .com] On Behalf
      Of David Kurtz
      Sent: 29 May 2009 11:45
      To: psftdba@yahoogroups .com
      Subject: RE: PeopleSoft DBA Forum DbFlags

      I have just realised that I was slightly misleading in my previous post.

      These are the bits defined in the app server config file. They can be
      set indepently.

      ; DbFlags Bitfield
      ;
      ; Bit Flag
      ; --- ----
      ; 1 - Ignore metaSQL to update database statistics(shared with
      COBOL)
      ; 2 - Ignore Truncate command for DB2Unix, use Delete instead
      ; 4 - Disable Second DB Connection
      ; 8 - Disable Persistent Secondary DB Connection

      Setting Bit 8 makes the second connection temporary. So you secondary
      sessions are created on demand, and then they are shut down, so this
      helps to prevent locking and deadlocking. However, if you create
      connections very frequently that can also create a significant overhead.

      Bit 4 disables the the second session completely - and you don't want to
      do that.

      Bit 1 is independent of these.

      regards
      ____________ _________ ____
      David Kurtz
      Go-Faster Consultancy Ltd.
      tel: +44 (0)7771 760660
      fax: +44 (0)7092 348865
      mailto:david.kurtz@ go-faster. co.uk <mailto:david.kurtz@ go-faster. co.uk>
      web: www.go-faster. co.uk
      Book: PeopleSoft for the Oracle DBA: http://www.psftdba. com
      <http://www.psftdba. com/>
      DBA Blogs: PeopleSoft: http://blog. psftdba.com
      <http://blog. psftdba.com/> , Oracle: http://blog. go-faster. co.uk
      <http://blog. go-faster. co.uk/>
      PeopleSoft DBA Forum: http://groups. yahoo.com/ group/psftdba
      <http://groups. yahoo.com/ group/psftdba>




      ____________ _________ _________ __

      From: psftdba@yahoogroups .com [mailto:psftdba@yahoogroups .com]
      On Behalf Of Brian Thompson
      Sent: Friday, May 29, 2009 9:49 AM
      To: psftdba@yahoogroups .com
      Subject: RE: PeopleSoft DBA Forum DbFlags

      Hi David,



      Thanks very much for that clarification.



      As you know we don't have a large numbers of users on our
      PeopleSoft system

      so it would seem likely that we wouldn't see much improvement by
      setting DbFlags to 8 ?



      Having said that is there any particular down-side in our case
      of setting DbFlags to 8 ?



      However there a second issue around the value of DbFlags which
      is related to the calculation

      of statistics. This is my understanding of how it works :-



      When DbFlags=0 the App Engine programs (and some Cobol programs
      as well I believe),

      calculate statistics for temporary tables (e.g. _TAO tables) at
      run-time, i.e. when the temporary

      tables have representative amounts of data in them.

      Hopefully this will encourage the Oracle optimizer to pick a
      better execution plan than would otherwise

      have been the case without the statistics.



      When DbFlags=1 this 'on-the-fly' statistics calculation is
      disabled.



      So if DbFlags=8 how does this effect the statistics calculation
      :?

      Do we still get the 'on-the-fly' statistics calculation or not ?



      Best Regards,

      Brian




      ____________ _________ _________ __

      From: psftdba@yahoogroups .com [mailto:psftdba@yahoogroups .com]
      On Behalf Of David Kurtz
      Sent: 29 May 2009 09:22
      To: psftdba@yahoogroups .com
      Subject: RE: PeopleSoft DBA Forum DbFlags









      dbflags=8 diables the secondary session in App server.



      This second database session is used for sequence number
      generation.

      Conceptually, It is similar to using an autonomous transaction
      or using an Oracle Sequence without a cache.

      The increment of the table with the sequence number is done in a
      secondary connection so that it can be committed immediately, thus
      reducing row lock contention.



      PeopleSoft uses tables to provide sequence numbers, the
      operations to increment these numbers serialise on row level locks.

      They don't use the Oracle database sequence object because that
      would be platform specific.



      There are some new PeopleCode functions provided to get the new
      sequence number value (see
      http://blog. psftdba.com/ 2008/07/sequence -number-allocati on-in.html
      <http://blog. psftdba.com/ 2008/07/sequence -number-allocati on-in.html> )

      The PeopleTools manual warns that it is possible to have the
      primary session locked by the secondary session. So it depends on how
      your application is coded.

      "PeopleSoft does not recommend Using both the
      GetNextNumberWithGa psCommit function and the GetNextNumber function in
      the same application, on the same table, in the same unit of work. This
      can lead to lock contention or deadlocking. "

      I think this risk is behind the recommendation to set it to 8.
      So it depends upon your application.



      My guess is that if you have done a tools upgrade on an older
      application it might not use the new GetNextNumberWithGa psCommit
      function. Hence the recommendation. However, I can't see how this
      relates to the Oracle version. I thought this behaviour was independent
      of Oracle version.



      This feature is aimed at larger, more active systems with very
      frequent increments to version numbers.

      If you disable this feature watch for row level lock contention
      on the sequence number tables.

      On smaller systems you are unlikely to be able to see much
      difference.

      regards
      ____________ _________ ____
      David Kurtz
      Go-Faster Consultancy Ltd.
      tel: +44 (0)7771 760660
      fax: +44 (0)7092 348865
      mailto:david.kurtz@ go-faster. co.uk
      <mailto:david.kurtz@ go-faster. co.uk>
      web: www.go-faster. co.uk
      Book: PeopleSoft for the Oracle DBA: http://www.psftdba. com
      <http://www.psftdba. com/>
      DBA Blogs: PeopleSoft: http://blog. psftdba.com
      <http://blog. psftdba.com/> , Oracle: http://blog. go-faster. co.uk
      <http://blog. go-faster. co.uk/>
      PeopleSoft DBA Forum: http://groups. yahoo.com/ group/psftdba
      <http://groups. yahoo.com/ group/psftdba>






      ____________ _________ _________ __

      From: psftdba@yahoogroups .com
      [mailto:psftdba@yahoogroups .com] On Behalf Of Brian Thompson
      Sent: Friday, May 29, 2009 8:37 AM
      To: psftdba@yahoogroups .com
      Subject: PeopleSoft DBA Forum DbFlags

      Hello everyone,



      We are upgrading our Oracle database from version
      9.2.0.8 to 10.2.0.4.

      Our Tools version is 8.49.13



      One of the changes that PeopleSoft recommend, on
      upgrading to 10g,

      is to set DbFlags = 8.

      This parameter is found in both psprcs.cfg and
      psappsrv.cfg.



      In 9i we have this set to zero.



      Has anybody got any views on this ?

      On the internet I've found arguments in favour of both
      8 and zero !



      Thanks in advance,

      Brian Thompson

      Diodes Zetex Semiconductors Ltd.




      ____________ _________ _________ _________ _________ _________ _

      Diodes Incorporated

      www.zetex.com <http://www.zetex. com/>
      www.diodes.com <http://www.diodes. com/>

      E-MAILS are susceptible to interference. You should not
      assume that
      the contents originated from the sender or Diodes
      Incorporated or that they
      have been accurately reproduced from their original
      form.
      Diodes Incorporated accepts no responsibility for
      information, errors or omissions in
      this e-mail nor for its use or misuse nor for any act
      committed or omitted in connection with this communication.
      If in doubt, please verify the authenticity with the
      sender.

      ____________ _________ _________ _________ _________ _________


      ____________ _________ _________ _________ _________ _________ _

      Diodes Incorporated

      www.zetex.com <http://www.zetex. com/>
      www.diodes.com <http://www.diodes. com/>

      E-MAILS are susceptible to interference. You should not assume
      that
      the contents originated from the sender or Diodes Incorporated
      or that they
      have been accurately reproduced from their original form.
      Diodes Incorporated accepts no responsibility for information,
      errors or omissions in
      this e-mail nor for its use or misuse nor for any act committed
      or omitted in connection with this communication.
      If in doubt, please verify the authenticity with the sender.
      ____________ _________ _________ _________ _________ _________

      ____________ _________ _________ _________ _________ _________

      Diodes Incorporated

      http://www.zetex. com
      http://www.zetexcn


      E-MAILS are susceptible to interference. You should not assume that
      the contents originated from the sender or the Diodes Incorporated or that they have been accurately reproduced from their original form.
      Diodes Incorporated accepts no responsibility for information, errors or omissions in this e-mail nor for its use or misuse nor for any act committed or omitted in connection with this communication.
      If in doubt, please verify the authenticity with the sender.
      ____________ _________ _________ _________ _________ _________


      Recent Activity
    Your message has been successfully submitted and would be delivered to recipients shortly.