이러한 습관은 DBA들 사이에서 흔히 볼 수있는 공통점이 있지만, 관리가 잘되어있어 치료가 가능합니다. 다음은 우리가 가장 치명적이라고 생각하는 7 가지 습관과 그것을 제거하는 방법에 대한 아이디어입니다.
습관 # 1. 믿음의 도약 : :우리는 백업에 대한 믿음이 있습니다.:
맹목적인 믿음은 사랑 스러울 수 있지만 데이터베이스를 백업 할 때는 그렇지 않습니다. 백업은 테스트되고 검증 된 경우에만 신뢰되어야합니다..
• DBA에게 정기적으로 백업 성공 여부를 확인하게하십시오. 문제가있는 경우 알려주는 스크립트를 사용하는 것이 좋습니다.
우리의 IQ 레벨이 조부모보다 높은 이유 | 제임스 플린
• 백업에 대한 백업을 유지합니다. DBA는 항상 최소한 두 가지 백업 방법을 사용해야합니다. 일반적인 기술은 이러한 구식 수출품을 온라인 백업에 대한 백업으로 사용하는 것입니다.
• 가능한 한 자주 자원 테스트를 복구합니다. 귀하의 DBA 팀이 과도하게 일했거나 정확하게 우선 순위를 매기 지 않는 초기 징후는 테스트 복구없이 1/4 분기가 진행되는 것입니다. 테스트 복구는 백업 전략이 궤도에 오르고있는 동안 팀이 복구 작업을 연습하면서 시간이 지나면 효과적으로 처리 할 수 있도록합니다..
습관 # 2. 대단한 기대 : :우리가 기대하는대로 작동 할 것입니다.
전통적인 의미에서 사용자 친화적이지는 않지만 오라클은 매우 파워 사용자 친화적입니다. 잠시 동안 작업 해 본 후에는 :해야:하는 방식에 대한 본능을 개발하게됩니다. 그 본능이 종종 옳긴하지만 DBA가 가질 수있는 가장 위험한 습관 중 하나는 오라클이.
• 조직 전체에 :실습, 실습, 실습:정신을 심어주십시오. DBA는 프로덕션 시스템의 동작을 가깝게 모방하도록 설계된 테스트 환경의 안전한 샌드 박스에서 활동을 리허설해야합니다. 조직은 그렇게 할 수있는 시간과 비용을 허용해야합니다..
• 경험이없는 DBA와 가능한 한 상위 DBA를 쌍으로 배치하거나 자신의 날개 아래에서 가져 가십시오. 새로운 DBA는 두려움이없는 경향이 있지만 다른 사람의 경험을 통해 학습하면 많은 편집증을 심어줄 수 있습니다..
• 모든 계획을 검토하십시오. DBA가 :100 번 해본 적이 있는데 계획이 필요 없다:고 말하는 사례가 놀랍습니다. 그들이 실행 모드로 향하고 있다면 절대적으로 계획이 필요합니다..
습관 # 3. LAISSEZ-FAIRE ADMINISTRATION : :우리는 시스템을 모니터링 할 필요가 없으며 사용자가 언제 잘못되었는지 알려줍니다.:
문제가 있다는 것을 DBA 팀에 알리기 위해 사용자에게 의존한다면, 이미 너무 늦을 수도 있습니다.
• 가용성 및 성능 모니터링 시스템을 설치하여 서비스에 영향을 미치는 오류를 발생시키기 전에 문제를 확인하고 해결하십시오..
• 개발자 및 테스터와 협력하여 생산 준비가 완료된 모든 소프트웨어가 안정적이고 고성능이되도록 보장함으로써 출시 후 소프트웨어 문제를 피하십시오.
습관 # 4. 기억 테스트 : :우리는 어떻게 이런 일이 있었는지, 우리가 일을 다시하기 위해 무엇을했는지 기억할 것입니다.:
DBA 팀이 수주가 걸리던 엄청난 절차를 잊어 버리는 것은 불가능한 것처럼 보일 수 있습니다. 그러나 그것은 항상 발생합니다. 반복되는 실수를 예방하고 경험을 활용하려면 문서화가 필수적입니다..
• DBA가 상당한 수준의 이론적 설명, 구문 및 워크 플로우 세부 정보를 포함하여 포괄적 인 문서 라이브러리 및 활동 일기를 유지하도록 요구합니다..
• 인트라넷에 그룹웨어를 제공하여 응급 상황에서이 문서를 검색 할 수있게하십시오..
• 문서의 규율을 시행하고 주기적으로 점검하십시오. DBA에게 물어보십시오.이 테이블 스페이스가 언제 만들어졌으며, 누구에 의해, 그리고 어떤 SQL로 만들어 졌습니까? 특정 일에 수행 된 작업은 무엇입니까? 그들이 빨리 대답 할 수 없다면, 그들은 기억에 의지하기로 돌아 간 것을 알게 될 것입니다..
습관 # 5. BLAME GAME : :나를 보지 마라, SQL이 생산되고 있다는 것은 개발자의 잘못이다.:일부 DBA는 조직의 개발자들에게 진짜 :우리 대 그들:이라는 사고 방식을 가지고있다..
그들은 개발자가 데이터베이스 관점에서 양질의 코드를 개발하는 데 도움이되는 촉진자가 아니라 품질이 떨어지는 코드가 생산에 들어가는 것을 막는 보호자로서 스스로를 보았습니다. 이는 의미론처럼 보일 수 있지만 개발자와 DBA 간의 대립 관계는 개발자 주도권 부족과 릴리스주기의 현저한 둔화를 초래합니다.
• 지원하는 개발자와 통합 된 팀으로 일할 책임이있는 DBA를 선택하십시오.
• 검토 단계보다는 모든 프로젝트에서 DBA의 지속적인 참여를 구조화하여 팀 태도를 기른다..
• 개발자 지원 역할에 개별 DBA를 할당하는 것을 고려하십시오. 그것이 명확하게 직업 설명에 있다면, 그것을 잘하는 동기가 더 있습니다..
습관 # 6. 솔로 행위 : :내가하고있는 일을 알고 어떤 도움도 필요가 없다.:
데이터베이스 관리가 점점 더 복잡해지고 대부분의 고위 DBA조차도 모든 마지막 세부 사항을 알 수 없습니다. DBA는 다른 전문 지식을 보유하고 있으며,이를 추출하여 활용해야합니다. DBA는 모든 것을 알고 있거나 알고 있어야한다고 생각하면 질문을하지 않고 다른 사람들로부터 얻을 수있는 소중한 지식을 놓치지 않습니다..
• DBA가 답변을 모르고 도움을 요청할 수 있음을 인정하는 팀워크 문화 조성.
• DBA에게 외부 파트너 그룹을 찾아 브레인 스토밍 및 가정 테스트를위한 포럼으로 찾아 보도록 권장하십시오. 상대적으로 소규모 그룹의 전문 지식과 경험을 한 사람도 일치시킬 수 없습니다..
• 참고 자료, 강좌 및 외부 전문가 또는 전화 상담원과 같은 기술 자원으로 안전망 제공.
습관 # 7. TECHNO-LUST : :우리가 가진다면 상황이 훨씬 좋아질 것입니다 ...:
DBA는 종종 최첨단 기술을 바탕으로 최상의 업무를 수행 할 수 있습니다. 그러나 신기술에 대한 열망으로 DBA는 불필요한 하드웨어 구매 또는 소프트웨어 추가 기능을 권장하게되므로 비용이 급증하는 경향이 있습니다..
• 처음에는 모든 튜닝 기회를 사용하지 않고 하드웨어 인프라를 업그레이드하지 마십시오. 10 년 전에 거대한 기업이 필요성과 기술 덕분에 서버 용량의 10 분의 1로 운영된다는 것을 기억하십시오..
• 지속적인 유지 보수 약속 및 결과 비용을 잘 알고 있어야 고급 또는 새 기능 사용에 동의하지 마십시오.
• 어려운 작업을위한 친숙한 GUI 인터페이스를 제공하는 DBA 지원 소프트웨어에주의하십시오. 이러한 유형의 인터페이스는 초보 DBA가 특정 상황에서 중간 DBA로 작동 할 수있게 해주지 만 초보자가 작업의 실제 기술을 배우지 못하게합니다. 또한 이러한 도구는 DBA로부터 실질적인 위험을 숨기므로 포인트 앤 클릭처럼 쉽게 잠재적으로 위험한 활동을합니다.
12 단계 프로그램이든 작은 조정이든, 치명적인 DBA 습관은 모두 쫓겨날 수 있습니다. 물론 첫 번째 단계는 문제를 인식하는 것입니다. 이 목록에서 시작하여 팀의 데이터베이스 관리에서 성공과 실패에 대한주의 깊은 목록을 작성하면 치료 방법을 찾을 수 있습니다..