데이터베이스 관리가 왜 그렇게 어려운가요?

나는 많은 데이터베이스 관리자를 알고 있으며 28-29 세 이상입니다.

모든 데이터베이스 관리가 그런가요? 내 말은, 적어도 7-8 년 이상의 경험을 얻는 것입니까?

아니면 데이터베이스 관리자가 너무 어렵습니까?

이 직책에는 개발에서 시스템 관리 및 관리에 이르는 광범위한 지식이 필요합니다 . DBA는 백업, 복구, 내부 작업, 메모리 및 보안뿐만 아니라 개발자 및 관리와의 통신 방법에 대해서도 알아야합니다. DBA는 개발자에게 쿼리를 조정하고 새로운 시스템을위한 디스크 공간을 제공하며 백업에서 데이터를 모두 같은 시간 내에 복원 할 수 있도록 고급 프레젠테이션을 제공 할 수 있습니다. 이러한 책임에는 겹치지 않는 풍부한 지식이 필요합니다.

실패의 결과는 일반적으로 개발자보다 DBA에서 더 큽니다 . DBA는 종종 수십 가지, 심지어 수백 가지의 서로 다른 응용 프로그램과 시스템을 지원하며 대부분이 회사의 성공에 필수적입니다. 보안 위반, 복구 실패 또는 성능 문제로 인해 심각한 결과가 초래 될 수 있습니다. 이를 위해서는 짧은 시간에 얻을 수없는 수준의 지식과 경험이 필요합니다.

DBA가 가시성을 떨어 뜨리면 작업을 더 잘 수행 할 수 있습니다. 안전하고 복구 가능하며 사용 가능하며 성능이 우수한 데이터베이스가있는 DBA는 인식 할 수 없습니다. DBA는 문제가있을 때 통지를받습니다. 문제가 자체적으로 발생할 때 알림을받을뿐만 아니라 데이터베이스의 코딩이 잘못되거나 네트워크 설정이 잘못되었거나 스토리지가 잘못 구성되어 데이터베이스에 문제가있는 경우 비난을받습니다.

저는 29 살 때 개발자에서 DBA로 전환했습니다. 저에게 DBA가 어려워지는 것도 보상이됩니다. 나는 광범위한 지식을 흡수하고 사용하는 것을 좋아하며, 실패 할 가능성이 높을수록 다른 사람들이 그것을 보든 그렇지 않든 그 실패를 피하는 것이 더 의미가 있습니다.

DBA가 되려면 실제로 상당한 경험이 필요하지만 기본적으로 네 가지 경로에서만 나올 수 있습니다.

1. 개발자가되어 DBA에 전념
2. 개발자로서 DBA로 초안 작성
3. 대학 / 무역 학교에서 직접 DBA가되기위한 교육
4. SysAdmin이되어 DBA로서의 임무 수행 또는 이중 의무 수행

개발자가되어 DBA에 전념

이 사이트에서 질문 한 또 다른 질문 인 DBA가보다 '프로그래머 친화적'이 될 수있는 방법은 무엇입니까? 저는 DBA와 함께 일한 16 년 동안 개발자라고 언급했습니다. 그들과 함께 일하면서 데이터베이스 이론, 이산 수학 및 프로그래밍 경험이 데이터베이스 경험과 쿼리 실행 방법을 알 수 있다는 것을 알게되었습니다.

그런 배경을 가진 DBA를 가지고 있으면서 나는 여전히 겸임 교수로부터 대학 학습을하고 있지만 자신의 것을 알고있는 사람이라고 느끼게되었습니다. DBA가 자신이 아는 것을 공유하고 기꺼이 공유 하지 않는 한 실제로는 SQL 문 (SQL 자체는 문맥 감지 프로그래밍 언어)을 개발하는 측면에서 실제로 멘토가 될 수 있습니다. 가능한. 물론 설치, 백업, 소프트웨어 업그레이드, 성능 지표 모니터링, 보고서 생성 등과 같은 기타 일반적인 부분이 있습니다. 그러나 개발자로서 데이터베이스와 해당 데이터베이스에 대해 실행되는 SQL에 중점을두면 시간이 지남에 따라 SQL에 익숙해 져서 자연스럽게 응용 프로그램 개발에 집중할 수 있습니다.

