RE: Middle-Tier Inflicted Corruption
- From: DENNIS WILLIAMS <DWILLIAMS@xxxxxxxxxxxxx>
- To: "'oracle-l@xxxxxxxxxxxxx'" <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 4 Feb 2004 11:50:05 -0600
Ian
I'm not that familiar with Peoplesoft, but I could see that if they have
a true client-server application with a lot of their code executing on the
desktop, if they continually send queries to the database in order to get
the time, this might increase the network traffic substantially, and cause
their application to run significantly more slowly because of the delays for
each time request. Also, most ERP functions don't depend so much on the
exact time of day as just having the correct day, and the desktops should be
okay for that, in general. Of course you might get the occasional PC with
wildly wrong clock (your situation). Our ERP (not Peoplesoft) executes most
of its code on the server, but I recall an incident where a bad PC clock
caused some bad records.
Dennis Williams
DBA
Lifetouch, Inc.
dwilliams@xxxxxxxxxxxxx
-----Original Message-----
From: MacGregor, Ian A. [mailto:ian@xxxxxxxxxxxxxxxxx]
Sent: Wednesday, February 04, 2004 11:35 AM
To: 'oracle-l@xxxxxxxxxxxxx'
Subject: RE: Middle-Tier Inflicted Corruption
To the best of my knowledge it did. This suggests that if there is no
middle tier, Peoplesoft would rely on the system timestamps of the
individual users' desktops. I am, however, no PS expert. We have
Peoplesoft administrators to manage the Peoplesoft software, and windows
administrators to manage the clients and middle tier. I just take care of
the databases.
I've now mined all the data I can from the redo logs. I am now producing
reports of all questionable timestamps in the database. It is rare that a
Peoplesoft record is created during off hours; except, many Peoplesoft rows
are created at "midnight", i.e., they have the time portion of the timestamp
truncated.
Ian MacGregor
Stanford Linear Accelerator Center
ian@xxxxxxxxxxxxxxxxx
-----Original Message-----
From: Hemant K Chitale [mailto:hkchital@xxxxxxxxxxxxxx]
Sent: Wednesday, February 04, 2004 5:49 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: Middle-Tier Inflicted Corruption
Does/did PeopleSoft pick the date from Application Servers or Clients [as
in "User's PCs"] ??
Scary and quite dangerous not to rely on one central location -- the
database -- for dates.
It is like allowing multiple sequence generators to generate numbers for
the same Sequence.
Hemant
At 04:27 PM 02-02-04 -0800, you wrote:
>I haven't had much sleep lately. The other day someone came to ask why
>our Financials Peoplesoft database thought it was 1998. I checked to be
>sure, and the database returned the correct date. I asked them to check
>the client, which in this case is a Citrix farm. Some of those servers
>showed the 1998 dates. The maintainer of that system was queried and
replied:
>
>
>"The problem with the clock was due to the old domain controller not
>correctly synchronizing its time with the new domain controller. Which is
>another good reason for building a new domain controller. Because the
>clocks never properly synchronized, when the new domain controller came
>online to backup the failing primary it came up with a time that was out
>of date. This has caused the domain time to be out of sync. It was a
>last vestige of the old domain controller 'OVERLORD'. I apologize for the
>problems it has caused you. If you have any questions about this please
>let me know."
>
>
>
>Peoplesoft (in-the-head) in their ultimate wisdom decided not to use
>the
>date on the database server, but that on the client. I now have these
>incorrect dates sprinkled through the system. Furthermore some have
>propagated from parent to child. I spent most of the weekend mining redo
>logs and believe I have come up with a complete list of the effected
>rows. One cannot ever be 100% sure. The project leaders for each
>Peoplesoft module have these. They will be responsible for implementing
>any corrections
>
>Peoplesoft does not use database enforced referential integrity.
>However
>it does employ unique indexes and calls them primary keys. These keys can
>include dates. If the date of a parent table is corrected in this
>situation and the children are missed, those children are now orphans. If
>a child's record is changed and the parent's missed, same thing. If the
>dates are not changed then reports are incorrect. Perhaps a capital asset
>get's an incorrect receipt date and the depreciation schedule is thrown
off.
>
>With database enforced RI I can find the lineage of a key through all
>generations, but that is not so easy when it is program based.
>
>I am open to suggestions as to how to best remedy this stituation
>
>
>Ian MacGregor
>Stanford Linear Accelerator Center
>ian@xxxxxxxxxxxxxxxxx
>
>
>
>
>
>
>
>
>
>
>
>
>----------------------------------------------------------------
>Please see the official ORACLE-L FAQ: http://www.orafaq.com
>----------------------------------------------------------------
>To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put
>'unsubscribe' in the subject line.
>--
>Archives are at //www.freelists.org/archives/oracle-l/
>FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
>-----------------------------------------------------------------
Hemant K Chitale
Oracle 9i Database Administrator Certified Professional
http://hkchital.tripod.com {last updated 24-Jan-04}
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put
'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
