RE: Criteria for handoff from development

John - Thanks for bringing up these critical issues:

1. Tools - This is our first Java adventure, so everyone is nervous. Please point out any Java pitfalls that have bitten you.
2. Hot-spot tables - Good issue, will keep it in mind. We are just creating the logical model today.
3. Storage and Tablespace layouts - That would be me. Some input into hardware decisions. On Compaq Tru64 our sys admins have had good luck with RAID5, so will probably insist on that on Sun Solaris.
4. Availability - 24X7. We are looking at RMAN. Too early to think about size, but not terribly large. Maybe 100-gig. tops. Well within the limits of
5. Data transfer not a big issue yet. They have toyed with the idea of replication, and I tried my politically-savvy best to discourage them (as politically-savvy as Dilbert).

Dennis Williams
DBA
Lifetouch, Inc.
dwilliams_at_lifetouch.com

-----Original Message-----
Sent: Friday, January 04, 2002 4:55 PM
To: Multiple recipients of list ORACLE-L

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).
-- 
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).