개발자에 대한 요구는 과세 될 수 있지만 DBA도 마찬가지입니다. DBA의 역할로 자발적으로 전환 한 개발자는 개발 및 코딩에서 이전에 언급 한 평범한 것으로 초점을 이동합니다. DBA는 프로그래머와 긴밀히 협력하여 DBA가 모든 프로젝트에 창의적으로 기여할 수있는 기회를 만들어 DBA의 역할을 훨씬 더 흥미롭게 만듭니다.

개발자로서 DBA로 초안 작성

남은 생애 동안 개발하고 코딩하는 것만 보지 않는 대부분의 개발자에게 이것은 실제 쇼 생존자 또는 게임 쇼 와이프 아웃 중 하나를 선택하는 것과 같습니다 . 새로운 DBA는 수년 동안 데이터와 접촉 한 Black Box (데이터베이스라고도 함)와 상호 작용하는 데 시간을 보냅니다.

새로운 DBA는 이제 자신의 테이블과 인덱스를 만들 수 있습니다. 이것은 일본 히바 치가 이탈리아 식당에서 요리하는 것과 비슷할 수 있습니다. 요리사는 무엇이든 채울 수 있지만 새로운 조리법, 주방 용품, 식기류, 고기, 향신료, 야채 및 기타 평범한 것들 (위생, 재고, 시작 시간, 근무 시간 등)이 있다는 것을 알아야합니다. 이것은 단지 전환의시기 일뿐만 아니라 위대한 학습 곡선을 극복 할 때이기도합니다. 수년에 걸쳐 전문적인 일본 요리에도 불구하고 새로운 수준의 경험을 배우고 개발해야합니다. 이러한 측면에서 개발자는 DBA처럼 생각하도록 스스로 교육해야합니다.

대학 / 무역 학교에서 직접 DBA가되기위한 교육

이것이 DBA가되는 가장 치명적인 방법입니다. 이것은 또한 가장 드문 경로입니다. 실제로 이것은 거의 들어 본 적이 없습니다. 이제 우리는 맥도날드 나 버거 킹의 누군가를 같은 이탈리아 식당으로 안내합니다.

세 가지 학습 곡선이 포함됩니다.

1. 대학 / 무역 학교의 기술을 DBA 역할에 적용
2. 특정 RDBMS (PostgreSQL, Oracle, MySQL, DB2, Sybase, Ingres)와 상호 작용
3. 개발자와의 상호 작용 ( 학교에서 곧바로 미래의 DBA 학습 괜찮은 사회 기술? 예, 맞습니다! ).

이로 인해 개발자들은 수년간 DBA보다 우위를 점하게 될 것입니다. DBA는 초기에 DBA로서 개발자의 요구에 빠르게 적응하는 법을 배워야합니다. 아마도 DBA는 괜찮은 연봉을 만들 수 있지만이 세 가지 학습 영역에서 스스로 발전하지 않으면 성장하기가 더 어렵습니다.

SysAdmin이되어 DBA로서의 임무 수행 또는 이중 의무 수행

이전 개발자이자 이제는 DBA로서 당연한 것으로 여겨서는 안되는 것은 SysAdmin의 역할입니다.

SysAdmin / DBA의 역할을하는 것은 약간의 경외심을 불러 일으 킵니다. 고용주 호스팅 회사에는 SysAdmin / DBA (SCMDBA) 직원이 있습니다. 그는 인프라 프로젝트와 자체 내부 MySQL 공연으로 가득 차 있습니다. 나는 그를 부러워하지 않습니다, 나는 그를 칭찬합니다. 솔직히 말해서, SysAdmin / DBA의 진정한 마음이 나에게는 이질적이기 때문에이 경로를 설명하기 위해 SysAdmin / DBA의 재량에 따라이 단락을 업데이트하거나 완전히 바꿉니다 .

결론

어떤 경로를 선택하든, 처음에 멘토링 (또는 고문)을받는 방법과 다른 오버 타임으로 기꺼이 일하는 방식에 따라 DBA의 역할은 구별되거나 혐오 할 수 있습니다. 그래야만 DBA를 즐긴다 고 말할 수 있습니다.

