make sure they use Java prepared statements, especially if they are using lots of literals.
mine didn't -- I had to turn cursor_sharing=force on to solve shared pool problems --- Kimberly Smith <[EMAIL PROTECTED]> wrote: > The only Java pitfall I have seen is making sure that developers > close their statements after they are done with them. Other then > that I have seen no issues (related to Oracle that is). > > -----Original Message----- > WILLIAMS > Sent: Friday, January 04, 2002 3:30 PM > To: Multiple recipients of list ORACLE-L > > > 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. > [EMAIL PROTECTED] > > > -----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:[EMAIL PROTECTED]] > > 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 > === message truncated === __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Rachel Carmichael INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
