작성자 : Techopedia Staff, 2017 년 4 월 19 일
테이크 아웃 : 호스트 Eric Kavanagh는 Dr. Robin Bloor, Rick Sherman 및 IDERA의 Bullett Manale과의 예측에 대해 논의합니다.
비디오를 보려면이 이벤트에 등록해야합니다. 비디오를 보려면 등록하십시오.
Eric Kavanagh : 신사 숙녀 여러분, 다시 한 번 안녕하세요. Hot Technologies 웹 캐스트 시리즈에 다시 오신 것을 환영합니다! 제 이름은 Eric Kavanagh입니다. 저는 오늘 웹 세미나에서“최적의 예측으로 시간, 돈 및 문제 절약”이라는 호스트가 될 것입니다.“코스 코스 제목의 첫 부분 인“최고의 계획”을 놓쳤습니다. 이 쇼에서 항상 그것에 대해 이야기하십시오. 물론 Hot Technologies는 오늘날 전 세계에있는 멋진 제품 중 일부, 엔터프라이즈 기술의 세계, 사람들이하는 일, 작동 방식, 모든 종류의 재미있는 것들을 이해하기위한 포럼입니다.
그리고 오늘 제안한 주제는 예측에 관한 것입니다. 실제로 조직에서 어떤 일이 일어나고 있는지 이해하려고 노력하고 있습니다. 무엇을하고 있든지 사용자를 어떻게 행복하게 유지 하시겠습니까? 그들이 분석을하고 있거나, 실제 업무를 수행하고 있다면, 거래 시스템을 가진 실제 고객을 만나고 있습니다. 어떤 상황이든 시스템의 운영 방식과 진행 상황을 이해하고자합니다. 오늘 이야기하겠습니다. 예측이 내가 좋아하는 것이 아니기 때문에 재미있다. 너무 많이 예측하면 나쁜 일이 일어날 것이라고 생각하는 것처럼 미신적이기 때문이다. 내 단서를 따르지 마
오늘 발표자입니다. 왼편에있는 릭 셔먼이 보스턴에서 전화를 걸고 IDERA의 친구 인 Bullett Manale과 우리의 Robin Bloor 박사가 전화를 겁니다. 그리고 그걸로 로빈에게 넘겨주고 사람들에게 상기시켜 줄 것입니다. 질문을하고, 부끄러워하지 말고, 좋은 질문을 좋아하며, 오늘 발표자와 다른 사람들에게 알려줄 것입니다. 그리고 로빈, 그걸 빼앗아
Robin Bloor : 좋아, 내가 말한대로 극한 입장에 있기 때문에, 나는 오늘 SQL 이야기를 들려 줄 것이라고 생각했다. 왜냐하면 토론이 진행될 배경이고 필연적으로 충돌하지 않을 것이기 때문이다. Rick은 이에 초점을 맞추지 않고 Rick이 말한 내용과 충돌하지 않기 때문입니다. SQL 이야기에는 SQL에 대한 흥미로운 점이 있습니다. SQL은 선언적인 언어입니다. 아이디어는 원하는 언어를 만들 수 있다는 것입니다. 그리고 데이터베이스는 그것을 얻는 방법을 알아낼 것입니다. 실제로는 잘 작동했지만 IT 업계 전체를 선언적 언어에 기반을 둔 결과에 대해서는 말할 가치가있는 것들이 많이 있습니다. 사용자는 데이터의 물리적 구성을 알거나 신경 쓰지 않으며 선언적 언어에 대해 좋은 점입니다. 선언적 언어와는 분리되어 있으며 걱정할 수도 있습니다. 원하는 것을 요구하면됩니다. 가서 얻을 것이다.
그러나 사용자는 SQL 쿼리를 구성하는 방식이 쿼리 성능에 영향을 미칠지 여부를 알지 못하며 약간의 단점이 있습니다. 수백 줄과 수백 줄 길이의 쿼리, 단 하나의 SQL 요청, “select”로 시작하고 하위 쿼리 등으로 계속 진행되는 쿼리를 보았습니다. 그리고 실제로 데이터베이스에서 특정 데이터 모음을 원할 경우 SQL을 사용하여 다양한 방법으로 요청할 수 있으며 데이터에 익숙한 경우 동일한 대답을 얻을 수 있습니다. 따라서 하나의 SQL 쿼리가 데이터를 요청하는 가장 좋은 방법 일 필요는 없으며 데이터베이스는 사용자가 입력 한 SQL에 따라 다르게 응답합니다.
따라서 SQL은 실제로 성능에 영향을 미치므로 SQL을 사용하는 사람들도 마찬가지입니다. SQL을 사용하는 SQL 프로그래머들도 마찬가지입니다. 왜냐하면 그들은 SQL에 영향을 줄 가능성이 훨씬 적기 때문입니다. 그들의 초점의 대부분은 실제로 데이터를 가져오고 넣는 것이 아니라 데이터를 조작하는 데 있습니다. 그리고 BI 툴에서도 마찬가지입니다. 원하는 경우 다양한 데이터베이스의 BI 툴을 압축하는 SQL을 보았습니다. 많은 것이 사실입니다. 그런 SQL 쿼리를 작성하지 마십시오. 매개 변수가 무엇이든간에 약간의 SQL을 버리고 다시 SQL이 반드시 효율적인 SQL이 아니라는 작은 모터를 만든 사람이 있습니다.
그런 다음 임피던스 불일치에 대해 언급했다고 생각했습니다. 프로그래머가 사용하는 데이터는 정렬 할 때 데이터와 다릅니다. 따라서 DMS는 테이블에 데이터를 저장하고, 객체 지향 코드는 대부분 코더로 구성되며, 오늘날 객체 지향 형태로 프로그래밍되며, 객체 구조에서 데이터를 정렬하므로 서로 매핑되지 않습니다. 따라서 프로그래머가 생각하는 데이터에서 데이터가 무엇인지 데이터베이스가 생각하는 것으로 변환해야 할 필요가 있습니다. 우리가 잘못한 일이 있었을 것 같습니다. SQL에는 데이터 정의를위한 DDL이 있고 데이터를 가져 오기위한 DML (데이터 조작 언어)이 있습니다. 이제는 수학과 시간 기반의 자료가 거의 없으므로 불완전한 언어입니다. 언어가 확장되어 계속 확장되고 있다고 말해야합니다.
그런 다음 다이어그램보다 항상 직선 인 SQL 장벽 문제가 발생하지만 많은 사람들이 일단 질문 데이터 용어에 대한 답변을 얻은 후 다른 질문을하고 싶은 경우 분석적인 이유로 질문을합니다. 따라서 대화 상자가됩니다 .SQL은 대화 상자를 위해 작성되지 않았으며 원하는 것을 한 번에 묻는 것입니다. 그리고 사용자와 데이터 사이의 대화를 가능하게하기 위해 실제로 SQL을 포기하는 일부 제품이 있기 때문에 알만한 가치가 있습니다.
데이터베이스 성능 측면에서 – 그리고 이런 종류의 모든 것이 퍼져 있습니다 – 예, CPU, 메모리, 디스크, 네트워크 오버 헤드, 그리고 한 사람 이상이 주어진 데이터를 독점적으로 사용하기를 원하는 잠금 문제가 있습니다. 시점. 그러나 SQL 호출도 좋지 않고 성능 측면에서 실제로 SQL을 최적화하면 수행 할 수있는 끔찍한 일이 있습니다. 따라서 데이터베이스 성능 요소 : 잘못된 디자인, 잘못된 프로그램 디자인, 워크로드 누락 동시성, 로드 밸런싱, 쿼리 구조, 용량 계획. 이것이 데이터 증가입니다. 그리고 간단히 말해서 SQL은 편리하지만 자체 최적화되지는 않습니다.
릭에게 넘어갈 수 있다고 생각합니다.
에릭 카바나 흐 : 좋아, 릭, WebEx 자동차 열쇠를 알려 줄께. 멀리 가져.
Rick Sherman : 좋습니다. 프리젠 테이션을 시작할 때 시작한 로빈에게 감사합니다. 그래픽은 여전히 지루하지만, 계속 진행하겠습니다. 그래서 로빈이 SQL 쪽에서 이야기 한 모든 것에 동의합니다. 그러나 지금 조금 집중하고 싶은 것은 데이터에 대한 수요입니다. 데이터에 대한 수요, 즉 해당 공간에서 사용되는 도구에서의 공급 또는 해당 공간에서 도구의 필요성입니다.
먼저 모든 기사에는 빅 데이터, 많은 데이터, 클라우드에서 오는 구조화되지 않은 데이터, 상상할 수있는 모든 곳의 빅 데이터와 관련이 있습니다. 그러나 데이터베이스 시장의 성장은 SQL을 통해 지속적으로 이루어졌으며, 아마도 2015 년 기준으로 관계형 데이터베이스는 여전히 데이터베이스 시장의 95 %입니다. 상위 3 개의 관계형 공급 업체는 해당 공간에서 시장 점유율의 약 88 %를 차지합니다. 우리는 여전히 Robin이 이야기 한 것처럼 SQL에 대해 이야기하고 있습니다. 실제로 우리가 Hadoop 플랫폼을보고 있더라도 데이터 과학자 인 내 아들이 지금 항상 사용하는 Hive and Spark SQL은 사람들이 데이터를 얻는 데 가장 중요한 방법입니다.
이제 데이터베이스 측면에는 두 가지 광범위한 데이터베이스 사용 범주가 있습니다. 하나는 운영 데이터베이스 관리 시스템, 엔터프라이즈 관계 계획, 고객 관계 관리, Salesforce ERP, Oracle, EPIC, N4 등을위한 것입니다. 그리고 데이터웨어 하우스 및 기타 비즈니스 인텔리전스 기반 시스템에있는 데이터의 양과 확장 량이 증가합니다. '포획, 저장 또는 거래되는 장소와 방법에 관계없이 모든 것이 결국 분석되므로 데이터베이스, 특히 시장에서 관계형 데이터베이스의 사용이 엄청나게 증가하고 있습니다.
이제 우리는 수요가 있고 엄청난 양의 데이터가오고 있습니다. 저는 빅 데이터에 대해서만 말하는 것이 아니라 모든 종류의 기업에서 데이터를 사용하는 것에 대해 이야기하고 있습니다. 그러나 공급 측면에서 이러한 리소스를 관리 할 수있는 사람들에게는 우선 DBA가 부족합니다. 우리는 노동 통계국에 따르면, 2014-2024 년에 DBA 일자리는 11 % 만 증가 할 것입니다. 이제는 DBA 직책을 가진 사람들입니다. 그러나 우리는 이에 대해 두 번째로 이야기 할 것입니다. 연간 데이터 증가 공간 비율 플러스. 그리고 우리는 많은 DBA를 가지고 있습니다. 평균적으로 같은 연구에서 평균 연령에 대해 이야기 한 것은 다른 IT 전문가에 비해 상당히 높습니다. 그리고 우리는 많은 사람들이 현장을 떠나 반드시 퇴직 할 필요는 없지만 다른 측면으로 옮겨 가거나 경영진 등으로 이동합니다.
그들이 떠나는 이유 중 하나는 DBA 작업이 점점 더 어려워지고 있기 때문입니다. 우선, 우리는 DBA가 다양한 데이터베이스 자체를 관리하고 물리적 데이터베이스는 물론 다양한 유형의 데이터베이스를 관리합니다. 이제는 관계 적이거나 다른 데이터베이스 유형의 데이터베이스 일 수도 있습니다. 그러나 관계가 있더라도 실제로 관리하려는 공급 업체가 1, 2, 3, 4 개가 될 수 있습니다. DBA는 일반적으로 데이터베이스 또는 응용 프로그램 설계 후에 관여합니다. Robin은 데이터베이스 또는 응용 프로그램 설계 방법, SQL 설계 방법에 대해 이야기했습니다. 데이터 모델링, ER 모델링, 확장 된 ER 모델링, 차원 모델링, 고급 차원 모델링 등 일반적으로 애플리케이션 프로그래머와 애플리케이션 개발자는 최종 목표를 염두에두고 설계하지만 효율성을 고려하여 설계하지는 않습니다. 데이터베이스 구조 자체 그래서 우리는 디자인이 열악합니다.
이제는 상용 엔터프라이즈 응용 프로그램 공급 업체에 대해 이야기하지 않습니다. 일반적으로 ER 모델 또는 확장 ER 모델이 있습니다. 내가 말하고있는 것은 모든 회사의 응용 프로그램 개발자가 구축하는 비즈니스 프로세스와 응용 프로그램이 훨씬 더 많다는 것입니다. 배포의 효율성이나 효율성을 위해 반드시 설계된 것은 아닙니다. 또한 DBA 자체는 과로되어 있으며 때때로 24/7 책임이 있으며, 점점 더 많은 데이터베이스를 보유하고 있습니다. 사람들이 자신이하는 일이나 수행 방식을 잘 이해하지 못한다고 생각합니다. 그들 자신의 작은 그룹과 사람들은 "이러한 모든 도구가 사용하기 쉬울뿐 아니라 워크로드에 점점 더 많은 데이터베이스를 계속 던질 수 있습니다"라고 계속 생각합니다.
파트 타임 및 우발적 인 DBA로 연결됩니다. 규모가 작은 IT 팀이 있으며 반드시 전용 DBA를 감당할 수는 없습니다. 이제는 지난 10 년 동안 데이터베이스 및 데이터베이스 응용 프로그램의 확장이 폭발적으로 확대되고 계속 확장되는 중소 기업에 해당됩니다. 그러나 대기업의 경우에도 일반적으로 오랫동안 데이터웨어 하우징, 비즈니스 인텔리전스 분석을 수행해 왔습니다. 오래 전에 우리는 그 프로젝트를위한 전용 DBA를 얻었습니다. 더 이상 전용 DBA를 얻지 못합니다. 우리는 데이터베이스를 디자인 할 책임이 있습니다. 데이터베이스를 경험 한 사람이라면 괜찮습니다. 그러나 일반적으로 DBA는 응용 프로그램 개발자이며 종종 파트 타임으로 업무를 수행하며 정식 교육을받지 않으며 최종 목표를 위해 설계하고 있습니다. 효율성을 위해 설계하지 않았습니다.
그리고 설계와 개발, 배포 및 관리에는 많은 차이가 있습니다. 그래서, 우리는 작은 돼지 저금통이있는“페니 현명하고 파운드 어리석은”프로젝트를 가지고 있으며 프로젝트에 필요한 기술과 자원을 얻는 것을 건너 뜁니다. 모두가“괴상한 복수”에서 나온 것이라고 생각하고 저의 작은 그림입니다. 이제 사람들이 필요로하는 한, 우리는 SQL에서 데이터베이스와 데이터의 사용이 확대되고 있습니다. 우리는 이러한 튜닝, 설계, 관리 및 구축 상황에 대해 숙련 된 전문가 인 DBA를 제한하고 있습니다. 그리고 공식 교육을받지 않은 시간제 또는 우연한 DBA가 점점 더 많아지고 있습니다.
그렇다면 이러한 데이터베이스가 조정되지 않았거나 관리되지 않는다는 사실과 관련하여 또 다른 사항은 무엇입니까? 첫째, 많은 사람들은 데이터베이스 시스템 자체가 스스로를 관리하기에 충분한 도구를 가지고 있다고 가정합니다. 이제 도구는 설계 및 개발이 쉬워지고 쉬워 지지만 배포를위한 우수한 설계, 우수한 관리, 용량 계획, 모니터링 등은 다릅니다. 따라서 사람들은 먼저 필요한 모든 도구가 있다고 가정합니다. 둘째, 파트 타임 또는 우발적 인 DBA 인 경우 자신이 모르는 것을 모릅니다.
나는 그 구절을 잊어 버렸기 때문에 많은 사람들은 디자인이나 데이터베이스를 관리하거나 운영 할 때 볼 필요가있는 것을 이해하지 못합니다. 그것이 당신의 직업이 아니라면, 당신은 당신이해야 할 일을 이해하지 못할 것입니다. 셋째, SQL은 도구로 사용하기 때문에 Robin은 SQL에 대해 이야기하고 SQL이 얼마나 잘못 구성되거나 구성되는지에 대해 이야기했습니다. 또한 BI 데이터웨어 하우징, 데이터 마이그레이션, 데이터 엔지니어링 분야에서 필자 중 하나는 값 비싼 데이터 통합 도구를 사용하더라도 도구를 사용하는 대신 SQL 코드, 저장 프로 시저를 작성하는 경향이 있다는 것입니다. 값 비싼 BI 도구 인 경우 종종 저장 프로 시저를 실행하는 데 실제로 사용합니다. 따라서 데이터베이스 설계, SQL 구성에 대한 이해의 중요성이 점점 더 중요 해지고 있습니다.
마지막으로이 사일로 접근 방식이 있습니다.이 사일로 방식에서는 개별 사람들이 개별 데이터베이스를 살펴볼 수 있습니다. 그들은 응용 프로그램의 작동 방식과 상호 작용 방식을 보지 않습니다. 또한 그들은 종종 데이터베이스와 데이터베이스를 사용하는 응용 프로그램을보고 있습니다. 따라서 데이터베이스에서 얻는 워크로드는 디자인, 튜닝, 용량 계획 방법 등을 결정하는 데 중요합니다. 따라서 나무에서 숲을 바라 볼 때 사람들은 잡초에 있습니다. 개별 테이블과 데이터베이스를보고 작업 부하에서 이러한 응용 프로그램의 전반적인 상호 작용을 보지 않습니다.
마지막으로, 사람들은보고자하는 주요 영역을 살펴 봐야합니다. 데이터베이스를 관리 할 계획이라면 먼저 테이블에 대해 생각하고 일부 응용 프로그램 중심의 성능 메트릭을 개발해야하므로이 테이블의 구성 방식, 특히 모델링 된 방법뿐만 아니라 사용 방법을 고려해야합니다. 따라서 공급망 관리가 필요한 엔터프라이즈 애플리케이션이있는 경우 웹에서 주문을받는 경우, BI를 수행하는 경우 (무엇을하든) 누가 사용하고 있는지, 어떻게 사용하는지 살펴 봐야합니다. 그것을 사용할 때, 데이터 볼륨이 무엇인지, 사용합니다. 실제로 찾으려는 것은 대기 시간입니다. 무엇이든, 모든 응용 프로그램은 사람이든 응용 프로그램이나 프로세서 간의 데이터 교환이든 관계없이 무언가를 수행하는 데 걸리는 시간으로 판단되기 때문입니다. 병목 현상은 무엇입니까? 물론 문제를 디버깅하려고 할 때 실제 병목 현상이 무엇인지 살펴 보려고합니다. 모든 것을 조정하는 방법은 아니지만 대기 시간을 늘리고 성능을 높이는 방법은 무엇입니까? 그리고 처리량 –보고자하는 모든 것.
또한 데이터 캡처, 트랜잭션, 데이터베이스의 변환 측면 및 분석을 분리해야합니다. 각각의 디자인 패턴은 서로 다르고 각각의 사용 패턴이 다르며 각각 다르게 조정해야합니다. 따라서이 데이터의 사용 방법, 사용시기, 사용 대상에 대해 생각하고 성능 지표와 해당 사용량과 관련하여 분석하려는 주요 사항이 무엇인지 파악해야합니다. 이제 성능 모니터링을 볼 때 데이터베이스 작업 자체를 보려고합니다. 데이터 구조, 데이터베이스의 인덱스, 파티셔닝 및 기타 물리적 측면, 심지어 ER 모델이든 차원 모델이든, 구조적이든 상관없이 데이터베이스의 구조까지 살펴보고 싶을 때 모든 것이 성능에 영향을 미칩니다. 특히 데이터 캡처 분석의 다양한 컨텍스트와 발생하는 변환에서.
그리고 Robin이 SQL 측에서 언급했듯이 이러한 데이터베이스에서 서로 다른 응용 프로그램이 실행하는 SQL을 살펴보고이를 조정하는 것이 중요합니다. 그리고 전체 애플리케이션 워크로드와 이러한 데이터베이스 및 애플리케이션이 실행되는 인프라 환경을 살펴보십시오. 따라서 네트워크, 서버, 클라우드 (실행중인 모든 서버)가 이러한 응용 프로그램 및 데이터베이스가 해당 컨텍스트에 미치는 영향을 살펴보면 데이터베이스를 튜닝 할 수있는 상호 작용이 있습니다.
마지막으로 도구를 볼 때 이와 관련된 세 가지 다른 종류의 분석을 볼 수 있기를 원합니다. 데이터베이스 및 애플리케이션 성능과 관련하여 발생하는 상황과 위치를 설명하는 분석을보고자합니다. 진단 분석을 수행하여 발생하는 상황뿐만 아니라 발생하는 이유, 병목 현상이 발생한 위치, 문제가있는 위치, 잘 실행되고있는 이유, 그렇지 않은 이유를 파악할 수 있기를 원합니다. 그러나 디자인이나 필요한 모든 것을 해결하기 위해 문제 영역을 분석하고 드릴 다운 할 수 있습니다.
마지막으로 가장 공격적이거나 능동적 인 분석 유형은 실제로 예측 분석, 예측 분석 모델링 등을 수행하는 것입니다. 우리는 데이터베이스와 애플리케이션이 이러한 맥락에서 작동한다는 것을 알고 있습니다. 용량을 늘리면, 더 많은 사용자를 확보하고, 더 많은 처리량을 수행하거나, 무엇을하고 있는지, 무엇을 어떻게, 어떻게, 어디에서 계획 할 수 있는지 데이터베이스, 응용 프로그램에 영향을 미치면 병목 현상이 발생한 위치, 대기 시간이 발생할 수있는 위치 및 문제를 해결하기 위해 수행해야하는 작업을 사전에 계획하고 파악할 수 있습니다. 따라서이 세 가지 유형의 분석에서와 같이 성능 지표를 구현하고 성능을 모니터링 할 수있는 도구가 필요합니다. 그리고 그것은 나의 개요입니다.
Eric Kavanagh : 알겠습니다. 두 가지 훌륭한 프리젠 테이션입니다.이 글을 Bullett Manale에게 건네 주겠습니다. 여러분, 좋은 질문을하는 것을 잊지 마십시오. 이미 좋은 내용이 있습니다. 가져 가세요, 불릿
Bullett Manale : 잘 들립니다 . 고마워, 에릭 그래서 Rick이 말한 많은 것들과 Robin은 분명히 100 %에 동의합니다. 나는이 슬라이드를 끌어 올렸다고 말하고 싶습니다. 왜냐하면 그것이 적절하다고 생각하기 때문에, 80 년대에 "A- 팀"팬인 팬들에게는 잘 모르겠습니다. 존 한니발 스미스는 항상 “계획이 모이면 마음에 들어요.”라고 말하면 특히 SQL Server에 대해 이야기 할 때 초점을 맞출 부분, 즉 오늘 이야기 할 제품인 SQL 진단 관리자는 반드시 필요한 것 중 하나입니다. 보유한 데이터를 활용하고 해당 데이터에서 의사 결정을 내릴 수 있어야하며, 경우에 따라 의사 결정을하지 않을 수도 있습니다. 자원이 부족할 때, 자원이 부족할 때, 병목 현상이 발생할 때, 그런 종류의 것들을 알려줄 무언가를 찾고 있습니다.
특정 측정 항목을 모니터링하는 것이 아닙니다. 따라서 진단 관리자를 사용하면 매우 잘 수행되는 작업 중 하나가 예측 및 작업 부하에 대한 이해 측면에서 도움이 될 것입니다. 오늘날 많은 것들에 대해 이야기 할 것입니다. 이 도구는 데이터 관리자, DBA 또는 연기 DBA에 적합하므로 Rick이 언급 한 많은 것들이 연기 DBA에 해당됩니다. 많은 경우에 DBA가 아닌 경우 SQL 환경을 관리 할 때 알아야 할 많은 물음표가 생길 것입니다. 그래서 당신은 당신을 도울 무언가를 찾고, 그 과정을 안내하며, 그 과정에서도 당신을 교육합니다. 따라서 이러한 종류의 의사 결정에 사용하는 도구가 이러한 결정이 내려진 이유에 대한 통찰력을 제공하는 것이 중요합니다. 이는“이봐, 이렇게해라”고 말하는 것이 아닙니다.
나는 연기 DBA이기 때문에 결국에는 해당 전문 지식과 지식을 갖춘 본격적인 DBA가 될 수 있습니다. 즉, 데이터베이스 관리자에 대해 이야기 할 때는 항상이 슬라이드를 먼저 보여 주어야합니다. 왜냐하면 DBA는 다른 역할을 수행하고있는 조직에 따라 다른 역할을하기 때문입니다. 그것들은 장소마다 다를 것입니다 – 그러나 일반적으로, 당신은 항상 당신의 스토리지, 그 스토리지의 계획 및 예상에 대한 이해에 대해 어떤 식 으로든 책임을 져야합니다. 백업용이든 데이터베이스 자체 용이든 필요합니다. 이를 이해하고 평가해야합니다.
또한 필요에 따라 사물을 이해하고 최적화 할 수 있어야하며, 환경 모니터링을 진행할 때 다음 사항에 따라 변경이 필요한 것이 분명합니다. 환경 자체 내에서 변화. 따라서 예측을 수행 할 때는 사용자 수, 응용 프로그램의 인기도, 데이터베이스의 계절 성과 같은 사항을 모두 고려해야합니다. 그런 다음, 결정을 내리는 데 필요한 보고서와 정보를 제공 할 수 있다는 점에서 다른 것을 분명히 살펴보십시오. 많은 경우에 비교 분석을하는 것을 의미합니다. 즉, 특정 측정 항목을 구체적으로보고 해당 측정 항목의 가치가 시간이 지남에 따라 어떤 가치를 지녔는 지 이해할 수 있으므로 앞으로 나아가는 곳을 예측할 수 있습니다.
따라서 진단 관리자가 수행하는 많은 도구에는 이러한 기능이 있으며 사람들은 매일 예측과 같은 작업을 수행하기 위해이를 사용하며 용량 계획의 정의를 여기에 넣었습니다. 그리고 그것은 매우 광범위하고 실제로는 모호한 정의입니다. 조직에서 제품에 대한 변화하는 요구를 충족시키기 위해 필요한 생산 능력을 결정하는 프로세스 일 뿐이며, 하루가 끝날 무렵 그것은 그것이 전부입니다. 어떤 식 으로든 다른 정보를 가지고 정보를 수집하고 데이터베이스 수명주기를 진행할 때 도움이되는 결정을 내릴 수 있습니다. 따라서 사람들이이를 수행해야하는 이유는 무엇보다도 돈을 절약하기위한 것입니다. 분명히 비즈니스의 주된 목표는 돈을 벌고 돈을 저축하는 것입니다. 그러나 그 과정에서 중단 시간이 없는지 확인할 수 있습니다. 또한 다운 타임 발생 가능성을 완화 할 수 있기 때문에 발생하지 않기 시작한 후 이에 대응하는 것으로 시작하지 않도록하십시오.
전체적으로 사용자 생산성을 향상시킬 수있을뿐만 아니라 더 많은 비즈니스를 수행 할 수 있도록보다 효율적으로 만드는 것이 여기의 핵심이므로 DBA 또는 예측 또는 용량과 관련된 사람의 유형입니다. 계획은 정보를 통해 결정을 내릴 수 있어야합니다. 그리고 전반적으로, 이것은 돈뿐만 아니라 시간, 그리고 일반적으로 다른 것들에 사용될 수있는 일반적으로 자원 측면에서 낭비를 제거하는 데 도움이 될 것입니다. 따라서 폐기물을 제거 할 수 있으므로 폐기물 자체와 관련된 기회 비용이 없습니다.
그렇다면, DBA 담당자와 관련하여 어떤 유형의 질문을 받습니까? 언제 공간이 부족합니까? 그것은 지금 얼마나 많은 공간을 소비하고 있을까요? 트렌드와 과거의 역사를 바탕으로 언제 소진 될까요? 어떤 서버를 통합 할 수있는 실제 SQL 인스턴스 인 데이터베이스도 마찬가지입니까? VM에 일부를 추가하려고합니다. 어떤 데이터베이스를 통합 할 것인지, 어떤 SQL 인스턴스가 있어야하는지에 대한 의미는 무엇입니까? 이러한 모든 유형의 질문에 대답 할 수 있어야합니다. 대부분의 경우, DBA이거나 DBA로 활동하는 경우 경력에서 언젠가이를 통합 할 것입니다. 많은 경우에 당신은 그것을 지속적으로 할 것입니다. 따라서 추측 할 때 게임을 추측하지 말고 신속하게 결정을 내릴 수 있어야합니다.
우리는 병목 현상과 그 다음에 일어날 위치에 대해 이야기했으며, 병이 일어나기를 기다리지 않고 다시 한 번 예측할 수있었습니다. 따라서 우리가 이야기하고있는 모든 것은 분명히 과거 데이터에 의존하고 있으며, 대부분의 경우 이러한 권장 사항을 생성하거나, 어떤 경우에는 스스로 결정을 내릴 수 있다는 의미에서 의미가 있습니다. 이 답변을 생각해 낼 수 있습니다. 그러나 유가 증권을 판매하는 누군가를위한 라디오 광고를들을 때 또는 그와 같은 것들이 항상 "과거의 성과는 미래의 결과를 나타내는 것이 아니라"고 생각합니다. 그리고 여기서도 마찬가지입니다. 이러한 예측 및 분석이 100 %가 아닌 상황이 발생할 수 있습니다. 그러나 과거와 현재 알려진 일을 처리하고 이러한 많은 유형의 질문으로 "만약"을 수행하고 수행 할 수 있다면 매우 가치가 있습니다. 추측 게임을하는 것보다 훨씬 더 많은 것을 얻을 수 있습니다.
따라서 이러한 유형의 질문은 분명히 나올 것입니다. 따라서 진단 관리자를 통해 이러한 많은 질문을 처리하는 방법은 무엇입니까? 먼저 예측 기능이 있으며 데이터베이스, 테이블 에서이 작업을 수행 할 수 있습니다. 드라이브 또는 볼륨으로. "이봐, 우리는 공간이 꽉 찼다"라고 말할 수있을뿐 아니라 지금부터 6 개월, 지금부터 2 년, 지금부터 5 년 후, 예산을 책정한다면 얼마나 많은 드라이브 공간을 이용할 수 있을까요? 예산이 필요하십니까? 그 질문은 제가 물어야 할 질문이며, 손가락을 공중에 올려 놓고 바람이 부는 방식을 기다리는 것보다 그 방법을 사용해야 할 것입니다. 불행히도 이러한 결정을 많이 내리는 방식은 여러 번입니다.
또한, 내 슬라이드가 약간 잘린 것처럼 보이지만 권장 사항의 형태로 약간의 지원을 제공 할 수 있습니다. 따라서 메트릭으로 가득 찬 대시 보드를 표시하고 "OK, 여기에 모든 메트릭과 위치가 있습니다"라고 말할 수 있지만, 일부를 이해하거나 이해할 수 있어야합니다. 이를 기반으로해야 할 일은 또 다른 도약입니다. 그리고 어떤 경우에는 사람들이 그러한 결정을 내릴 수 있도록 DBA의 역할에 대해 충분히 교육을 받았습니다. 도구에 몇 가지 메커니즘이 있습니다.이 메커니즘에 도움이 될 것입니다. 그러나 권장 사항이 무엇인지 보여줄뿐만 아니라 그 권장 사항이 작성된 이유에 대한 통찰력을 제공 할 수 있으며, 경우에 따라서는 실제로 자동화를 수행하는 스크립트를 만들 수도 있습니다. 이 문제의 해결도 이상적입니다.
우리가 보게 될 다음 단계로 넘어 가면, 그것은 일반적으로 메트릭 레벨까지의 이해를 말하는 것입니다. 정상이 무엇인지 모른다면 정상이 아닌 것을 말할 수 없습니다. 따라서이를 측정 할 수있는 방법이 있으므로 여러 유형의 영역을 고려할 수 있어야합니다. 예를 들어 시간 프레임 (서로 다른 서버 그룹)을 동적으로 수행 할 수 있어야합니다. 즉, 한밤중이나 유지 관리 기간 동안 경고 관점에서 볼 때, 진행중인 모든 유지 관리를 기반으로 CPU가 80 %에서 실행될 것으로 예상합니다. 따라서 활동이 많지 않은 시간대 나 시간대에 임계 값을 높이고 싶을 수도 있습니다.
이러한 환경은 분명히 환경적인 것이지만 관리 대상에 적용 할 수 있고 환경을보다 효율적으로 관리하고보다 쉽게 수행 할 수 있도록하는 것입니다. 분명히 다른 영역은 이러한 유형의 "가정 (what if)"질문에 대답 할 수 있도록 보고서와 정보를 전체적으로 제공 할 수있는 것입니다. 방금 환경을 변경 한 경우 그 영향이 무엇인지 이해하여 환경의 다른 인스턴스 나 다른 데이터베이스에 동일한 변경 내용을 적용 할 수 있습니다. 마음의 평화로 변화를 이룰 수 있고 좋은 변화가 될 것이라는 것을 알기 위해 정보 나 탄약을 가질 수 있기를 원합니다. 따라서 비교보고를 수행하고 SQL 인스턴스 순위를 매기고 데이터베이스를 서로 순위를 정할 수 있습니다 (예 : "가장 높은 CPU 소비자는 누구입니까?") 대기 조건과 같은 것들? 따라서 많은 정보가 도구와 함께 제공 될 것입니다.
마지막으로, 어떤 상황이든 다룰 수있는 툴이 필요한 전반적인 능력 일뿐입니다. 대부분의 경우, 특정 상황에 따라 DBA가 경우에 따라 모니터링하려는 메트릭이 아닌 메트릭이 아닌 메트릭을 가져와야하는 상황에 처하게 될 수 있습니다. 따라서 확장 가능한 도구를 사용하면 추가 메트릭을 추가 할 수 있고 기본 제공 방식을 사용하는 경우와 동일한 형식과 방식으로 이러한 메트릭을 사용할 수 있습니다. 예를 들어 따라서 보고서를 실행하고, 경고하고, 기준을 세울 수 있습니다. – 우리가 이야기하는 모든 것 –이 예측을 수행하고 원하는 답변을 얻을 수 있도록하는 데 중요한 부분입니다. 이러한 결정을 내릴 수 있습니다.
이제 진단 관리자가이를 수행하는 방식에 중앙 집중식 서비스, 실행되는 서비스 그룹이 있으며 2000에서 2016 개의 인스턴스에 대한 데이터를 수집합니다. 그리고 우리가하는 일은 데이터를 가져 와서 중앙 저장소에 넣은 다음, 그 데이터로 할 일은 명백히 더 많은 통찰력을 제공 할 수 있도록하는 것입니다. 이제 그 외에도 – 여기에없는 것 중 하나 – 우리는 한밤중에 실행되는 서비스를 제공합니다.이 서비스는 예측 분석 서비스이며 약간의 크 런칭을 수행하고 이해하는 데 도움이됩니다. 이러한 유형의 권장 사항을 작성하고 기준선에 대한 통찰력을 제공 할 수 있도록 DBA 또는 DBA 역할을 수행하는 데 도움이됩니다.
제가하고 싶은 것은 아키텍처의 간단한 예일뿐입니다. 여기서 중요한 것은 실제로 관리중인 인스턴스에있는 에이전트 나 서비스가 없다는 것입니다. 그러나 내가하고 싶은 것은 실제로 여기 응용 프로그램으로 이동하여 빠른 데모를 제공하는 것입니다. 그리고 나도 나가서 그렇게하도록하겠습니다. 에릭이라고 생각합니다. 알 겠어요?
에릭 카바나 흐 : 지금 알았습니다.
Bullett Manale : 알겠습니다. 제가 말씀 드린 여러 가지 부분을 살펴 보겠습니다. 그리고 본질적으로 여기에 나와있는 것들부터 시작해보아야 할 것이 있습니다. 또는 여기에 미래의 시점이되는 것이 있습니다. 그리고 우리는 당신에게 그에 대한 통찰력을 줄 것입니다. 그리고 이것은 실제로 일어나고있는 일들을 실제로 예상하거나 동적으로 예측해야합니다. 이제 보고서의 경우 도구에 포함 된 것 중 하나는 세 가지 예측 보고서입니다. 예를 들어 데이터베이스 예측의 경우 일정 기간 동안 데이터베이스의 크기를 예측할 수있는 상황에서 수행 할 작업은 몇 가지 예를 제공합니다. . 따라서 감사 데이터베이스를 가져와야합니다. 감사 데이터베이스는 많은 I / O 집약적입니다. 많은 데이터가 필요합니다. 우리는 여기서 보도록하겠습니다. 여기에서 헬스 케어 데이터베이스를 선택하겠습니다.
하지만 요점은 공간이 무엇인지보고있는 것이 아니라“작년의 데이터를 보도록하겠습니다”라고 말할 수 있다는 것입니다. 실제로 1 년 분량의 데이터가없고 약 2 개월 분량의 데이터가 있습니다. 그러나 여기서는 몇 달의 샘플 속도를 선택하기 때문에이를 예측하거나 예측할 수 있습니다. 표본 비율이 한 달, 즉 한 달, 한 달로 설정되어 있기 때문에 다음 36 개 단위를 설정 한 다음 기본적으로 미래 성장을 예상 할 수있는 위치를 보여주는 보고서를 실행할 수 있습니다. 세 데이터베이스. 그리고 우리는 서로 다른 세 데이터베이스 사이, 특히 역사적으로 소비하는 데이터의 양에 따라 다양한 정도의 차이가 있음을 알 수 있습니다.
여기에서 데이터 포인트가 과거 데이터를 나타내는 것을 볼 수 있습니다. 그런 다음 라인은 예측을 제공하는 숫자와 함께 해당 수치를 백업합니다. 따라서 테이블 수준에서이를 수행 할 수 있으며, 드라이브 수준에서도이를 수행 할 수 있으며 마운트 지점을 포함하여 드라이브의 용량이 얼마나 커질 지 예상 할 수 있습니다. 동일한 유형의 정보를 예측할 수 있지만 샘플 속도에 따라 다시 한 번 몇 개의 단위와 예측 대상을 가져갈 지 결정할 수 있습니다. 다른 유형의 예측 유형도 있습니다. 따라서 예측을 수행 할 때 많은 옵션과 유연성을 얻을 수 있습니다. 이제는 실제로 특정 날짜를 제공하고 "이 날짜에 데이터의 성장을 예측할 수있는 곳입니다."라고 말할 수있는 한 가지 방법입니다. 근무 외 시간에 수행 한 분석 및 서비스 실행시 수행되는 일부 분석과 관련된 기타 통찰력을 제공합니다. 그것이하는 것 중 일부는 과거에 일어난 일의 역사에 근거하여 일어날 가능성이있는 것을 예상하려고하는 것입니다.
우리는 여기에서 실제로 볼 수 있습니다. 예측은 과거에 다시 한 번 일어났던 일들에 기초하여 저녁 내내 문제가 발생할 가능성에 대한 통찰력을 제공합니다. 따라서, 이것이 DBA가 아닌 경우에 특히 좋으며, 이것들을 볼 수 있지만, DBA가 아니라면 더 나은 것이이 분석 탭입니다. 이 도구가 여기에 오기 전에 우리는 사람들에게 제품을 보여주고 보여줄 것입니다.“좋습니다.이 숫자들을 모두보고 있습니다. 모든 것을 보지만 어떻게해야할지 모르겠습니다.”(웃음) "그 결과로."따라서 우리가 여기있는 것은 성능 향상을 위해 조치를 취하려고한다면, 심지어 내가 조치를 취하려고한다면 더 잘 이해할 수있는 방법입니다. 내 환경의 건강을 돕고, 권장 사항을 제공하는 순위가 매겨진 방법뿐만 아니라 해당 권장 사항에 대해 자세히 배우고 실제로 해당 데이터 중 일부에 대한 외부 링크를 갖는 정보의 유용한 팁을 얻을 수 있습니다. 이러한 권장 사항이있는 이유를 알려주세요.
그리고 많은 경우에, 내가 말했듯이 이러한 문제의 해결을 자동화하는 스크립트를 제공 할 수 있습니다. 이제이 분석을 통해 우리가하고있는 일의 일부 –이 인스턴스의 속성을 구성하려고 할 때와 분석 구성 섹션으로 갈 때를 보여 드리겠습니다. 여기에 나열되고 그 일부에는 인덱스 최적화 및 쿼리 최적화가 있습니다. 그래서 우리는 메트릭 자체뿐만 아니라 워크로드 및 인덱스와 같은 것들을 평가하고 있습니다. 여기서는 실제로 몇 가지 추가 가상 인덱스 분석을 수행합니다. 따라서 많은 경우에 필요하지 않은 경우 색인을 추가하고 싶지 않은 상황 중 하나입니다. 그러나 어떤 시점에서는 일종의 팁 포인트가 있습니다.“글쎄요, 테이블이 워크로드 내에서 실행되는 쿼리의 크기 나 유형에 따라 인덱스를 추가하는 것이 합리적입니다. 그러나 아마도 6 주 전에는 말이되지 않았을 것입니다.”따라서, 내가 말했듯이 환경에서 발생하는 일, 작업 부하 내에서 발생하는 일을 기반으로 성능을 향상시킬 수있는 것에 대한 통찰력을 동적으로 얻을 수 있습니다. 그런 종류의 일을하고 있습니다.
따라서 여기에서 많은 정보를 얻을 수있을뿐만 아니라 이러한 것들을 자동으로 최적화 할 수 있습니다. 이것이 바로 예측 분석이라는 측면에서 우리가 도울 수있는 또 다른 영역입니다. 이제 그 외에도, 일반적으로 의사 결정을 돕는 데 도움이되는 다른 영역도 있습니다. 또한 의사 결정에 대해 이야기 할 때 다시 한 번 기록 데이터를 볼 수 있으면 성능 향상에 필요한 위치를 파악할 수있는 통찰력을 제공합니다.
이제 우리가 할 수있는 것 중 하나는 원하는 기준을 선택하여 선택할 수있는 기준선 시각화 기능을 가지고 있다는 것입니다. 여기에서 적절한 메트릭을 찾을 수 있도록하겠습니다. SQL CPU 사용량에 대해 설명하겠습니다. 그러나 몇 주를 거슬러 올라가서이 그림을 페인트하여 특이 치가 언제 있는지, 일반적으로 데이터를 수집 한 기간 내에 해당 값이 어디에 속하는지 알 수 있습니다. 그리고 그 외에도 실제 인스턴스 자체로 나가면 기준선을 구성 할 수 있습니다. 그리고 기준선은 사물을 자동화하고 사물을 알 수있는 데있어 정말 중요한 부분입니다. 그리고 대부분의 DBA가 말하듯이 문제는 하루 종일, 저녁과 비교하여 항상 같은 환경을 유지하는 것이 아니라는 점입니다. 높은 수준의 CPU 또는 발생할 수있는 모든 것이 있습니다.
따라서이 실제 기준선과 함께 여기에 여러 기준선이있을 수 있으므로 예를 들어 유지 관리 시간 동안의 기준선이있을 수 있습니다. 그러나 생산 시간에 대한 기준을 쉽게 만들 수있었습니다. 그리고 그 시점은 SQL 인스턴스에 들어가서 실제로 여러 기준선을 가지고있을 때, 자동화, 복구 또는 일반적인 경고를 예측하고 수행 할 수 있다는 것입니다. 시간의 창에 따라 다릅니다. 여기에서 볼 수있는 것 중 하나는 우리가 생성하는 기준이 이력 데이터를 사용하여 해당 분석을 제공하는 것이지만, 더 중요한 것은 이러한 임계 값을 정적으로 변경할 수 있지만 동적으로도 자동화 할 수 있다는 것입니다. 따라서 유지 관리 기간 또는 유지 관리 기준 창이 표시되면 이러한 임계 값은 해당 기간 동안 발생하는 부하에 따라 자동으로 전환됩니다. 워크로드에 영향을 미치지 않는 경우만큼 많지 않습니다.
따라서 기준과 관련하여 염두에 두어야 할 것이 있습니다. 분명히 이것들은 당신에게 정말 도움이 될 것입니다. 정상적인 것을 이해하고 이해할 수 있고, 자원이 부족할 때 참여하십시오. 자, 도구에 포함 된 다른 종류의 결정은 결정을 내리는 데 도움이 될뿐만 아니라 기준선과 기준선 및 동적으로 생성하는 임계 값에 대해 경고를 설정할 수있는 기능입니다. 무슨 일이 일어나고 있는지에 대한 질문에 대답하는 데 도움이되는 수많은 보고서를 실행할 수 있습니다.
예를 들어, 내가 관리하고있는 150 개의 인스턴스가있는 경우 (내 경우에는 그렇지 않은 경우) 여기서 척 게임을해야합니다. 그러나 모든 프로덕션 인스턴스가 있고 어디에 있는지 이해해야하는 경우 즉, 주의를 기울여야 할 영역, 즉 성능 향상을 위해 특정 유형의 관리를 수행하는 데 시간이 제한되어 있다면 핵심 영역에 집중하고 싶습니다. "그 환경에 따라 인스턴스를 서로 순위를 매기고 경합 파이프별로 순위를 부여합니다."디스크 사용량, 메모리 사용량, 대기 여부 등 응답 시간이든 관계없이 이러한 인스턴스를 서로 연관시킬 수 있거나 순위를 말해야합니다. 분명히 각 목록의 맨 위에있는 인스턴스 (동일한 인스턴스 인 경우)는 목록의 맨 위에 다시 한 번 있기 때문에 내가 실제로 집중하고 싶은 것일 수 있습니다.
따라서 도구에 인스턴스 수준에서 환경 순위를 결정하는 데 도움이되는 많은 보고서가 있습니다. 데이터베이스 수준에서도이 작업을 수행 할 수 있습니다. 여기서 데이터베이스를 서로 비교할 수 있습니다. 특히 임계 값과 설정할 수있는 영역에 대해서는 원하는 경우 특정 데이터베이스에만 초점을 맞추기 위해 여기에 와일드 카드를 설정할 수도 있지만 요점은 데이터베이스를 동일한 방식으로 비교할 수 있다는 것입니다. 또한 다른 유형의 비교 분석과이 도구의 가장 큰 분석은 기본 분석입니다. 여기에서 서비스보기로 스크롤하면 기준 통계 보고서가 있음을 알 수 있습니다. 이제이 보고서는 측정 항목 값이 무엇인지 이해하는 데 도움이 될뿐만 아니라 특정 인스턴스에 대해 나가고 이러한 측정 항목에 대해 이러한 측정 항목의 기준을 실제로 확인할 수 있도록 도와줍니다.
그래서, 그것이 무엇이든, 나가서 나갈 수있는 비율 또는 무엇이든, “지난 30 일 동안 이것에 대한 기준선을 보자”고 말하면 실제 값과 기준선을 보여줄 것입니다. 나는 그 정보를 사용하여 어떤 결정을 내릴 수 있었을 것입니다. 그래서 이것은 어떤 질문인지, 당신이 당시에 묻는 질문에 따라 달라지는 상황 중 하나입니다. 그러나 이것은 분명히 많은 질문에 도움이 될 것입니다. 나는 우리가 모든 것을 수행하는 하나의 보고서를 가지고 있다고 말할 수 있기를 바랍니다. 그리고 그것은 당신이 누르는 버튼과 같은 쉬운 보고서와 비슷하며, 당신이 대답 할 수있는 모든“만약”질문에 답합니다. 하지만 실제로는 풀다운 메뉴에서 선택할 수있는 많은 속성과 옵션을 통해 원하는 "만약"유형의 질문을 공식화 할 수 있습니다. .
따라서 이러한 많은 보고서는 이러한 유형의 질문에 대답 할 수 있도록 설계되었습니다. 따라서, 앞서 언급 한 바와 같이 이러한 보고서와 툴에서 이미 보여 드린 모든 내용, 새로운 측정 항목을 통합하고 관리 할 수있는 유연성, 폴링 간격에 통합 된 카운터 또는 SQL 쿼리를 통해 이러한 질문에 대한 답변을 얻을 수 있습니다. 모니터링하지 않을 것으로 예상되는 경우 해당 항목을 추가 할 수 있습니다. 그런 다음 방금 보여 드린 것과 같은 모든 작업을 수행 할 수 있습니다. 기준선, 보고서 실행 및 해당 메트릭에서 보고서를 작성하고 내가 보여주고있는 다양한 유형의 작업에 응답하고 수행 할 수 있습니다. 여기.
이제 그 외에도 – 최근에 우리가 겪었던 것 중 하나는 – 모두가 VM으로 전환하거나 전환하는 것입니다. 그리고 지금 우리는 많은 사람들이 클라우드로 향하고 있습니다. 그리고 이런 종류의 것들에 관해 많은 질문이 있습니다. 클라우드로 전환하는 것이 이치에 맞습니까? 클라우드로 이동하여 비용을 절약 할 수 있습니까? VM, 공유 리소스 머신에 이러한 것들을 넣으면 얼마나 많은 돈을 절약 할 수 있습니까? 이러한 유형의 질문은 분명히 나올 것입니다. 따라서 많은 정보를 염두에두고 진단 관리자를 사용하여 VMware 및 Hyper-V의 가상화 된 환경을 추가하고 가져올 수 있습니다. 또한 클라우드에있는 인스턴스를 추가 할 수 있으므로 Azure DB (예 : RDS)와 같은 환경에서도 해당 환경에서 메트릭을 가져올 수 있습니다.
따라서 사람들이 떠나는 다른 유형의 환경과 관련하여 많은 유연성과 이러한 질문에 대답 할 수있는 능력이 많이 있습니다. 그리고이 문제에 대해서는 여전히 많은 질문이 있으며, 우리는 사람들이 그러한 환경을 통합하는 것을 볼 때 그러한 질문에 대답 할 수 있어야합니다. 이것이 바로이 주제와 관련된 진단 관리자의 개요입니다. 비즈니스 인텔리전스의 주제가 떠 올랐으며 오늘날 우리가 이야기하지 않은 비즈니스 인텔리전스 도구도 있지만 이러한 유형의 질문에 대한 통찰력을 제공 할 것입니다. 큐브와 다양한 유형의 것들도 마찬가지입니다. 그러나이 제품이 좋은 계획을 세우는 데 어떻게 도움이 될 수 있는지에 대한 관점에서 이것은 좋은 개요였습니다.
에릭 카바나 : 좋습니다. 그래, 릭이 아직 거기 있다면 버리 겠어 릭, 질문 있어요?
Rick Sherman : 그렇습니다. 처음에는 훌륭합니다. 마음에 듭니다. 특히 VM과 클라우드로 확장하는 것이 좋습니다. 많은 앱 개발자들이 클라우드에 있다면 튜닝 할 필요가 없다고 생각합니다. 그래서-
Bullett Manale : 그렇습니다. 우리는 여전히 비용을 지불해야합니까? 사람들이 클라우드에 올리는 것에 대한 비용을 여전히 지불해야하므로 제대로 실행되지 않거나 CPU주기가 많이 발생하면 지불해야하는 돈이 더 많으므로 그렇지 않습니다. 여전히이 물건을 절대적으로 측정해야합니다.
Rick Sherman : 예, 클라우드에서 많은 좋지 않은 디자인을 보았습니다. 이 제품도 사용할 수 있는지 묻고 싶었습니다. BI 제품에 대해 언급했으며 서로 상호 작용하는 수많은 다른 제품이 있지만이 도구에서 SQL 성능, 개별 쿼리를 살펴 볼까요? 아니면 다른 도구일까요?
Bullett Manale : 아니요. 절대적으로 그렇습니다 . 그것은 내가 다루지 않았고 의도했던 것 중 하나입니다. 쿼리 성능을 식별하는 방법에는 여러 가지가 있습니다. 특히이 뷰에서 볼 수 있듯이 대기하거나 전체 쿼리의 리소스 소비와 관련이 있는지 여부는 쿼리를 분석 할 수있는 다양한 방법이 있습니다. 공연. 지속 시간, CPU, I / O 여부에 관계없이 워크로드 자체를 검토하여 통찰력을 제공 할 수도 있습니다. 분석 섹션에서 권장 사항을 제공하고 쿼리 자체에 대한 정보를 제공하는 웹 기반 버전도 있습니다. 따라서 누락 된 인덱스와 실행 계획 및 모든 종류의 항목을 볼 수있는 기능에 대한 권장 사항을 얻을 수 있습니다. 또한 기능이기도합니다. 따라서 절대적으로 쿼리를 일요일에 이르는 7 가지 방법으로 진단 할 수 있으며 (웃음) 실행 횟수, 리소스 소비, 대기 시간, 지속 기간, 모든 좋은 항목에 대한 통찰력을 제공 할 수 있습니다.
Rick Sherman : 좋습니다. 그런 다음이 모든 모니터링을 통해 인스턴스 자체의 부하는 무엇입니까?
Bullett Manale : 좋은 질문입니다. 그 질문에 대답하는 것의 도전은 그것이 다른 것과 똑같다는 것입니다. 우리의 도구가 제공하는 많은 기능은 유연성을 제공하며 유연성의 일부는 수집 할 것과 수집하지 않을 것을 알려줍니다. 예를 들어 쿼리 자체를 사용하면 대기 정보를 수집 할 필요가 없습니다. 실행 시간을 초과하는 쿼리와 관련된 정보를 수집 할 수 있습니다. 예를 들어, 구성 쿼리 모니터로 이동하여 "이 값을 0으로 변경합시다"라고 말하면 실제로는 기본적으로 도구가 실행되는 모든 쿼리를 수집하게되므로 실제로는 그렇지 않습니다. 그것이 왜 존재하는지에 대한 정신이지만, 일반적으로 모든 쿼리에 대한 전체 데이터 샘플을 제공하고 싶다면 그렇게 할 수 있습니다.
따라서 설정이 일반적으로 말하는 것과 관련이 있습니다. 약 1 ~ 3 %의 오버 헤드가 발생하지만 다른 조건이 적용됩니다. 또한 환경에서 얼마나 많은 포트 쿼리가 실행되고 있는지에 따라 다릅니다. 또한 해당 쿼리를 수집하는 방법과 SQL 버전에 따라 다릅니다. 예를 들어, SQL Server 2005에서는 확장 된 이벤트를 가져올 수 없지만 추적에서 끌어 올 수는 없습니다. 우리가 그 데이터를 수집하는 방식에 있어서는 조금 다를 것입니다. 그러나 제가 말했듯이, 우리는 2004 년 이래로이 제품으로 추측 해 왔습니다. 오랜 시간이 지났고 수천 명의 고객이 있었으므로 마지막으로해야 할 일은 성능 문제를 일으키는 성능 모니터링 도구입니다 (웃음). 우리는 가능한 한 그것을 피하려고 노력하지만 일반적으로 말하자면 약 1 ~ 3 %가 좋은 경험 법칙입니다.
Rick Sherman : 좋습니다. 아주 낮습니다. 대단합니다.
에릭 카바나 흐 : 좋습니다. 로빈, 질문 있어요?
Robin Bloor : 죄송합니다. 음소거 상태였습니다. 여러 데이터베이스 기능이 있으며 여러 데이터베이스를 볼 수 있으므로 더 큰 리소스 기반이 다양한 가상 시스템 등으로 나뉘어져 있음을 알 수 있습니다. 사람들이 실제로 어떻게 사용하는지에 관심이 있습니다. 고객이 그 일을하고있는 것에 관심이 있습니다. 그것이 데이터베이스를 망칠 때, 나는 결코 손에 넣지 않았던 것을 분명히 알기 때문입니다. 그리고 주어진 시점에서 의미있는 방식으로 하나의 인스턴스 만 고려할 것입니다. 그래서 사람들은 이것을 어떻게 사용합니까?
Bullett Manale : 일반적으로 툴 자체에 대해 이야기하고 있습니까? 그들은 그것을 어떻게 사용하고 있습니까? 제 말은 일반적으로 환경의 중심점을 가질 수 있다는 것입니다. 마음의 평안을 가지고 화면을 쳐다보고 녹색이 보이면 모든 것이 좋다는 것을 알고 있습니다. 문제가 발생하고 DBA의 관점에서 대부분의 경우가 콘솔 앞에있을 때 문제가 발생하는 경우가 많으므로 문제가 발생하자마자 알림을받을 수 있습니다. 그러나 그 외에도 문제가 발생한시기를 이해하고 문제가 발생하는 이유에 대한 정보를 제공하는 정보의 핵심에 도달 할 수 있습니다. 그래서 그것이 가장 큰 부분이라고 생각합니다.
제가 이야기하는 대부분의 DBA는 – 그리고 그 비율이 좋은 비율입니다 – 불행히도 여전히 반응 형 환경에 있습니다. 소비자가 소비자에게 접근하여 문제가 있음을 알리기를 기다립니다. 그래서, 우리는 많은 사람들이 그것으로부터 벗어나려고 노력하는 것을 봅니다. 저는 이것이이 도구를 좋아하는 사람들이 그들이 능동적으로 행동하는 데 도움이되지만 그들에게 무슨 일이 일어나고 있는지에 대한 통찰력을 제공하기 때문이라고 생각합니다., 문제는 무엇입니까, 그러나 많은 경우에, 적어도 우리가 찾은 것 – 아마도 우리에게 이것을 알려주는 것은 단지 DBA 일뿐입니다 – 그러나 DBA는 인식이 응용 프로그램을 작성한 응용 프로그램 개발자라도 항상 문제입니다 제대로 작성하지 않은 사람은 그 응용 프로그램을 시스템이나 서버로 가져 가서 성능이 나빠질 때 모두가 DBA를 지적하기 때문에 책임을 져야 할 사람들입니다. "이봐 당신 잘못이야."
따라서이 도구는 DBA가 다음과 같이 말하는 데 도움이 될 것입니다.“이봐, 이것이 문제가있는 곳이고 내가 아닙니다.”(웃음) 우리는 쿼리를 변경하거나 무엇이든간에이를 향상시킵니다. 어떤 경우에는 책임의 관점에서 버킷에 빠질 것이지만, 적어도 이해하고 이해하도록 도울 수있는 도구를 갖추어야하며 적시에 수행하는 것이 분명히 이상적인 접근 방식입니다.
Robin Bloor : 예. 제가 알고있는 대부분의 사이트이지만 여러 멀티 데이터베이스 사이트를 살펴본 이후로 오랜 시간이 지났지 만 주로 내가 찾던 사이트는 소수의 데이터베이스에 중점을 둔 DBA. 그리고 그것들은 데이터베이스 일 것입니다. 만약 그들이 다운 되었다면 그것은 비즈니스에 큰 문제가 될 것입니다. 다른 하나는 통계를 수집하고 공간이 부족하지 않았으며 전혀 보지 않을 것입니다. 그리고 당신이 데모를하고있는 동안 나는 이것을보고 있었고 어떤 식 으로든 잘 생각하고있었습니다. 데이터 증가가 있기 때문에 아무도 신경 쓰지 않는 데이터베이스에 대해 이와 같은 것을 제공함으로써 확장됩니다., 그들은 때때로 응용 프로그램 성장이 있습니다. 당신은 상당히 극적인 방식으로 DBA 적용 범위를 확장하고 있습니다. 이것이 바로 문제입니다. 이와 같은 도구 세트를 사용하면 회사 네트워크에있는 모든 데이터베이스에 DBA 서비스를 제공 할 수 있습니까?
Bullett Manale : 당연히, 문제는, 당신이 꽤 설득력있게 말했듯이, DBA가 관심을 갖는 데이터베이스가 있고 관심이없는 데이터베이스가 있다는 것입니다. 이 특정 제품의 라이센스 방식은 인스턴스별로 다릅니다. 사람들이“이 도구를 사용하여 관리하고 싶은 중요한 인스턴스는 아닙니다.”라고 결정하는 임계 값이 있다고 생각합니다. 우리가하는 다른 도구가 있습니다. 그보다 덜 중요한 SQL 인스턴스를 제공한다고 생각합니다. 그 중 하나는 인벤토리 관리자와 비슷하지만 인스턴스에 대해 상태를 약간 검사하지만 검색 이외에도 온라인 상태가 된 새로운 인스턴스를 식별하고, DBA로서 다음과 같이 말할 수 있습니다.“여기 SQL의 새로운 인스턴스가 있습니다. 이제 Express입니까? 무료 버전입니까, 아니면 엔터프라이즈 버전입니까?”이 질문은 저 자신에게 묻고 싶은 질문 일 수 있습니다. 그러나 둘째, 그 인스턴스가 나에게 얼마나 중요한가? 그것이 중요하지 않다면이 도구를 사용하여 일반적인 일을 수행 할 수 있습니다. 일반적인 건강 검사라고 부르는 것은 내가 DBA로 관심을 갖는 요소 유형의 요소라는 의미에서 일반적인 건강 검사라고 부릅니다. ? 서버가 문제에 응답하고 있습니까? 주요한 것 맞지?
방금 보여 드린 도구 인 Diagnostic Manager를 사용하면 쿼리 수준으로 내려 가서 인덱스 권장 사항으로 내려 가서 실행 계획과 모든 좋은 것들을 살펴볼 것입니다. 누가 무엇을 소유하고 무엇을 소유하고 누가 책임지고 있습니까? 어떤 서비스 팩과 핫픽스가 있습니까? 그리고 서버가 SQL의 정상적인 인스턴스라고 생각하는 주요 구성 요소로 실행됩니까? 따라서 귀하의 질문에 대답하기 위해 약간의 혼합이 있습니다. 이 도구를보고있는 사람들이 있으면 일반적으로보다 중요한 인스턴스 집합을보고 있습니다. 즉, 우리는 모든 인스턴스를 구매하고 관리하는 사람들이 있으므로 그 방법에 따라 다릅니다. 그러나 전반적으로 말하면, 환경을 관리하는 데 이와 같은 도구를 갖추기에 충분한 환경이 중요하다고 생각하는 사람들에게는 한계가 있습니다.
로빈 블로어 : 알겠습니다. 에릭에게 건네주기 전에 또 다른 질문입니다. 업계를 관찰하면서 얻은 인상은 데이터베이스에는 여전히 수명이 있지만 모든 데이터가 이러한 모든 데이터 레이크 등으로 쏟아지는 것입니다. 그것은 과대 광고이며, 과대 광고는 결코 현실을 반영하지 않으므로, 나는 당신이 어떤 현실을 인식하고 있는지에 관심이 있습니까? 조직 내 중요한 데이터베이스가 기존 데이터 증가를 경험하고 있습니까? 제가 매년 10 %로 생각 했습니까? 아니면 그 이상으로 성장하고 있습니까? 빅 데이터가 이러한 데이터베이스를 풍선처럼 만들고 있습니까? 당신이 보는 그림은 무엇입니까?
Bullett Manale : 사용 가능한 다른 기술이있을 때 일부 데이터가 다른 세그먼트로 이동하는 것을보고있는 경우가 많다고 생각합니다. 최근에는 더 큰 데이터가 있습니다. 그러나이 데이터베이스는 모든 사람이 조금씩 다르기 때문에 많은 경우에 일반화하기가 어렵습니다. 그러나 일반적으로 말하면, 나는 약간의 차이점을 봅니다. 내가 말했듯이 사람들은 다른 분야에서는 그리 많이 자원을 늘리고 싶지 않기 때문에 많은 경우 탄성 모델로 이동하고 있습니다. 일부 사람들은 빅 데이터로 이동하고 있습니다. 그러나 일반적으로 내가 말하는 모든 사람들은 전통적인 데이터베이스를 가지고 있으며 SQL Server 환경에서 이것을 사용하기 때문에 인식을 느끼기가 어렵습니다.
즉, SQL 자체로 말하면 여전히 시장 점유율이 높아지고 있다고 생각합니다. 그리고 저는 Oracle과 같은 다른 곳에서 SQL로 향하고있는 사람들이 여전히 많다고 생각합니다. 왜냐하면 SQL 버전이 더욱 발전함에 따라 더 저렴하고 분명해 보였기 때문입니다. 암호화 및 환경 또는 데이터베이스 플랫폼으로 만드는 다른 모든 기능 측면에서 SQL을 계속 진행하고 있습니다. 그래서 우리도 그것을보고 있다고 생각합니다. 당신이 변화를보고있는 곳에서도 여전히 일어나고 있습니다. 내 말은 10 년 전에 일어 났지만 여전히 환경이 성장하고 시장 점유율이 증가하고있는 SQL Server와 관련하여 발생하고 있다고 생각합니다.
로빈 블로어 : 좋아, 에릭, 나는 청중에게 한두 가지 질문이 있다고 생각 하는가?
에릭 카바나 흐 : 네, 한 가지 빠른 것을 당신에게 넘겨 드리겠습니다. 사실 꽤 좋은 질문입니다. 참석자 중 한 명이 묻습니다.이 도구는 쿼리 속도를 높이기 위해 테이블에 인덱스가 필요한지 알려줍니다. 그렇다면 예를 보여줄 수 있습니까?
Bullett Manale : 예, 인덱스를 구체적으로 추가하기위한 인덱스가 있는지 모르겠지만 여기에서 볼 수 있습니다. 여기에는 조각화 권장 사항이 있습니다. 또한 우리가 방금 가지고 있다고 믿고 이것이 웹 기반 버전을 제공하는 진단 관리자의 일부였으며 여기서 색인이 누락되었다고 알려줍니다. 이러한 권장 사항을 볼 수 있으며 해당 정보를 인덱싱하여 잠재적 인 이익을 얻을 수 있습니다. 내가 언급해야 할 또 다른 사항은 권장 사항을 수행 할 때 대부분의 경우 스크립트가 작성된다는 것입니다. 좋은 예는 아니지만 인덱스 (중복 인덱스 또는 인덱스 추가)가 성능을 향상시키는 상황을 볼 수있을 것입니다. 앞에서 말씀 드린 것처럼 가정 인덱스 분석을 통해 따라서 작업 부하를 이해하는 데 도움이되고 권장 사항에 적용 할 수 있습니다.
에릭 카바나 흐 (Eric Kavanagh) : 정말 대단한데, 여기에 마지막 의견에 대한 좋은 소식이 나옵니다. Robin과 I 및 Rick도 수년 동안 자체 튜닝 데이터베이스에 대해 이야기하고 있습니다. 자체 튜닝 데이터베이스입니다! 내가 당신에게 말할 수있는 것은 : 그들을 믿지 마십시오.
Bullett Manale : 과대 광고를 믿지 마세요.
에릭 카바나 흐 (Eric Kavanagh) : 동적으로 수행되는 작은 일들이있을 수 있지만, 그것을 확인하고 원하지 않는 일을하고 있지 않은지 확인하고 싶을 수도 있습니다. 그래서 꽤 오랫동안 데이터베이스 수준에서 무슨 일이 일어나고 있는지 이해하기 위해 이와 같은 도구가 필요합니다. Robin이 말했듯이 데이터 레이크는 매혹적인 개념이지만, 아마도 그보다 더 많은 가능성이 있습니다. 곧 Loch Ness Monster가 있습니다. 다시 한 번 말하지만, 실제 세계에는 많은 데이터베이스 기술이 있습니다. 우리는 이러한 것들을보고 합성하기 위해 사람, DBA가 필요합니다. 당신은 말할 수 있습니다, 당신은이 물건을 작동시키기 위해 무엇을하고 있는지 알아야합니다. 그러나 현재하고있는 일을 알기위한 정보를 제공하는 도구가 필요합니다. 결론은 DBA가 제대로 작동한다는 것입니다.
IDERA의 Bullett Manale과 친구들에게도 감사합니다. 그리고 물론 Rick Sherman과 Robin Bloor도 있습니다. 우리는 이러한 웹 캐스트를 모두 보관하므로 온라인에서 anaanalysis.com 또는 파트너 사이트 www.techopedia.com을 방문하여 자세한 내용을 확인하십시오.
그리고 우리는 여러분에게 작별 인사를 할 것입니다. 다시 한 번 감사드립니다. 다음에 연락 드리겠습니다. 조심해 안녕.