그건 그렇고, 2004 년 8 월부터 39 세의 나이에 처음 두 개의 DBA 경로를 경험했습니다. 작성된 DBA 역할에 대한 2 년간의 경험으로 인해 전일제 DBA 로의 전환이 매우 즐겁고 편안해졌습니다. .

28-29 세의 DBA에 대한 조언은? RDBMS를 사용하는 것처럼 사람들과 일을 잘하십시오. 두 영역 모두에서 자라면 앞으로 몇 년간 DBA로 만들 수 있습니다.

두 가지 이유 때문에 데이터베이스 관리가 어렵다

느린 피드백 소프트웨어 아키텍트의 역할에서 잘못된 결정을 내리는 경우 프로그래머에 비해 부정적인 피드백을 얻는 데 보통 더 오래 걸립니다. 프로그래머는 종종 컴파일 중이나 테스트 실행 중 오류를 인식 할 수 있으므로 학습주기가 매우 빠릅니다. 데이터베이스를 설계하는 동안 실수를 한 데이터베이스 관리자는 최종 사용자가 실제로 소프트웨어를 사용하는 방법을 발견했을 때 피드백을받을 수 있습니다. 즉, 데이터베이스 설계에 결함이 있고 다시 만들어야한다는 피드백을받는 데 몇 년이 걸릴 수 있습니다. 따라서 프로그래머에게는 몇 분 (때로는) 대신 경험을 얻는 데 몇 년이 걸립니다.

비싼 실수 이것은 대기업의 CEO가 일반적으로 50 대에 이르는 이유이기도합니다.

나쁜 DBA가되는 것은 꽤 쉽다

그러나 DBA는 일반적으로 비즈니스의 성공 또는 실패에 중요한 요소 인 데이터에 대한 특별한 책임이 있습니다.

당신이 회사를 운영하는 경우에 당신은 그 역할에 유능한 경험있는 사람들을 고용하고 싶어 할지도 모릅니다

나는 그것이 더 쉬운 또는 더 어려운 문제라고 생각하지 않습니다. 데이터가 얼마나 가치가 있는지에 대한 질문입니다. 후자를위한 좋은 거래

제 생각에는 데이터베이스 관리자가되는 것은 쉬운 일입니다. 어떤 일이 일어날 때까지 회사를 위협하고 어깨에있는 모든 것을 고치고 복원해야하는 부담이 있습니다.

데이터베이스 관리자 (또는 네트워크 또는 시스템 관리자)는 특정 성숙도 수준이 필요한 위치입니다. 압박을 받고 잘 일하는 사람이 필요합니다. 그것은 필요한 스킬 셋으로 이것을 처리 할 수있는 젊은이가 없다는 것을 말하는 것은 아닙니다.

또한 책에서 데이터베이스를 백업 / 복원하고 서버 구성을 최적화하는 등의 명령을 쉽게 배울 수 있습니다. 그러나 데이터베이스가 다운되었다는 경고를 받으면 경험에 유리합니다.

나는 많은 데이터베이스 관리자를 알고 있으며 28-29 세 이상입니다. 모든 데이터베이스 관리가 그런가요?

내가 아는 가장 훌륭하고 견고한 프로그래머도 25 세 이상입니다. 나이 + 경험 = 좋은 코더와 상관 관계가 있다고 생각합니다. ;)

내 말은, 적어도 7-8 년 이상의 경험을 얻는 것입니까? 아니면 데이터베이스 관리자가 너무 어렵습니까? 어떻게 생각해?

그것이 데이터베이스 관리자가되는 것은 쉬운 일이 아닙니다. dba로 알아야 할 것들이 많이 있습니다. 그것은 또한 학교를 의미하며, 다른 사람의지도 아래 몇 년을 의미합니다. 데이터베이스는 논리적으로 설정되어 거의 아무도 배우기에 충분히 학교에 가지 못하므로 아무도 알지 못합니다. Set-logic은 대수와 일부 규칙을 공유하지만 엔진 (MSSQL, Oracle 등)은 그 자체로 이러한 규칙을 구현하는 데있어 가장 큰 영향을 미칩니다. 따라서 데이터베이스 배후의 수학을 이해해야 할뿐만 아니라 구현에 대해서도 이해해야합니다. 위에 실행하십시오. 선호하는 스크립팅 언어 (PL / SQL, TSQL 등)를 아는 것도 중요하지 않습니다.

