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