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