그런 다음 dba로서 가장 중요한 비즈니스 데이터가 종종 귀하의 손에 맡겨 질 책임이 있음을 고려하십시오. "벙어리 실수하기"의 최악의 부분을 넘어서야하고 약간의 자제력을 배워야합니다. 21-23 세의 대부분의 사람들은 아직 그것을 배우지 못했습니다. 30 세의 우리 중 일부는 아직하지 않았습니다.

OT : 이것이 제가 사람들이 적어도 40 살이되기 전까지는 아무것도 알지 못한다고 말하는 이유입니다. 그리고 실제로 그들은 단지 그들의 보폭에 도달 할 때 언덕 너머로 간주됩니다. (31 세인 사람)

나는 DBA가 어렵다고 생각하지 않습니다. 그래도 하나가되었습니다.

위에서 잘 논의되지 않은 또 다른 측면, 즉 시야를 추가하기 위해 대답하고 싶었습니다.

개발자에게는 다양한 역할이 있으며 일부 (예 : 장치 드라이버 개발 또는 운영 체제 스케줄러 개발)에는 매우 좁은 시야와 작은 문제를 깊이 파고 들고 순수한 기술적 관점에서 볼 수있는 기능이 필요합니다. . 매우 광범위한 비전이 필요하지만 기술적 인 깊이는 필요하지 않은 다른 분야도 있습니다 (선택한 ERP 프레임 워크를 사용한 비즈니스 응용 프로그램 개발).

데이터베이스는 잘 작동하기 때문에 독특합니다. 이러한 모드간에 빠르고 완벽하게 이동할 수 있어야합니다. 데이터베이스는 수학 엔진이지만 비즈니스 환경에 매우 복잡한 방식으로 적합한 수학 엔진입니다. 따라서 수학 문제를 수학 문제로 해결하고 다른 모든 문제에 어떻게 적용되는지 물어볼 수 있어야합니다.

선임 네트워크 엔지니어 나 선임 시스템 관리자를 살펴보면이 분야의 선임 DBA와 가장 일치합니다 (각 필드는 상당히 다르지만 선임 sysadmin은 좋은 dba보다 더 넓은 시야를 필요로합니다. 좋은 네트워크 엔지니어는 더 깊은 분야를 요구합니다).

다시 말해, 우수한 DBA가 되려면 실제 온 디스크 스토리지와 관련된 고급 비즈니스 요구 사항과 매우 낮은 수준의 이해, 관계형 수학 및 순수 기술 설계 문제로 전환 할 수 있어야합니다. 실제 전환 (그리고 아마도 특정 결정을 평가하는 과정에서).

DBA와 개발자로 활동하고 있습니다. 이 두 가지 역할은 매우 보완 적이지만, 나는 먼저 DBA이고 내가 작성한 라이브러리를 본다면 그것은 분명 할 것입니다. 그러나 그들이 보완 적 인 이유는 개발 측면에서 소프트웨어의 최종 사용자와 직접 인터페이스하기 때문에 비전의 번영에 대해 끊임없이 추진되고 있기 때문에 db 측면에서는 나 자신에게 도전하기 때문입니다. 깊이에.

나열된 경로와 약간 다른 다른 경로가 있습니다.

개발자로 시작한 다음 데이터베이스 디자이너가되고 DBA가됩니다. 이 경로는 약 30 년 전에 데이터베이스가 파일 기반 응용 프로그램을 크게 추월하기 시작했으며 데이터베이스 전문 지식을 가진 사람들이 그 사이에 거의 없었습니다.

추신 : 전 프로그래머가 DBA가되었을 때 프로그래머들은 "DBA가 지루하지 않습니까?"

내 대답 : "올 바르면 지루 해요!". :)

나는 DBA 여정의 시작에있다. 그러나 사람들이이 직업을 찾기 힘든 몇 가지 이유는 다음과 같다.

