RE: Re:RE: RE: Oracle DBA evolution path - please share your opi
Title: RE: Re:RE: RE: Oracle DBA evolution path - please share your opi ---snip--- OK then, since you were including all the employees, and since you didn't mention Quest in your list of companies, I'll forgive you. But just in case you didn't know, the main source of the problems you encounter is those people in Marketing and Sales. :-) ---snip--- Passing the buck huh?;) I don't believe that ALLSales Marketing staff are theprimary problem when it comes to getting an intuitive, well coded,widely functional database product in the market place! Me, myself, and I all work as a Sales Marketing Exec for RDBMS performance tools, and I can say from past and present experience that we are just handed the tool, and told to market and sell it.From time to time we may get asked for opinions on software, but hey - who listens toSales Marketing - we're just the drive by gunmen that are sharks looking for a sale right? NOT TRUE!I keep in constant contact with prospects AND customers! A good software company has theright MANAGEMENT in place. It is not about the certain areas of the company, and the internal pettiness that can occur between these departments. The key to success IMHO, is to have a management team in place that can keep all areas of a business in touch with each other, working together - to come up with a product that will go down like a storm in the market! RD have to realise that it is the frontline (Sales Marketing) who are talking to the customers day in and day out, and are in fact the ones that are told day in and day out what a performance tool "should" do, and hey - that is this ultimate goal - to deliver a product to the market that the USER wants to use! How often have you heard of developers talking to customers? We work very closely with customers and prospects alike. Our main aim is to deliver a product to the customers desktop that they WILL use day in day out.. If that means that we spend a maximum of a day on site, installing and configuring the product - whilst training the customer - so be it. I would rather have a happy customer, than one shouting down my ear that the tools have crashed and the database is down. And hey, what's a day right? To conclude - it is not mainly marketing sales that are the problem, it is a break down of communication within these companies that cause the problems! That's why when you have a small close knit company, they can produce really cool products, that match what the customer wants, and needs! Then these small companies get acquired (because of their great new technology), by corporations who throw the product in to the pile, and the breakdown of communication starts there, and so does the breakdown of the product! Does this mean it is a collective failure of all groups? Maybe. Or could it be the failing of the management structure trying to hold all of this in place, strongly defending his/her own little "Castle"? That is more my feeling.. Just my £0.02 Mark P.S Damn I need a coffee now, where's my mug disappeared to?
Re: Re:RE: RE: Oracle DBA evolution path - please share your opi
Jared, Yes, you are absolutely right, nobody is having interest in selling quality products. Money is coming from the support of the product, not from the selling of the product itself. If the product is well-written, then it'll be no big deal with maintenance, hence no money from contractors who support and "customize" the application ( read: fix the numerous bugs on fly and try to make the whole $hit work ). The more complicated the product, the more money is paid for it's maintenance. The more money is paid, the more people are is interested in working with it. The only problem is to sell the whole stuff - but it's only a matter of the sales department' qualification. Just IMHO, Michael Netrusov, www.atelo.com - Original Message - To: "Multiple recipients of list ORACLE-L" [EMAIL PROTECTED] Sent: Saturday, March 17, 2001 00:15 Dick, We should formalize this rant and post it and a web page and publicize it. Almost without exception, databases for 3rd party software are designed in the dark by drunken monkeys. In the past I've toyed with the idea of offering a service of ERD and database design to 3rd party developers, but have since realized that they have no interest in selling quality products. As for posting your rant, I have a domain 'duhvelper.com' that I haven't done anything with yet... Jared On Fri, 16 Mar 2001 [EMAIL PROTECTED] wrote: Jacques, First things first, DON'T TAKE THIS PERSONAL. I am not trying to brow beat anyone, just venting a common problem I have with third party software applications. I've had a couple interactions with Quest which for the most part have been uneventful. Over the last 5 years I've had run-ins with a lot of third party applications, like PeopleSoft, Support Magic, Etrade, and now CoCreate. To say the least they all have NOT been pleasant, actually some are down right too painful and really get my blood pressure up. ... -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: 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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Michael Netrusov 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).
RE: Re:RE: RE: Oracle DBA evolution path - please share your opi
Title: RE: Re:RE: RE: Oracle DBA evolution path - please share your opi -Original Message- From: Michael Netrusov [mailto:[EMAIL PROTECTED]] Yes, you are absolutely right, nobody is having interest in selling quality products. Money is coming from the support of the product, not from the selling of the product itself. If the product is well-written, then it'll be no big deal with maintenance, hence no money from contractors who support and customize the application ( read: fix the numerous bugs on fly and try to make the whole $hit work ). The more complicated the product, the more money is paid for it's maintenance. The more money is paid, the more people are is interested in working with it. The only problem is to sell the whole stuff - but it's only a matter of the sales department' qualification. Coming from a development company, I think I have to point out that in my humble opinion the statements above are an unfair generalization. I think developpers in general try to produce a well-written product, and the fact that products get more complicated is that users expect more features from newer versions. To give an analogy, if I posted on this list all DBAs try to have a database that requires a lot of manual maintenance and don't document anthing - that's in their interest for job security, I'm sure there would be a general outcry. -- any ignorant comments made are the sole responsibility of J. R. Kilchoer and should not reflect adversely upon my employer. Jacques R. Kilchoer (949) 754-8816 Quest Software, Inc. 8001 Irvine Center Drive Irvine, California 92618 U.S.A. http://www.quest.com
RE: Re:RE: RE: Oracle DBA evolution path - please share your opi
Title: RE: Re:RE: RE: Oracle DBA evolution path - please share your opi -Original Message- From: Michael Netrusov [mailto:[EMAIL PROTECTED]] I think I forgot to put a smile in my previous letter. Sorry, I didn't mean to offend all the respectable software development companies. I didn't speak only about developers .. Developers are responsible for the code, DA is responsible for the ER-model, DBA is responsible for support / maintenance. All of those people are responsible for the end product. Take PeopleSoft, Oracle Applications, Platinum, Scala, etc - all of those products are known for their overcomplicated maintenance. OK then, since you were including all the employees, and since you didn't mention Quest in your list of companies, I'll forgive you. But just in case you didn't know, the main source of the problems you encounter is those people in Marketing and Sales. :-)
Re: Re:RE: RE: Oracle DBA evolution path - please share your opi
Title: RE: Re:RE: RE: Oracle DBA evolution path - please share your opi I am looking for a People Soft Oracle application candidate for one of my clients. Please respond with your interest. Thanks Dick Vander Laan from R Vander Search LLC. Great client. Thanks - Original Message - From: Michael Netrusov To: Multiple recipients of list ORACLE-L Sent: Monday, March 19, 2001 1:26 PM Subject: Re: Re:RE: RE: Oracle DBA evolution path - please share your opi I think I forgot to put a smilein my previous letter. Sorry, I didn't mean tooffend all the respectable software development companies. I didn't speak only about developers .. Developers are responsible for the code, DA is responsible for theER-model, DBA is responsible for support / maintenance. All of those people are responsible for the end product. TakePeopleSoft,Oracle Applications, Platinum, Scala, etc - all of those productsare known for theirovercomplicated maintenance. Do those companies have time / money toredesign / rewrite their products? Yes. Do they do it? No.It's all about the enormous amount of money they make on customization/ support. The DA's and developers can be well-meaning though and never be aware of the whole plan :-)). Regards, Michael Netrusov, www.atelo.com - Original Message - From: Jacques Kilchoer To: Multiple recipients of list ORACLE-L Sent: Monday, March 19, 2001 14:01 Subject: RE: Re:RE: RE: Oracle DBA evolution path - please share your opi -Original Message- From: Michael Netrusov [mailto:[EMAIL PROTECTED]] Yes, you are absolutely right, nobody is having interest in selling quality products. Money is coming from the support of the product, not from the selling of the product itself. If the product is well-written, then it'll be no big deal with maintenance, hence no money from contractors who support and "customize" the application ( read: fix the numerous bugs on fly and try to make the whole $hit work ). The more complicated the product, the more money is paid for it's maintenance. The more money is paid, the more people are is interested in working with it. The only problem is to sell the whole stuff - but it's only a matter of the sales department' qualification. Coming from a development company, I think I have to point out that in my humble opinion the statements above are an unfair generalization. I think developpers in general try to produce a well-written product, and the fact that products get more complicated is that users expect more features from newer versions. To give an analogy, if I posted on this list "all DBAs try to have a database that requires a lot of manual maintenance and don't document anthing - that's in their interest for job security", I'm sure there would be a general outcry. -- any ignorant comments made are the sole responsibility of J. R. Kilchoer and should not reflect adversely upon my employer. Jacques R. Kilchoer (949) 754-8816 Quest Software, Inc. 8001 Irvine Center Drive Irvine, California 92618 U.S.A. http://www.quest.com
Re:RE: RE: Oracle DBA evolution path - please share your opi
Jacques, First things first, DON'T TAKE THIS PERSONAL. I am not trying to brow beat anyone, just venting a common problem I have with third party software applications. I've had a couple interactions with Quest which for the most part have been uneventful. Over the last 5 years I've had run-ins with a lot of third party applications, like PeopleSoft, Support Magic, Etrade, and now CoCreate. To say the least they all have NOT been pleasant, actually some are down right too painful and really get my blood pressure up. Around here we build a lot of software for in house use I have always mandated that the applications "behave" themselves as users, not abusers of the database. That means in a nutshell that they are clients of MY database and no developer can expect more than that. They get one or more tablespaces as the two of us jointly decide and some public privileges, like "create public synonym". Note they do not get "drop public synonym". The application is also not created to be platform specific from a database view. In other words they can be installed into a database on any platform so long as we can access the required client tools. Today's install may be on Unix from an NT client, tomorrow's could be in reverse. Keep it generic simple. This I know is not the case at all third party shops, actually I've talked to an Oracle DBA at Support Magic who was informed by the CTO that he could either "do as the developers want or clean out your desk". I've also had the unpleasant experience of talking to one of those developers. At the end of the conversation, if you want to call it that it was more of a lecture from his end, I informed him I wanted to know when his funeral was and was hoping it would be sooner(like tomorrow) vs. later. Why? you'll ask. The reason was that according to this particular duhveloper all of the database instance was his to manipulate as he desired without regards for the consequences. I quote: "Recovery of a failed database is your task, not mine. And if I did something that makes that task harder on you that it should, tough s^t". Not an attitude that I appreciate, but then I did not appreciate the sales person either when he said "if you don't like our installation method, go somewhere else. I've other things to do." An attitude that was recently featured in ComputerWorld saying that many software vendors see a sale as a one off item or as the author put it "a drive by sale". You know, something like a "drive by shooting". One other reason that has been raised is that the "application was ported from name of a data management scheme". In this case you can replace the with either AllBase, Xbase, flat files, etc In any case porting is in my mind a VERY poor excuse for a bad DB implementation. Lets face facts, we're buying the software from you because we can't/don't want to create it or try re-inventing your wheel. Therefore I expect that a good DB development job was done. Lets just say that those expectations have been very heavily dashed. Also, I recently (like a month ago) rejected a job offer at a third party shop mainly because they did not feel it was their place to consider how those who support the product look at it. Now I understand that some shops work on the premise that "the client will not have a trained Oracle staff". All well and good, yes it would be good in these cases to have the appropriate scripts in hand to handle that, but if they have why "impose" your views on the in place folks. Give them the system requirements (Tablespaces, Names, sizes) get out of Dodge. Why does this rattle my cage so badly, Lets look at some of that CoCreate recently (like two weeks ago) did: First they asked that I run orainst let it create the basic database. OK then they went in created some tablespaces on their own as follows: TABLESPACE_NAME FILE_NAME ALLOCATED FREE_BYTES --- -- -- RBS_HP_DMS /users/cocreate/database/wm_rbs_.dat 2 1 ROLLBACK_SEGS /ora2/roll01.dbf100 92 SYSTEM /ora2/system01.dbf 100 58 TEMP/ora2/temp.dbf 150150 TOOLS /ora2/tools.dbf 15 15 USERS /ora2/users01.dbf75 75 WM_ARCHIVEFS/users/cocreate/database/wm_arch_.dat12 12 WM_CLASSINFOS /users/cocreate/database/wm_eles_.dat24 24 - /users/cocreate/database/wm_erels_.dat 24 23 - /users/cocreate/database/wm_files_.dat 20 20 - /users/cocreate/database/wm_frels_.dat7 7 - /users/cocreate/database/wm_infos_.dat
Re:RE: RE: Oracle DBA evolution path - please share your opi
Amen !! [EMAIL PROTECTED]@fatcity.com on 03/16/2001 10:26:43 AM Please respond to [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] cc: Jacques, First things first, DON'T TAKE THIS PERSONAL. I am not trying to brow beat anyone, just venting a common problem I have with third party software applications. I've had a couple interactions with Quest which for the most part have been uneventful. Over the last 5 years I've had run-ins with a lot of third party applications, like PeopleSoft, Support Magic, Etrade, and now CoCreate. To say the least they all have NOT been pleasant, actually some are down right too painful and really get my blood pressure up. Around here we build a lot of software for in house use I have always mandated that the applications "behave" themselves as users, not abusers of the database. That means in a nutshell that they are clients of MY database and no developer can expect more than that. They get one or more tablespaces as the two of us jointly decide and some public privileges, like "create public synonym". Note they do not get "drop public synonym". The application is also not created to be platform specific from a database view. In other words they can be installed into a database on any platform so long as we can access the required client tools. Today's install may be on Unix from an NT client, tomorrow's could be in reverse. Keep it generic simple. This I know is not the case at all third party shops, actually I've talked to an Oracle DBA at Support Magic who was informed by the CTO that he could either "do as the developers want or clean out your desk". I've also had the unpleasant experience of talking to one of those developers. At the end of the conversation, if you want to call it that it was more of a lecture from his end, I informed him I wanted to know when his funeral was and was hoping it would be sooner(like tomorrow) vs. later. Why? you'll ask. The reason was that according to this particular duhveloper all of the database instance was his to manipulate as he desired without regards for the consequences. I quote: "Recovery of a failed database is your task, not mine. And if I did something that makes that task harder on you that it should, tough s^t". Not an attitude that I appreciate, but then I did not appreciate the sales person either when he said "if you don't like our installation method, go somewhere else. I've other things to do." An attitude that was recently featured in ComputerWorld saying that many software vendors see a sale as a one off item or as the author put it "a drive by sale". You know, something like a "drive by shooting". One other reason that has been raised is that the "application was ported from name of a data management scheme". In this case you can replace the with either AllBase, Xbase, flat files, etc In any case porting is in my mind a VERY poor excuse for a bad DB implementation. Lets face facts, we're buying the software from you because we can't/don't want to create it or try re-inventing your wheel. Therefore I expect that a good DB development job was done. Lets just say that those expectations have been very heavily dashed. Also, I recently (like a month ago) rejected a job offer at a third party shop mainly because they did not feel it was their place to consider how those who support the product look at it. Now I understand that some shops work on the premise that "the client will not have a trained Oracle staff". All well and good, yes it would be good in these cases to have the appropriate scripts in hand to handle that, but if they have why "impose" your views on the in place folks. Give them the system requirements (Tablespaces, Names, sizes) get out of Dodge. Why does this rattle my cage so badly, Lets look at some of that CoCreate recently (like two weeks ago) did: First they asked that I run orainst let it create the basic database. OK then they went in created some tablespaces on their own as follows: TABLESPACE_NAME FILE_NAME ALLOCATED FREE_BYTES --- -- -- RBS_HP_DMS /users/cocreate/database/wm_rbs_.dat 2 1 ROLLBACK_SEGS /ora2/roll01.dbf100 92 SYSTEM /ora2/system01.dbf 100 58 TEMP/ora2/temp.dbf 150 150 TOOLS /ora2/tools.dbf 15 15 USERS /ora2/users01.dbf75 75 WM_ARCHIVEFS/users/cocreate/database/wm_arch_.dat12 12 WM_CLASSINFOS /users/cocreate/database/wm_eles_.dat24 24 - /users/cocreate/database/wm_erels_.dat 24 23 - /users/cocreate/database/wm_files_.dat 20 20 -
Re:RE: RE: Oracle DBA evolution path - please share your opi
Dick, We should formalize this rant and post it and a web page and publicize it. Almost without exception, databases for 3rd party software are designed in the dark by drunken monkeys. In the past I've toyed with the idea of offering a service of ERD and database design to 3rd party developers, but have since realized that they have no interest in selling quality products. As for posting your rant, I have a domain 'duhvelper.com' that I haven't done anything with yet... Jared On Fri, 16 Mar 2001 [EMAIL PROTECTED] wrote: Jacques, First things first, DON'T TAKE THIS PERSONAL. I am not trying to brow beat anyone, just venting a common problem I have with third party software applications. I've had a couple interactions with Quest which for the most part have been uneventful. Over the last 5 years I've had run-ins with a lot of third party applications, like PeopleSoft, Support Magic, Etrade, and now CoCreate. To say the least they all have NOT been pleasant, actually some are down right too painful and really get my blood pressure up. ... -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: 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).
