RE: Development vs. Production DBA
LOL -- developers deciding architecture design. Never really involved in implementing anything, all conceptual. I am what you call a production DBA, my personal bias on this is that leaving architecture decisions to developers could be a mistake, if you think long term. The Production DBA should be involved, and should have the ability to veto any hair-brained scheme that is proposed. Patrice. -Original Message- Sent: Wednesday, November 19, 2003 12:20 PM To: Multiple recipients of list ORACLE-L I don't know about a paper, but I've always made a distinction between these types of DBAs as well. Development DBA responsibilities: - initial DB design - data modelling, data dictionary creation - naming standards, datatype standards - sql development - working w/ front end developers, tuning queries - data load, legacy to current Production DBA responsibilties: - day to day administrative support: adding users, creating schemas, moving objects around - backup/recovery - disaster recovery - monitoring - Troubleshooting, working with Oracle Tech Support - Database PT concerns: buffer pools, tablespace objects, etc. I would NOT force developers to funnel through the DBA to create objects in development. What a roadblock that could be. Instead, have the dba be available as a resource to the developers to handle query tuning concerns, answer SQL questions and the like. my 2 cents. Boss Group, If this was discussed before, I missed it. There is a discussion going on trying to define the duties of a development vs. production DBA and where in-depth DBA involvement should occur. Is there any papers that anyone can share w/me on this subject. IMHO a DBA should be involved early on in the project to translate the functional requirements into a physical model using the features of the target version. I also think that it should be the DBA's job to create the packages, procedures and triggers in the development and testing phases. To me,this would facilitate the transition from testing to production. Our development DBA's are involved in the production side so are aware of our standards. Comments, opinions please. TIA Al Rusnak DBA - WEB Team/CISIS, Computer Operations * 804-734-8371 * [EMAIL PROTECTED] -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Rusnak, George A. (SEC-Lee) CTR INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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.net -- Author: Todd Boss INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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.net -- Author: Boivin, Patrice J INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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: Development vs. Production DBA
the arrogance here is troubling. though there seems to be more incompetent developers who do not know the database I have worked with my share of incompetent DBAs. Havent used anything since versoin 5.0 and so on. Dont know anything at all about development. If a production DBA knows development, fine, their opinion is valuable, if they are an SA/DBA who cant code, cant design a system, then their opinion is not very valuable. Ive seen lots of silly roadmaps put up by production DBAs who dont know nearly as much as lead on. What large enterprise systems need is an experienced Systems Architect. Im not one of those, but they do wonders for projects and they should work with the DBA to decide the best way to implement something. From: Boivin, Patrice J [EMAIL PROTECTED] Date: 2003/11/21 Fri AM 07:12:13 EST To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Subject: RE: Development vs. Production DBA LOL -- developers deciding architecture design. Never really involved in implementing anything, all conceptual. I am what you call a production DBA, my personal bias on this is that leaving architecture decisions to developers could be a mistake, if you think long term. The Production DBA should be involved, and should have the ability to veto any hair-brained scheme that is proposed. Patrice. -Original Message- Sent: Wednesday, November 19, 2003 12:20 PM To: Multiple recipients of list ORACLE-L I don't know about a paper, but I've always made a distinction between these types of DBAs as well. Development DBA responsibilities: - initial DB design - data modelling, data dictionary creation - naming standards, datatype standards - sql development - working w/ front end developers, tuning queries - data load, legacy to current Production DBA responsibilties: - day to day administrative support: adding users, creating schemas, moving objects around - backup/recovery - disaster recovery - monitoring - Troubleshooting, working with Oracle Tech Support - Database PT concerns: buffer pools, tablespace objects, etc. I would NOT force developers to funnel through the DBA to create objects in development. What a roadblock that could be. Instead, have the dba be available as a resource to the developers to handle query tuning concerns, answer SQL questions and the like. my 2 cents. Boss Group, If this was discussed before, I missed it. There is a discussion going on trying to define the duties of a development vs. production DBA and where in-depth DBA involvement should occur. Is there any papers that anyone can share w/me on this subject. IMHO a DBA should be involved early on in the project to translate the functional requirements into a physical model using the features of the target version. I also think that it should be the DBA's job to create the packages, procedures and triggers in the development and testing phases. To me,this would facilitate the transition from testing to production. Our development DBA's are involved in the production side so are aware of our standards. Comments, opinions please. TIA Al Rusnak DBA - WEB Team/CISIS, Computer Operations * 804-734-8371 * [EMAIL PROTECTED] -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Rusnak, George A. (SEC-Lee) CTR INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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.net -- Author: Todd Boss INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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.net -- Author: Boivin, Patrice J INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services
RE: RE: Development vs. Production DBA
not arrogance, experience. Granted, there are good developers out there. The tendency is to think only on a project by project basis in development because of the way developers sometimes get funding to sustain themselves. No offense was intended, it was a cautionary note nothing more. Patrice. -Original Message- Sent: Friday, November 21, 2003 8:54 AM To: Multiple recipients of list ORACLE-L the arrogance here is troubling. though there seems to be more incompetent developers who do not know the database I have worked with my share of incompetent DBAs. Havent used anything since versoin 5.0 and so on. Dont know anything at all about development. If a production DBA knows development, fine, their opinion is valuable, if they are an SA/DBA who cant code, cant design a system, then their opinion is not very valuable. Ive seen lots of silly roadmaps put up by production DBAs who dont know nearly as much as lead on. What large enterprise systems need is an experienced Systems Architect. Im not one of those, but they do wonders for projects and they should work with the DBA to decide the best way to implement something. From: Boivin, Patrice J [EMAIL PROTECTED] Date: 2003/11/21 Fri AM 07:12:13 EST To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Subject: RE: Development vs. Production DBA LOL -- developers deciding architecture design. Never really involved in implementing anything, all conceptual. I am what you call a production DBA, my personal bias on this is that leaving architecture decisions to developers could be a mistake, if you think long term. The Production DBA should be involved, and should have the ability to veto any hair-brained scheme that is proposed. Patrice. -Original Message- Sent: Wednesday, November 19, 2003 12:20 PM To: Multiple recipients of list ORACLE-L I don't know about a paper, but I've always made a distinction between these types of DBAs as well. Development DBA responsibilities: - initial DB design - data modelling, data dictionary creation - naming standards, datatype standards - sql development - working w/ front end developers, tuning queries - data load, legacy to current Production DBA responsibilties: - day to day administrative support: adding users, creating schemas, moving objects around - backup/recovery - disaster recovery - monitoring - Troubleshooting, working with Oracle Tech Support - Database PT concerns: buffer pools, tablespace objects, etc. I would NOT force developers to funnel through the DBA to create objects in development. What a roadblock that could be. Instead, have the dba be available as a resource to the developers to handle query tuning concerns, answer SQL questions and the like. my 2 cents. Boss Group, If this was discussed before, I missed it. There is a discussion going on trying to define the duties of a development vs. production DBA and where in-depth DBA involvement should occur. Is there any papers that anyone can share w/me on this subject. IMHO a DBA should be involved early on in the project to translate the functional requirements into a physical model using the features of the target version. I also think that it should be the DBA's job to create the packages, procedures and triggers in the development and testing phases. To me,this would facilitate the transition from testing to production. Our development DBA's are involved in the production side so are aware of our standards. Comments, opinions please. TIA Al Rusnak DBA - WEB Team/CISIS, Computer Operations * 804-734-8371 * [EMAIL PROTECTED] -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Rusnak, George A. (SEC-Lee) CTR INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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.net -- Author: Todd Boss INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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
RE: RE: Development vs. Production DBA
I don't normally like to get into these turf battles, but in this case I have to agree with Patrice. Most developers are looking strictly at their current project with no regard for anything they've done in the past or that others around them are doing. Also I find that a significant number of developers have an attitude that what they did in the past is sufficient for the future no new functionality in the database or elsewhere is needed. Believe it or not, we still have a test engineering programmer who uses Turbo Pascal. My greatest frustration is people who demand to write applications strictly in a client server mode. They see no benefit into encapsulating processes that are very database intensive into packages/procedures/functions. So instead of one round trip to the database they have to do 30 or 40 and wonder why they can't get sub second response from their application. Dick Goulet Senior Oracle DBA Oracle Certified 8i DBA -Original Message- Sent: Friday, November 21, 2003 9:14 AM To: Multiple recipients of list ORACLE-L not arrogance, experience. Granted, there are good developers out there. The tendency is to think only on a project by project basis in development because of the way developers sometimes get funding to sustain themselves. No offense was intended, it was a cautionary note nothing more. Patrice. -Original Message- Sent: Friday, November 21, 2003 8:54 AM To: Multiple recipients of list ORACLE-L the arrogance here is troubling. though there seems to be more incompetent developers who do not know the database I have worked with my share of incompetent DBAs. Havent used anything since versoin 5.0 and so on. Dont know anything at all about development. If a production DBA knows development, fine, their opinion is valuable, if they are an SA/DBA who cant code, cant design a system, then their opinion is not very valuable. Ive seen lots of silly roadmaps put up by production DBAs who dont know nearly as much as lead on. What large enterprise systems need is an experienced Systems Architect. Im not one of those, but they do wonders for projects and they should work with the DBA to decide the best way to implement something. From: Boivin, Patrice J [EMAIL PROTECTED] Date: 2003/11/21 Fri AM 07:12:13 EST To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Subject: RE: Development vs. Production DBA LOL -- developers deciding architecture design. Never really involved in implementing anything, all conceptual. I am what you call a production DBA, my personal bias on this is that leaving architecture decisions to developers could be a mistake, if you think long term. The Production DBA should be involved, and should have the ability to veto any hair-brained scheme that is proposed. Patrice. -Original Message- Sent: Wednesday, November 19, 2003 12:20 PM To: Multiple recipients of list ORACLE-L I don't know about a paper, but I've always made a distinction between these types of DBAs as well. Development DBA responsibilities: - initial DB design - data modelling, data dictionary creation - naming standards, datatype standards - sql development - working w/ front end developers, tuning queries - data load, legacy to current Production DBA responsibilties: - day to day administrative support: adding users, creating schemas, moving objects around - backup/recovery - disaster recovery - monitoring - Troubleshooting, working with Oracle Tech Support - Database PT concerns: buffer pools, tablespace objects, etc. I would NOT force developers to funnel through the DBA to create objects in development. What a roadblock that could be. Instead, have the dba be available as a resource to the developers to handle query tuning concerns, answer SQL questions and the like. my 2 cents. Boss Group, If this was discussed before, I missed it. There is a discussion going on trying to define the duties of a development vs. production DBA and where in-depth DBA involvement should occur. Is there any papers that anyone can share w/me on this subject. IMHO a DBA should be involved early on in the project to translate the functional requirements into a physical model using the features of the target version. I also think that it should be the DBA's job to create the packages, procedures and triggers in the development and testing phases. To me,this would facilitate the transition from testing to production. Our development DBA's are involved in the production side so are aware of our standards. Comments, opinions please. TIA Al Rusnak DBA - WEB Team/CISIS, Computer Operations * 804-734-8371 * [EMAIL PROTECTED] -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Rusnak, George A. (SEC-Lee) CTR INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San
RE: RE: Development vs. Production DBA
I'm going to keep this response in my in-box to forward to developers when they complain about their poorly tuned database. Goulet, Dick DGoulet To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] @vicr.com cc: Sent by: Subject: RE: RE: Development vs. Production DBA ml-errors 11/21/2003 09:39 AM Please respond to ORACLE-L I don't normally like to get into these turf battles, but in this case I have to agree with Patrice. Most developers are looking strictly at their current project with no regard for anything they've done in the past or that others around them are doing. Also I find that a significant number of developers have an attitude that what they did in the past is sufficient for the future no new functionality in the database or elsewhere is needed. Believe it or not, we still have a test engineering programmer who uses Turbo Pascal. My greatest frustration is people who demand to write applications strictly in a client server mode. They see no benefit into encapsulating processes that are very database intensive into packages/procedures/functions. So instead of one round trip to the database they have to do 30 or 40 and wonder why they can't get sub second response from their application. Dick Goulet Senior Oracle DBA Oracle Certified 8i DBA -Original Message- Sent: Friday, November 21, 2003 9:14 AM To: Multiple recipients of list ORACLE-L not arrogance, experience. Granted, there are good developers out there. The tendency is to think only on a project by project basis in development because of the way developers sometimes get funding to sustain themselves. No offense was intended, it was a cautionary note nothing more. Patrice. -Original Message- Sent: Friday, November 21, 2003 8:54 AM To: Multiple recipients of list ORACLE-L the arrogance here is troubling. though there seems to be more incompetent developers who do not know the database I have worked with my share of incompetent DBAs. Havent used anything since versoin 5.0 and so on. Dont know anything at all about development. If a production DBA knows development, fine, their opinion is valuable, if they are an SA/DBA who cant code, cant design a system, then their opinion is not very valuable. Ive seen lots of silly roadmaps put up by production DBAs who dont know nearly as much as lead on. What large enterprise systems need is an experienced Systems Architect. Im not one of those, but they do wonders for projects and they should work with the DBA to decide the best way to implement something. From: Boivin, Patrice J [EMAIL PROTECTED] Date: 2003/11/21 Fri AM 07:12:13 EST To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Subject: RE: Development vs. Production DBA LOL -- developers deciding architecture design. Never really involved in implementing anything, all conceptual. I am what you call a production DBA, my personal bias on this is that leaving architecture decisions to developers could be a mistake, if you think long term. The Production DBA should be involved, and should have the ability to veto any hair-brained scheme that is proposed. Patrice. -Original Message- Sent: Wednesday, November 19, 2003 12:20 PM To: Multiple recipients of list ORACLE-L I don't know about
RE: RE: Development vs. Production DBA
Title: RE: RE: Development vs. Production DBA But if you make them stored procedures, you might be giving up some vestige of control. CAN'T give up control... April Wells Oracle DBA/Oracle Apps DBA Corporate Systems Amarillo Texas /\ / \ / \ \ / \/ \ \ \ \ Few people really enjoy the simple pleasure of flying a kite Adam Wells age 11 -Original Message- From: Goulet, Dick [mailto:[EMAIL PROTECTED]] Sent: Friday, November 21, 2003 8:40 AM To: Multiple recipients of list ORACLE-L Subject: RE: RE: Development vs. Production DBA I don't normally like to get into these turf battles, but in this case I have to agree with Patrice. Most developers are looking strictly at their current project with no regard for anything they've done in the past or that others around them are doing. Also I find that a significant number of developers have an attitude that what they did in the past is sufficient for the future no new functionality in the database or elsewhere is needed. Believe it or not, we still have a test engineering programmer who uses Turbo Pascal. My greatest frustration is people who demand to write applications strictly in a client server mode. They see no benefit into encapsulating processes that are very database intensive into packages/procedures/functions. So instead of one round trip to the database they have to do 30 or 40 and wonder why they can't get sub second response from their application. Dick Goulet Senior Oracle DBA Oracle Certified 8i DBA -Original Message- Sent: Friday, November 21, 2003 9:14 AM To: Multiple recipients of list ORACLE-L not arrogance, experience. Granted, there are good developers out there. The tendency is to think only on a project by project basis in development because of the way developers sometimes get funding to sustain themselves. No offense was intended, it was a cautionary note nothing more. Patrice. -Original Message- Sent: Friday, November 21, 2003 8:54 AM To: Multiple recipients of list ORACLE-L the arrogance here is troubling. though there seems to be more incompetent developers who do not know the database I have worked with my share of incompetent DBAs. Havent used anything since versoin 5.0 and so on. Dont know anything at all about development. If a production DBA knows development, fine, their opinion is valuable, if they are an SA/DBA who cant code, cant design a system, then their opinion is not very valuable. Ive seen lots of silly roadmaps put up by production DBAs who dont know nearly as much as lead on. What large enterprise systems need is an experienced Systems Architect. Im not one of those, but they do wonders for projects and they should work with the DBA to decide the best way to implement something. From: Boivin, Patrice J [EMAIL PROTECTED] Date: 2003/11/21 Fri AM 07:12:13 EST To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Subject: RE: Development vs. Production DBA LOL -- developers deciding architecture design. Never really involved in implementing anything, all conceptual. I am what you call a production DBA, my personal bias on this is that leaving architecture decisions to developers could be a mistake, if you think long term. The Production DBA should be involved, and should have the ability to veto any hair-brained scheme that is proposed. Patrice. -Original Message- Sent: Wednesday, November 19, 2003 12:20 PM To: Multiple recipients of list ORACLE-L I don't know about a paper, but I've always made a distinction between these types of DBAs as well. Development DBA responsibilities: - initial DB design - data modelling, data dictionary creation - naming standards, datatype standards - sql development - working w/ front end developers, tuning queries - data load, legacy to current Production DBA responsibilties: - day to day administrative support: adding users, creating schemas, moving objects around - backup/recovery - disaster recovery - monitoring - Troubleshooting, working with Oracle Tech Support - Database PT concerns: buffer pools, tablespace objects, etc. I would NOT force developers to funnel through the DBA to create objects in development. What a roadblock that could be. Instead, have the dba be available as a resource to the developers to handle query tuning concerns, answer SQL questions and the like. my 2 cents. Boss Group, If this was discussed before, I missed it. There is a discussion going on trying to define the duties of a development vs. production DBA and where in-depth DBA involvement should occur. Is there any papers that anyone can share w/me on this subject. IMHO a DBA should be involved early on in the project to translate the functional requirements into a physical model using the features of the target version. I also think that it should be the DBA's job to create the packages, procedures and triggers in the development
RE: RE: Development vs. Production DBA
i was on a project last year where the lead didnt let us make stored code. she thought it 'cluttered the database'. what can you do? lots of incompetence out there. worst when its the boss. From: April Wells [EMAIL PROTECTED] Date: 2003/11/21 Fri AM 09:54:33 EST To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Subject: RE: RE: Development vs. Production DBA But if you make them stored procedures, you might be giving up some vestige of control. CAN'T give up control... April Wells Oracle DBA/Oracle Apps DBA Corporate Systems Amarillo Texas /\ / \ / \ \ / \/ \ \ \ \ Few people really enjoy the simple pleasure of flying a kite Adam Wells age 11 -Original Message- Sent: Friday, November 21, 2003 8:40 AM To: Multiple recipients of list ORACLE-L I don't normally like to get into these turf battles, but in this case I have to agree with Patrice. Most developers are looking strictly at their current project with no regard for anything they've done in the past or that others around them are doing. Also I find that a significant number of developers have an attitude that what they did in the past is sufficient for the future no new functionality in the database or elsewhere is needed. Believe it or not, we still have a test engineering programmer who uses Turbo Pascal. My greatest frustration is people who demand to write applications strictly in a client server mode. They see no benefit into encapsulating processes that are very database intensive into packages/procedures/functions. So instead of one round trip to the database they have to do 30 or 40 and wonder why they can't get sub second response from their application. Dick Goulet Senior Oracle DBA Oracle Certified 8i DBA -Original Message- Sent: Friday, November 21, 2003 9:14 AM To: Multiple recipients of list ORACLE-L not arrogance, experience. Granted, there are good developers out there. The tendency is to think only on a project by project basis in development because of the way developers sometimes get funding to sustain themselves. No offense was intended, it was a cautionary note nothing more. Patrice. -Original Message- Sent: Friday, November 21, 2003 8:54 AM To: Multiple recipients of list ORACLE-L the arrogance here is troubling. though there seems to be more incompetent developers who do not know the database I have worked with my share of incompetent DBAs. Havent used anything since versoin 5.0 and so on. Dont know anything at all about development. If a production DBA knows development, fine, their opinion is valuable, if they are an SA/DBA who cant code, cant design a system, then their opinion is not very valuable. Ive seen lots of silly roadmaps put up by production DBAs who dont know nearly as much as lead on. What large enterprise systems need is an experienced Systems Architect. Im not one of those, but they do wonders for projects and they should work with the DBA to decide the best way to implement something. From: Boivin, Patrice J [EMAIL PROTECTED] Date: 2003/11/21 Fri AM 07:12:13 EST To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Subject: RE: Development vs. Production DBA LOL -- developers deciding architecture design. Never really involved in implementing anything, all conceptual. I am what you call a production DBA, my personal bias on this is that leaving architecture decisions to developers could be a mistake, if you think long term. The Production DBA should be involved, and should have the ability to veto any hair-brained scheme that is proposed. Patrice. -Original Message- Sent: Wednesday, November 19, 2003 12:20 PM To: Multiple recipients of list ORACLE-L I don't know about a paper, but I've always made a distinction between these types of DBAs as well. Development DBA responsibilities: - initial DB design - data modelling, data dictionary creation - naming standards, datatype standards - sql development - working w/ front end developers, tuning queries - data load, legacy to current Production DBA responsibilties: - day to day administrative support: adding users, creating schemas, moving objects around - backup/recovery - disaster recovery - monitoring - Troubleshooting, working with Oracle Tech Support - Database PT concerns: buffer pools, tablespace objects, etc. I would NOT force developers to funnel through the DBA to create objects in development. What a roadblock that could be. Instead, have the dba be available as a resource to the developers to handle query tuning concerns, answer SQL questions and the like. my 2 cents. Boss Group, If this was discussed before, I missed it. There is a discussion going on trying to define the duties of a development vs
RE: RE: Development vs. Production DBA
Title: RE: RE: Development vs. Production DBA Just don't grant execute. ;-) - Alan Davey Senior Analyst/Project Leader Oracle 9i OCA; 3/4 OCP w) 973.267.5990 x458 w) 212.295.3458 -Original Message-From: April Wells [mailto:[EMAIL PROTECTED]Sent: Friday, November 21, 2003 9:55 AMTo: Multiple recipients of list ORACLE-LSubject: RE: RE: Development vs. Production DBA But if you make them stored procedures, you might be giving up some vestige of control. CAN'T give up control... April Wells Oracle DBA/Oracle Apps DBA Corporate Systems Amarillo Texas /\ / \ / \ \ / \/ \ \ \ \ Few people really enjoy the simple pleasure of flying a kite Adam Wells age 11 -Original Message- From: Goulet, Dick [mailto:[EMAIL PROTECTED]] Sent: Friday, November 21, 2003 8:40 AM To: Multiple recipients of list ORACLE-L Subject: RE: RE: Development vs. Production DBA I don't normally like to get into these turf battles, but in this case I have to agree with Patrice. Most developers are looking strictly at their current project with no regard for anything they've done in the past or that others around them are doing. Also I find that a significant number of developers have an attitude that what they did in the past is sufficient for the future no new functionality in the database or elsewhere is needed. Believe it or not, we still have a test engineering programmer who uses Turbo Pascal. My greatest frustration is people who demand to write applications strictly in a client server mode. They see no benefit into encapsulating processes that are very database intensive into packages/procedures/functions. So instead of one round trip to the database they have to do 30 or 40 and wonder why they can't get sub second response from their application. Dick Goulet Senior Oracle DBA Oracle Certified 8i DBA -Original Message- Sent: Friday, November 21, 2003 9:14 AM To: Multiple recipients of list ORACLE-L not arrogance, experience. Granted, there are good developers out there. The tendency is to think only on a project by project basis in development because of the way developers sometimes get funding to sustain themselves. No offense was intended, it was a cautionary note nothing more. Patrice. -Original Message- Sent: Friday, November 21, 2003 8:54 AM To: Multiple recipients of list ORACLE-L the arrogance here is troubling. though there seems to be more incompetent developers who do not know the database I have worked with my share of incompetent DBAs. Havent used anything since versoin 5.0 and so on. Dont know anything at all about development. If a production DBA knows development, fine, their opinion is valuable, if they are an SA/DBA who cant code, cant design a system, then their opinion is not very valuable. Ive seen lots of silly roadmaps put up by production DBAs who dont know nearly as much as lead on. What large enterprise systems need is an experienced Systems Architect. Im not one of those, but they do wonders for projects and they should work with the DBA to decide the best way to implement something. From: "Boivin, Patrice J" [EMAIL PROTECTED] Date: 2003/11/21 Fri AM 07:12:13 EST To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Subject: RE: Development vs. Production DBA LOL -- developers deciding architecture design. Never really involved in implementing anything, all conceptual. I am what you call a "production DBA", my personal bias on this is that leaving architecture decisions to developers could be a mistake, if you think long term. The Production DBA should be involved, and should have the ability to veto any hair-brained scheme that is proposed. Patrice. -Original Message- Sent: Wednesday, November 19, 2003 12:20 PM To: Multiple recipients of list ORACLE-LI don't know about a paper, but I've always made a distinction between these types of DBAs as well. Development DBA responsibilities: - initial DB design - data modelling, data dictionary creation - naming standards, datatype standards - sql development - working w/ front end developers, tuning queries - data load, legacy to current Production DBA responsibilties: - day to day administrative support: adding users, creating schemas, moving objects around - backup/recovery - disaster recovery - monitoring - Troubleshooting, working with Oracle Tech Support - Database PT concerns: buffer pools, tablespace objects, etc. I would NOT force developers to funnel through the DBA to create objects in development. What a roadblock that could be. Instead, have the dba be available as a resource to the developers to handle query tuning concerns, answer SQL questions and the like. my 2 cents. Boss Group, If this was discussed before, I missed it. There is a discussion going on trying to define the duties of
Development vs. Production DBA
Group, If this was discussed before, I missed it. There is a discussion going on trying to define the duties of a development vs. production DBA and where in-depth DBA involvement should occur. Is there any papers that anyone can share w/me on this subject. IMHO a DBA should be involved early on in the project to translate the functional requirements into a physical model using the features of the target version. I also think that it should be the DBA's job to create the packages, procedures and triggers in the development and testing phases. To me,this would facilitate the transition from testing to production. Our development DBA's are involved in the production side so are aware of our standards. Comments, opinions please. TIA Al Rusnak DBA - WEB Team/CISIS, Computer Operations * 804-734-8371 * [EMAIL PROTECTED] -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Rusnak, George A. (SEC-Lee) CTR INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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).
Development vs. Production DBA
Group, If this was discussed before, I missed it. There is a discussion going on trying to define the duties of a development vs. production DBA and where in-depth DBA involvement should occur. Is there any papers that anyone can share w/me on this subject. IMHO a DBA should be involved early on in the project to translate the functional requirements into a physical model using the features of the target version. I also think that it should be the DBA's job to create the packages, procedures and triggers in the development and testing phases. To me,this would facilitate the transition from testing to production. Our development DBA's are involved in the production side so are aware of our standards. Comments, opinions please. TIA Al Rusnak DBA - WEB Team/CISIS, Computer Operations * 804-734-8371 * [EMAIL PROTECTED] -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Rusnak, George A. (SEC-Lee) CTR INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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: Development vs. Production DBA
I don't know about a paper, but I've always made a distinction between these types of DBAs as well. Development DBA responsibilities: - initial DB design - data modelling, data dictionary creation - naming standards, datatype standards - sql development - working w/ front end developers, tuning queries - data load, legacy to current Production DBA responsibilties: - day to day administrative support: adding users, creating schemas, moving objects around - backup/recovery - disaster recovery - monitoring - Troubleshooting, working with Oracle Tech Support - Database PT concerns: buffer pools, tablespace objects, etc. I would NOT force developers to funnel through the DBA to create objects in development. What a roadblock that could be. Instead, have the dba be available as a resource to the developers to handle query tuning concerns, answer SQL questions and the like. my 2 cents. Boss Group, If this was discussed before, I missed it. There is a discussion going on trying to define the duties of a development vs. production DBA and where in-depth DBA involvement should occur. Is there any papers that anyone can share w/me on this subject. IMHO a DBA should be involved early on in the project to translate the functional requirements into a physical model using the features of the target version. I also think that it should be the DBA's job to create the packages, procedures and triggers in the development and testing phases. To me,this would facilitate the transition from testing to production. Our development DBA's are involved in the production side so are aware of our standards. Comments, opinions please. TIA Al Rusnak DBA - WEB Team/CISIS, Computer Operations * 804-734-8371 * [EMAIL PROTECTED] -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Rusnak, George A. (SEC-Lee) CTR INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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.net -- Author: Todd Boss INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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: Development vs. Production DBA
George, Early involvement and advice are certainly in my view essential to the success of a project. However, concerning the creation of packages, etc. I fear I don't share your views. Involvement is justified if it adds value. If it's just adding another layer of red tape, forget about it. I think that DBAs should _review_ installation scripts, especially those creating tables, indices, constraints (I sometimes dream of meeting a developer aware of the 'using index' clause), not necessarily to _run_ them but to check that they satisfy local standards; and if they don't, they should be returned to the sender for correction. If you correct scripts and run them, you'll have to do it again and again with each release. We have a duty to teach developers :-). Concerning procedures, if you are yourself a competent PL/SQL developer and can review the code and tell people how they can do it better and faster, great. But many competent DBAs are not necessarily competent developers themselves - and I don't think that they have to be. I don't see where having stored procedures created by DBAs on a development database can improve development quality or speed. I see more added value creating a suitable environment (generating a realistic volume of data, creating and administering the suitable roles, creating synonyms to allow people to work on separate parts of a project without having multiple copies of the same database, helping with version control, helping with developing performance monitoring tools, etc.) than running scripts. In many ways, regularly meeting the project manager at the coffe machine may prove more fruitful. My $ 0.0238 ... SF - --- Original Message --- - From: Rusnak, George A. (SEC-Lee) CTR [EMAIL PROTECTED] To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Wed, 19 Nov 2003 07:50:21 Group, If this was discussed before, I missed it. There is a discussion going on trying to define the duties of a development vs. production DBA and where in-depth DBA involvement should occur. Is there any papers that anyone can share w/me on this subject. IMHO a DBA should be involved early on in the project to translate the functional requirements into a physical model using the features of the target version. I also think that it should be the DBA's job to create the packages, procedures and triggers in the development and testing phases. To me,this would facilitate the transition from testing to production. Our development DBA's are involved in the production side so are aware of our standards. Comments, opinions please. TIA Al Rusnak DBA - WEB Team/CISIS, Computer Operations * 804-734-8371 * [EMAIL PROTECTED] -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Stephane Faroult INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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: Development vs. Production DBA
Agree with Stephane on this. Finding a balance of productivity, trust and security would be the goal... -Original Message- Sent: Wednesday, November 19, 2003 10:55 AM To: Multiple recipients of list ORACLE-L George, Early involvement and advice are certainly in my view essential to the success of a project. However, concerning the creation of packages, etc. I fear I don't share your views. Involvement is justified if it adds value. If it's just adding another layer of red tape, forget about it. I think that DBAs should _review_ installation scripts, especially those creating tables, indices, constraints (I sometimes dream of meeting a developer aware of the 'using index' clause), not necessarily to _run_ them but to check that they satisfy local standards; and if they don't, they should be returned to the sender for correction. If you correct scripts and run them, you'll have to do it again and again with each release. We have a duty to teach developers :-). Concerning procedures, if you are yourself a competent PL/SQL developer and can review the code and tell people how they can do it better and faster, great. But many competent DBAs are not necessarily competent developers themselves - and I don't think that they have to be. I don't see where having stored procedures created by DBAs on a development database can improve development quality or speed. I see more added value creating a suitable environment (generating a realistic volume of data, creating and administering the suitable roles, creating synonyms to allow people to work on separate parts of a project without having multiple copies of the same database, helping with version control, helping with developing performance monitoring tools, etc.) than running scripts. In many ways, regularly meeting the project manager at the coffe machine may prove more fruitful. My $ 0.0238 ... SF - --- Original Message --- - From: Rusnak, George A. (SEC-Lee) CTR [EMAIL PROTECTED] To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Wed, 19 Nov 2003 07:50:21 Group, If this was discussed before, I missed it. There is a discussion going on trying to define the duties of a development vs. production DBA and where in-depth DBA involvement should occur. Is there any papers that anyone can share w/me on this subject. IMHO a DBA should be involved early on in the project to translate the functional requirements into a physical model using the features of the target version. I also think that it should be the DBA's job to create the packages, procedures and triggers in the development and testing phases. To me,this would facilitate the transition from testing to production. Our development DBA's are involved in the production side so are aware of our standards. Comments, opinions please. TIA Al Rusnak DBA - WEB Team/CISIS, Computer Operations * 804-734-8371 * [EMAIL PROTECTED] -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Stephane Faroult INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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.net -- Author: Odland, Brad INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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: Development vs. Production DBA
I will ditto Stephane's and Brad's opinions on this. If the DBA is a competent PL/SQL developer, then sure. If not, then don't try to write the PL/SQL. Being a competent PL/SQL developer is *much* more difficult than it was a few years ago. I can write PL/SQL all day if I can stick with stuff that is 5+ years old. :) There are so many new features available to the Oracle developer that it would be very difficult for a DBA to keep up. Jared Stephane Faroult [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 11/19/2003 08:55 AM Please respond to ORACLE-L To:Multiple recipients of list ORACLE-L [EMAIL PROTECTED] cc: Subject:RE: Development vs. Production DBA George, Early involvement and advice are certainly in my view essential to the success of a project. However, concerning the creation of packages, etc. I fear I don't share your views. Involvement is justified if it adds value. If it's just adding another layer of red tape, forget about it. I think that DBAs should _review_ installation scripts, especially those creating tables, indices, constraints (I sometimes dream of meeting a developer aware of the 'using index' clause), not necessarily to _run_ them but to check that they satisfy local standards; and if they don't, they should be returned to the sender for correction. If you correct scripts and run them, you'll have to do it again and again with each release. We have a duty to teach developers :-). Concerning procedures, if you are yourself a competent PL/SQL developer and can review the code and tell people how they can do it better and faster, great. But many competent DBAs are not necessarily competent developers themselves - and I don't think that they have to be. I don't see where having stored procedures created by DBAs on a development database can improve development quality or speed. I see more added value creating a suitable environment (generating a realistic volume of data, creating and administering the suitable roles, creating synonyms to allow people to work on separate parts of a project without having multiple copies of the same database, helping with version control, helping with developing performance monitoring tools, etc.) than running scripts. In many ways, regularly meeting the project manager at the coffe machine may prove more fruitful. My $ 0.0238 ... SF - --- Original Message --- - From: Rusnak, George A. (SEC-Lee) CTR [EMAIL PROTECTED] To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Wed, 19 Nov 2003 07:50:21 Group, If this was discussed before, I missed it. There is a discussion going on trying to define the duties of a development vs. production DBA and where in-depth DBA involvement should occur. Is there any papers that anyone can share w/me on this subject. IMHO a DBA should be involved early on in the project to translate the functional requirements into a physical model using the features of the target version. I also think that it should be the DBA's job to create the packages, procedures and triggers in the development and testing phases. To me,this would facilitate the transition from testing to production. Our development DBA's are involved in the production side so are aware of our standards. Comments, opinions please. TIA Al Rusnak DBA - WEB Team/CISIS, Computer Operations * 804-734-8371 * [EMAIL PROTECTED] -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Stephane Faroult INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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: Development vs. Production DBA
George - The earlier discussion was What is a Production DBA, and I found the links by Googling Oracle-l production dba. Excellent topic. Dennis Williams DBA Lifetouch, Inc. [EMAIL PROTECTED] -Original Message- Sent: Wednesday, November 19, 2003 10:20 AM To: Multiple recipients of list ORACLE-L Group, If this was discussed before, I missed it. There is a discussion going on trying to define the duties of a development vs. production DBA and where in-depth DBA involvement should occur. Is there any papers that anyone can share w/me on this subject. IMHO a DBA should be involved early on in the project to translate the functional requirements into a physical model using the features of the target version. I also think that it should be the DBA's job to create the packages, procedures and triggers in the development and testing phases. To me,this would facilitate the transition from testing to production. Our development DBA's are involved in the production side so are aware of our standards. Comments, opinions please. TIA Al Rusnak DBA - WEB Team/CISIS, Computer Operations * 804-734-8371 * [EMAIL PROTECTED] -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Rusnak, George A. (SEC-Lee) CTR INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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.net -- Author: DENNIS WILLIAMS INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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: Development vs. Production DBA
As I moved from development to DBA, I am trying to keep up with pl/sql ... it is FUN !! Raj Rajendra dot Jamadagni at nospamespn dot com All Views expressed in this email are strictly personal. QOTD: Any clod can have facts, having an opinion is an art ! -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]Sent: Wednesday, November 19, 2003 12:50 PMTo: Multiple recipients of list ORACLE-LSubject: RE: Development vs. Production DBAI will ditto Stephane's and Brad's opinions on this. If the DBA is a competent PL/SQL developer, then sure. If not, then don't try to write the PL/SQL. Being a competent PL/SQL developer is *much* more difficult than it was a few years ago. I can write PL/SQL all day if I can stick with stuff that is 5+ years old. :) There are so many new features available to the Oracle developer that it would be very difficult for a DBA to keep up. Jared **This e-mail message is confidential, intended only for the named recipient(s) above and may contain information that is privileged, attorney work product or exempt from disclosure under applicable law. If you have received this message in error, or are not the named recipient(s), please immediately notify corporate MIS at (860) 766-2000 and delete this e-mail message from your computer, Thank you.**4
Re: RE: Development vs. Production DBA
there arent that many new pl/sql features. 90% of the time your using the generic stuff. the new stuff is nice, but not always that special. Or maybe its just because I do it everyday. But how much is new? PL/SQL tables? Bulk binds? Dynamic SQL? That stuff is all basic. Its minor syntax differences. ive worked with plenty of developers who dont know anything beyond cursors. I think everyone should be competetent in PL/SQL. I also think all developers should be competent in tuning and architecture. The skillsets overlap. From: [EMAIL PROTECTED] Date: 2003/11/19 Wed PM 12:50:12 EST To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Subject: RE: Development vs. Production DBA I will ditto Stephane's and Brad's opinions on this. If the DBA is a competent PL/SQL developer, then sure. If not, then don't try to write the PL/SQL. Being a competent PL/SQL developer is *much* more difficult than it was a few years ago. I can write PL/SQL all day if I can stick with stuff that is 5+ years old. :) There are so many new features available to the Oracle developer that it would be very difficult for a DBA to keep up. Jared Stephane Faroult [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 11/19/2003 08:55 AM Please respond to ORACLE-L To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] cc: Subject:RE: Development vs. Production DBA George, Early involvement and advice are certainly in my view essential to the success of a project. However, concerning the creation of packages, etc. I fear I don't share your views. Involvement is justified if it adds value. If it's just adding another layer of red tape, forget about it. I think that DBAs should _review_ installation scripts, especially those creating tables, indices, constraints (I sometimes dream of meeting a developer aware of the 'using index' clause), not necessarily to _run_ them but to check that they satisfy local standards; and if they don't, they should be returned to the sender for correction. If you correct scripts and run them, you'll have to do it again and again with each release. We have a duty to teach developers :-). Concerning procedures, if you are yourself a competent PL/SQL developer and can review the code and tell people how they can do it better and faster, great. But many competent DBAs are not necessarily competent developers themselves - and I don't think that they have to be. I don't see where having stored procedures created by DBAs on a development database can improve development quality or speed. I see more added value creating a suitable environment (generating a realistic volume of data, creating and administering the suitable roles, creating synonyms to allow people to work on separate parts of a project without having multiple copies of the same database, helping with version control, helping with developing performance monitoring tools, etc.) than running scripts. In many ways, regularly meeting the project manager at the coffe machine may prove more fruitful. My $ 0.0238 ... SF - --- Original Message --- - From: Rusnak, George A. (SEC-Lee) CTR [EMAIL PROTECTED] To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Wed, 19 Nov 2003 07:50:21 Group, If this was discussed before, I missed it. There is a discussion going on trying to define the duties of a development vs. production DBA and where in-depth DBA involvement should occur. Is there any papers that anyone can share w/me on this subject. IMHO a DBA should be involved early on in the project to translate the functional requirements into a physical model using the features of the target version. I also think that it should be the DBA's job to create the packages, procedures and triggers in the development and testing phases. To me,this would facilitate the transition from testing to production. Our development DBA's are involved in the production side so are aware of our standards. Comments, opinions please. TIA Al Rusnak DBA - WEB Team/CISIS, Computer Operations * 804-734-8371 * [EMAIL PROTECTED] -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Stephane Faroult INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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). I will ditto Stephane's and Brad's opinions on this. If the DBA
RE: Development vs. Production DBA
Jared writes Being a competent PL/SQL developer is *much* more difficult than it was a few years ago. I can write PL/SQL all day if I can stick with stuff that is 5+ years old. :) A job with an ERP vendor awaits Niall -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Niall Litchfield INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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: Slightly OT: Development Vs. Production DBA
Title: RE: Slightly OT: Development Vs. Production DBA DITTO! ... I personally like it when they come screaming to me (Iam the "production" dba for the most part)that the test database is all messed up... couldn't be them... they haven't touched their code... all they did is point the same code at test instead of development... DBAs must have broken it. (Because I don't have anything better to do than mess with duhvelopers... nothing more fun, granted, but more important sometimes). But you know... no one has said word one after they found out that the networking people upgraded websphere on the server where the java code was running and not anywhere else... and the code (when tested EVERYWHERE else) works fine... yeah, yeah... I broke my database just to mess with them... muerdame April April Wells Oracle DBA Great spirits have always encountered violent opposition from mediocre minds -- Albert Einstein -Original Message-From: Webber Valerie H [mailto:[EMAIL PROTECTED]]Sent: Tuesday, January 28, 2003 11:09 AMTo: Multiple recipients of list ORACLE-LSubject: RE: Slightly OT: Development Vs. Production DBA I agree 100%. I am fighting this battle as we speak. Many Duhvelopers think they can do it all until something goes wrong then guess who they call to bail them out. Then Damagement is breathing down your neck to get it fixed when you have no idea what happened neither does the Duhveloper! I think an organization needs to have clear policies in place and enforce them to the end. Valerie H. Webber Management Systems Designers, Inc Database Administrator [EMAIL PROTECTED] 704-566-5321 -Original Message- From: Boivin, Patrice J [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 28, 2003 8:04 AM To: Multiple recipients of list ORACLE-L Subject: RE: Slightly OT: Development Vs. Production DBA A "development DBA" is a developer who wants to design the schemas his/her application will rely on. I prefer calling them application designers, because that's what they are. Sometimes you have another role, that of "Application Administrator." This second group is for larger applications that sometimes require constant attention, esp. if user accounts have to be created, or custom views etc. ... or if the application wasn't ready for production and was placed into production anyway -- then it will require constant babysitting. Consultants come in usually to implement new projects, or to add features to an existing system. That makes them application designers or application developers. Sometimes (rarely) consultants are hired to tune systems, that would be a blend of DBA and application designer. This is rare though, usually the database layer is working properly it seems to me, if the DBA has been there for more than a year, has read a book or two, and has at least the echo of a conscience. A "production DBA" is responsible for ensuring that the structure beneath the application stays up and is tuned properly. He/she works with the system administrator(s) to ensure that the hardware and the Oracle software (rdbms, developer server, iAS, networking,...) are all working properly and as expected. I don't fully understand why developers (some developers) strive to be called a DBA. Here is my guess: Perhaps this distinction stays fuzzy in organizations because there is a constant tug-of-war for control over resources between the development and production groups. If an overlap can be created, then there is an opportunity to take over some of the other group's resources. Also, when responsibilities are not delineated clearly, there is an opportunity for one side to blame the other and management can never figure out who is doing what. I worked in a lab where we were implementing Good Laboratory Practice (GLP) for the Food and Drug Administration (FDA), there was supposed to be no overlap between positions. I noticed that the managers who played games and only thought about their own advancement didn't like GLP at all, they fought it tooth and nail. I liked the idea of separate each person's circle of responsibility myself. Why can't IT shops strive to do the same? Speaking as a DBA, it is my perception that developers tend to be project-oriented. That's fine, it's why they are there. But that tendency also means, when they see their deadlines coming, that they sometimes aren't keen on thinking long term. Perhaps it's not their fault, it's because of the way projects are funded. Which client wants to hear that for every project, money will have to be allocated for ongoing costs of maintenance, operation, upgrades every 2-3 years? No one wants to think about that when they only want to think about the great new things they will be able to do with the n
Slightly OT: Development Vs. Production DBA
Hi Listers, I would like to know the differences between Development and Production DBA w.r.t. Roles and Responsibilities, Scope etc. Is there any difference in the role(s) played by a DBA in OLTP and DSS environments? Your invaluable viewpoints in this regard is most welcome. Thanks and Regards, Ranganath WARNING: The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. Thank you. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Krishnaswamy, Ranganath INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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: Slightly OT: Development Vs. Production DBA
A development DBA is a developer who wants to design the schemas his/her application will rely on. I prefer calling them application designers, because that's what they are. Sometimes you have another role, that of Application Administrator. This second group is for larger applications that sometimes require constant attention, esp. if user accounts have to be created, or custom views etc. ... or if the application wasn't ready for production and was placed into production anyway -- then it will require constant babysitting. Consultants come in usually to implement new projects, or to add features to an existing system. That makes them application designers or application developers. Sometimes (rarely) consultants are hired to tune systems, that would be a blend of DBA and application designer. This is rare though, usually the database layer is working properly it seems to me, if the DBA has been there for more than a year, has read a book or two, and has at least the echo of a conscience. A production DBA is responsible for ensuring that the structure beneath the application stays up and is tuned properly. He/she works with the system administrator(s) to ensure that the hardware and the Oracle software (rdbms, developer server, iAS, networking,...) are all working properly and as expected. I don't fully understand why developers (some developers) strive to be called a DBA. Here is my guess: Perhaps this distinction stays fuzzy in organizations because there is a constant tug-of-war for control over resources between the development and production groups. If an overlap can be created, then there is an opportunity to take over some of the other group's resources. Also, when responsibilities are not delineated clearly, there is an opportunity for one side to blame the other and management can never figure out who is doing what. I worked in a lab where we were implementing Good Laboratory Practice (GLP) for the Food and Drug Administration (FDA), there was supposed to be no overlap between positions. I noticed that the managers who played games and only thought about their own advancement didn't like GLP at all, they fought it tooth and nail. I liked the idea of separate each person's circle of responsibility myself. Why can't IT shops strive to do the same? Speaking as a DBA, it is my perception that developers tend to be project-oriented. That's fine, it's why they are there. But that tendency also means, when they see their deadlines coming, that they sometimes aren't keen on thinking long term. Perhaps it's not their fault, it's because of the way projects are funded. Which client wants to hear that for every project, money will have to be allocated for ongoing costs of maintenance, operation, upgrades every 2-3 years? No one wants to think about that when they only want to think about the great new things they will be able to do with the new application. Also, no one wants to spend more money than necessary, so there is a tendency to try to cut corners to get to the end of the project. That is probably why projects tend to be rushed into production. Once the projects are in production mode funding to finish the product dries up. That sometimes leaves the application designer off the hook and leaves the production DBA holding the bag. Finally, if you are designing a new project, the tendency is to try to retain control over as much of it as possible. If you declare yourself to be a development DBA, then people are less likely to insist that you consult the DBA(s) during the design phase of a project. What a bother that is, having to listen to other people -- it's my project! It will only slow us down... Worse, I will have to share the credit once the application works properly. That won't be as good for my career. If you know that the DBA in the organization is stubborn and intractable, then this is the route the application designers will try to take. I could draw up a list of things that can go wrong when DBAs are not involved in the design phase of a project, but I think all people need to do is brainstorm for ten minutes to get a list of 10 or more things that can go wrong... Then try to put a cost value to each of these items. Can you think of any examples from your work place? ; ) Regards, Patrice Boivin Systems Analyst (Oracle Certified DBA) [this is my opinion, not the opinion of my employer... etc. etc.] -Original Message- [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 28, 2003 4:29 AM To: Multiple recipients of list ORACLE-L Hi Listers, I would like to know the differences between Development and Production DBA w.r.t. Roles and Responsibilities, Scope etc. Is there any difference in the role(s) played by a DBA in OLTP and DSS environments? Your invaluable viewpoints in this regard is most welcome. Thanks and Regards, Ranganath WARNING: The information in this message is confidential and may be legally privileged. It is intended
RE: Slightly OT: Development Vs. Production DBA
It's not quite so hard and fast I'm considered a development DBA here. I design the schemas, the database layouts, the initialization parameters that are set etc I work with a hosting company to manage the staging and production databases. I create scripts for ALL changes to any of these environments. Because we use a hosting company for our production data center, I'm also involved in creating and maintaining runbooks. I control all emergency fixes to the databases, no matter what the environment. I handle data problems (yea, I know, I don't WANT to but for the ecommerce website, sometimes we can't wait for the corrections to flow through the system) I work with all developers, helping to tune their code. I monitor and help tune the production databases. I manage the move of databases from one data center to another. --- Boivin, Patrice J [EMAIL PROTECTED] wrote: A development DBA is a developer who wants to design the schemas his/her application will rely on. I prefer calling them application designers, because that's what they are. Sometimes you have another role, that of Application Administrator. This second group is for larger applications that sometimes require constant attention, esp. if user accounts have to be created, or custom views etc. ... or if the application wasn't ready for production and was placed into production anyway -- then it will require constant babysitting. Consultants come in usually to implement new projects, or to add features to an existing system. That makes them application designers or application developers. Sometimes (rarely) consultants are hired to tune systems, that would be a blend of DBA and application designer. This is rare though, usually the database layer is working properly it seems to me, if the DBA has been there for more than a year, has read a book or two, and has at least the echo of a conscience. A production DBA is responsible for ensuring that the structure beneath the application stays up and is tuned properly. He/she works with the system administrator(s) to ensure that the hardware and the Oracle software (rdbms, developer server, iAS, networking,...) are all working properly and as expected. I don't fully understand why developers (some developers) strive to be called a DBA. Here is my guess: Perhaps this distinction stays fuzzy in organizations because there is a constant tug-of-war for control over resources between the development and production groups. If an overlap can be created, then there is an opportunity to take over some of the other group's resources. Also, when responsibilities are not delineated clearly, there is an opportunity for one side to blame the other and management can never figure out who is doing what. I worked in a lab where we were implementing Good Laboratory Practice (GLP) for the Food and Drug Administration (FDA), there was supposed to be no overlap between positions. I noticed that the managers who played games and only thought about their own advancement didn't like GLP at all, they fought it tooth and nail. I liked the idea of separate each person's circle of responsibility myself. Why can't IT shops strive to do the same? Speaking as a DBA, it is my perception that developers tend to be project-oriented. That's fine, it's why they are there. But that tendency also means, when they see their deadlines coming, that they sometimes aren't keen on thinking long term. Perhaps it's not their fault, it's because of the way projects are funded. Which client wants to hear that for every project, money will have to be allocated for ongoing costs of maintenance, operation, upgrades every 2-3 years? No one wants to think about that when they only want to think about the great new things they will be able to do with the new application. Also, no one wants to spend more money than necessary, so there is a tendency to try to cut corners to get to the end of the project. That is probably why projects tend to be rushed into production. Once the projects are in production mode funding to finish the product dries up. That sometimes leaves the application designer off the hook and leaves the production DBA holding the bag. Finally, if you are designing a new project, the tendency is to try to retain control over as much of it as possible. If you declare yourself to be a development DBA, then people are less likely to insist that you consult the DBA(s) during the design phase of a project. What a bother that is, having to listen to other people -- it's my project! It will only slow us down... Worse, I will have to share the credit once the application works properly. That won't be as good for my career. If you know that the DBA in the organization is stubborn and intractable, then this is the route the application designers will try to take. I could draw up a list of things that
RE: Slightly OT: Development Vs. Production DBA
Ranganath You are getting some excellent responses to your question (which I consider very on topic). We had a good discussion on this list previously. I went to Google and entered fatcity production dba and was able to pick up the thread. As to your question of OLTP vs. DSS situations, I think the differences are more subtle. I thing OLTP environments are more standard than DSS environments. Our DSS is more relaxed since it is a weekly load. Sunday and Monday are the critical days. Some of it is attitude, not being a normalization bigot, realizing that marketing people are a different species that will never know their needs in advance. Dennis Williams DBA, 40%OCP Lifetouch, Inc. [EMAIL PROTECTED] -Original Message- [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 28, 2003 2:29 AM To: Multiple recipients of list ORACLE-L Hi Listers, I would like to know the differences between Development and Production DBA w.r.t. Roles and Responsibilities, Scope etc. Is there any difference in the role(s) played by a DBA in OLTP and DSS environments? Your invaluable viewpoints in this regard is most welcome. Thanks and Regards, Ranganath WARNING: The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. Thank you. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Krishnaswamy, Ranganath INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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.net -- Author: DENNIS WILLIAMS INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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: Slightly OT: Development Vs. Production DBA
Title: RE: Slightly OT: Development Vs. Production DBA I agree 100%. I am fighting this battle as we speak. Many Duhvelopers think they can do it all until something goes wrong then guess who they call to bail them out. Then Damagement is breathing down your neck to get it fixed when you have no idea what happened neither does the Duhveloper! I think an organization needs to have clear policies in place and enforce them to the end. Valerie H. Webber Management Systems Designers, Inc Database Administrator [EMAIL PROTECTED] 704-566-5321 -Original Message- From: Boivin, Patrice J [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 28, 2003 8:04 AM To: Multiple recipients of list ORACLE-L Subject: RE: Slightly OT: Development Vs. Production DBA A development DBA is a developer who wants to design the schemas his/her application will rely on. I prefer calling them application designers, because that's what they are. Sometimes you have another role, that of Application Administrator. This second group is for larger applications that sometimes require constant attention, esp. if user accounts have to be created, or custom views etc. ... or if the application wasn't ready for production and was placed into production anyway -- then it will require constant babysitting. Consultants come in usually to implement new projects, or to add features to an existing system. That makes them application designers or application developers. Sometimes (rarely) consultants are hired to tune systems, that would be a blend of DBA and application designer. This is rare though, usually the database layer is working properly it seems to me, if the DBA has been there for more than a year, has read a book or two, and has at least the echo of a conscience. A production DBA is responsible for ensuring that the structure beneath the application stays up and is tuned properly. He/she works with the system administrator(s) to ensure that the hardware and the Oracle software (rdbms, developer server, iAS, networking,...) are all working properly and as expected. I don't fully understand why developers (some developers) strive to be called a DBA. Here is my guess: Perhaps this distinction stays fuzzy in organizations because there is a constant tug-of-war for control over resources between the development and production groups. If an overlap can be created, then there is an opportunity to take over some of the other group's resources. Also, when responsibilities are not delineated clearly, there is an opportunity for one side to blame the other and management can never figure out who is doing what. I worked in a lab where we were implementing Good Laboratory Practice (GLP) for the Food and Drug Administration (FDA), there was supposed to be no overlap between positions. I noticed that the managers who played games and only thought about their own advancement didn't like GLP at all, they fought it tooth and nail. I liked the idea of separate each person's circle of responsibility myself. Why can't IT shops strive to do the same? Speaking as a DBA, it is my perception that developers tend to be project-oriented. That's fine, it's why they are there. But that tendency also means, when they see their deadlines coming, that they sometimes aren't keen on thinking long term. Perhaps it's not their fault, it's because of the way projects are funded. Which client wants to hear that for every project, money will have to be allocated for ongoing costs of maintenance, operation, upgrades every 2-3 years? No one wants to think about that when they only want to think about the great new things they will be able to do with the new application. Also, no one wants to spend more money than necessary, so there is a tendency to try to cut corners to get to the end of the project. That is probably why projects tend to be rushed into production. Once the projects are in production mode funding to finish the product dries up. That sometimes leaves the application designer off the hook and leaves the production DBA holding the bag. Finally, if you are designing a new project, the tendency is to try to retain control over as much of it as possible. If you declare yourself to be a development DBA, then people are less likely to insist that you consult the DBA(s) during the design phase of a project. What a bother that is, having to listen to other people -- it's my project! It will only slow us down... Worse, I will have to share the credit once the application works properly. That won't be as good for my career. If you know that the DBA in the organization is stubborn and intractable, then this is the route the application designers will try to take. I could draw up a list of things that can go wrong when DBAs are not involved in the design phase of a project, but I think all people need to do is brainstorm for ten minutes to get a list of 10 or more things that can go wrong... Then try to put a cost value to each
RE: Slightly OT: Development Vs. Production DBA
Title: RE: Slightly OT: Development Vs. Production DBA -realizing that marketing people are a different species -that will never know their needs in advance. ... and don't actually care what *our* needs are ... Raj __ Rajendra Jamadagni MIS, ESPN Inc. Rajendra dot Jamadagni at ESPN dot com Any opinion expressed here is personal and doesn't reflect that of ESPN Inc. QOTD: Any clod can have facts, but having an opinion is an art! *This e-mail message is confidential, intended only for the named recipient(s) above and may contain information that is privileged, attorney work product or exempt from disclosure under applicable law. If you have received this message in error, or are not the named recipient(s), please immediately notify corporate MIS at (860) 766-2000 and delete this e-mail message from your computer, Thank you.*1
RE: Slightly OT: Development Vs. Production DBA
-realizing that marketing people are a different species -that will never know their needs in advance. Amen brother, Amen -Original Message- Sent: Tuesday, January 28, 2003 10:49 AM To: Multiple recipients of list ORACLE-L Ranganath You are getting some excellent responses to your question (which I consider very on topic). We had a good discussion on this list previously. I went to Google and entered fatcity production dba and was able to pick up the thread. As to your question of OLTP vs. DSS situations, I think the differences are more subtle. I thing OLTP environments are more standard than DSS environments. Our DSS is more relaxed since it is a weekly load. Sunday and Monday are the critical days. Some of it is attitude, not being a normalization bigot, realizing that marketing people are a different species that will never know their needs in advance. Dennis Williams DBA, 40%OCP Lifetouch, Inc. [EMAIL PROTECTED] -Original Message- [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 28, 2003 2:29 AM To: Multiple recipients of list ORACLE-L Hi Listers, I would like to know the differences between Development and Production DBA w.r.t. Roles and Responsibilities, Scope etc. Is there any difference in the role(s) played by a DBA in OLTP and DSS environments? Your invaluable viewpoints in this regard is most welcome. Thanks and Regards, Ranganath WARNING: The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. Thank you. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Krishnaswamy, Ranganath INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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.net -- Author: DENNIS WILLIAMS INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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.net -- Author: Farnsworth, Dave INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - 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).