• 많은 책임이 있습니다. 사람들은 회사에오고 갈 수 있지만, 그 중 상당수의 경우 가장 중요한 자산은 데이터입니다. 당신은 그것을 책임지고 그것에 대한 모든 힘을 가지고 있습니다. 그 말이 진행됨에 따라 큰 힘으로 큰 책임이 따릅니다. 비용이 많이 드는 실수가 숨어 있습니다.
• 당신은 배우고 계속 배워야합니다 : 나는 이것을 보너스로보고 있지만, 모든 사람들이 자신의 지식을 최신 상태로 유지하기 위해 시간을 할애하지는 않습니다.
• 시간이 많이 걸릴 수 있습니다. 한밤중에 일이 망가질 것입니다. 준비가 되셨습니까?
• 당신은 종종 다른 사람들의 실수를 고쳐야 할 것입니다 : 그리고 당신은 대부분 당신의 모든 좋은 일에 대해 많은 신용을 얻지 못할 것입니다. 사람들의 기술을 연마하는 것을 두려워하지 마십시오.

브래드 맥 게히 (Brad Mc Gehee)는 "뛰어난 DBA가되는 방법"에 관한 책을 썼습니다 . 질문을 심화하려는 경우 읽을 가치가 있습니다.

행운을 빕니다!

25 세의 나이에 dba가되었습니다. 인증을 받기 위해 공부를 시작한지 ​​6 개월이 걸렸고 2 개월 후에는 일을했습니다. 나는 결단력이 확실히 중요한 역할을한다고 생각합니다. 나에게는 직업을 얻는 것이 힘들지 않았다. 공부하고 공부할 수있는 힘만 있으면 내 앞에 놓인 내용을 배울 수있었습니다.

나는 내가 가진 모든 것이 심리학 학위와 헬프 데스크 배경이라고 말할 것입니다. Oracle Apps DBA로 일을 받았을 때, 나는 즉시 OMG를 생각했습니다. CORE DBA가되기 위해 공부 한 모든 것들이 저에게 조금 도움이되지 않았습니다. 압도적 인 느낌이 듭니다. 나는 매일 이것을 스스로 배울 수 있었고 나는 이것을 배울 수 있었고 2 년 후에 더 많은 지식을 얻었습니다.

내가 말하는 것은 DBA가 어렵지 않고 전혀 힘들지 않고 일과 업무에서 모든 것을 배우기 때문에 이전 dba가 이전에 언급했듯이 알아야 할 것은 시간이 많이 걸리고 많은 노력이 필요하다는 것입니다. 나는 27 세에 대부분의 나이에 젊은 사람들이 그러한 광범위한 기술을 배우고 자하는 성실함이나 욕구를 가지고 있지 않다는 것을 알았습니다. 그러나 저는 Oracle Apps DBA로서의 일을 좋아하며 지속적으로 배울 수있는 다른 모든 것을 기대합니다. 마음에 든다면 몇 살이든 상관 없습니다!

DBA가된다는 것은 또한 반응성이 아니라 능동적이라는 것을 의미합니다. 미래가 무엇을 보유하고 있는지 계획하고 그에 따라 계획을 세워야합니다. 여기에는 열심히 일하는 것이 포함됩니다. 한 번, 여러 번, 그리고 여러 번 올바르게 수행하면 보상은 이름 인식이 완전히 부족합니다. :-) 또한 사람들 (보스 포함)에게 "아니오"라고 말할 수있는 능력이 있어야하며, 청중이 이해할 수있는 이유에 대한 이유를 객관적으로 효과적으로 전달해야합니다. 압박이 심한 상황에서는 신중하고 합리적인 결정을 내려야합니다. 실수를 신속하게 소유 할 수 있어야하고 실수로 블루 스크린을 표시하지 말아야합니다. 대신 기어를 "그냥 믿지 못합니다"에서 "이 문제를 해결하는 가장 좋은 방법은 무엇입니까?"로 기어를 효과적으로 전환해야합니다.

자신을 주로 SysAdmin으로 생각하고 우연히 DBA라고 생각하는 사람으로서, 나는 자신의 일을하고 일을하거나 더 중요한 것은 일을 이해하는 데 필요한 지식의 양에 달려 있다고 생각합니다.

