Management will not understand technical arguements in favour of one strate=
gy or another.
You have to hit them with the issue of data quality, and integrity. The sys=
tem you describe seems to put these factors into question. Bring it down to=
money - a simplistic approach most management do understand. Consider the =
cost to the organisation of the database going pear-shaped. That's your bas=
e line. Then try and quantify the successive costs of each step towards you=
r perceived best system, with the financial costs of not doing that. Place =
a qualitative assessment of the vulnerablitiy of your present system to col=
lapse (a % figure has impact). Ultimately, you have to make a cost-assessme=
nt of doing / not doing something.=20
Whatever else, management will be very aware that if they ignore your advic=
e, and things go wrong, there will be a written document from yourself havi=
ng warned of the situation, which would leave them very exposed. That can c=
oncentrate minds.
Ho Hum - it all seems incredibly elementary, but its not the first time I h=
ave encountered this sort of ostrich-like attitude to database...
peter
edinburgh
> ------------------
> Original message, formatting fixed
> -------------------
>=20
> OK guys, need some help and ammunition here, so a bit of background
> first. I'm in my 3rd week in a new job where they are have a=20
> 3rd party
> financials app sitting on 8.1.7 on win2k. Software vendor=20
> is coming in
> today to make some changes.
>=20
> They've never had any in-house DBA skills and have relied=20
> solely on 3rd
> parties. No Oracle support contract (I'm working on getting this
> changed!). No DBA contract with 3rd party, only chargeable,=20
> ad-hoc work.
>=20
> So, they've talked about getting the data in the test/dev databases
> refreshed, far as I can see they only have one database. =20
> Turns out they
> have one database with three separate schemas. To refresh data, 3rd
> party has done export/import between the schemas. I've tried=20
> explaining
> that this is not ideal and that=3D20
> really they need a separate test system, but they don't understand.
> Absolutely no database knowledge in here, and it would seem that even
> the software vendor is lacking in this department. (Just to=20
> demonstrate,
> 3 redo log groups, 1 member per group size 1M, all sat in=20
> same location,
> 2 copies of controlfile, in same location - get the drift??)
>=20
> The work the software vendor is coming in to do is create 6=20
> new schemas
> as a way of providing 6 different=3D20
> 'staging areas' where copies of the live data can be kept at different
> points in time to help through year end. Once year end is=20
> completed they
> think they can use these 'staging areas' for testing enhancements.
>=20
> I can't look on Metalink, as no CSI number. I'm about to look at OTN
> and go RTFM's, which I only got today.
>=20
> What I would like, and quickly is some strong arguments as to why it
> should not be done this way and alternatives to suggest. I've already
> mentioned creating a dedicated test database. I've so far managed to
> hold off on the software vendor beginning work, but I now need to
> justify this to my manager and to the software vendor.=3D20
>=20
> TIA
>=20
> Lisa.
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request_at_freelists.org
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
>=20
This e-mail message, and any files transmitted with it, are
confidential and intended solely for the use of the addressee. If
this message was not addressed to you, you have received it in error
and any copying, distribution or other use of any part of it is
strictly prohibited. Any views or opinions presented are solely those
of the sender and do not necessarily represent those of the British
Geological Survey. The security of e-mail communication cannot be
guaranteed and the BGS accepts no liability for claims arising as a
result of the use of this medium to transmit messages from or to the
BGS. . http://www.bgs.ac.uk
*********************************************************************
----------------------------------------------------------------
Please see the official ORACLE-L FAQ:
http://www.orafaq.com
To unsubscribe send email to: oracle-l-request_at_freelists.org
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Received on Thu May 13 2004 - 04:33:06 CDT
