RE: Criteria for handoff from development

Dennis,

In addition to the points mentioned by Tom, I would also ask the following questions:

• What tools/clients will be used to populate the data and extract it for reporting? Depending on the tool, your 'performance' will vary... I wouldn't want an MSAccess/ODBC type query running against a 1mil row table that is joined to another 2mil table.. The DBA invariably gets blamed at the end for *any* performance problem!
• What is the concurrency requirements and are they being met? In other words, are hot-spot tables present and if so, how can this be mitigated? Note: Increase in no.of.users = decrease in concurrency!
• Who's gonna decide the STORAGE parameters and Tablespace layout? Would you have inputs in the Hardware side of things?
• What are the availability requirements? How is the backup going to being done? How big would the database grow to?
• What is the data transfer requirements between this database and the rest of the databases in the organization? What are the mechanisms to achieve that? (i.e. replication has a significant overhead not only on the network, but also in Admin time!)

In short - take a look at all the Production issues that come up in this list and apply the relevant ones.

John Kanagaraj
Oracle Applications DBA
DBSoft Inc
(W): 408-970-7002

Fear is the darkroom where Evil develops your negatives. Wanna break free of fear? Click on 'http://www.needhim.org'

• The opinions and statements above are entirely my own and not those of my employer or clients **

> -----Original Message-----
> From: Mercadante, Thomas F [mailto:NDATFM_at_labor.state.ny.us]
> Sent: Friday, January 04, 2002 12:50 PM
> To: Multiple recipients of list ORACLE-L
> Subject: RE: Criteria for handoff from development
>
>
> Dennis,
>
> First of all, I would tell your manager that 90% of tuning is
> in writing
> good queries no matter what the data model looks like.
>
> Unfortunately, you receiving a data model and expecting to
> perform miracles
> is pretty naive of the organization. This is a classic
> example of how NOT
> to do things.
>
> Saying that, I would look closely at the model and check for
> the following:
>
> Look closely for normalization problems. If you see
> repeating fields in a
> table, reject it and tell them to change it.
>
> Look for column-naming standards. If they do not have them,
> make some up
> and enforce them. Some common naming standards would use a suffix to
> indicate the type of data the column is holding. Things like
> _DATE _NBR
> _FNAME _LNAME _ID and _CODE would indicate date, number,
> standard length
> first and last name, Id type columns indicating it is a primary key
> (possibly) an integer value, and a Code column indicating
> that this is a
> foreign key to another table. This is soooo important for
> report-writing
> people on the back-end of the project. They can implicitly
> see that the
> column has a certain value by the name.
>
> Ask how they determined primary key values for all tables.
> Specifically,
> how do they KNOW that the values will be unique. Question
> everything you
> see. This is probably the biggest area of concern that I would have.
> Non-db designers will always make a mistake here. I
> developed a db once
> that used the soc-sec as the pk. WRONG! The db was at a
> college. Want to
> know how many parents use their personal soc-sec on the
> application for the
> child? :(
>
> Look for obvious foreign key relationships and enforce them.
> Develop a
> standard where the related columns in database tables (like
> FK columns) have
> the same name in both tables (like soc_sec_number is named
> the same in all
> tables).
>
> This is not an easy thing to do. You should have been involved in the
> meetings from the very get-go. Hopefully, this is not a
> 300-table design
> that will take you very long to review.
>
> Hope these help!
>
> Tom Mercadante
> Oracle Certified Professional
>
>
> -----Original Message-----
> Sent: Friday, January 04, 2002 2:45 PM
> To: Multiple recipients of list ORACLE-L
>
>
> Can anyone provide some criteria of what you look for when a
> data model is
> handed off from production? We are starting a large
> development project and
> I lobbied management to hire a data architect. As they have
> talked to these
> people, they are getting statements such as "and then the DBA
> will check out
> the data model to make sure there won't be any performance
> problems". I am
> concerned about what will be expected of me and wondered how
> other DBAs
> handle this situation. What do you look for in a model in
> terms of making
> sure the performance will be good? I said that I could look
> at the queries
> that would be run to see how many tables would need to be
> joined to retrieve
> the data, but the manager replied that a good DBA wouldn't
> need to see the
> queries, should just be able to look at the model. Up until
> this point, our
> client-server design tools have tended to protect the
> developers from doing
> dumb stuff, but now in the Java world some of those safeguards.
>
> Dennis Williams
> DBA
> Lifetouch, Inc.
> dwilliams_at_lifetouch.com
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: DENNIS WILLIAMS
> INET: DWILLIAMS_at_LIFETOUCH.COM
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Mercadante, Thomas F
> INET: NDATFM_at_labor.state.ny.us
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: John Kanagaraj
  INET: john.kanagaraj_at_hds.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).