구 MCDBA 인증은 내가 생각하기에 그것을 잘 요약합니다. SysAdmin 시험, 네트워크 인프라 시험, 데이터베이스 개발 시험 및 SQL 관리 시험의 4 가지 시험에 합격해야했습니다. 그것은 매우 광범위한 주제이므로 현실적으로는 먼저 주제 중 하나를 통해 그 주제에 도달 할 것입니다. 나는 많은 SQL 관리가 다른 세 가지의 어깨에 서 있다고 주장하기 때문에 대부분의 사람들은 처음에 이러한 경로 중 하나를 통해 SQL 관리 시스템을 사용합니다. 예를 들어 SysAdmin이 SQL 백업 (수년 전에 SQL을 처음 도입 한 경우)을 처리하거나 개발자가 작성하는 코드에 대한 데이터베이스를 설계하는 개발자입니다. 처음부터 모든 것을 알지는 못하지만 최소한 SQL SQL이 실행되는 시스템과 사용 권한이 작동하는 방식 또는 데이터베이스와 통신하는 데 사용되는 프로그래밍 방법 등

DBA가되는 것이 실제로하고 싶을 때까지 실제로하고 싶은 것인지 판단하기는 어렵지만, 위의 경로를 통해 사람들은 점차 그것에 도달 할 수 있습니다. 당신은 그것을 좋아하고 그것을 당신의 커리어 포커스로 만들거나, 당신에게 적합하지 않다는 것을 발견하고 이전의 커리어 경로를 고수 할 수 있습니다. 그러나 시간이 걸리고 업계에서 DBA의 "수년이 더 현명한"경향이 있습니다.

좋은 DBA가 되려면 나이가 들면서 자신감과 성숙함이 필요합니다. 다른 사람들은 이것의 다른 측면을 나열했지만, 나는 아니오라고 말하고 자신의 입장을 견딜 수 있다는 확신을 가지고 추가 할 수있는 경험을 가지고 있습니다.

마지막으로, 좋은 DBA가 되려면 특정한 사고 방식이 필요하다고 생각합니다. 세부 사항을 주시하고 미리 계획을 세울 의향, 큰 그림을 볼 수있는 능력, 작업 내용을 문서화하는 것을 두려워하지 않는 것이 안정적인 시스템을 유지하는 데 중요한 측면입니다. 일부 SysAdmins 및 개발자는 이와 유사하며 쉽게 전환 할 수 있지만, 다른 SysAdmins 및 개발자는 현재 작업에서 가치가있는 반면 DBA는 이러한 일을 번거롭게하고 일을 즐기지 않을 것입니다.

적어도 비자발적 인 데이터베이스 관리자가되는 데있어 가장 어려운 부분은 당신이 우연히 겪은 특정 조직의 데이터베이스에 무슨 일이 생겼는지 알아야한다는 것입니다.

내 경험상 첫 번째 충격은 월요일 아침에 하드웨어 오류가 발생하여 데이터베이스 서버가 충돌했을 때였지만 그럼에도 불구하고 뭔가 잘못한 것으로 의심되었습니다.

일생 동안 배우거나 운동 한 모든 것을 다시 적용하려면 적용해야한다고 상상할 수 있습니다. 물론 복제본을 만들고 전체를 플래시 백업 할 수도 있습니다. 여기서는 링크 서버를 통해 다른 컴퓨터 네트워크로 사물을 라우팅하는 작은 데이터베이스 서버에 대해서만 이야기하고 있습니다. 그러나 그 순간에 책임은 엄청납니다.

소프트웨어 개발자 또는 소프트웨어 테스터로서의 책임 또한 크지 만, 그런 어려운시기를 경험 한 적이 없습니다. 그 이유는 그들 각각이 정보 기술 세계의 거미줄을 조금만 짜는 사실에 있다고 상상할 수 있습니다.

데이터베이스 관리자가 된 경우 여기에 작성한 내용을 업데이트해야합니다.

그리고 예, 저는 38 세 / 2 세입니다.

대부분의 기술과 마찬가지로 dba를 배우는 데는 시간이 걸립니다. 되기 좋은 DBA 것은 오래 걸립니다. 더 많이 읽고 배울수록 더 많은 지식을 적용 할 수 있습니다.

dba가되는 또 다른 방법은 보고서 작성 또는 응용 프로그램 전문가입니다. SQL에 대해 더 많은 시간을할수록 DB 작동 방식에 대해 더 많이 배울 수 있습니다. SQL 쿼리에 능숙하면 dba가되기위한 좋은 출발점이 될 것입니다.