Re: Logical DBA needed

When you say that this is a mainframey type of concept, you're right. They're used to a slightly different type of environment and having a properly designed database is of paramount importance. The same thing applies on Unix, of course. Folks just have yet to recognize it. A poorly designed database can lead to some interesting problems down the road (I'm faced with some now) that can make porting and expanding applications nearly impossible. I know of one where an allegedly "properly" trained DBA had a column with multiple possible sets of domains, much like in a union of struct in C or a COBOL redefines. Worked OK, too, until they discovered a case where they needed to record BOTH values for one class of tuple. Oops. There is no, repeat NO advantage to a poorly designed database. If you work in a shop where the day to day DBA has time to do all the analysis work required to design AND administer, though, I envy you, and can only assume that your environment isn't changing a whole lot in relation to your data and applications. Me? I'm sitting on about 15 production databases on 4 different classes of servers with several million lines of legacy code. I don't have time. Thanks, David >Na. That's a mainframey/Oracle-y concept that the physical DBA is in >charge of the engine and disks and configuration and tuning while the >logical DBA is in change of database/table design, index specification, >and query optimization. Mainframey shops seem to think that DBAs are And so when the physical DBA adds another disk/dbspace, the logical DBA goes mad as his table fragmentation schema now no longer fits!! Oh...they are suppose to make work for one another I see how it works... >either too dumb or too busy to do both jobs well. I've never been sure >which. I met an Oracle Physical DBA and Logical DBA from some bank >several years ago at a Sybase training class and they explained it to >me. The Informix and Sybase DBAs at the class had no clue but the >other Oracle people all nodded their heads in understanding. > >Art S. Kagel -- David Williams