작성자 : Techopedia Staff, 2016 년 11 월 30 일
테이크 아웃 : 호스트 인 Eric Kavanagh와 Dr. Robin Bloor, Dez Blanchfield 및 IDERA의 Bullett Manale과 함께 쿼리가 효율성에 미치는 영향에 대해 논의합니다.
현재 로그인하지 않았습니다. 비디오를 보려면 로그인 또는 가입하십시오.
에릭 카바나 흐 : 신사 숙녀 여러분 안녕하세요, 다시 한 번 환영합니다. 수요일 오전 4시 (동부 표준시)로 요즘 핫 테크놀로지의 시간입니다! 네 확실합니다. 우리는 오늘 멋진 것들에 대해 이야기하고 있습니다. 물론, 나는 당신의 호스트 Eric Kavanagh입니다. 오늘 공연의 제목은“유효한 분석의 열쇠 : 빠른 귀환 쿼리”입니다. 여러분, 우리 모두는 금식을 원합니다. 누가 빨리 원하지 않습니까? 당신에 대해, 그리고 나에 대해 충분히 슬라이드가 있습니다. 트위터 (@eric_kavanagh)에서 연락주세요. 나는 거기에서 당신과 연결하고 소셜 미디어에서 대화를 드리겠습니다. 재미있을 수 있습니다. 정치를 말하지 마십시오.
올해는 더워요. 우리는 올해 다양한 분석 문제에 대해 이야기하고 있으며 오늘날의 주제는 실제로 작업을 수행하는 데있어 핵심적인 부분입니다. 나는 누군가가“데이터와 대화를한다”라는 표현을 처음 사용한다고 들었을 것입니다. 아마도 약간의 치즈 소리가 들릴지라도 요점은 반복적 인 경험을 할 수 없다면 요점입니다. 데이터를 신속하게 수정하지 못하고 새 쿼리를 보내고 응답을 빠르게 받으면 데이터와 대화하지 않고 전체 분석 프로세스가 잘립니다. 그 좋지 않다.
당신이 당신의 데이터와 대화를 할 때, 그 의미는 당신이 앞뒤로 갈 수 있고 내 의견으로는 통찰력을 찾을 수 있다는 것입니다. 처음에는 완벽한 쿼리를 거의 만들지 않기 때문입니다. 분석의 모차르트가 아니라면 (사람이 이미 있다고 확신하지 않는 한) 수정, 측정 기준 추가, 원하는 내용을 미세 조정하기 위해 시간을 소비해야합니다. .
다시 말하지만, 이는 분석 세계에서 다루고있는 엄청나게 거친 환경이 아니기 때문입니다. 우리는 다루기 힘든 환경과 매우 복잡하고 다차원적인 환경을 다루고 있습니다. 오늘날 웹 캐스트의 전체 아이디어는 데이터와의 반복적 인 상호 작용을 가능하게하는 방법에 대해 이야기하는 것입니다.
발표자가 3 명 있습니다. 물론, Hot Technologies에서는 브리핑 실과 달리 두 명의 분석가가 있습니다. 그들은 각자 먼저 테이크 아웃을하고 손님은 들어와 프레젠테이션을하고 원탁 회의를합니다. 그리고 여러분, 우리의 청중은 그것에 큰 역할을 할 수 있습니다. 부끄러워하지 마십시오. 언제든지 질문을 보내십시오. 가능하면 Q & A 패널을 사용하십시오. 그렇지 않으면 채팅 패널이 정상입니다. 공연하는 동안 둘 다 모니터하려고합니다. 그리고 우리는 이것을 기록하므로, 당신이 무언가를 놓치거나 동료와 공유하고 싶다면 나중에 다시 오십시오. Techopedia.com과 InsideAnalysis.com에 게시합니다.
이를 통해 똑똑한 사람들을 데려 올 것입니다. 로빈 블로어 박사에게 전달하겠습니다. 그에게 열쇠를주고 발표자를 바꾸고 거기로 가겠습니다. 로빈, 가져가
로빈 블로어 : 알겠습니다. 소개해 주셔서 감사합니다. 약 한 달 반 전에 실제로 DBA 인 개발자와 대화를 나 had습니다. 그는 실제로 DBA가 아닙니다. 특정 회사의 DBA였으며 실제로 쿼리를 수행 할 수있는 유일한 사람이었습니다. 그러나 그는 실제로 그렇게 똑똑한 개발자이기 때문에 그렇게 아프게되었습니다. 그래서 그는 떠났다.
그리고 그는 어쨌든 그들을 위해 매달 며칠을 할 필요가 있습니다. 왜냐하면 그들은 자신의 자리를 대신 할 사람을 찾을 수 없었고 데이터베이스가 무엇을 수행하는지 또는 그것을 어떻게 튜닝 할 것인지 전혀 알 수 없었기 때문입니다. 그리고 저는 그것에 대해 일종의 생각을하고 있었으며, 실제로 IT 부서는 없었지만이 사람이 그들을 지원하고있었습니다. 실제로, 그는 대부분의 시간 동안 DBA 작업을 수행했습니다.
Oracle, SQL Server, DB2와 같은 모든 고가의 데이터베이스와 같은 정교한 데이터베이스의 경우 데이터베이스 조정은 어려운 작업입니다. 안전한 직업이기도합니다. 그리고 이것이 사실이라고 말하는 이유는 변화하는 풍경입니다. 좀 이걸하겠습니다. 관계형 데이터베이스 – 일반적으로 큰 그림은 관계형 데이터베이스가 여전히 인기를 얻고 있다는 것입니다. 그들은 오랫동안 오게 될 것입니다. 예, 더 많은 방송 시간을 확보 할 수있는 다른 데이터베이스가 있습니다.하지만 실제로 어떤 일이 벌어지고 있는지, Oracle이 가장 많은 일을하고 있고, Microsoft SQL Server가 두 번째이며, 클라우드에는 여러 가지 일이 있습니다. 그러나 도전을 일으킬 수 있습니다. 그들은 게임에서 큰 거인입니다. 또한 OLTP 및 실제로 데이터웨어 하우스 워크로드에 모두 사용할 수있는 데이터베이스입니다. 대안은 일반적으로 주로 분석 환경에서 사용되며 일반적으로 데이터가 관계형이 아닌 왜 선택하는지에 따라 결정됩니다. 대부분 사람들은 그렇지 않습니다.
회사는 단일 데이터베이스에서 표준화하는 경향이 있습니다. 최근에 5, 000 개가 넘는 Oracle 인스턴스가있는 회사를 방문했습니다. 그리고 저는 그 회사와 이야기를 나누는 사람에게 DBA에 대해 물어 보았습니다. 그들은 약 10 개의 DBA를 가지고 있고 약 30 개의 데이터베이스가 조사되고 있다고 말했다. 나머지는 오라클이 전반적으로 최종 시스템으로 사용하고있었습니다. 데이터를 사용한 응용 프로그램의 데이터에는 거의 스트레스가 없었습니다. 그러나 5, 000 개에 달하는 Oracle 인스턴스가 놀랍습니다.
그런데, 그들은 Oracle Estate 라이센스를 가지고있었습니다. 회사 라이센스는 분명히 알 것입니다. 그러나 때로는 다른 응용 프로그램에도 응용 프로그램에 기본 데이터베이스가 제공되기 때문에 다른 데이터베이스가 있습니다. 오라클 만이 유일한 것은 아니 었습니다. 그리고 Hadoop이나 Spark도 실제로 데이터베이스가 아니며 데이터베이스 규칙으로 생각하는 것을 얻는 데 오랜 시간이 걸릴 것입니다. 물론 데이터 링크에 좋습니다.
DBA 활동을 사용하면 아마도 Bullett이 나보다 이것에 대해 더 많은 것을 말할 수 있습니다. 그러나 나는 그저 그것들을 살펴볼 것입니다. 이것들은 DBA가하는 일에 대해 내가 생각하는 경향이 있습니다. 라이센스 관리를 설치, 구성, 업그레이드하고 수행합니다. 그들은 많은 방식으로 많은 ETL 및 복제 작업을 수행합니다. 스토리지 및 용량 계획을 수행합니다. 문제를 해결하거나 문제 해결 팀의 일원입니다. 성능 모니터링 및 튜닝은 대부분의 활동이지만, 이 모든 다른 것들은 작지 않습니다. 보안은 백업 및 복구를 담당합니다. 소프트웨어 테스트 시스템과 데이터 수명주기에 관여해야합니다.
공연. 내가이 사람들 중 한 사람이었을 때. 데이터베이스를 실행하고 조정할 때 이것이 내가 이해 한 방식이었습니다. CPU가 있고, 오늘날 우리는 CPU가 거의 유휴 상태입니다. 왜냐하면 다른 두 개 중 하나 일 것이기 때문입니다. 글쎄, 다른 병목 현상 중 하나는 실제로 문제를 일으킬 것입니다. 네트워크의 여러 노드에서 실행 중이고 실제로 일부 잠금이 발생할 수있는 경우 메모리, 스 래싱 및 조각화, 디스크 또는 디스크 I / O 포화 (네트워크 오버 헤드).
그러나 내가 본 세상은 바로 세상이었습니다. 최근 Oracle과 Oracle에있는 튜닝 매개 변수 수를 살펴 보았습니다. 당신은 알고 있습니다. 그리고 실제로 그것에 대해 생각한다면, 그가하고있는 것을 실제로 아는 DBA는 왜 당신이 그 중 하나를 엉망으로 만들 것인지에 대한 아이디어를 가져야합니다. 그래서 그것은 복잡한 일입니다. 아시다시피 더 복잡합니다.
아시다시피, 지금 우리는 CPU를 가지고 있지만, 이미 존재하는 CPU, CPU의 GPU 또는 CPU의 FPGA를 가지고 있습니다. 따라서 실제로 CPU에서 일어나는 일에 대한 일종의 크로스 브리딩이 있습니다. CPU는 오래 전에 멀티 코어가되었습니다. 실제로, 나는 더 이상 데이터베이스를 튜닝하지 않았습니다. 나는 그것이 실제로 어떤 차이를 가져 왔는지 전혀 모른다.
우리는 3D Xpoint와 IBM의 PCM이 추가 메모리 계층으로 올라오고 SSD를 가지고 있지만, 그들은 녹슬고 있다는 것을 알고 있습니다. 그러나 SSD는 속도가 다를 수 있습니다. 너무 많은 경우 병렬 액세스가 가능하며 RAM 속도에 근접하여 매우 빠릅니다. 그리고 모든 병렬 하드웨어 아키텍처가 있습니다.
그리고 이것이 전부입니다. 비용이 떨어지고 있습니다. 정말 좋은 일이지만, 이것이 전부입니다. 다음 릴리스의 데이터베이스를 가져 와서 머신에서 구현하기 시작하면 지연 시간이 매우 다르기 때문에 실제로 데이터가 동작하는 방식에 대한 장의 느낌을 잃어 버렸습니다. 여기에는 3 개의 스토리지 계층이 아닌 4 개의 계층이 있습니다.
데이터베이스 문제. 데이터베이스 엔트로피를 얻습니다. 인스턴스 확산이 매우 일반적입니다. 찬장으로 사용되는 데이터베이스는 실제로 제가 제시 한 예입니다. 자체 튜닝되는 데이터베이스는 거의 없으며 자체 튜닝이라고 주장하는 데이터베이스는 실제로 그렇게 좋지 않습니다. 그러나 다른 하나는, 거의 튜닝 된 데이터베이스가 거의 없다는 것입니다. 워크로드의 균형을 맞출 수있는 힘든 작업입니다. 즉, 데이터베이스에 대해 생각할 때 24 시간 동안 데이터베이스가 수행하는 작업의 경우 작업량이 매우 달라질 수 있습니다. 데이터베이스에는 특히 진정한 데이터웨어 하우스가 있어야합니다.
따라서 튜닝이 사소한 문제가 아니라는 것을 알고 있습니다. 왜냐하면 특정 시점에 걸쳐 전체 범위의 워크로드를 수용해야하는 파라미터를 튜닝하는 것이기 때문입니다. 기본적으로 힘든 일입니다. SQL은 특히 SQL JOIN에 맞게 조정해야합니다. 리소스 소비가 극도로 클 수 있습니다. 그리고 데이터베이스가 구체화 된 관점을 가지고 있다면, 솔직히 말해서, 모든 것을 엄청나게 빠르게 만들 수 있기 때문에 그 사용을 조사해야합니다. 그리고이를 위해서는 워크로드를 이해하고 SQL 트래픽 등을 이해하는 사람이 필요합니다.
그리고 대부분의 회사는 DBA를 거의 사용하지 않고 매우 비쌉니다. 저는 3 명의 사람들과 같이 상당히 큰 회사를 알고 있습니다. 실제로, 그들은 비용이 많이 들고, 복잡성 측면에서 어려운 일입니다. 그들은 도구가 필요합니다.
그리고 그것이 내가해야 할 전부라고 생각합니다. 오 예. 데즈에게 손을 뻗어 보자.
Dez Blanchfield : 감사합니다, Robin. 이것은 거대한 주제입니다. 저는 우리가 직면하는 실질적인 일상 과제라고 생각하는 것들을 계속 유지하려고합니다. 그것을 직시하자면, 이 주제에 관한 책의 전체 라이브러리가 있습니다. 기술 서점에 가지 않은 사람은 데이터베이스 성능 및 데이터베이스 튜닝 및 모니터링에 대한 일반적인 주제로 작성된 서적과 벽을 발견했습니다. 때로는 시간을 낭비하는 좋은 방법입니다.
일반적인 주제 : 성능 쿼리 받기 이 주제를 땀 나게하는 조직의 여러 부분이 있습니다. 최종 사용자 수준에서 제 경험상 사람들은 단지 성능을 경험하고 상황이 느리다는 것을 알고 있습니다. 물레가 쿼리를 다시받는 데 시간이 걸립니다. 스펙트럼의 반대쪽 끝에는 데이터베이스 전문가가 예상대로 실행하지 않고 있기 때문에 데이터베이스 전문가가 이길 수있는 인프라 및 네트워크 및 스토리지 엔지니어링 인력이 있습니다. 그리고 그것은 내 경험상 그 스펙트럼에서 우리의 삶에 영향을 줄 수있는 것들의 매우 광범위한 스펙트럼입니다.
물리적 공간에서 컴퓨터 공간 만 생각하면됩니다. 디스크 공간, 네트워크 및 그 주위의 모든 비트-원하는 경우 메모리, RAM이 있습니다. 이 공간에는 원시 디스크 나 JBOD를 사용하는 것이 낫다는 생각이 담겨 있습니다. 가능한 한 빨리 디스크를 높이고 데이터베이스는 데이터 보호 계층을 정렬합니다. 다른 사람들은 저렴한 디스크의 중복 배열 인 RAID의 열성 팬이며, 하드 디스크에 장애가 발생할 경우 RAID 0, 1, 3, 때로는 5 및 6의 다른 유형의 스트라이핑 또는 복제와 관련하여 종교적인 경험이 다릅니다. 스토리지 수준과 엔지니어링 수준에서도 여전히 스토리지 유형에 대한 성능에 대해 다른 견해와 경험을 가진 사람들이 있습니다.
직접 연결된 디스크와 서버 자체인지 또는 어떤 형태의 저장 영역 네트워크와 파이버 채널을 통해 연결되어 있는지 여부, 예를 들어 iSCSI를 통해 서버에서 마운트 된 저장소인지 이더넷인지 여부 그리고 실제로 데이터베이스 계층에 도달하기 전에, 우리가 당연한 것으로 생각하는 것들 – Eric이 설명한 것처럼, 우리가 데이터와의 대화라고 부르는 것을 그대로 유지하면됩니다. . 우리가 다이빙을 시작하고 성능 문제를 찾을 수 있다고 생각하는 패턴과 의미있는 패턴을 식별 할 수 있습니다.
그리고 그것은 매우 광범위한 주제이므로, 경험과 시간, 에너지와 노력이 좋은 수익을 얻는 두 가지 영역으로 뛰어들 것입니다. 먼저이 중 첫 번째 항목으로 바로 건너 뛰겠습니다. 그리고 나는 반 농담으로 내부에 골격이 있고 외부에 피부가있는 무언가의 사진을 찾기 위해 갔지만 Lego 블록은 아마도 가장 소름 끼칠 것입니다. 그러나 여러면에서 이것은 분석 플랫폼과 데이터베이스를 지원하는 데이터베이스에서 종종 직면하는 문제를 상상하고 정신적으로 묘사하는 방법입니다. 그리고 그것은 오직 소비자와 최종 사용자 또는 개발자 인 경우에만 종종 베니어 스킨 레이어를 볼 수 있지만 실제로는 그 아래의 골격입니다. 실제로 초점을 맞춰야하는 문제입니다.
이 경우 특정 날짜에 발생한 데이터베이스 성능 및 분석, 성능 저하, 핵심 인프라 및 핵심 인프라 모니터링에 영향을 미칠 수있는 사항에 대해 생각할 때 디스크와 메모리 및 CPU. Robin Bloor 박사가 강조한 것처럼, 가상화 및 칩 자체에서 발생하는 일, 코어 수준까지의 성능 및 각 코어의 각 칩에 저장되는 메모리의 양에 대한 과제가 해결되었습니다. 이들은 일상적인 사람을 찾아야 할 매우 기술적 과제입니다.
쿼리 모니터링을 유지합니다. 쿼리 및 쿼리 큐 모니터링과 관련된 문제 중 하나는 예를 들어, 언어로서의 SQL 및 분석 도구와 함께 제공되는 데이터베이스 도구는 매우 강력하며 특히 언어로는 SQL입니다. 그러나 그 강력 함과 단순함은 많은 경우에옵니다. 즉, 동일한 개발자가 반복해서 같은 일을하는 응용 프로그램이 아니라면 좋은 개발자가 작성하고 좋은 DBA가 발견 한 응용 프로그램이라면 구조화되지 않은 쿼리를 수행하는 사람들입니다.
그리고 그 문제는 약간의 SQL을 배우고 쿼리를 시작하는 것이 매우 쉽지만, 그 결과로, 당신이하고 있는지 여부를 알 수있는 모든 기술과 경험과 지식을 가지고 있지는 않습니다. 데이터베이스를 수행하는 것이 좋거나 나쁜 것. 따라서 크고 똑같은 크고 잘못을 계속 실행하면 건물이 무너질 수 있습니다. 쿼리 모니터링을 유지하는 것은 흥미로운 과제입니다.
플랫폼이 수행하는 작업과 사용자가받는 작업까지 응답 시간을 모니터링하기 만하면됩니다. 다시 말하지만, 올바른 도구가 없으면 직관적 인 것으로 생각하고 "아, 네트워크 속도가 느리다"또는 "사용자 메모리가 제대로 작동하지 않음"또는 "색인이 제대로 작동하지 않는다"고 생각하는 것이 아닙니다 ”또는“팽만감”
그런 다음 문제를 발견 한 후 어떻게 분리하고 번들을 풀고 제대로 구성되지 않은 쿼리의 모든 문제를 해결하는지 어떻게 알 수 있습니까? 아시다시피, 누군가가 직접 실행하는 임시 쿼리이거나, 질문에 잘못된 방식으로 질문을했기 때문에 성능이 좋지 않은 대시 보드 프런트 엔드가있는 분석 도구이거나 실제로 정말 잘못 작성된 코드?
그리고 그 반복을 반복하면서 Eric은 처음에 셋업 과정에서 반복적으로 반복적으로 진행하고 해당 워크 플로를 미세 조정한다고 말했습니다. 내가 실행중인 워크 플로, 실행 방식, 실행 빈도, 실행중인 코드, CPU 및 메모리, 디스크 및 네트워크에서 실행중인 코드는 어디입니까? 네, 그건 정말 기술적 인 도전입니다.
그런 다음 사람들이이 세상에서 찾고있는 너바나, 과거 분석 및 성능 조정 및 환경에 대한 경고에서 벗어나는 이유가 무엇인지 아는 경우 향후 계획을 세울 수 있기 때문에보기에 좋습니다. 어제 아침 9시에. 그러나 그것은 지금 당신에게 도움이되지 않으며, 당신의 계획이 발전하는 데 도움이되지 않습니다.
용량 계획, 크기 조정, 확장 및 조정이 가능하다고 생각합니다. 현재 사람들이 큰 데이터베이스 플랫폼을 보유하고 데이터베이스 환경을 널리 퍼뜨리는 대규모 환경에서 변화가 일어나고있는 추세라고 생각합니다. 과거 경고 및 계획에서 예측 경고 및 계획에 이르기까지 현재 상황을 파악하고 향후 계획을 수립 할 수 있습니다. 아니면 메모리가 부족하고 다음 시간에 메모리가 부족해지며 어떻게해야합니까? 실시간으로 어떤 용량 계획을 수행 할 수 있습니까?
실례합니다. 이러한 장애물을 발견하는 모든 과제는 본질적으로 우리가 유동적 분석이라고하는 것을 방해하고 조직의 표준으로 삼는 지점에 도달합니다. 보시다시피, 그것은 매일 매우 크고 씻지 않은 대중들에게는 사소한 도전입니다. 그리고 기술적으로 정통한 사람에게는 여전히 쉽지 않은 과제입니다.
단순한 필사자에게 어려운 경우 어떻게 이것을 가능한 일로 만들 수 있습니까? 알다시피, 대부분의 사용자는 일반 사용자가 해결할 수없는 것들이며, 특별한 데이터베이스 엔지니어, 데이터베이스 개발자, 코드 개발자, 프로그래머가있을 수 있지만 실제로는 환경을 묶을 수 없었습니다. 사람들은 코드를 재사용하는 것과 같은 문제를 해결해야합니다.
이 공간에서 데이터베이스 서버 인프라의 대규모 배포에서 분석 플랫폼의 성능 저하와 관련하여 내가 본 최악의 사실 중 하나는 코드 조각, SQL 조각 또는 도난당한 절차를 수행하는 사람들입니다. t 코드를 작성하면 코드가 좋은지 나쁜지 알 수 없으며 원하는 결과를 얻을 수 있기 때문에 재사용 할 수 있습니다. 그러나 보고서와 같이 한두 가지 결과를 얻기 위해 즉석에서 작성된 것일 수도 있습니다. 누군가가 서두르고있었습니다.
그래서 사람들은 작성하지 않은 복잡한 코드를 사용하고 실제로 백엔드를 처벌하고 있다는 사실을 알지 못하고 응용 프로그램 개발 과정에 넣었습니다. 성능 저하를 모니터링하고 쿼리가 어디에서 나오는지 살펴보고 드릴 다운하는 것조차도 일상적인 과제입니다.
가능한 경우 성능을위한 사전 준비 데이터와 같은 기본 동작. 대량 가져 오기를 수행 한 다음 인덱스를 다시 색인화하려는 경우 인덱스를 삭제하는 것과 같이 경험이 많은 것만으로도 테라 바이트 단위의 데이터를 가져올 때 인덱스가 유지되지 않습니다. 적절한 도구가 없으면 색인이 망치는 것을 모르기 때문에 거의 볼 수 없습니다.
정기적으로 인덱스를 최적화하는 것은 일종의 101이지만 대량 가져 오기를 수행 할 때 또는 누군가가 실제로 큰 쿼리를 수행하는 경우 쿼리에 테이블을 생성하는 것은 어떻습니까? 알다시피, 그것은 엄청난 성능 저하가 될 수 있으며 다시 모니터링하지 않으면 그것을 볼 수있는 도구가 없으며 그러한 종류의 배경은 백그라운드에서 발생하며 해결 방법을 모릅니다 .
쿼리를 필요한 수의 열로 제한 – 실제로는 기본적으로 들리지만 다시 볼 수 없다면, 그것이 발생하고 있다는 것을 알지 못하고 백그라운드에서 발생하여 아프게됩니다., 너에게.
임시 테이블을 언제 어디서 사용할지 알면서 대량의 삭제 및 업데이트를 일괄 처리합니다. 다시 말하지만, 매우 간단한 일이지만 그 가시성없이 도구를 사용하지 않으면 백그라운드에 앉아서 계속 아프고 데이터베이스 환경에서 더 많은 메모리 또는 CPU를 던져 더 나은 분석 플랫폼 성능을 얻을 수 있습니다. 실제로 당신은 당신을 해치는 것의 세부 사항을 뚫고 그 특정한 것을 다룰 수 있어야합니다. 그러면 외래 키 제약 조건과 같은 것들을 어떻게 알 수 있으며, 그것이 어떻게 문제인지 어떻게 알 수 있습니까?
그것은 나의 핵심 요점으로 결론을 이끌어 주며, 그것은 매일 매일 우리가 이러한 문제들을 모든 곳에서 보게된다는 것입니다. 그리고 데이터베이스 환경이 점점 더 넓어지고 넓어짐에 따라 Dr. Robin Bloor가 강조한대로 데이터베이스 시간이 점점 더 복잡한 환경 모델을 얻게됩니다.
그리고 Hadoop 및 Spark와 같이 점점 더 많은 빅 데이터 플랫폼에 통합해야 할 필요성이 점점 커지고 있습니다. 이 실시간 플랫폼 성능과 분석 및 진단을 지능적으로 수행 할 수있는 더 나은 방법과 특정 도구를 찾는 것이 우리의 생각입니다. 우리가 이러한 일에 뛰어 들기 위해 도구를 사용하지 않으면 최종 사용자와 실제 비용에 대한 실시간 및 실제 비용과 좌절이 발생하기 때문입니다.
그리고 저는이 문제를 어떻게 해결할 수 있을지에 대해 이야기 할 좋은 이야기가 있다고 생각하기 때문에 IDERA에서 친구들에게 넘겨 줄 것입니다.
Bullett Manale : 잘 들립니다 . 대단히 감사합니다. 계속 진행하겠습니다. 여기에도 몇 가지 슬라이드가 있으며, 계속 진행해 보겠습니다. 이것들 중 일부는 우리가 꽤 빨리 뛰어 넘을 것입니다.
통찰력을주기 위해 저는 IDERA의 영업 엔지니어링 담당 이사입니다. 우리가하는 일은 DBA와 정기적으로 DBA와의 고통과 도전에 대해 꽤 많은 이야기를하는 것입니다. 성능 모니터링 및 그와 같은 것들이 있습니다. 그리고 우리는 그 청중으로부터 많은 이야기를 듣습니다. 그래서 저는 그들이받는 정보를 정기적으로 공유 할 수 있다고 생각합니다. 나는 그들이 대화에 실제로 관련이 있다고 생각하지 않기 때문에 몇 가지를 뛰어 넘을 것입니다.
알다시피, 여기 DBA의 책임에 대한 내 자신의 목록이 있습니다. 그것은 Robin의 목록과 매우 비슷하며 꽤 일관성이 있다고 생각합니다. 데이터베이스 관리자와 대화 할 때는 항상 그렇습니다. 다른 영역보다 이러한 영역에 더 집중되어 있기 때문에 운율이나 이유가 없으며 환경에 따라 다릅니다.
사람들이하고 싶어하는 상당히 넓고 광범위한 것들을들을 수 있습니다. 그리고 많은 경우에, 이러한 것들을 원하는 사람들은 원하지 않습니다 – 그들은 그것을 요구할 것이고, 어떤 경우에는 그들이 실제로 요구하는 것에 대해 일종의 시추를 시작한 다음, 정말 더 많은 것을 찾고 있습니다. 그들은 처음에 필요하다고 생각하는 것보다 더 많은 정보를 원하며, 도구로 드릴을 시작하면 데이터와 대화하고 있다고 말할 수 있습니다.
그리고 저는 이것이 정말 흥미로운 문구라고 생각합니다. 예를 들어, 잘못된 쿼리가 있다면 실제로 나쁜 쿼리 란 무엇입니까? 많은 읽기 또는 쓰기 또는 CPU를 소비하는 쿼리입니까? 그것은 많이 실행되는 것일 수도 있고, 당신이 말한 것처럼 잘못 쓰여진 것일 수도 있습니다.
우리가 그것을 식별하는 방법과 관련하여 우리 제품, Diagnostic Manager 제품과 관련하여 볼 수있는 여러 가지 방법이 있습니다. 정말 유연하고 큰 장점 중 하나입니다. 이러한 성능 문제를 해결하는 데 도움이되는 도구가 있어야합니다. 모든 사람의 환경이 약간 다릅니다.
모니터링 측면에서 요구 사항이 많고 요구 사항이 모호 할 수 있으므로 유연하고 작동 가능한 환경을 갖추어야합니다. 당신은 관리하려고합니다. 아시다시피, 그리고 저는이 예제들을 많이 가지고 있습니다 – 나는 그것들 각각을 거치지 않을 것이지만, 당신은 하나의 데이터와 다른 것 사이에서 앞뒤로 피봇 할 수있는 무언가가 필요합니다. 우리가 제품에 조금 들어가서 그것을 보여줄 때, 그리고 우리가 그것을 어떻게하는지에 대해 이야기하십시오.
하지만 좋은 분석 도구의 관점에서 내가 생각하는 다른 것은 실제로 찾고있는 핵심 사항이 있다는 것입니다. 가장 먼저 성능 이름으로 자체 성능 문제를 일으키는 도구를 원하지 않습니다. 내가 무료로 데이터를 수집한다고 말할 때, 나는 당신이 알고있는 금전적 비용의 관점에서 비용이 아니라 오버 헤드와 비용의 측면에서 우리가 자원의 양으로 비용에 대해 이야기하고 있습니다. 성능의 이름으로 사용하려고합니다. 당신은 분명히 도움이 될만한 것을 원합니다.
당신은 당신이 일상에서 직면하는 문제에 대해 구체적으로 찾고있는 데이터를 얻을 수있는 무언가가 필요하며, 필요하지 않은 것과 원하지 않는 것이있을 수 있습니다. 보고하지 않거나 해당 데이터를 관리하려는 데 필요한 정보가없는 경우 해당 데이터를 수집하는 것은 의미가 없습니다. 예를 들어 성능과 관련된 메타 데이터와 관련하여.
좋은 예는 SQL의 Distributed Transaction Coordinator 서비스가 처음에 실행되고 싶지 않은 경우 다운 될 경우 경고 할 필요가 없다는 것입니다. 그러니 알려주지 말고 데이터를 수집하지 마십시오. 정보가 필요하지 않습니다. 따라서 이러한 기능을 켜고 끄는 기능이 중요합니다.
또한 일단 데이터를 수집하고 데이터에 매우 빠르게 액세스 할 수있는 기능 – 데이터를 알고, 실행 및 마사지 할 필요가 없으며, 데이터를 조작하여 데이터를 빠르고 효율적으로 수행 할 수 있습니다. 그런 다음 데이터를 확보 한 후에는이를 이해하는 것이 중요합니다.
예를 들어 오늘 소개 할 진단 관리자 제품과 같은 제품을 통해이 제품이 출시 될 예정임을 알려 드리고자합니다. 상자에 DBA를 교체하십시오. 실제로는 환경이 무엇인지, 달성하려는 내용에 대한 지식이 필요합니다. DBA 자체의 역할에 대한 이해가 분명히 중요합니다.
우리가하려고하는 것은 도움과 다른 방법을 통해 교육하는 것입니다. 그러나 항상 경험 수준의 유형이나 데이터를 수신 한 후해야 할 일에 대한 지식이있는 사람과이 관계를 맺고 싶을 것입니다. 그리고 제품에 올바른 질문을 할 수있는 사람을 확보하고 데이터와 대화하는 것이 분명히 중요합니다. 그리고 분명히 데이터를 이해할 수 있습니다.
정보를 얻은 후에는 올바른 사람들에게 정보를 전달할 수 있습니다. 내 개발자, 운영 팀 – 누구든 관계없이 다른 제품과 통합해야 할 수 있습니다. 이것들은 모두 진짜 중요한 것입니다. 그리고 마지막으로, 더 자세히 알고 싶다면 그렇게 할 수 있어야합니다. 더 많은 데이터를 수집해야하는지 또는 데이터를 조금 더 깊이 파고든다는 의미입니다. 성능을 향상시키는 도구를 사용하면 이러한 질문에 대답하는 데 필요한 모든 것을 얻을 수 있기를 바랍니다.
내가 여기에 언급하지 않은 것은 아마도 주목할 가치가 있다고 생각하는 것은, 정상과 정상이 아닌 것을 구별하는 데 도움이되는 도구가 필요하다는 것입니다. 알다시피, 많은 경고 제품과 외부에있는 것들이 있지만 경고가 표시되고 경고가 잘못된 경고 인 경우 아무런 효과가 없습니다. ; 시간 낭비가 많고 효율성을 줄이면서 도움을 줄 것입니다. 그래서, 제가 명심해야 할 것들이 있습니다.
IDERA 제품군 내에서 이러한 모든 것들을 연결하는 제품에 대해 이야기 할 때 데이터베이스와 관련하여 여기서 말하는 내용의 주요 특징이있을 것으로 생각되는 진단 관리자 제품이라고 생각합니다. 튜닝 및 성능 및 모니터링과 그와 같은 것들.
사람들은 엔터프라이즈 수준의 모니터링을 찾고 있습니다. 그들은 한 화면에서 액세스가 가능하고 상황이 제대로 작동하는지 알기를 원합니다. 또는 문제가있는 경우 분명히 문제의 위치를 확인한 다음 드릴 다운 할 수 있기를 원합니다. 제 생각에 사람들이 당신이 실제로 공연에서 연마 할 수있는 이런 유형의 방법으로 찾고있는 것의 큰 부분입니다.
분명히 그와 함께 진행되는 또 다른 것은, 나는 현재에서 작동 할 수 없으며, 제대로 실행되지 않은 쿼리를 보는 것이 든, 그것이 의미가 있는지 여부에 관계없이 일정 기간 동안 되돌아 갈 수 있어야한다는 것입니다. 호스트 VM 자체가 리소스 측면에서 동작하는 방식을 살펴보십시오. 당신이 할 수있는 모든 종류의 일들이 있고, 당신은 하루 24 시간 주 7 일 콘솔을 쳐다보고 앉아 있지 않을 것입니다.
휴가 중이거나 한밤중에 있거나 그 밖의 상황에 처한 경우 인스턴스에서 발생한 일을 말할 수 있도록 시간을 거슬러 갈 수있는 무언가가 필요합니다. 우리가 문제를 겪었던 시간. 그리고 다시 한 번, 효율적이고 신속하게이를 수행 할 수있는 것은이 논의에서 중요한 부분입니다. 그리고 사람들이 찾고있는 측면에서 가장 중요한 것 중 하나라고 생각합니다. 그들은 항상 그 창을 과거로 찾고 있습니다. 왜냐하면 그게 정말 im이기 때문입니다. 여러분은 아시다시피, 거기에 앉아 무언가가 다시 일어날 때까지 기다릴 필요가 없습니다.
목록의 다음 것은 쿼리 성능 자체를 사용하여 이전에 이야기했던 내용과 실제로 연결되는 것입니다. 그리고 저는 진단 관리자 제품 내에서 몇 가지 다른 예를 보여 드리려고합니다. 어떻게해야하는지, 하루가 끝날 무렵, 검색어 자체와 관련하여 다양한 옵션을 제공 할 것입니다. 당신은 수집하고 싶습니다.
리소스 고통, CPU 소비 또는 I / O 소비를 유발하는 쿼리에 관심이 있는지 여부와 관련하여. 완료하는 데 시간이 오래 걸리거나 일반적으로 수행되는 쿼리가 성능면에서 가장 나쁜 것은 아니지만 너무 자주 실행되어 자체 실행 빈도가 문제가 될 수 있습니다. 그리고 이러한 쿼리를 통해 시간이 지남에 따라 추세를 파악할 수있는 것도 중요한 부분입니다.
우리는이 제품 내에서 여러 가지 방법으로이를 수행 할 수 있으며, 이것이 대부분의 DBA에게 실제로 중요한 부분이라고 생각합니다. 자체 개발 한 응용 프로그램이없는 경우에도 소프트웨어 공급 업체에 문의하여“이봐 요, 무엇을 알고 있습니까? 매일 오후 2시에이 업무가 시작될 때, 또는 "이 문제를 일으키는 응용 프로그램이므로 문제를 해결해야했습니다." 코드 자체를 제어하면 문제가 발생하는 시점을 아는 것이 좋습니다.
그리고 다른 부분은 분명히 더 적극적입니다. 가장 먼저 알 수 있고 문제가 발생한시기를 이해할 수 있습니다. 가장 먼저 알아야 할 수있을뿐 아니라 정정 할 수 있지만, 많은 경우에 필요한 경우 응답을 자동화 할 수있는 경우도 있습니다. 내가 회의 중이거나 이동 중이거나 도로 또는 그 밖의 어떤 것이 든“이봐, 이 문제를 해결해야합니다.”라는 이메일을받는 것보다 말할 수 있습니다. '하고 있습니다. 자동화 된 방식으로 해결할 수있는 무언가가 있다고 말할 수있어서 매우 기쁩니다.
그리고 자동화 된 방식으로 해결되지 않으면 최소한 가장 먼저 알아볼 수 있으므로 시정 조치를 취하거나 가능한 누군가에게 연락 할 수 있습니다. 머신과 인스턴스 모니터링 및 분석 자체와 관련하여 발생할 수있는 이러한 유형의 문제는 분명히 중요합니다.
저는 이것에 대해 앞에서 이야기했습니다. 이것이 유연성입니다. 모니터링 할 수없는 것이 있거나 제품 내에 기능을 추가하여 해당 기능을 추가 할 수있는 기능을 충분히 강조 할 수는 없습니다. 모니터링됩니다. 또한 Diagnostic Manager의 예와 관련하여 WMI 카운터, 카운터, SQL Server 카운터를 통해 자체 쿼리를 만들 수 있습니다.
원하는 경우 폴링이 발생하고 정기적으로 수행 할 수있는 폴링의 결과로 vCenter 환경 또는 Hyper-V 환경에서 데이터를 가져올 수 있습니다. 해당 데이터를 가져 와서 볼 수 있습니다. 그리고 다시 한 번이 정보를 보면서 한 곳에서 다른 곳으로 피벗하십시오.
사람들이 튜닝 및 성능 측면에서 도움을 줄 도구에 대해 이야기 할 때 요구하는 관점에서 볼 수있는 것들입니다. 두 번째는 Diagnostic Manager이며, 2000 년부터 2016 년까지 모든 것을 지원합니다. SQL Server에만 해당되므로 관리 업무를 모니터링합니다. 인스턴스 자체에는 인스턴스를 모니터링하는 에이전트가 없습니다.
그것은 약간의 비용으로 정보를 수집하는 것으로 되돌아갑니다. 우리는이 정보를 더 많이 모 으려고 노력했지만 많은 자원을 사용하지 않습니까? 우리는 SQL Server가 이미 우리에게 제공하고 동적 관리 뷰인지, 확장 된 이벤트인지, 컬렉션 자체의 관점에서 무엇이든지간에이를 개선하려고 노력하고 있습니다. 그 정보를 활용하고 더 나은 정보를 만드는 것이 우리의 임무 중 하나입니다.
이제이 사실을 빠르게 살펴보면 아키텍처를 너무 자세하게 살펴 보지 않고 관리 할 수 있고 오래 유지할 수있는 모든 기록 데이터가 포함 된 백엔드 리포지토리가 있습니다. 당신이 원합니다. 보관하려는 정보 유형과 기간을 선택할 수도 있습니다. 그것은 적절한 데이터를 수집하고 불필요한 데이터를 남기지 않는 것으로 되돌아갑니다. 핵심 성과 인 5 일 동안 쿼리를 유지하고 2 년 동안 경고를 유지하려는 경우 이는 전적으로 귀하에게 달려 있으며이를 수행하는 데있어 귀하의 특권입니다.
이 제품에는 다양한 콘솔이 있습니다. 웹 기반 버전이 있고 두꺼운 클라이언트 버전도 있습니다. 브라우저에서 뛰어 내릴 수있는 유연성과 전용 클라이언트가 설치된 랩톱이있는 경우 이러한 방법 중 하나가 적합합니다.
자, 제가하고 싶은 것은 빠른 시연을하는 것입니다. 그리고 저는이 다른 슬라이드로 다시 돌아가겠습니다. 우리는 이미 제품에 익숙한 사람들을 위해 FYI로 추가했습니다. 진단 관리자 프로. Workload Analysis라고하는 것을 포함하는 전문 오퍼링.
실제로 대화 형으로 매우 큰 시간을보고 30 일보기에서 약 3 번의 클릭으로 5 분보기로 전환 할 수 있습니다. 그리고 성능의 급상승 또는 병목 현상에서 발생할 수있는 병목 현상을 매우 높은 수준으로보고 매우 낮은 수준으로 드릴 다운 할 수 있습니다. 특히 오늘날에도이 제품은 새로운 기능입니다.
그러나 내가하고 싶은 것은 단지 시작부터 시작하는 것입니다. 나는 그 선회와 전후에 대해 조금 이야기하고 싶습니다. 예를 들어서 여기 화면에서 공유하겠습니다. 그리고 보자 … 우리가 간다. 내 화면. 그리고 당신이 그것을 볼 수 있음을 알려주세요.
에릭 카바나 흐 : 거기 있습니다.
Bullett Manale : 저기 괜찮아? 좋구나. 여러분이 지금보고있는 것은 – 이것은 진단 관리자 제품입니다. 여기서는 현재 진행되고있는 것에 대한 일종의 높은 수준의 데모를 보여 드리고자합니다. 이 특정 예에서 우리가하는 일은 대기와 관련된 쿼리를 보여주는 것입니다. 그리고 내가 앞뒤로 움직일 수있는 것에 대해 이야기 할 때, 더 깊게 드릴 다운하고 피벗 팅을하는 것입니다. 여기이보기가 좋은 예입니다. 여기서 볼 수있는 타임 라인보기에서 지금 볼 수 있습니다. 우리의 경우에 우리는 대기 자체와 대기 자체의 범주를보고 있습니다. 우리는 그러한 대기와 관련된 진술을 볼 수 있으며, 응용 프로그램을 볼 수 있습니다.
여기가 타임 라인보기에 있으므로 문제가 발생한 시점을 기준으로 정보를 선형으로 식별 할 수 있지만, 다시 한 번 피벗을 원하면 다음과 같이 말하십시오. "이것은 다른 관점에서 볼 것입니다."계속해서 "이 문제를 가장 많이 유발하는 쿼리 나 대기 또는 응용 프로그램을보고 순위를 매기고 싶습니다." “지속 시간에 따른 쿼리 대기 시간”으로 다시 볼 것입니다. 이제 우리는 저에게 가장 많은 고통을 주거나 대기하는 응용 프로그램 자체를보고 있습니다.
그리고 여기에 가장 중요한 부분은 이러한 것들을 분리 할 수 있다는 것입니다. 이 NoSQL 응용 프로그램이 여기에서 시작되고 있음을 알 수 있습니다. 우리가 뚫린이 30 분 동안 25 초의 대기 시간으로 인해 상당한 대기 시간을 유발하고 있습니다. 그런 다음 해당 응용 프로그램을 격리하고이 경우이 특정 인스턴스에 직접 영향을 미치는 설명을 볼 수 있습니다.
따라서 이것은 병목 현상을 식별하고 정보 순위를 정하며 우선 해결해야 할 문제의 우선 순위를 정할 수있는 방법의 한 예일뿐입니다. 이것들은 당신이 고려해야 할 모든 것입니다. 하루 종일 문제를 해결할 수는 있지만 목록 맨 아래에있는 문제를 해결하려면 시간을 낭비하는 것입니다. 이와 관련된 기회 비용이 있습니다.
또 다른 예를 들겠습니다. 이것은 약간 다른 예입니다. 문제를 구체적으로 지적하거나 영역을 가리키는 대신, “이봐, 문제가 있니?”또는“Are가 있습니까?”라고 말할 수있는 광범위한 의미로 당신을 도울 수있는 도구가 필요합니다. 성능을 향상시키기 위해 할 수있는 일이 있습니까?”라고 말하면서, 어떤 일이 벌어지는 지 지켜 보면서 뒤에서 무언가를 갖습니다. 이 경우 구성과 관련 될 수 있습니다. 인스턴스 자체의 상태가 관리되는 방식과 관련 될 수 있습니다. 또한 성능도 마찬가지입니다.
여기에있는이 분석 버튼으로 가면이 제품 내에서 본질적으로 통찰력을 제공 할 수있는 순위 형식으로 수행 할 수있는 사전 목록이 있습니다. 해당 인스턴스의 성능을 향상 시키거나 해당 인스턴스의 상태를 향상시킬 수 있습니다. 또한 식별 된 특정 유형의 문제와 관련된 성능을 향상시킬 수있는 기능을 파악할 수 있다는 점에서 순위 형식입니다.
그래서, 이것들을보고 그것들을 식별 할 때, 나는 문제가 있음을 알뿐만 아니라 많은 경우에 그 문제를 해결하기 위해 자동으로 구축 될 수있는 스크립트를 가지고 있습니다. 그러나 많은 경우에, 우리는 또한 우리가 겪고있는 문제의 유형을 참조 할 외부 링크를 가지고 있으며, 왜 우리가이 권장 사항을 제공하는지에 대한 교육적인 측면을 얻습니다. 다시 한 번 말하지만 문제를 해결할 때 매우 중요하다고 생각합니다.
나는이 권고들을 맹목적으로 따르고 싶지 않고, 이 권고들이 왜 만들어지고 있는지 이해하고 싶습니다. 그리고 저는 30 년 동안이 일을해온 선임 DBA 일 수 있습니다.이 경우에는 확인하거나 –를 점으로 표시하고 t를 교차 시키거나 – 주니어 DBA이거나 이러한 문제가 발생하는 과정을 이해하고 이러한 권장 사항이 제시되는 이유에 대해 약간의 도움이 필요합니다.
내가 말했듯이, 나는 당신을 제품의 두 가지 다른 부분으로 안내 할 것입니다. 이 도구는 2004 년부터 2003 년부터 사용되어 왔습니다. 그리고 실제로 많은 개발이 이루어졌고 많은 정보가 있으므로 여기에있는 모든 것을 보여 드리려고 시도하는 것은 이치에 맞지 않습니다. 하지만 주목할만한 것 중 하나는, 우리가 들어 와서 모니터링 할 수있는 모든 것, 그리고 다시 한번 경고 할 수있는 모든 것에 대해 이야기하기 시작한다는 것입니다. 여기에 모니터링중인 모든 항목의 목록이 있습니다.
그렇다고 임계 값 측면에서 문제가 발생했을 때 경고 상태에 있다고 생각할 필요는 없으므로 이러한 기능을 켜거나 끌 수 있습니다. “저는 특정 측정 항목에 대해서만 특정 작업을 수행하면됩니다. 나는 단지 특정한 문제들에 대해 경고 할 필요가있다.”그리고 우리가 많은 오탐으로 당신을 포화시키지 않도록 할 수있다. 이러한 기능을 켜거나 끌 수있을뿐만 아니라 각 메트릭과 관련하여 정규 범위를 제공하는 경우가 많습니다. 따라서이 특정 기준 (이 경우 기준)을 살펴보면 현재 임계 값이 임계 값보다 높을 수 있습니다.
코인의 다른 측면에서, 어떤 이유로 든 일부 메트릭과 해당 메트릭을 추적하는 SQL 인스턴스가 있다면 어떤 이유로 든 내가 설정 한 임계 값이 올바르지 않습니까? 다시 말해, 기준선이 실제로 앉아있는 중간에 임계 값이 급증합니다. 즉, 해당 임계 값에 연결된 경고가있는 경우 정상적인 이벤트에 대한 경고가 표시 될 수 있습니다. 이러한 상황에서 우리는 전반적으로 그러한 통찰력을 제공 할 수 있습니다.
이 특정 인스턴스의 모든 메트릭에 대해 정상 상태와 그렇지 않은 측면에서 오 탐지 가능성이 높은 임계 값을 볼 수 있습니다. 이것은 메모리 측면에서 더 일반적인 사용법으로 간주 될 것입니다.이 임계 값을 늘리고 싶다면 가능하지만 기준선에 대한 아이디어입니다.
기준 자체 측면에서 진단 관리자 제품의 멋진 점은 여러 기준을 설정하는 기능입니다. "왜 그렇게 하시겠습니까?"라고 물을 수도 있습니다. 그리고 정답은 자정부터 새벽 4 시까 지 운영되는 유지 관리 기간이 있다면 실제로 자원을 과세하는 곳입니다. ‘실제로 가능한 한 많은 리소스를 사용하고 있습니다. 다시 한 번 교대 할 수 있기를 원하고 조금 피벗하고 싶을 것입니다. "저희는 이에 대한 임계 값을 변경하겠습니다" 또한 시간이나 요일 등을 기준으로 임계 값을 동적으로 조정할 수 있습니다. 그런 다음 임계 값을 동적으로 조정합니다.
한 걸음 더 나아 갑시다. 일단 이러한 임계 값을 확인하고 나면, 알림 및 알림을 설정하고 이러한 상황이 발생할 수 있다는 점에서 다시 한 번 유연성이 가장 중요합니다. 특정 상황에서 경고 할 수 있기를 원합니다. 다른 상황에서는 다른 사람에게 전자 메일을 보내거나 PowerShell 스크립트를 실행하고 목록이 계속 표시 될 수 있습니다.
SNMP 트랩을 통해 또는 SCOM과 같이 직접 통합하고 싶을 수도 있습니다. 요점은 유연성이 뛰어나고 모든 인스턴스에 걸쳐 매우 광범위한 조건 (내 CPU, 메모리 또는 리소스 등)에 관계없이 모든 유형의 조건에서이를 보증 할 수 있다는 것입니다. 또는 우리가 위반 한 것을 발견하면 해당 문제에 대해 매우 구체적이고 지시 된 스크립트를 실행하고 싶기 때문에 모니터링하려는 매우 구체적인 유형의 항목이 있습니다. 알림 및 알림 측면에서 Diagnostic Manager 제품 내부에서 이러한 종류의 작업을 수행 할 수 있으며, 이러한 관점에서 융통성이있을 수 있습니다.
이제, 나는 모든 경고와 그 좋은 것들을 모두 거치지 않을 것입니다. 보고서에 대해 이야기하고 싶었습니다. 그리고 다시 한 번, 정보를 가져 와서 여러 가지 다른 방식으로 해당 데이터를 활용할 수있게되었습니다. 이는 다시 데이터와의 대화로 되돌아갑니다. 그리고 많은 사람들이이 제품을 처음 볼 때, “아, 문제가 생겼을 때 알려주는 도구를 갖게 될 것입니다. 그것이 바로 내가 필요로하는 것입니다.”그리고 현실적으로, 그들은 그 도구가 필요하지만 그 반대편은, 그들이 실제로 결정을 내리는 데 도움이되는 도구가 필요하다는 것입니다. 성과의 이름과 경고의 이름으로 수집하여 앞으로 나아가는 길에서 결정을 내리는 데 도움을 줄 수 있습니다.
좋은 예는 데이터베이스 내 성장 예측입니다. 증가하는 특정 데이터베이스가있는 경우 해당 데이터베이스 또는 여러 데이터베이스를 가리켜 서 증가율을 확인할 수 있습니다. 우리는 오늘 그것이 무엇인지에 근거하여 보여주지 않습니다. 우리가 경험 한 과거의 성장을 기반으로 예측할 것입니다.
여기에 몇 개의 데이터베이스가 있다면 – 상상해보세요 –“연도 별 데이터를 가져 와서, 한 달 단위로, 샘플로 상관 시키도록하겠습니다. 몇 개월 후, 앞으로 3 년 동안 또는 36 개 단위로 얼마나 많은 성장을할지 살펴 보겠습니다.”그렇다면이 질문에 매우 빠르게 대답 할 수 있습니다. 자, 스스로 그렇게하려고합니까? 내가 혼자서 한만큼 많은 시간을 할애하십시오. 시간이 좀 걸릴 것입니다.
이제 더 많은 스트레스를 받기 위해 다른 서버를 보도록하겠습니다. 100 개의 프로덕션 인스턴스가 있는데이 경우에는 그렇지 않습니다. 그러나 누군가 내게 와서 말하기를, “당신에게 말해줘야합니다 – 우리는이 새로운 새로운 응용 프로그램을 위해이 새로운 데이터베이스를 거기에 놓을 것입니다. 우리가 알고있는 모든 것을 바꿀 것입니다. 인생을 정말 멋지게 만들 것입니다. 그건 그렇고, 데이터베이스 자체는 실제로 I / O 집약적이거나 CPU 집약적이거나 메모리 집약적 일 것입니다.” 모든 프로덕션 인스턴스에서 해당 데이터베이스를 어디에 배치해야하는지 알 수 있습니까? 그리고 CPU, 메모리, 디스크 또는 사건이 무엇이든 관계없이 모든 유형의 인스턴스를 우발적 유형 측면에서 서로에 대해 순위를 지정할 수 있습니다. 그리고 여기서 요점은 그 질문에 신속하고 효율적으로 답할 수 있고, 언제 할 것인지를 추측하는 것이 아니라 올바른 결정을 내릴 수 있다는 것입니다. 그 모두가 실제로 중요하며, 도움이 될만한 것이 필요합니다.
또한 분석에 대해 이야기 할 때 용량 계획과 관련하여 이야기하는 것에서부터 CPU를 처리 할 수있는 일상적인 상황에 대한 경보에 이르기까지 그 범위가 다양 할 수 있습니다. 물론 차단 등이 있는지 여부에 관계없이 쿼리 자체도 마찬가지입니다.
또 다른 예는 여기에있는 관리 섹션으로 이동 한 경우 (실제로 여기의 경고 섹션으로 다시 가져 가서) 과거에 발생한 일에 대한 과거 정보의 보관소에 쿼리하는 것입니다. 프로덕션 환경에서 차단이 발생 했습니까? 모르겠어요, 알아 봅시다
프로덕션 태그로 돌아갈 수 있으며, 모든 프로덕션 인스턴스에 대해 특정 기간에 관계없이 식별하려는 메트릭에 대해 말할 수 있습니다. 경고 상태로 전환 한 경우 차단 시간 (초)이 아니라 카운트로 차단한다고 가정 해 보겠습니다.이 경우 몇 달이 지나야 할 수 있습니다. 한 달 동안 – 그리고 그 차단을 볼 수 있습니다. 언제 시작했는지, 언제 끝났는지, 필요한 경우 이러한 당김 간격 중 하나로 드릴 다운하여 자체 차단 사고의 세부 사항을 확인할 수 있습니다. 당신은 매우 빠른 무언가를 가질 수 있어야하고, 그것을하기 위해 많은주기를 돌리는 것보다 당신이 필요로하고 찾고있는 것을 찾을 수 있어야합니다. 그리고 저는 그것이 또한 중요하다고 생각합니다.
마지막으로 제가 보여 드리고 싶은 것은 –이 제품인 Diagnostic Manager 제품은 이전에 언급 한 것처럼 SQL Diagnostic Manager에 다른 구성 요소를 추가 한 것입니다. 프로 오퍼링. 이것이 바로 Workload Analysis 구성 요소입니다. 이 버전은 웹 기반 버전이며이 경우 여기에 표시됩니다. 그러나 여기서 중요한 점은 실제로 광범위한 기간이나 매우 구체적인 시간을 볼 수 있으며 몇 번의 클릭만으로 발생할 수있는 문제와 직접 관련된 코드를 볼 수 있다는 것입니다. .
예를 들어, 4 주보기를 살펴보면 여기 데이터베이스의 성능과 데이터베이스 성능 및 해당 데이터베이스에서 대기 활동을 볼 수있는 모든 급상승을 볼 수 있습니다. 자, 여기에 스파이크가 보이면이 도구 자체의 장점은 바로 그 작은 막대를 강조 할 수 있다는 것입니다. 그리고 내가 그렇게하면 여기있는 모든 것들이 바뀝니다. 우리는 데이터베이스를 볼 수 있고 모든 명령이 그 막대 뒤에 무엇이 있는지 볼 수 있습니다.
지난 4 주가 아니라“마지막 4 시간을 보자”고 말한 경우에도 마찬가지입니다. 여전히 그래도 돼 나는 그 기간을 여전히 강조 할 수 있으며, 여기에서 다시 한 번 여기에 내 피벗 포인트가 있습니다. 여기에서 내가 연결할 수있는 모든 것들이 있습니다. 상위 SQL 문 에서이 경우 CPU 소비와 관련된 대기를 유발하는 쿼리를 볼 수 있습니다. 드릴 다운 만하면 여기에서 관련된 질문 (후프)을 볼 수 있으며 프로그램과 관련없는 항목도 볼 수 있습니다.
여기에서 많은 통찰력을 얻을 수있을뿐만 아니라, 명령 수준으로 내려 가면 알려줄 것입니다. 무거운 연산자가 있는지 여부를 알려주고 실행 계획을 볼 수 있습니다. 이 파일을로드하는 데 꽤 광범위하기 때문에 약간의 시간이 걸립니다. 그러나 여기서 중요한 점은 데이터를보고, 원하는 것을보고, 필요에 따라 거기에서 조치를 취할 수있는 다양한 방법이 있다는 것입니다. 평소보다 오래 걸리므로 그대로 두겠습니다.
그리고 그 말로, 나는 그것을 다시 전달할 것입니다. 그리고 이것이 우리가 말하고있는 것들에 대한 좋은 시연 이었기를 바랍니다. 제가 말했듯이, 우리가 이러한 예제를 제공하기 위해 사용했던 제품 자체는 꽤 오랫동안 사용되어 왔기 때문에 우리가 이야기하고 보여줄 수있는 다른 많은 것들이 있습니다. 당신은, 당신은 항상 우리의 웹 사이트로 이동하여 다운로드하고 그것을 가지고 놀 수 있습니다.
에릭 카바나 : 이 모든 세부 사항을 보여 드리는 것이 좋습니다. 몇 개의 화면으로 돌아 가면이 화면도 좋습니다. 실제로 일어나고있는 일을 시각화하는 데는 여러 가지 방법이 있기 때문에, 이것은 오늘날 컴퓨팅에서 가장 평가되지 않은 측면 중 하나라고 생각합니다. 확실히 "우리는 여전히 실리콘을 배우는 법을 배우고 있습니다."라고 여러 가지면에서 반 농담을하는 것은 데이터베이스 환경입니다. 우리는 여전히 무슨 일이 일어나고 있는지, 그리고 당신의 요점을 이해하는 법을 배우고 있습니다. 문제가 많기 때문에 진행 상황을 이해하고 상황이 느리게 진행되는 이유를 더 잘 이해하려면 데이터와의 대화가 필요합니다. 물론, IDERA는 다양한 제품을 보유하고 있으며 그 중 하나는 무료로 생각할 수있는 오래된 Precise 제품입니다.
하지만 로빈, 몇 가지 질문에 대해 당신에게 넘겨주고, 데즈, 몇 가지 질문에, 그리고 청중의 누군가는 부끄러워하지 않을 것입니다. 지금 보내주세요.
Bullett Manale : Robin, 지금 음소거하고 있습니까?
로빈 블로어 : 그렇습니다. 괜찮아, 난 그냥 나 자신을 음소거하고 있습니다. 나는이 도구에 대해 가장 극적으로 충격을받은 사실을 믿을 수 없을 정도로 말해야합니다. 왜냐하면 실제로, 특히 여러분이 방금 옮길 수없는 일련의 치수가 실제로 명백한 사실을 감안할 때, 제 생각에 가장 인상적인 것은 DBA를 훈련시키는 정말 좋은 방법이어야한다는 것입니다. 알다시피, 데이터베이스 작업을 처음 시작할 때 실제로 데이터베이스에서 실제로 발생하는 일에 대해 많이 알지 못하면 실제로 실제로 이해하기가 매우 어렵습니다. 이것은 특히 훈련에 많이 사용됩니까? 나는 그것을 사용할 것입니다.
글 머리 기호 : 예. 당신이 훈련을 말할 때, 당신은 DBA와 같은 진행중인 훈련과 같은 것을 의미합니다. 관점에서 …
로빈 블로어 : 예, 예, 예. 학습 도구. 당신은 알고 있습니다.
Bullett Manale : 예, 이것이 사실 일 것입니다. 그리고 이전에 보여 드린 Analyze 구성 요소 인이 구성 요소를 추가했습니다. 여기에는 모든 권장 사항이 포함되어 있습니다. 그러나 나는 당신이 제품 내에서 도움과 많은 다른 영역을 찾을 것이라고 확신합니다. 그것은 당신에게 많은 통찰력을 제공합니다. 많은 정보.
그리고 제가 말씀 드린 것처럼 현실은 DBA가 아니라면 이것을 사용할 수 있습니다. 대부분의 DBA가 가지고있는 것에 대한 일반적인 지식을 바탕으로 Google 검색 및 이와 유사한 작업을 수행하는 것을 알게 될 것입니다. 그러나이를 연관시킬 수 있으며“이봐 요. "조각이 6, 000 회 실행되는 이유는 무엇입니까?"또는 "이 쿼리가 6, 000 번 실행되는 이유는 무엇입니까?" 당신은 당신이 알다시피, 정상인 것과 그렇지 않은 것을 볼 수 있습니다. 뾰족한 것들과 그렇지 않은 것들을 보게 될 것입니다.
원칙적으로 우리는 모범 사례와 관련 하여이 것을 설정하려고합니다. 따라서 인스턴스를 가리킬 때 모범 사례 이외의 것으로 식별 된 사항을 보여줍니다. 물론, 실제로는 모범 사례는 모범 사례이며 항상 실제 사례는 아니라는 것을 의미합니다. 그러나 초기 설치 시점부터 인스턴스를 가리 키더라도 특이 치가 표시됩니다.
그런 다음 문제를 해결하고 이것이 실제로 문제인지 또는 일상적으로 발생하는 문제인지 확인해야 할 때 필요한 조치를 취할 수 있습니다. 그리고 도움을 줄 수있는 정보와 권장 사항이 많기 때문에 그렇습니다.
로빈 블로어 : 좋습니다. 그리고 또 다른 질문 – 그러나 이것에 대한 답변이 매우 빠르다고 확신합니다 – 개별 쿼리와 개별 시점으로 바로 내려 가서 해당 차원에서 볼 수있는 세분성이 있습니다.
Bullett Manale : 물론입니다. 하고 싶은 일에 따라 1 분의 시간을 보거나 3 일의 시간을 보거나 3 주일의 시간을 볼 수 있습니다. 내가 말했듯이 데이터를 보는 방법과 수집하려는 내용에 따라 다릅니다. 경우에 따라 식별 한 임계 값에 도달 한 쿼리 만 수집합니다. 다른 경우에는 대기를 유발하는 모든 쿼리를 수집 할 수도 있습니다.
그러나 "내가 확인한 임계 값, 쓰기 또는 읽기 또는 CPU에 대한 임계 값"이라고 말하는 기능도 있습니다. 따라서 임계 값을 초과한다고 가정하면 해당 임계 값을 초과하게됩니다. 보고자하는 시간대에 상관없이 위반으로 간주되는 내용에 따라 불쾌한 쿼리를 볼 수 있습니다.
데이터를 보는 방법에는 여러 가지가 있습니다. 통합 된보기에서이 보고서를보고, 쿼리의 수에 대한 비하인드 쿼리 수와 해당 쿼리의 모든 단일 사건이 시작된 경우 패턴을 볼 수있는 쿼리를 확인할 수 있습니다. 계속 악화되고 있는지 확인합니다.
그러나 귀하의 질문에 대답하기 위해 원하는 시간을 정확하게 가리킬 수 있습니다. 당신은 History Browser라는 것을 가지고 있습니다 – 그리고 나는 그것을 조금 사용하고있었습니다 – 그러나 기본적으로 당신이 선택한 어떤 시점, 어떤 달력에서 당신이 선택한 어떤 날짜, 당신은 그 시점으로 직접 갈 수 있습니다.
지금은 11 월 15 일 오후 7시 05 분에보고 있는데, 그 당시의 특정 쿼리를 볼 수 있습니다. 해당 기간 동안 제대로 실행되지 않은 세션이있는 경우 해당 기간과 관련된 세션 세부 정보를보고 어떤 세션이 실행 중인지 확인할 수 있습니다. 내 말은, 여기에는 많은 데이터가 있으며, 내가 말했듯이, 가장 어려운 부분은 실제로 콘솔을 가지고 놀고이 작업을 수행하는 방법을 알아내는 데 30 분이 걸릴 것입니다.
그러나 여기에있는 대부분의 데이터가이 리본에 있고이 탭으로 나뉘어져 있음을 인식하면 각 탭에는 클릭 할 때마다 표시되는 동적으로 변경되는 버튼 세트가 있습니다. 지난 주에 일어난 일이나 시간도 마찬가지입니다. 기본적으로 지금 11 월 15 일을보고 있지만 버튼을 클릭하면 실시간으로 쉽게 볼 수 있습니다. 그리고 같은 방식으로 데이터와 상호 작용할 것입니다.
그러나 귀하의 질문에 대답하기 위해 그렇습니다. 과거 정보를 보는 여러 가지 방법이 있으며 이는 또한 쿼리 자체와 관련이 있습니다.
로빈 블로어 : 알겠습니다 . 매우 인상적입니다. 그리고 요즘은 실시간 데이터를 다루는 모든 것이 거의 필요하더라도 윈도우가 동기화된다는 사실을 좋아합니다.
글 머리 기호 : 예. 확실한.
Robin Bloor : 여기에 실제로 답을 모른 정보가 있습니다. SQL Server 및 클라우드와 같은 오퍼는 비율 아래에서 클라우드를 가리킬 수 있습니까?
Bullett Manale : 가능합니다. 구름 아래에서 이것을 가리킬 수 있습니다. 실제로 인스턴스를 추가하면 RDS인지 Azure인지 묻습니다. 이제 클라우드에서 노출되는 것에 따라 몇 가지 제한이있을 수 있습니다. 따라서 모니터링 할 수있는 것과 약간의 차이가있을 수 있습니다. 단순히 계측이 어떤 경우에는 우리가 마이크로 소프트가 노출하고있는 것에 근거하여 모일 수는 없습니다.
자, 여러분이 알고있는 것처럼 플랫폼으로서의 인프라 나 EC2 또는 이와 유사한 것이라면 전혀 문제가되지 않습니다. 우리는 모든 것을 얻습니다. 그리고 Microsoft와 함께 일하고 Amazon과 함께 일할 때; 우리는 그 정보를 더 자세하게 공개하려고 노력하고 있습니다. 그러나 절대적으로 그렇습니다. 우리는 그러한 환경을 지원합니다.
로빈 블로어 : 좋습니다. 흥미 롭습니다. 글쎄, 나는 다른 방향에서 질문을 던질 것이라고 Dez에게 넘길 것이다.
글 머리 기호 관리 : 알겠습니다.
Dez Blanchfield : 감사합니다. 나는 당신을 위해 두 가지 매우 빠른 것을 가지고 있습니다. 제 생각에는, 첫 번째는, 비늘입니다. 저를 공격하는 것 중 하나는 퍼포먼스의 일반적인 주제가 우리가 매우 커질 때 생각할 수있는 것입니다. 매우 광범위하고 광범위하며 테라 바이트 단위의 데이터. 데모를 보았을 때, 이것은 매우 작은 환경에도 실제로 적용되는 일종의 성능 저하를 일으켰습니다.
당신은 이것의 흡수에서 어떤 종류의 확산을 보았으며, 그것이 당신이 그것을 가지고 있다고 생각합니까, 당신은 그것이 좋은 도구라고 생각합니까, 당신은 알고 있습니다 – 내 마음에, 그것이 있습니다, 그래서 나는 그것이 예라고 생각합니다 – 하지만 난 네가보고있는 것을보고 싶어 소규모 조직도 같은 대화를 나누고이를 수행 할 수있는 도구를 찾고 있습니까? 아니면 실제로 더 큰 도시에서 무언가입니까?
Bullett Manale : 재미 있네요. 좋은 질문입니다. 그것은 약간의 혼합이지만, 우리는 많은 소규모 고객이 있다고 말하고 싶습니다. 소규모 고객이라고 할 때, 1 ~ 5 개의 인스턴스 구매를 통해 라이센스를 부여 받아 관리 할 수 있습니다. 이제 어떤 경우에는 30 개의 SQL 인스턴스가있을 수 있으며 5 개의 인스턴스에 대해 이와 같은 도구에 투자 할 수있는 5 개에 대해 정말로 중요합니다.
그러나 실제로는 소규모 상점에서도 소수의 SQL Server가 있다는 것입니다. 대부분의 경우 또는 많은 경우에 작은 상점은 데이터베이스가 수행하는 작업 때문에 데이터베이스에 매우 의존적입니다. 그래서 그들은 그렇게하지 않습니다. 그들은 도구를 가질 필요가 없습니다.
이 코인의 다른 측면은 일부 소규모 상점에는 전용 DBA가 없기 때문에 회의실에서 가장 똑똑한 사람이거나 회의실에서 더 기술적 인 사람이 할당 된 DBA가된다는 것입니다. 따라서 그러한 상황에서 그들은 분명히 도움을 구하고 있으며, 이 도구는 분명히 그 점에서도 도움이 될 것입니다.
더 큰 환경의 경우, Dez라고 생각한 것처럼, 또는 Robin은 확실하지 않습니다. 그러나 더 큰 환경에서는 DBA가 몇 개인 지에 대해 놀랄 것입니다. 많은 수의 SQL 인스턴스에 대해 이야기하면, 책임을 져야 할 DBA가 실제로 있습니다. 그리고 그러한 관점에서, 그 사람들은 그들이 실제로 그들을 도울만큼 충분한 자원을 가지고 있지 않기 때문에 도움을 찾고 있습니다. 그래서 도구는 그 중 일부를 상쇄하는 데 도움이 될 것입니다.
우리는 또한 200 명의 인스턴스를 관리하는 세 사람이 있다는 것을 알 수 있습니다. 이와 같은 도구가없는 경우 문제가 발생했을 때 알아 내기 위해 그 물류를 상상할 수 있습니다. 사전 예방 적 방법은 아닙니다. 확신 할 수 있습니다. 희망적으로 그것은 귀하의 질문에 대답합니다. 네.
Dez Blanchfield : 그렇습니다 . 그것은 나를 때렸다 – 그리고 나는 Robin이 그것에 대해 암시한다고 생각한다 – 그러나, 당신은 당신이 데모를했을 때 묘사하고있는 약속의 종류, 그것은 그들이 매우 큰 환경에 독점적이지 않다는 것을 의미합니다. 아시다시피, 한 가지 용도로 설계된 상용 기성품 플랫폼을 구매하여 다른 용도로 데이터베이스 공유 환경에 배치하면 전체 환경을 처벌 할 수 있습니다.
저를 강타했던 또 다른 것은 – 그것은 많은 질문이 아니라 관찰 일뿐입니다. 그러나 나는 그것을 질문으로 이끌 것입니다 – 그리고 그것은 여러분이 이미 인프라와 인프라에 투자 한시기입니다. 플랫폼, 데이터베이스, 서버 및 그 주변의 인프라, 그리고 HR, ERP, BI 도구 등 제품을 구매할 예정입니다. 그들은 이미 상당히 큰 투자를했습니다.
사람들과 대화를 나눌 때 성능 문제가 있다는 것을 깨달았지만 이제는 또 다른 투자를해야한다고 생각합니까? 당신이 그것을 시연하면이 점을 염두에 두지 않는다는 것을 깨달을 수있는 지점이 있습니까? 그리고 그것은 판매 피치가 아니고, 더 많은 주현절입니다. "우리는 즉시 이것으로부터 이익을 보게 될 것입니다."제품을 판매하는 것과 반대로? 그것은 나 자신에게 팔리고 ROI는 페이지에서 뛰어 넘습니다.
Bullett Manale : 예, 정말 재밌습니다. 왜냐하면 많은 시간이 걸리기 때문에 누군가가 DBA 나 영업 담당자와 같이 와서“이 사람들은 이것에 대한 ROI 시트를 참조하십시오.”그리고 종이에 우리가 그들에게 보낼 무언가가 더 있습니다. 데모는 항상 10 배나 더 좋습니다. 특히 DBA 자체로 데모를 수행 할 수 있습니다.
데즈 블랑 필드 : 네.
Bullett Manale : 말씀 드린 대로 제품 자체가 판매됩니다. 백서에 ROI를 적용하는 것은 정말 어렵습니다. "좋아요, DBA는 일반적으로 몇 시간 만에 몇 번의 클릭을합니까?"라고 말하면 백업, 알거나 또는 사건에 관계없이 알고 있니? 그리고 그것을 종이에 씌우려고 노력하는 것은 정말로 어렵습니다. 그러나 당신이 누군가를 얻고 당신이 그들에게 제품을 보여줄 때, 그들이 그것을 본다면 그것은 바로 당신이 말한 것입니다.
사람들은 그것의 가치를 깨닫습니다. 그들이 이해하고 더 나은 결정을 내리는 데 도움이 될뿐만 아니라 나쁜 사람이되지 않도록 도와줍니다. 그들은 가장 먼저 알 수 있습니다. 문제가 있음을 식별하기 전에 문제를 해결할 수 있습니다.
그것의 다른 부분은 DBA로서 그것이 실제인지 인식인지, 그리고 그것이인지인지 생각합니다 – 당신은 실제로 성능 문제를 소유하고 있다는 것입니다. 성능이 떨어질 때 손가락을 가리킬 수있는 사람입니다. 실제로 실제로 문제를 일으키는 개발자가 될 수 있습니다.
"이건 내 문제가 아니야, 개발자에게이 문제를 해결할 수 있어야하고이를 수정해야합니다."라고 말할 수있는 도구가 있습니다. 당신의 무기고에 무언가를 가질 수있는 좋은 방법입니다.“이것은 실제 문제가있는 곳입니다.”아시나요?
데즈 블랑 필드 : 네. 당신을위한 마지막 것, 그리고 우리가 겪을 때 이것을 본다면, 종종 성능 문제에 대해 생각할 때 우리는 특별한 기술을 가져 오는 경향이있었습니다. 그들은 20 년의 경험을 가지고 있으며, 그것을보고, 엔지니어링 상점에 들어가서 작은 망치를 가지고 기계를 맞은 사람의 고전적인 농담을 말합니다. "15, 000 달러짜리 문제입니다."5 분이 걸리기 때문에 사람들은 "우리는 비용을 지불하지 않습니다"라고 말합니다. "음, 5 분의 작업 시간은 15 년의 경험으로 해결되었으며 수백만 달러를 절약했습니다."
나에게 그것은 중간 단계가있는 것처럼 보입니다. 사람들은이 과정을 통해“좋아요, 특별한 기술을 가지고 문제를 해결하면 사라질 것입니다.”라고 말합니다. 그러나 그들이 한 일은 방금 반창고를 썼어요? 내가 여기서 볼 수있는 것, 이것이 어디로 갔는지에 대한 시나리오와 달리, 그들은 그들이 겪고 있다고 생각한 몇 가지 성능 문제를 해결했을 수도 있지만, 그때 나는 단지이 24 / 환경을 실시간으로 바라 보는 7 가지 종류의 눈.
보고서가 실행 중이기 때문에 오전 4시에 DBA가 깨어나는 시나리오에서 벗어나게됩니다. 사례일까요? 아마도 수사적인 것일 수도 있습니다. 그러나 사람들이 특정 문제를 해결하기 위해 제품에 투자하는 것에서 빠르게 전환하지만, 일반적으로 DNA의 일부가됩니까?
Bullett Manale : 예, 지역마다 다릅니다.하지만 2006 년에 처음으로 제품을 구입 한 사람들이 있고 다른 회사에서 3 개의 다른 직업을 가졌습니다. 그들은 그 다음 회사에 갔을 때 워크 플로우를 가지고 있기 때문에 이것을 무언가로 홍보합니다. 그리고 그것을 부르는 것을 싫어합니다.하지만 워크 플로에는이 제품이 관련되어 있으며 일상적으로 사용되며 도움이되므로 원하지 않습니다. 새로운 것을 배우다.
그러나 절대적으로. 대부분의 경우 사람들이이 제품을 다운로드하도록하는 것은 예산이없고 나가고 있다는 말이 아닙니다.“저는이 성능 예산이 있습니다. 개념 증명, 그리고 우리는 개입하고 파악하고 평가와 그 모든 것을 수행해야합니다.”일반적으로 발생하는 일은 SQL 인스턴스에 문제가 있고 도움이 필요하다는 것입니다. 그 문제를 해결하십시오. 그들은 우리 도구를 다운로드하여 문제를 해결 한 다음, 도구 자체가 당시의 문제를 해결하는 것 이상으로 실제로 전체적인 성능을 향상시키는 데 도움이 될 것임을 깨닫습니다. 다른 문제가 발생하지 않도록합니다. 그리고 그것은 확실합니다. 또한이 도구를 계속 사용하여 환경을 지속적으로 조정할 수 있습니다. 항상 현재 상황뿐만 아니라 지난 주, 지난 달, 작년에 발생한 상황을 볼 수 있고 앞으로 일어날 일과 비교할 수 있기 때문입니다. 내일. 당신은 알고 있습니까? 그런 종류의 것.
데즈 블랑 필드 : 네.
Bullett Manale : 물론 이죠 .
Dez Blanchfield : 완벽합니다. 그래서 당신은 언급했습니다. 당신은 무언가에 대해 언급했습니다 – 나는 에릭에게 손을 before 기 전에 마무리를하겠습니다. 내가 항상 관심을 갖는 것 중 하나는 사람들이 어떻게 손을 잡는가하는 것입니다. 당신은 그것을 다운로드 언급했다. 인스턴스를 가져 오기 위해 손을 잡고, 사본을 가져 와서, 가지고 놀거나, 인프라에 필요한 것이 무엇인지에 대한 30 초 요약은 무엇입니까?
Bullett Manale : 이제 IDERA (idera) .com으로 이동합니다. IDERA.com은 회사이며, 귀하가 해당 웹 사이트를 방문한 경우 – 여기에 실제로 표시 할 수 있습니다 – 여전히 화면을 공유하고 있는지 알 수 없지만 제품 페이지로 이동하면 진단으로 이동하십시오. 관리자 링크에는 약간의 다운로드 버튼이 있으며 정보를 작성한 후에 빌드를 다운로드 할 수 있습니다. 그들은 32 비트 또는 64 비트 빌드를 요구할 것이고, 당신은 그들이 말하는 것처럼 경주를 떠납니다.
Dez Blanchfield : 랩톱에서 누군가와 함께 플레이 할 수 있습니까, 아니면 서버에로드해야합니까?
불릿 관리 : 아니요, 아니요. 사실, 오늘 제가 보여 드린 것은 모두 내 랩톱에서 실행 중이었습니다. 이제 랩톱에는 32 기가 있고 8 코어 프로세서가 있지만 여전히 랩톱입니다. 그러나 귀하의 질문에 대답하기 위해 반드시 그렇게 많은 자원을 가질 필요는 없습니다. 평가 자체는 14 일 동안 유효하지만 평가 기간을 연장 할 수 있습니다. 전화를 주시면 원하는 경우 전화를 연장 할 수 있습니다.
Dez Blanchfield : 저는 분명히해야 할 일이라고 생각합니다. 제 생각에는 사물을 보면 다운로드하여 가지고 놀아도 좋습니다. 아마 당신의 환경 중 하나에 가서 당신이 볼 수있는 것을 보아라. 왜냐하면 지난 20 년 동안 데이터베이스 배경에서 본 모든 것과 같이, 나보다 나이가 들어간 것을 의심하기 때문이다. 후드, 빠르게 고칠 수 있고 성능이 거의 향상되지 않는다는 사실을 알고 있다는 것은 놀라운 일입니다.
시연 해 주셔서 감사합니다. 정말 좋았습니다. 질문에 대해 토론 해 주셔서 감사합니다.
Bullett Manale : 천만에요 . 에 감사하다-
Dez Blanchfied : Eric, 다시 연락 드리겠습니다.
Eric Kavanagh : 예, 청중들로부터 정말 좋은 질문이 있습니다. 당신은 프레젠테이션에서 이것에 대해 이야기했습니다. 귀하는 성능에 부정적인 영향을 미치는 성능을 모니터링하기 위해 도구를 사용하고 싶지 않다고 말했습니다.
총알 관리 : 맞습니다. 맞습니다. 성능 모니터링 도구의 중요한 부분은 성능 문제를 일으키지 않는다는 것입니다. 정확히 맞습니다.
에릭 카바나 흐 : 맞습니다. 글쎄, 그것은 시스템에 혼란을 줄 수있는 항 바이러스 프로그램과 같습니다. 나는 안티 바이러스 프로그램이 시작되어 스트림을 자르는 방송에 여러 가지 기술을 사용했습니다. 따라서 예상치 못한 일이 있지만 질문은 귀하가 작성한 특정 의견과 관련이 있습니다. 그리고 어떤 종류의 성능 저하가 보입니까? 2 %입니까, 5 %입니까, 1 %입니까? 당신이 우리에게 던질 수있는 번호가 있습니까?
Bullett Manale : 글쎄요, 이 질문에 대한 도전은 우리가 이전에 논의했던 토론의 일부라는 것입니다. 나는 당신에게 줄 수 있습니다 – 그것은 당신의 질문에 대답하기 위해 보통 1-3 % 정도입니다. 그러나 필자가 필요하다고 생각하는 더 많은 설명이 있습니다. 즉, 모니터링 할 대상을 도구에 알릴 수있는 많은 방법을 제공합니다. 그리고 그것은 다시 돌아갑니다. 글쎄, 나는 실행중인 모든 쿼리의 샘플을 얻고 싶을 것이다. 그래서 나는 그것을 볼 수있을만큼 충분히 유연한 도구를 원합니다.
따라서 유연성의 일부에는 비용이 포함됩니다. 마지막에 실행되는 모든 쿼리의 샘플을 원하기 때문에 더 많은 데이터를 수집해야하는 경우 20 분만에이 기능을 켜면 가능합니다. 그리고 일반적으로 말하면, 1 ~ 3 %는 오버 헤드 측면에서 우리가 보는 것입니다. 그러나 그것은 다양 할 것입니다. 그리고 대부분은 임계 값, 수집 할 데이터의 양, 폴링 간격, 모든 종류의 것들과 관련하여 켜고 끄는 것에 의존합니다. 그.
실제로 관리하고있는 인스턴스 자체로 나가면 지정할 수있는 여러 폴링 간격이 있습니다. 그 이유는 모든 것을 점검 할 필요가 없기 때문입니다. 인스턴스에서 하트 비트 점검을 수행하려는 경우 CPU와 그 밖의 모든 것을 폴링 할 필요가 없습니다. 매 20 초마다 요 따라서 지정할 수있는 폴링 간격이 여러 개 있습니다.
내가 말했듯이 지정할 수있는 쿼리 모니터링 기능도 있습니다. 또한 각 인스턴스에 대해 독립적으로 수행 할 수 있으므로 모니터링하려는 측면에서 특정 인스턴스를 실제로 수용 할 수 있습니다. 대기 통계 및 대기 모니터링의 경우이를 켜거나 끌 수 있습니다. 그리고 모든 것을 캡처하도록 지시 할 수 있습니다. 내가 무엇을 캡처하고 싶은지, 언제 캡처하고 싶은지를 말할 수 있습니다. 따라서 많은 부분도 마찬가지입니다. 모니터링 할 도구를 말하고있는 측면에서 수행중인 작업을 고려해야합니다.
그러나 일반적으로 말하면, 내가 말했듯이, 약 1 ~ 3 %가 우리가 보는 것입니다. 2003 년이나 2004 년에 말한 것처럼이 도구를 오랫동안 판매 해 왔으며 수천 명의 고객을 확보하고 있기 때문에 우리는 가지고 있지 않다는 것을 확신 할 수 있습니다. 성능 이름에 성능 문제를 일으키지 않는 것이 가장 좋습니다.
Eric Kavanagh : 네, 정말 좋은 정보입니다. 난 그냥 당신이 달성하려는 목표의 목적을 이기고 싶지 않기 때문에, 그것은 훌륭한 인용이라고 생각했습니다.
글 머리 기호 관리 : 정확합니다.
에릭 카바나 흐 : 그리고 로빈의 질문에 감사합니다. 이것은 실제로 DBA가 우리가 이야기하는 다양한 측면, 차원 및 계층을 이해하도록 돕는 훌륭한 플랫폼입니다. 그리고 저는 데이터와의 대화 개념이 여기에서 매우 적절하다고 생각합니다. 왜냐하면, 이전 시점에서는 일반적으로 첫 번째 시도에서 알아낼 수 없기 때문입니다. 데이터를보고, 기록 데이터를보고, 마음에 합성하는 데 시간을 할애해야합니다. 그리고 그것은 인간의 일입니까? 거기에 앉아서 직업적으로 일을 끝내고 열차를 정시에 운행하기 위해 상당히 정기적으로 사업에서 열을받는 직업의 일?
총알 관리 : 물론입니다.
Eric Kavanagh : 글쎄요, 여러분, 이것은 또 다른 환상적인 이벤트였습니다. 요청하신 질문에 대한 답변이 없으면 언제든지 알려주십시오. 에 이메일을 보내십시오. 당사는 이러한 모든 이벤트를 보관하므로 항상 InsideAnalysis.com에서 보관함을 찾거나 파트너 인 Techopedia.com을 방문하십시오. 해당 페이지의 오른쪽을 보면 이벤트 및 웹 캐스트가 표시됩니다. 추가 이벤트를 클릭하면 과거, 현재 및 미래에 나열된 모든 웹 캐스트를 볼 수 있습니다.
그리고 우리는 작별 인사를 할 것입니다. 올해 남은 시간 동안 웹 캐스트가 5 번 더 있습니다. 하나 더 예약 할 수 있습니다. 그러나 그렇지 않으면 2017 년이 될 것입니다. Google에 알려 주시고 기술을 소개하려는 사람이있는 경우에 이메일을 보내십시오.
그걸로 우리는 작별 인사를 할거야. 귀하의 시간과 관심에 다시 한번 감사 드리며 다음에 연락 드리겠습니다. 조심해 안녕.
