차례:
작성자 : Techopedia Staff, 2016 년 5 월 9 일
테이크 아웃 : 호스트 Eric Kavanagh는 대기 시간과 성능에 대해 Mark Madsen, Dez Blanchfield 및 Bullett Manale을 인터뷰했습니다.
현재 로그인하지 않았습니다. 비디오를 보려면 로그인 또는 가입하십시오.
Techopedia 컨텐츠 파트너
Techopedia 직원은 Bloor Group과 관련이 있으며 오른쪽의 옵션을 사용하여 연락 할 수 있습니다. 업계 파트너와 협력하는 방법에 대한 자세한 내용을 보려면 여기를 클릭하십시오.- 프로필
- 웹 사이트
Eric Kavanagh : 신사 숙녀 여러분 안녕하세요, Hot Technologies에 다시 오신 것을 환영합니다! 네 확실합니다! 저는 Eric Kavanagh입니다. 이것은 Techopedia의 좋은 친구들과의 파트너십 인 Hot Tech 쇼입니다. 광범위한 엔터프라이즈 기술 분야에서 최신 정보를 얻으려면 Techopedia.com을 온라인으로 이용하십시오. 물론 그들은 소비자의 물건도 포함합니다. 우리는 여기서 프로그램에 대해 엔터프라이즈에 중점을 두므로 오늘날 우리가 할 일입니다.
나에 대한 진실하고 충분한 장소가 있습니다. Twitter @eric_kavanagh에서 저를 때리십시오. Twitter를 좋아합니다. 나는 그 물건을 확인하는 것을 좋아합니다. 사람들과 연락을 유지하고 좋은 대화를 나누는 좋은 방법입니다. 하나의 대화.
그래서 우리는 무엇에 대해 이야기하고 있습니까? 올해는 덥습니다. 이것은 오늘날 정보 관리 세계에서 볼 수있는 기회의 전 세계입니다. 오늘날 우리가 이야기하는 것은 쿼리가 될 것이며 쿼리 속도가 빨라질 것입니다.
"퍼포먼스 플레이 : 대기 시간 작별 인사"라는 제목을 언급하지 않은 것 같습니다. 누가 대기 시간을 원하는가? 대기 시간을 원하는 사람은 없습니다. 대기 시간은 사용자가 앉아있을 때 버튼을 클릭하고 어떤 일이 일어날 때까지 기다립니다. 아이들은 마음에 들지 않고 멋지다고 생각하지 않으며 어른도 마음에 들지 않습니다. 우리는 모두 웹의 속도에 망쳐졌고, 우리는 빨리 물건을 원하고, 지금 물건을 원하며, 오늘 우리 쇼에서 그것에 대해 모든 것을 이야기 할 것입니다.
분석가 Mark Madsen은 오늘 우리의 규칙 중 하나 인 Third Nature에서 우리와 함께 있습니다. 우리의 새로운 데이터 과학자 인 Dez Blanchfield는 호주 시드니에서 전화했습니다. 그리고 Bullett Manale은 사실 그의 이름입니다. 실제로는 2 개의 T입니다. Bullett Manale은 매우 흥미로운 회사 인 Idera의 손님으로서 많은 일을하고 있습니다. 나는 그들에 대해 이미 알고 있는데, 그중 하나는 Precise라고 불리는 회사를 구입했습니다. 나는 그들의 CEO 인 Zohar Gilad를 알았습니다. 이름은 어떻습니까? 그는 똑똑한 사람 중 하나였습니다.
그러나 여러분, 여러분은이 웹 캐스트에서 여러분이 묻는 질문에 중요한 역할을하므로 부끄러워하지 말고 언제든지 질문을 보내십시오. 웹 캐스트 콘솔의 Q & A 구성 요소를 사용하여 할 수 있습니다. 오른쪽 하단에 저와 채팅 할 수도 있고 스피커와 채팅 할 수도 있습니다. 우리는 이미 이탈리아에서 전화를 한 사람이 있습니다.“Ciao, ciao. stai ??”좋아, Mark의 첫 번째 줄을 밀고, 데크를 Mark에게 넘겨 줄 것이다. 마크, 이제 WebEx가 있습니다. 치워, 바닥은 당신입니다.
Mark Madsen : 감사합니다. Eric. 나는 중간에 시작하지 않을 것이다, 나는 처음에 시작할 것이다. 따라서 Dez와 Idera, 개발 상태의 일종의 상태, 데이터베이스 및 운영과의 토론을 설정하는 몇 가지 의견. 알다시피, 개발자가 DBA를 어려움에 처한 사람들로 간주하기 때문에 데이터베이스와 응용 프로그램 시장에 이러한 두 가지 문제가 여전히 있습니다. 데이터 모델을 작성해야하고, 액세스 할 수 없으며, 해당 항목을 작성할 수 없으며, 데이터베이스에있는 모든 테이블의 모든 열에 색인을 추가하여 더 빠르게 만들 수는 없습니다. 물론 모델이 필요한 이유는 무엇입니까? 데이터 구조 일뿐입니다. 변경하면 직렬화 된 형식으로 작성할 수 없습니까?
문제는 개발자가 코드와 응용 프로그램을 알고 있지만 종종 알지 못하는 두 가지가 동시성, 동시 프로그래밍 및 데이터베이스와 그 아래의 운영 체제라는 것입니다. 커널 개발자와 운영 체제 및 데이터베이스를 사용하고 있기 때문에 동시성과 병렬 처리가 실제로 어렵다고 말할 수 있으므로 코드에서 우수한 성능을 얻는 방법을 배우는 많은 것들이 실제로 시작될 때 떨어지기 시작합니다. 데이터베이스 작업. 그리고 성능은 좋아 보이고 테스트 환경은 좋아 보이고 Q & A 환경은 실제 시스템에 영향을 미쳐 갑자기 그리 좋지 않습니다. 코드가 다방면으로되어 있기 때문에 코드가 데이터베이스와 작동하는 방식, 환경과 작동하는 방식, 실제로 실행되는 규모에 따라 간단한 작은 방법이 크게 영향을 줄 수 있습니다.
그리고 외부 응용 프로그램에 대해 이야기하기 시작할 때, 외부 응용 프로그램, 웹 응용 프로그램은 갑자기 일직선이 될 때까지 훌륭하고 그렇지 않기 때문에 실제로 어려울 수 있습니다. 당신은 이해하기 위해 많은 뉘앙스가 필요한 흥미로운 고원에 부딪 칠 것입니다.
단점은 DBA 뷰입니다. DBA의 견해에는 운영이 있고 운영에 80 ~ 90 %의 시간을 투자하며 10 ~ 20 %의 시간이 선행되는 개발 작업을 처리한다는 데 있습니다. 이러한 관점에서, 당신은 지금 지불하거나 나중에 지불하고, 모든 시간을 선불로 지출한다면, 기능을 탐구하는 경향이있는 개발과는 반대로 나중에 더 나은 기회를 갖게 될 것입니다 공간, 그리고 최선의 방법을 알아 내려고 노력합니다. 따라서 문제가 생겼으며 이제는 지속적 배포, 준비가 될 때마다 앱 롤업, 주기적으로 코드 푸시, 개발 작업을 수행하는 상점에서 일하는 호환되지 않는 방법론이 있습니다. 이런 종류의 작업은 개발 속도를 높이지만, 데이터베이스와 관련된 모든 관행과 DBA의 기능 및 시스템 관리자의 교육, IT 운영 관행은 보조를 맞추지 못했습니다.
생각해 보면 대부분의 DBA는 변경 제어 환경과 지속적인 배치 환경에서 작동합니다. 안정성과 제어, 변화 속도 및 가역성에 관한 것입니다. 지속적인 배포, 변경을 되돌릴 수 없다면 어려움을 겪고 있으므로 모든 것을 쉽게 되돌릴 수 있고 코드 전환이 가능하도록 구축해야합니다. 이는 관계형 데이터베이스, 개발 사례 및 관리 사례가 작동하는 방식과 크게 다르지 않습니다. .
또한 DBA로서 문제에 대해들을 때까지 수십만 명이 웹 사이트에 불만 양식을 작성하기 때문에 DBA로서 더 적극적이어야하는 이러한 문제에 부딪치게됩니다. 기존 환경에서 벗어나지 않는 새로운 것들이 필요합니다. 더 나은 모니터링 및 경고와 같은 것들을 알고 있습니다. 동시에 데이터베이스가 증가하고 있으며, 그 어느 때보 다 많은 것을 지원할 수있는 더 많은 응용 프로그램이 있습니다. 내부, 외부, 외부에 있습니다. 더 독립적 인 분석을위한 데이터 세트는 사람들이 데이터베이스를 시작하는 것은 당연하지만 이제는 쉽게 가상 머신을 설정할 수 있기 때문입니다. 클라우드 제공 업체 또는 내부 클라우드가있는 경우 즉시 팝업을 표시하여 전체 조달 경로를 변경합니다.
구식 조달 경로는“서버를 가져 와서 랙에 꽂고 공간을 할당하고 스토리지를 확보하고 데이터베이스를 설치하고 작업을 수행 할 시간이 있습니다.”고 신용 카드를 스 와이프하고 5 분 안에 갈 사람과 비교했습니다. 그렇게한다면, 현대의 개발 환경은 매우 다른 속도로 운영되고 있기 때문에 데이터베이스를 생성하기가 쉬우 며 이전에는 보지 못했던 것과 같은 확산 문제를 야기 할뿐입니다. 그리고 이것은 10 년 동안 진행되어 왔으며, 이는 누구에게도 뉴스가 아니지만 운영 환경이 복잡해 졌다는 것을 의미합니다.
더 이상 클라이언트 서버 환경이 아니기 때문에 전체 클라이언트 서버 환경이 실제로 변경되었습니다. 그 당시에는 서버가 있었고 데이터베이스가 있었으며 어떤 것이 잘못되었는지 알고 있다면 모범 사례는 하나의 데이터베이스, 하나의 서버이기 때문에 리소스를 관리하는 방법을 알았습니다. 데이터베이스 서버라고 생각하는 것은 단지 소프트웨어이기 때문에 가상화가이를 분리하기 시작했습니다. 그래서 환경은 현실이 아닙니다. 그것은 실제 환경을 포함하고 있으며 블레이드 랙 또는 큰 서버가 조각으로 조각되어있을 수도 있습니다. 실제로 알지 못합니다.
데이터베이스 관리 및 성능 관리와 관련된 모든 것, 하나의 서버 또는 소수의 서버 및 몇 개의 데이터베이스를 통한 엄격한 제어를 위해 구축 된 데이터베이스는 모든 것을 제어 할 수 없습니다. 컴퓨터에 앉아 있지만 가상 관리자가 대역폭을 쉽게 분할 할 수 없으므로 메모리와 CPU로 모든 것이 잘 될 수 있지만 처리 할 수없는 일부 리소스에 병목 현상이 발생합니다. 당신이 그것을 고치려고 노력하면, 오래된 모델은 더 큰 서버를 얻고 그와 비슷한 것을 할 수 있었을 것입니다. 이제는 정말 간단하고 가상 코스를 추가하고 VM에 메모리를 추가하면 해결됩니다. 그러나 VM이 과밀 한 서버에 있고 마이그레이션해야하는 경우 어떻게됩니까? 아니면 AWS 시스템의 크기에 있고 최대 크기에 도달하면 어떻게됩니까?
이제 환경이 데이터베이스의 일부인 이러한 모든 문제가 있습니다. 데이터베이스, 모든 특수 자원, 구성의 일부인 응용 프로그램의 모든 구성으로 환경을 패키지화하면 구성이 푸시됩니다. 이것은 데이터베이스 환경에서 가져온 것이므로 관리 및 제어하기가 훨씬 어렵습니다.
데이터베이스 센터의 활동을 살펴보면 손에 앉아 있었습니까? 우리는 데이터베이스와 서버를 애완 동물처럼 취급한다는이 아이디어에서 멀어졌습니다. 서버에는 이름이 있으며 개별적으로 고유 한 것으로 취급하고 소처럼 취급하고 무리를 관리합니다. 그리고 무리를 관리 할 때의 문제점은, 통제하지 않으면 결국 스탬프를 찍을 수 있고 스탬프는 좋지 않다는 것입니다. 우리는 더 나은 모니터링 도구가 필요하고, 이 문제를 다루는 더 좋은 방법이 필요하며, 무엇이 영향을 받았는지 알고 있어야합니다. 이전 모델에서는 운영 체제와 모든 제어 시스템에서 알려 주었기 때문에 더 쉬웠지만 서버 이름이 UPC 코드 인 경우 상황을 파악하기가 어렵습니다.
잘못된 경고를 감당할 수 없으며 "이 시스템에 문제가 있으며 해당 시스템에 30 개의 데이터베이스를 호스팅하고 있습니다"라는 내용을 감당할 수 없습니다. 기록을 제공 할 여유가 없습니다. 콘솔이 켜지면 모니터링 콘솔이 훌륭하지만, 빨간색 표시등이 다시 녹색으로 바뀌고 그 이유를 모르는 경우, 그 원인을 파악하기 위해 과거로 돌아가는 기록이없는 경우 상황은, 당신은 곤경에 처했다. 우리는 우리를 위해 모니터링 할 시스템이 필요하고, 더 나은 모니터링이 필요하며, 데이터 기록을 유지하는 일시적인 간헐적 문제를 처리합니다.
더 나은 일과 간단한 지표 임계 값으로 주요 지표를 얻을 수 있지만 정상적인 상황, 비정상적인 상황 및 이러한 문제가 발생하는 빈도를 직접 안내하지는 않습니다. 우리가 실제로 이야기하고있는 것은 모니터링 환경과 성능을 다루는 것입니다. 벤더들은 손을 잡고 있습니다. 그들은 우리에게 더 나은 도구를 제공하지 않았습니다. 우리는 우리가해야 할 일보다 많은 CPU와 메모리를 가진 시스템을 가지고 있지만, 여전히 수동 개입 모델에 의존하고 있지만, 기계를 작동시키고, 안내하고, 문제의 지점에 도달하게하지 않았습니다. 우리는이 새로운 스타일을 얻지 못했습니다. "여기에 문제가 있습니다. 문제를 해결하기 위해이 작업을 수행 할 수 있습니다."또는 "성능 문제가 있습니다. 실제로이 특정 SQL 문에 있습니다. 여기에 세 가지가 있습니다. 휴리스틱을 적용하고 시스템 사용 패턴을보고 문제를 발견하고 잘못된 경고를 피할 수있는 기계 학습 모델을 적용하는 휴리스틱을 적용합니다. 머신을 사용하여 머신의 최상의 기능을 수행하거나, DBA를 보강하거나, 성능 문제를 처리해야하는 사람을 보강합니다.
이전 스타일과 달리 새로운 방식입니다. 이 데이터베이스에는 문제가 있고, 속도가 느리기 때문에 새로운 기술과 새로운 방법이 있으며이를 적용해야합니다. 시장이 나아가고있는 곳입니다. 대규모 공급 업체가 아닌 타사와 함께 자라기 시작한 것을 볼 수 있습니다. 이는 데이터베이스 공급 업체가 시스템 관리에 도움이되는 단일 항목을 제공하지 않은 20 년 전에 발생한 일을 반영합니다. 그것이 시장의 방향과 같은 것입니다. 그리고 저는 그것을 시장으로 되돌리고 싶습니다.
에릭 카바나 흐 : 좋아, 데즈에게 넘겨 줄게. 그리고 데즈, 가져 가라, 바닥은 너의 것이다.
Dez Blanchfield : 감사합니다. Mark. 당신은 그것의 기술적 구성 요소를 다루는 환상적인 일을했습니다. 비즈니스와 그 주변의 데이터베이스에 미치는 영향을 제외하고는 세계 다른 지역에서 일어난 일을 강조하기 위해 약간 다른 각도에서 다룰 것입니다. 첫 슬라이드로 넘어가겠습니다.
기술 측면과 개발자 측면에서 방금 다룬 내용을 바탕으로 비즈니스가 특히 데이터 및 데이터베이스의 문제에 직면해야한다는 것을 알았습니다. 이러한 빅 데이터의 개념이지만 데이터베이스는 여전히 효과적으로 조직이 비즈니스 정보를 유지하는 핵심 요소이며 정문에서 백 오피스까지 제공됩니다. 조직의 모든 부분은 어떤 종류의 데이터베이스에 의해 영향을 받고 데이터베이스에 의해 구동되며 데이터베이스 또는 데이터베이스 시스템의 주제가있는 조직에서 프로젝트 토론이나 혁신적인 전략적 대화 형태에 거의 참여하지 않습니다. 성능 및 보안에서 방금 들었던 유형과 개발이 어떻게이 문제에 접근하고 데이터베이스가 적합한 지, 환경 및 애플리케이션에 대한 인식에 대해 항상 궁금한 점이 있습니다. 환경은 장치와 이동성은 어떻습니까?
그것은 여전히 매우 뜨거운 주제이며, 현대 기술이 진행되는 한, 대단한 계획에서 오랫동안 오랫동안 사용되어 왔습니다. 지금까지 우리가 일상 생활, 일상 생활에서 수행하는 거의 모든 것이 현재 어떤 형태의 데이터베이스에서 지원되고 있다고 생각합니다. 우리가 구매하는 일부 서비스에 대해 매일 우편으로 발송되는 청구서이든, 데이터베이스와 통신하는 시스템에 의해 인쇄되는 것이 건 우리 주변의 모든 것들에 대해 생각할 때, 우리는 거기에 있습니다. 우리 전화에는 연락처와 통화 기록 및 기타 정보가 담긴 데이터베이스가 있습니다.
우리가 어디를 가든, 대화 뒤에 어떤 형태의 데이터베이스가 있으며 우리가 사용하는 시스템은 종종 우리에게 상당히 투명하지만 사실은 그들이 거기에 있다는 것입니다. 그래서 나는 이것이 왜 아주 짧은 시간 안에 약간의 문제가 된 이유를 빨리 다룰 것이라고 생각했습니다. 처음에 데이터베이스의 개념은이 사랑스러운 신사 Edgar Codd에서 나왔습니다. IBM에서 일하는 동안 그는 현재 관계형 데이터베이스라고하는 개념을 만들어 데이터 관리가 진행되는 한 세상을 바꿨습니다.
처음에는 데이터베이스가 데이터베이스 였고 수명이 좋았고 열과 참조 등이 상당히 간단했으며 테이블과 소프트웨어 개발은 매우 간단했으며 성능은 그리 큰 문제가 아니 었습니다. 새로운 흥미로운 기술이었습니다. 우리는 어떤 형태의 터미널을 통해 데이터베이스에 액세스했으며, 메인 프레임에서 3270 터미널의 끝 부분과 다른 시스템이 따라온 다른 유형의 터미널에서만 실제로 큰 혼란을 일으킬 수 있습니다. 그리고 대부분의 경우, 구식 터미널은 현재 웹 환경과 매우 유사했습니다. 즉, 터미널 자체의 화면에 양식을 작성하고 Enter 키를 누르면 종료됩니다. 요청으로 하나의 패킷으로 시작하면 백엔드 시스템이 처리합니다. 그것은 요즘 웹 브라우저에서 발생하는 일입니다. 웹 브라우저에 링크를 입력 할 때 그 형식은 일반적으로 실시간으로 시스템으로 돌아 가지 않지만 요즘 AJAX에서는 완전히 그렇지 않습니다. 케이스.
그러나 어떤 일이 일어 났고, 미래가오고, 더 최근에는 인터넷, 그리고 거의 어제 초 웹 2.0에서, 사방에 사물 인터넷이 있습니다. 그리고 미래의 과정에서 데이터베이스의 세계는 방금 폭발했으며 데이터베이스와의 상호 작용은 기본적으로 우리 모두가 한 일이되었습니다. 구매와 같이 무언가를하기 위해 어딘가에 가지 않을 경우는 없었습니다. 비행기 표를 구매하고 지구 반대편으로 여행하고 싶을 때 누군가가 터미널에 모든 세부 정보를 입력하고 데이터베이스에 들어가서 표를 인쇄해야했습니다.
응용 프로그램으로 Google의 택시를 불러 일으키는 지, 인터넷 뱅킹에서 뛰어 내리는 지, 매일 시스템을 사용하여 수행하는 모든 작업, 일종의 시스템으로 데이터베이스에 의해 구동됩니다. 인터넷이 등장했을 때, 그것은 우리에게 조금 더 쉬워졌고, 우리의 일상은 웹 브라우저를 통해 생겼고, 웹 2.0이 등장하여 모바일이되었고, 규모가 폭발적으로 증가했습니다. 사실, 이 주제에서 가장 좋아하는 라인은 "인터넷은 모든 것을 연결하고, 웹 2.0은 모바일 및 소셜로 만들었으며, 사물은 매우 커졌으며 이제는 인터넷과 사물, 그리고 IoT … Yikes !!" 우리는 사물 인터넷이 데이터베이스 시스템에서 세상에 미치는 영향을 상상하기 시작하지 않았습니다.
그래서 현대 용어로, 우리가 단말기로 생각했던 것은 실제로 이러한 것들이되었습니다. 휴대폰, 다양한 종류의 태블릿, 개인용 또는 엔터프라이즈 급 대형 스크린 태블릿, 노트북 및 전통적인 데스크탑입니다. 어떤 형태로. 그 하나의 이미지에서 우리는 지금 우리가 걸어 다니는 작은 가제트에서 데이터베이스 시스템 및 이들에 의해 구동되는 응용 프로그램과 대화하는 데 사용하는 거의 모든 형태의 인터페이스를 볼 수 있습니다. 약간 더 큰 버전, iPad, 기타 태블릿 및 Microsoft Surfaces, 일상적인 랩톱으로의 전환은 이제 전문적인 환경 등에서 항상 그러합니다. 사람들은 고정 된 데스크톱이 아닌 랩톱을 사용하는 경향이 있지만 데이터베이스는 개발뿐만 아니라 우리 삶의 관리 성능 부분에서 모든 종류의 문제를 겪고있는 이유 중 하나입니다.
따라서 비즈니스가 여전히 일상적으로 직면하고있는 가장 큰 과제 중 하나라고 생각합니다. 모두 데이터베이스가 우리의 유일한 문제라고 생각했지만 그렇지 않습니다. 그래서 모든 소란은 무엇입니까? 데이터베이스와 관련된 모든 것, 상업적 의미에서 한 쪽 끝에서 다른 쪽 끝으로 갈 때 Marks는 기술적 구성 요소를 매우 잘 다루었지만 상업적 의미에서 조직으로서 데이터베이스에 대해 생각합니다. 우리는 기본 설계 및 개발 프론트 엔드에서 모든 것을 다루고 있습니다. 비즈니스가 시작되면 응용 프로그램 개발, 기능 개발 또는 기존 응용 프로그램을 어떤 형태로 구현할지 생각하게됩니다. 어떤 형태의 설계 및 개발이 이루어져야하며 이러한 데이터베이스 시스템이 구현, 지원 및 관리되는 방법, 성능 등을 추적하는 방법에 대해 많은 생각이 필요합니다.
데이터베이스 환경과 애플리케이션, API 유형, 제공되는 액세스 유형의 통합이 점점 더 어려워지고 복잡해지고 있습니다. 일상적인 관리, 지원 및 백업은 다시 한 번 우리가 해결 한 것으로 생각되었지만 갑자기 규모가 훨씬 커졌고 상황이 더 빨라지고 볼륨이 훨씬 커졌습니다. 환경의 규모에 따라 데이터베이스 시스템은 트랜잭션이 이동하는 속도를 지원해야했습니다.
매우 높은 빈도의 거래 환경에서 데이터베이스에 대해 생각해보십시오. 인간이이를 추적 할 수있는 방법은 없습니다. 다른 컴퓨터 클러스터와 싸우고 고주파 거래, 구매 및 판매를 수행하는 기계의 클러스터 일뿐입니다. 이러한 거래가 발생합니다. 수백, 수천, 심지어 수십만에 대해 이야기하지 않는 Netflix 영화의 초기 릴리스와 같은 현대 시나리오를 생각해보십시오. 잠재적으로 수백만 명의 사람들이 그 영화가 출시되는 순간부터 그 영화를보고 싶어합니다. 이러한 모든 정보는 데이터베이스 플랫폼에서 캡처, 추적 및 기록 및 분석됩니다.
그리고 지금 우리가 살고있는 상시 작동하는 세상이 24/7입니다. 태양을 따라가는 것이 아니라 자정에 항상 무언가를하고 싶어하는 사람이 있으며, 영업 시간은 전 세계의 태양을 따릅니다. 따라서 가동 시간과 가용성은 기본적으로 현재 기후이며 가동 중단이 실제로 허용되는 것은 아닙니다. 또한 중복성, 성능 문제가 있거나 업그레이드 또는 패치 또는 보안을 수행하기위한 유지 관리 기간이 필요한 경우 실제로는 한 데이터베이스 환경에서 다른 데이터베이스 환경으로 자동으로 원활하게 수행 할 수 있어야합니다.
보안 및 표준 및 규정 준수, 우리는 특히 GFC와 같은 세계에서 매우 큰 일이 일어 났으므로 규정 준수, 보안 및 일치하는 표준과 관련하여 충족해야 할 광범위한 새로운 과제가 있습니다. 실시간으로 이상적으로 대시 보드 형식으로보고 할 수 있습니다. 우리는 원숭이 팀을 데이터 센터로 보내지 않고 물건을 찾으려고합니다. 실시간으로 즉시 알려주는 시스템이 필요합니다.
그리고 거의 아무도 이야기하지 않는 두 가지 큰 재미있는 사람들은 일반적으로 깔개 아래로 밀어 넣고 추악한 머리를 올리지 않고 재난 복구 및 비즈니스 연속성을 기대하기를 희망합니다. 필요한 경우 대부분 자동으로 발생합니다.
우리는 데이터베이스 환경에서 잘못 될 수있는 일에 대해 이야기하고 며칠 동안 인간이 일반적으로 응답했다고 할 수 있지만 이제는이를 위해 시스템과 도구가 필요합니다. 한 가지 예는 데이터 유출이며 데이터베이스에 대해 생각할 때 다양한 형태로이 질문을 공개적으로합니다. 우리가 시선을 끌 때 데이터베이스에 어떤 일이 발생하고 중요한 것이 잘못 되었습니까? 특히 성능과 보안 및 데이터베이스 실행의 다른 주요 측면을 감시하는 시스템이없는 경우.
글쎄, 이것이 일어날 수있는 일은 이것이 지난 2 년에서 3 년 동안의 최근 침입 중 일부의 스크린 샷입니다. 이 모든 것은 데이터베이스 시스템에서 나 왔으며, 보안이나 제어 또는 액세스에 문제가 있었으며, 왼쪽 상단에는 1 억 5 천 5 백만 개의 Adobe 계정이 있습니다. 그 고객 중 하나가 위반되었습니다. 그리고 사건을 추적하고 포착하고 보안을 통제하기위한 적절한 도구가있는 경우, 우리는 그 중 일부를 피했을 수 있습니다. 도난당한 처음 몇 백 레코드가 우리에게 경고했을 것입니다. 다음 5 천만 명이 멈췄어요
그런 다음이 전체 여정의 핵심에 도달했습니다. 즉, 더 나은 시스템이 필요한 이유는 무엇입니까? 왜 우리는이 일에 더 많은 시체를 던질 수 없습니까? 우리는 내 견해에서 전환점을 잘 넘어 갔으며, 늦게 증거가 있었으며 더 많은 DBA, 관리자 및 더 많은 사람들을 던지는 사례가 있다고 생각합니다. 이 문제는 해결되지 않습니다. 더 나은 도구 세트와 더 나은 시스템 세트가 필요합니다.
다음은 제가 이것을 지원한다고 생각하는 5 가지 이유이며, 이러한 민간 기업과 환경에서 통제되는 환경, 데이터베이스 환경에서 직면 한 문제, 그리고 그들을 관리합니다.
보안 및 규정 준수 – 1 위. 액세스 권한이있는 사람, 액세스 권한이있는 위치, 액세스 권한이있는 시간, 액세스 빈도, 액세스 위치를 제어합니다. 잠재적으로 그들이 실제로 만졌던 장치와 그들이 본 것들의 유형, 그리고 그에 따르는 규정 준수. 인간이 30 일 후에 보고서를 실행하여 문제가 더 이상 적절하지 않은지 알려 주면 실시간으로 발생해야합니다.
성능 및 모니터링 – 전혀 생각할 필요는 없지만 항상 그렇지 않습니다. 우리가 오픈 소스 도구를 사용하든 또는 타사의 상용 도구를 사용하든, 필요한 성능 모니터링 유형, 세부 사항 및 시간에 따라 대응하는 능력 등 여러 가지면에서 보트를 놓치지 않았습니다. .
사고 감지 및 대응 – 즉각적인 실시간 작업이어야하며, 항상이를 위해이를 수행 할 시스템이 필요하거나, 최소한 신속하게 경고하여 처리 할 수 있으므로 발생하는 몇 가지 문제를 처리 할 수 있습니다. 신속하게 제어 할 수 있습니다.
관리 및 관리 – 우리는 이러한 문제가 해결되었다고 생각합니다. 데이터베이스 팀, 특히 시스템이 우리를 위해 처리해야하는 DBA가 직면 한 문제의 목표는 아직 해결되지 않았지만 여전히 실제입니다.
그리고 설계 및 개발과 함께 프론트 엔드부터 이러한 도구를 구축 할 때 데이터베이스 환경을 구축하고 개발 및 테스트 및 통합 플랫폼에서 적절한 도구를 던질 수 있습니다. 이것은 여전히 우리에게 쉬운 일이 아니며, 이 전체 여정에서 우리를 같은 메시지로 이끌고 있습니다. 제 생각에는 우리가 필요로하는 결과를 전달할 수 있도록 더 나은 시스템과 더 나은 도구가 필요합니다. 데이터베이스 환경, 고객으로부터 가치를 창출하는 비즈니스. 우리는 더 많은 신체와 더 많은 DBA를 계속 던질 수 없으며, 규모가 너무 크고, 속도가 너무 빠르며, 볼륨이 너무 높습니다. 그걸로 에릭 나는 당신에게 다시 전달할 수 있습니다.
Eric Kavanagh : 좋아합니다. 우리는 많은 사람들과 많은 잠재 고객을 보유하고 있으며, 1 초만에 Bullett로 넘어갑니다.
글 머리 기호 관리 : 알겠습니다.
에릭 카바나 흐 : 아, 그걸 가져 가자, Bullett, 이제 내가 너에게 건네주고, 바닥은 너의 것이다.
Bullett Manale : 알겠습니다. 감사합니다. 좋은 점이 많이 있다고 생각합니다. 나는 우리가 누구인지 Idera에 대해 잠깐 얘기하고 싶었습니다. 그리고 우리는 뛰어들 것입니다. 나는 우리가 이야기하고있는 많은 것들에 대해 생각할 수있는 도구에 대해 이야기 할 것입니다. 이 도구를 사용하여 진단 관리자 제품과 일치하는 일부 영역에 대해 설명합니다.
제가 먼저하고 싶은 것은 이데 라가 누구인지에 대한 배경 지식입니다. 우리는 약 2003 년부터 사용되어 왔기 때문에 SQL Server 도구만으로 시작했으며 오늘날 우리가 집중해야 할 것은 Diagnostic Manager 제품입니다. 그러나 우리는 여기에있는 모든 버킷을 볼 수 있으며 최근에 언급했듯이 Precise를 인수하고 인수를 통해 Embarcadero도 확보하여 제품 포트폴리오가 꽤 좋습니다.
성능 모니터링 측면에서 SQL Server 측면에서 논의하고자하는 주제에 맞는 대화하려는 제품은 진단 관리자입니다. 이 제품은 Idera의 시작과 거의 비슷해 왔으며 2005 년 이래로 그 일부가 될만큼 운이 좋았던 제품입니다. 그리고 저는 여러 측면에서 많은 변화를 보았습니다. SQL Server, 물리적 환경에서 가상 환경으로의 전환, 발생하는 모든 종류의 작업, 환경이 성장함에 따라 DBA의 요구 및 이러한 유형의 작업
제가 처음 시작한 것은 제품의 일반적인 사용자가 DBA 였기 때문에 처음으로 잠재 고객과 이야기 할 때 주로 고객과 대화를 나누는 것은 DBA입니다. 우리는 IT 관리자 나 책임자와 대화하지 않고 어느 시점에서 그 수준에 도달 할 수 있지만, 처음에는 DBA에 문제가 있고 DBA가 문제를 해결하려고 시도하는 경우가 많습니다. 데이터 관리자 나 DBA 또는 연기 DBA (실내에서 가장 기술적 인 사람 일 수도있는 운이 좋은 사람)를 구할 수 있습니다. 이제 더 큰 엔터프라이즈 환경에 도달하면 당연히 본격적인 DBA를 얻게 될 것입니다.이 도구는 일반적으로 도구를 사용하는 DBA입니다. 그리고 나는 Wikipedia에서 약간의 흐림을 추가했습니다. Wikipedia가 말한 것처럼 DBA의 책임을 맡고 있습니다.
여기에있는 목록, 이 많은 것들을 살펴보면, 나는 그것을 읽지 않을 것이지만, 당신은 당신이 생각할 전형적인 것들을 많이 얻었고, 그중 하나에서, 당신은 모니터링을 받았습니다. 데이터베이스의 성능을 최적화하는 것은 꽤 큰 일입니다. 흥미로운 점은 DBA와 대화 할 때 항상 가장 먼저 비난을받는 문제이며 문제가 발생할 때 실제로 문제가 될 수 있지만 실제로는 응용 프로그램에서 성능 문제가있는 경우입니다. DBA 데이터베이스에 묶여 있고, 그들은 비난을받는 사람들입니다. 그래서 그들은 항상 그것이 그들의 잘못이 아닌 이유를 찾고 있습니다. 많은 경우에이 도구 인 진단 관리자를 사용하여 도움을 줄 수 있습니다.
그러나 하루가 끝날 때 데이터베이스가 작동하지 않으면이 다른 많은 것들이 실제로 중요하지 않으며 응용 프로그램이 작동하지 않고 실제로는 중요하지 않습니다. 소지품. 무엇보다도, 우리는 사용자가 우리가 알고있는 방식을 경험할 수 있고, 줄어들지 않으며, DBA가 항상 노력하고있는 것입니다. 사람들이 일반적으로 SQL Diagnostic Manager 제품을 구매하고 사용하는 이유를 살펴보면, 가장 중요한 이유는 아닐 수도 있지만, 전반적으로 동일하지만 그리고 당신이 누구에게 말을 하느냐에 따라, 이러한 이유들 중 거의 한두 가지가 항상 존재합니다.
그러나 첫 번째는 인스턴스에 대한 중앙 집중식보기를 관리중인 SQL로 볼 수 있다는 것입니다. 그리고 재미있는 점은 많은 경우 DBA에 "관리하는 인스턴스 수는 몇 개인가요?"라고 물으면 그 수가 자주 변경되어 어떤 경우에는 실제로 확실하지 않다는 것입니다. 따라서 화면에 모든 것을 던질 수있는 것 이상이 필요합니다. 정보를 파악하고 이해하고 싶기 때문에 Diagnostic Manager가 확실히 도움을 줄 수있는 것 중 하나는 환경에 대한 그런 종류의 견해를 제공하는 것입니다.
또한 환경에 대한 관점 일뿐 아니라 데이터베이스 관리자 인 DBA가 편안하고 DBA 중심의 콘솔이라는 견해입니다. 데이터베이스 관리자를 위해 만들어졌습니다. 모니터링 도구는 많고 성능 도구는 많지만 제가 말했듯이 DBA는 DBA를 위해 설계된 도구를 원합니다. 그들의 일상에서.
그리고 SCOM, HPF, 다른 모든 기술을 보유하고 있지만, 그들이하는 일에 특별한 무언가를 원합니다. 이 제품으로 해당 영역에서 도움을 줄 수 있다고 생각합니다. 잠시 후에 제품을 볼 수 있습니다. 우리가 이전에 만졌던 것들 중 하나 인 DBA에서 볼 수있는 또 다른 것은 그들이 진행중인 일을 분명히 볼 수 있어야하며, 전체 기업을 살펴볼 수 있어야한다는 것입니다. 무슨 일이 일어나고 있는지 알면서 마음의 평화를 누리십시오. 그러나 동시에 콘솔을 쳐다보고 앉아 있지 않습니다.
당신이 그 목록에서 보았던 모든 글 머리 기호를 기억하십시오. 그들은 다른 것들도해야하므로 불이 꺼지기를 기다리는 것이 아닙니다. 대부분의 경우 회의가 있거나 데이터베이스 관리자와 관련된 많은 유지 관리 기간이 한밤중에 자고있을 때 돌아가므로 돌아가서 어떤 일이 발생했는지 확인할 수 있어야합니다. . 많은 경우에, 문제가 발생했을 때, 또는 일단 문제가 사라지거나 적어도 SQL Server와 관련하여 무언가를 포착하지 않으면, 그렇지 않은 상황을 다루는 문제가됩니다. 더 이상 그 문제의 나머지를 가지고 있습니다. 이러한 문제는 사라지고 잔재도 마찬가지입니다. 즉, 문제 해결이 적고 작업 할 정보가 적습니다.
그 말로, 그것은 진단 관리자가 도울 수있는 것 중 하나입니다. 과거에 대한 정보를 쿼리하기 위해 과거에 대한 견해를 제공하는 것입니다.“차단에 대한 경고가 있었습니까? 교착 상태에 문제가 있었습니까? 자원 측면에서 무슨 일이 있었습니까?”돌아가서 그 정보를 쿼리 할 수 있습니다. 특정 시점으로 드릴 할 수 있습니다. 도구 내에서 직접 이러한 모든 작업을 수행 할 수있었습니다.
내부 또는 외부 응용 프로그램인지 여부에 관계없이 DBA는 문제의 원인을 볼 수 있기를 원하기 때문에 알고 싶어합니다. 조직 내부의 사람이거나 코드를 작성한 조직 외부의 사람인지는 중요하지 않습니다. 그들은 여전히 문제를 해결하고 문제가 어디에서 발생하는지 알 수 있도록 격리 할 수 있기를 원합니다.
따라서 성능과 책임은 당사 제품의 핵심 부분입니다. 우리는 모든 세부 사항을 제공 할 수 있으며, 좋은 점은 드릴 다운 할 수 있다는 것입니다. 병목 현상이있는 경우이를 응용 프로그램, 사용자, 데이터베이스, 쿼리와 연관시킬 수 있습니다. 그리고 다시 한 번, 그것은 일종의 흡연 총입니다. 이 쿼리가 실행되는 시점과 직접적인 상관 관계가 있습니다. 그리고 그것은 쿼리 자체뿐만 아니라 자체적으로 실행되는 측면 에서뿐만 아니라 시간이 지남에 따라 쿼리가 악화되고 있습니까? 그리고 이러한 것들에 대해서도 제품에 대한 답변을 얻을 수 있습니다. 이것은 능동적으로 행동하려고한다면, "여기서 나쁘게 실행 된 쿼리가 있지만, 소년은 그것을 보았습니다. 더 나아갈수록 더 나 빠지고있는 것을 볼 수 있습니다. "
우리가 다음 영역으로 가면; 그리고 이것은 아마 – 이것은 이것이 큰 것 중 하나라고 말할 것입니다. 제품을 보여줄 때 질문하는 질문 중 하나는 항상 데이터베이스 관리자에게 "SQL Server 데이터베이스와 관련된 문제에 대해 어떻게 알 수 있습니까?"라는 질문입니다. 그리고 대부분의 경우 – 지금 당장 우리 제품을보고있는 대부분의 시간이기 때문에 매우 재밌습니다. 많은 경우에 그들은 특정한 필요를 해결하려고 노력하고 있기 때문입니다. 그러나 최소한 SQL Server에서 초기 종류의 이야기를 듣는 것은 흥미 롭습니다. SQL Server 초기에는 SQL Server가 있고 Oracle이있었습니다. 그리고 모든 사람들이 Oracle을 가지고 있었고 SQL Server는 데이터베이스가 처음 시작되었을 때 빨간 머리를 띤 데이터베이스의 더 나은 표현이 부족하기 때문에 그와 비슷했습니다.
그런 다음 Microsoft가 더 많은 기능을 추가함에 따라 조금 더 많은 엔터프라이즈 도구가되었습니다. 그리고 분명히, 그 이후로 먼 길을 왔습니다. 그러나 요점은 데이터베이스가 당시에 중요하지 않은 것으로 간주되지 않았다는 것입니다. 그리고 그것은 시간이 지남에 따라 변했습니다. 그로 인해 많은 경우 사람들은 주변을 둘러 보면서 다음과 같이 말합니다. 이 모든 SQL Server 데이터베이스를 보유하고 있습니다. 처리하려고 노력하고 있습니다. "헬프 데스크의 문제 나 사용자와 같은 특정 사람들의 문제에 대해 듣는 것이 아니라 그들은 그 상황이 발생하기 전에 그 상황을 알 수있는 방법을 찾고 있습니다.
그리고 우리가하려고하는 것 중 하나 인 Diagnostic Manager를 사용하여 DBA가 그러한 상황이나 문제에 대해 가장 먼저 알 수 있도록 할 수 있어야합니다. 모니터링되는 시스템을 분석하기 위해 문제가 발생했을 때 또는 한 걸음 더 나아가 야합니다. 또한 해당 인스턴스의 성능을 향상시키고 정기적으로이를 수행 할 수있는 사전 조언을 제공 할 수 있습니다. 예를 들어, 워크로드를 기반으로 인덱스를 추가해야합니다. 이러한 유형의 작업, 수행 할 수있는 도구. 툴에서 많은 것을 볼 수 있습니다.
이 목록에있는 다른 것 및 마지막 것은 일반적인 설명의 일종이지만 확실히 주목할만한 가치가 있습니다. 특히 인스턴스가 많은 대규모 엔터프라이즈 급 유형의 상황에 처할 때 데이터베이스 관리자 인 경우 항상 모니터링하고 싶은 모호한 부분이 있습니다. 예. 그리고 우리가하려고하는 것은 전형적인 DBA가 모니터링하고자하는 것에 대한 관점입니다.
그 말로, 당신은 또한 측면에서 볼 수 있습니다 – 항상 새로운 무언가가있을 것입니다. 따라서 설치 지점을 추가 한 후 모니터링하고 관리해야하는 메트릭을 추가 할 수있는 방법을 제공했습니다. 따라서 모든 PerfMon 카운터, WMI 카운터, SQL Server 카운터 개체; 모든 것을 도구에 통합 할 수 있습니다. 폴링 간격에 통합 할 수있는 추가 쿼리를 추가 할 수 있습니다.
마지막으로 주목할 가치가있는 것은 vCenter와 Hyper-V 모두를 추가하고 실제로 통신하여 이러한 환경에서 메트릭을 가져올 수 있다는 것입니다. DBA로 식별 한 것 중 하나는 일반적으로 구체적으로 작업의 일부가 아니라는 것입니다. 그리고 일반적으로 vCenter 환경, 사용 가능한 환경 또는 사용 가능한 환경이 반드시 필요한 것은 아닙니다.
따라서 문제는 SQL Server 인스턴스를 처리하고 리소스가 할당되었지만 해당 인스턴스가 가상화 된 경우 세상에 모든 리소스가있는 것처럼 보일 수 있습니다. 게스트 운영 체제에서. 실제로는 호스트에 액세스하려는 다른 VM이 30 개, 40 개 또는 50 개 또는 100 개의 다른 VM이 있고 동일한 리소스에 대한 경합이있을 수 있습니다. 실제로 볼 수있는 유일한 방법은 다른 환경과이 경우 인터페이스와 통신하는 것입니다.
이러한 다른 유형의 카운터를 도구에 추가 할 수 있습니다. 이제 해당 카운터를 모니터링 할 수있을뿐만 아니라 새 카운터를 만들어 제품을 소개하고 도구로 사용하여 기본 제공되는 메트릭스처럼 만들 수 있습니다. . 모니터링하고 싶은 즉시 사용 가능한 것. 따라서 대시 보드에 통합 할 수 있습니다. 즉, 보고서를 사용자 정의 보고서에 추가하고, 임계 값을 설정하고 경고 할 수 있지만, 기준선을 설정하고 일부 지식을 통해 임계 값을 설정하여 사용자의 기준과 정상입니다. 그래서, 당신은 또한 제품에있는 많은 종류의 것들을 가지고 있습니다.
제가 여러분에게 제공 한 것은 제가 "진단 관리자를위한 핵심 결과물"이라고 부르는 것입니다. 계속해서 제품에 들어가서 약간의 맛을 볼 수 있습니다. 내 화면을 공유하고, 이걸 드래그하면됩니다. 이제 보시는 바와 같이, 이것은 진단 관리자 용 콘솔입니다. 앞에서 언급했듯이, 첫 번째 핵심 제품으로 가서 이 도구에는 다양한 썸네일보기가 있으며 그리드와 유사한보기가 있으며 유연성 측면에서 볼 때 웹 기반 콘솔에는 주요 맵과 같은 것들과 같이 사용 가능한 다른보기가 있지만, 요점은 여러분이 물건을보고 볼 수있는 능력이 있다는 것입니다 그러나 문제가 발생하면 도구를 조금 더 깊이 파고 들어 실제로 특정 조사를 봅니다. 렘, 그리고 무슨 일이 일어나고 있는지 이해하고 알 수있는 방법이 있습니다. 그리고 분명히 그것은 매우 중요합니다.
이제 과거에 무슨 일이 있었는지 실제로 볼 수 있다는 측면에서; 어제 또는 일주일 전에 발생한 문제를보고 있다면 해당 상황에서 특정 SQL 인스턴스로 이동할 수 있어야합니다. 그리고 좋은 소식은 제품 내에서 문제가 발생한 시간을 알고 있다면 히스토리 브라우저로 바로 이동할 수 있다는 것입니다. 하루 중 특정 시간을 가리킬 수 있습니다. 몇 주 전일 수도 있고 어제 일 수도 있습니다. 그러나 달력에서 어떤 날을 선택하든 다른 폴링 간격이 표시됩니다. 어떤 경우에, 나는 4 월 20 일 오후 1시 37 분에 콘솔을 보았을 때 내가 보았던 것을 효과적으로보고 있습니다.
그래서 시간을 거슬러 올라가서 일단 그렇게하면, 여기에 보이는 모든 다른 탭들은 아마도 특정 시점을 반영 할 것입니다. 차단 세션이있었습니다. 이러한 모든 종류의 도구가 도구에 표시 될 것입니다.이 역사적인 정보를 분명히 활용하여 문제를 해결할 수 있습니다. 이제 우리가 역사에 관해 이야기 할 때, 여기서 주목할 가치가있는 다른 것은 단지 문제를 해결하기 위해 역사를 사용하는 것이 아니라는 것입니다. 그 역사는 다른 이유로 분명히 매우 가치가 있습니다. 그리고 가장 중요한 것은 올바른 정보를 사용하여 효율적으로 의사 결정을 내리고 신속하게 의사 결정을 내릴 수 있다는 것입니다. 그 모든 역사, 수집하는 모든 정보를보고 할 수 있습니다.
누군가가 내게 와서 "이것은 정말 새로운 응용 프로그램을 얻었습니다. 우리가 알고있는 것처럼 세상을 바꿀 것입니다. 오, 데이터베이스가 필요하고, 오. 해당 데이터베이스가있는 시스템의 I / O " 내가 그것을 알고 있다면, 그 정보를 활용하여 지난 7 일 동안 수집 한 모든 프로덕션 서버의 순위를 제공 할 수 있습니다. 그리고 어떤 데이터베이스가 해당 데이터베이스를 사용하는 것이 가장 적합한 지에 대한 결론에 매우 빨리 도달 할 수있었습니다. 따라서 그것은 매우 귀중한 유형의 역사적 정보입니다.
쿼리 자체 측면에서; 검색어를 살펴보면 도구에서 여러 가지 방법으로이를 수행 할 수 있습니다. 그리고 내가보고 싶은 것은 Query Waits View입니다. Query Waits View는 평가할 수 있다는 점에서 매우 유용하기 때문입니다. 병목 현상이 발생하는 경우 해당 특정 쿼리에 영향을 미치는 다른 모든 영역을 본질적으로 식별 할 수 있습니다. 쿼리 자체와 해당 쿼리의 영향이 무엇인지뿐만 아니라 어떤 응용 프로그램에서 왔는지, 어떤 세션에서 왔는지, 어떤 사용자를 호출했는지, 모든 정보에 대해 알 수 있습니다. 실시간으로 볼 수 있지만 과거의 데이터를 볼 수도 있습니다. 그리고 그것은 여기에있는 것 중 하나이며, 스크립트를 시작했지만, 팝업이 나올 때까지 기다려야합니다.
기다리는 동안 저는 시간이 부족하다는 사실을 알고 싶습니다. 따라서 미리 알리는 경고 알림에 대해서도 조금 이야기하고 싶었습니다. 내가 말했듯이 능동적 인 부분에 대해 이야기 할 때 경고하는 도구가 많이 있습니다. 어려운 부분은 이메일을 보내지 않습니다. 어려운 부분이 이벤트 로그에 쓰거나 SNMP 트랩을 생성하지 않습니다. 어려운 부분은 적절한 시간에 경고를 보낼시기를 알고 있습니다. 따라서 그 계산에 많은 계산이 필요합니다. "특정 인스턴스에 대한 것이 무엇인지, 해당 인스턴스에 관련된 정상적인 것은 무엇입니까?"를 이해해야합니다.
따라서 이와 관련이있는 모든 측정 항목에 대해 해당 측정 항목의 기준을 정합니다. 우리는 실제로 기준을 보여줍니다. 현재 설정된 임계 값을 보여줍니다. 그리고 다른 좋은 점은, 이 예제에서는 임계 값을이 경우 6과 10으로 설정 한 것입니다. 6 주 후이 인스턴스로 돌아 오면 기본 기준을 계산할 때 수행하는 작업 중 하나가 기본적으로 7 일 동안 진행되므로이 기준이 완전히 변경 될 수 있습니다. 항상 최신 버전의베이스 라인을 제공합니다. 기준이 임계 값으로 올라가면 어떻게됩니까? 이 경우 기본적으로 다음과 같은 권장 사항을보고 경고 할 수 있습니다. "여기, 임계 값이있는 위치 및 기준선의 위치에 따라 잘못 설정된 임계 값이 있습니다. 아마도 정상적인 상황에 대한 경고를 받고 있습니다. "
따라서 정상적인 증상을 치료하지 않고 실제 임계 값이 잘못 설정된 상황을 식별 할 수 있습니다. 그리고 분명히 내가 할 수있는 것은 경고를받을 위치에 따라 임계 값을 설정하는 것입니다. 그것이 실제로 문제인지 알아보기 위해 조사를 요구하는 것보다 조사를 요구하는 것으로 알고 있습니다. 그리고 도구의 일부가 기준 자체와 계산 측면에서 실제로 도움이된다고 생각합니다.
이제이 제품을 사용하면 실제로 여러 기준을 가질 수 있습니다. 서로 다른 기간에 대해이를 설정할 수 있으며 기준선을 기준으로 임계 값을 동적으로 조정할 수 있습니다. 이는 SQL Server 인스턴스에 대한 일상적인 변경에 적응하는 데 매우 중요한 부분이기도합니다. . 이제이 경우에는 임계 값의 많은 설정을 다루고 기준선을 보여줍니다. 그러나 실제 경고에 관한 한, 진단 관리자의 멋진 점인 알림 자체는 여러 경고 프로필을 제공한다는 것입니다. 예를 들어 오전 2 시부 터 오전 5 시까 지의 온콜 프로파일이있는 경우 해당 시간 범위에만 해당하는 프로파일을 가질 수 있으며 여기에서 모든 조건과 적절한 설정을 지정할 수 있습니다. 내 답변에.
이제 응답에 대한 것은 전자 메일을 보내거나 SNMP 트랩을 발사하여 생성하거나 이벤트 로그에 쓸 수 있다는 것입니다. 우리가 할 수있는 다른 많은 것들이 있지만, 제가 DBA와 이야기 할 때, 그들이 실제로 좋아하는 것은 대부분의 경우 수행되는 많은 작업이 반복적 인 작업이라는 사실입니다. 문제가 발생한시기를 정확히 알고 문제를 해결하기 위해해야 할 일입니다. 그들은 그냥 가서 개입해야합니다. 따라서 환경이 성장함에 따라 인스턴스가 많을수록 수행하기가 훨씬 어려워집니다. 따라서 도구 내에서 주목할 가치가 있다고 생각하는 것 중 하나는 조건을 설정할 수 있지만 해당 조건을 기반으로 스크립트를 실행하고 응답을 실행하도록 응답을 설정할 수 있다는 것입니다. 작업, 실행 파일을 실행합니다. 그리고 요점은 스크립트를 실행하기로 결정하면 런타임에있을 스크립트 내부에서 실제 정보로 채워지는 매개 변수를 사용할 수 있다는 것입니다.
따라서 특정 데이터베이스에 문제가있는 경우 스크립트는 문제가 발생한 데이터베이스에 대해서만 실행되도록 설계됩니다. 따라서 자동화 된 방식으로 문제를 동적으로 처리 한 후에도 여전히 "문제가 있었지만 해결 된 문제"라는 이메일을 다시받을 수 있습니다. 스크립트가 실행되었고 DBA로서 알고 있었지만 실제로는 개입 할 필요가 없었습니다. 이제 사전 예방 적이라는 동일한 참고 사항에 "분석"기능인 다른 기능도 있습니다. 그리고 이것이 할 일은 SQL 인스턴스에 대해 정기적으로 점검하는 것입니다. 그리고 어떤 경우에는 찾고자하는 측면에서 더 심도있는 다이빙을합니다. 가상 인덱스 분석과 같은 것들이 수행됩니다. 색인을 추가합니까? 색인을 제거합니까? 그리고 그러한 모든 것들이 분명히 나의 공연에 도움이 될 것입니다. 그러나 다시 한 번, 그것은 능동적 인 것입니다. 문제가 발생하기 전에 결정을 내리고 더 잘 운영 할 수 있도록하는 것입니다. 그리고 많은 경우에, 그것은 우리가 여기서하려고하는 것입니다.
쿼리로 돌아 가기 앞에서 이야기했던 것을 기다립니다. 보시다시피 여기에 큰 스파이크가 있습니다. 나는 대기 활동을 일으킨 스크립트를 더 일찍 실행했으며, 앞에서 언급했듯이이 정보를 드릴 다운 할 수있는 고유 한 방법이 있습니다. 어떤 응용 프로그램인지 확인하려면 NoSQL 응용 프로그램에서 나온 것을 볼 수 있습니다. 우리는 그것이 연결된 데이터베이스, 세션, 사용자를 볼 수 있으며, 원한다면 대기 시간으로도 순위를 매길 수 있습니다. 그래서, 나는 그 창에서 일어난 모든 대기 중 어떤 것이 가장 많이 발생했는지 말할 수 있습니다. 그리고 그것이 가장 많이 일어 났을 때, 정말 좋은 점은 그 대기 유형을 드릴 할 수 있고 모든 명령을 볼 수 있다는 것입니다. 당신이 여기를 보면, 그들은 그 대기가 일어나게 만들고 있었어요. 또한 주로 어떤 응용 프로그램이 대기 시간을 발생 시켰는지 확인할 수 있습니다.
엄지 손가락처럼 튀어 나옵니다. "이것은 내 병목 현상을 일으키는 응용 프로그램입니다. 이제 실행 된 쿼리는 무엇입니까? 어떤 사용자가 실행 했습니까? 어떤 데이터베이스에 대해 실행 되었습니까?"등이 있습니다. 또한 데이터베이스와 관련하여 환경 내에서 대기 시간이 없는지 확인하는 데 도움이됩니다. 이것이 도움이 되길 바랍니다.이 시점으로 진행하여 다시 전달하겠습니다. 우리는 거기서부터 계속할 수 있습니다.
Eric Kavanagh : 물론입니다. 그래서 나는 오늘의 전문가에게 그것을 던질 것이라고 생각합니다. 마크, 어쩌면 먼저 댓글을 달고 몇 가지 질문을하고 싶을 수도 있습니다. 그런 다음 데즈, 당신은 차임 할 수 있습니다.
Mark Madsen : 예, 감사합니다.이 중 일부를 보는 것이 정말 즐거웠습니다. 내가 보던 것보다 훨씬 더 지능적인 모니터링입니다. 이 데이터 뒤에있는 데이터를 관리하는 것이 궁금합니다. 추적 할 수있는 측정 항목을 관리 할 때 대시 보드를 사용하여 기준선을 바꾸는 것과 같은 문제를 찾아야합니다. 이 데이터를 다루는 방법과 그 두 번째 부분은 일종의 변화와 같은 기준 메트릭을 사용하는 것입니다. 임계 값도 자동으로 이동하여 자동으로 임계 값을 이동할 수있는 능력이 있습니까? 기준선이 바뀌면 손으로 다시 들어가서 임계 값을 재설정합니까?
Bullett Manale : 그렇습니다. 좋은 점은 그것을 결정할 수 있다는 것입니다. 어느 쪽이든 할 수 있습니다. 임계 값을 설정하여 정적 설정으로 만들거나 "이 기준을 변경하면 동적 임계 값으로 설정합니다."라는 확인란을 선택하면 기본 창을 설정할 수있는 기능과 도구가 있습니다. 그러나 필요한 경우, 예를 들어 오전 2 시부 터 오전 5 시까 지 유지 보수 기간과 같은 별도의 기준 기간이있을 수 있습니다. CPU, 내 드라이브 및 그 밖의 모든 것이 유지 관리 작업을 모두 수행 할 때이므로 자동으로 수행하도록 선택한 경우 자동으로 임계 값을 조정하여 해당 메트릭에 대해 정상적인 위치를 벗어나게합니다. 기본적으로 도구 내에서 기준 창인 시간 창을 설정하는 기능이 있으며 각 창은 다음과 같은 관점에서 별도의 개체로 취급 될 수 있습니다. 동적 기준선 조정이 가능하며 기준선의 창을 요만큼 추가 할 수 있습니다. 말이된다면 말이됩니다. 주말 창, 근무 시간 중 주중, 한밤중에 발생하는 유지 관리 창 등을 가질 수 있습니다.
마크 매드슨 : 감사합니다.
Bullett Manale : 질문의 첫 부분으로 돌아가서이 정보를 모두 수집합니다. 아키텍처에 대해서는 언급하지 않았지만 백엔드 리포지토리에는 데이터 보존을 완벽하게 제어 할 수 있지만 심야에 실행되는 서비스도 있습니다. 모든 기본 계산과 데이터를 수집하고 수집하여 이해합니다. 그리고 분명히 그와 함께 특정 지표에 대해 기준에 대해보고하는 데 사용할 수있는 수많은 보고서가 있습니다. 또한 동일한 기간 동안 동일한 메트릭에 대해 동일한 서버의 기준을 비교할 수도 있습니다. 차이가 발생했는지 또는 델타가 무엇인지 확인할 수 있습니다. 이러한 유형의 옵션도 많이 있습니다.
에릭 카바나 흐 : Dez.
Dez Blanchfield : 한 가지 간단한 질문입니다.이 도구가 수행 할 수있는 작업에 대한 광범위한 스펙트럼이 있습니다. 현재 개발 초기 단계에서이 소프트웨어를 사용하고 있습니까? 아니면 여전히 기본적으로 프로덕션 환경 도구입니까? 다시 말해 개발자가 초기 개발을 통해 액세스하여 사용하고 통합 단계를 테스트하고 있습니까? 아니면 여전히 프로덕션 환경에서 주로 사용됩니까?
Bullett Manale : 대부분의 경우 프로덕션 환경에서 볼 수 있습니다. 상황에 따라 다르지만 대부분 생산과 우리가 주로하는 말입니다. 또한 개발 및 테스트 환경에 따라 가격이 다르기 때문에 조금 더 매력적입니다. 우리는 사람들이 그 환경에 그것을 사용하는 것을 보았습니다.하지만 나는 당신에게 어떤 식 으로든 대답을 주어야한다면, 사람들 이이 제품에 대한 투자를하는 것이 여전히 생산 환경이라고 말하고 싶습니다. .
Dez Blanchfield : 물론 그렇습니다. 분명히 다른 워크로드가 있고 실제 작업이 수행되는 곳이 많을수록 더 많은 가격이 책정됩니다. 그러나 저는 많은 조직, 특히 정부, 특히 국방 분야에서 많은 개발을 겪고 있습니다. 현재 개발 환경은 툴과 시스템에 프로덕션 환경과 동일한 수준의 투자를 받고 있습니다. 예를 들어 방어에는 수십억 개의 테스트, 수십억 개의 테스트를 응용 프로그램 및 시스템 및 도구에서 실행하고 통합 테스트를 시작하기 전에 모니터링하는 팀이 있습니다. 왜냐하면 빌드 된 코드와 데이터베이스가 있는지 확인하기 때문입니다. 아래에 앉아 있습니다. 그것은 누군가가 현장에서 촬영하는 동안 일억 일회 반복 또는 무언가에 도달하지만, "뱅"하지 않습니다.
불릿 관리 : 물론입니다.
Dez Blanchfield : 제 경험에 따르면 구식 데이터베이스 세계에서 데이터베이스 환경은 데이터에 남겨져 있고 일부는 아는 바가 거의 없으며 거의 말하지 않는 것으로 생각합니다. 앱은 특히 분석 플랫폼을 사용하여 개발되고 있으며 이제는 핸드셋과 장치에 있습니다. 클라이언트가 단순한 기술 전문가가 아닌 일상적인 토론에서 데이터베이스 성능 및 데이터베이스 관리 대화를 가져 오는 것을보고 있습니까? 그리고 앞서 언급 한 것을 압니다. 주로 DBA와 이야기하고 있지만, 일반 어휘에 나오는 경향이 있습니까? 괴짜와는 달리 사람들이 이러한 주제를 논의하는 곳을보고 있습니까?
Bullett Manale : 말하기 힘든 일입니다. 내가 말했듯이, 어쨌든 우리가 판매 프로세스와 관련하여 다루는 사람들은 DBA 인 실무자입니다. "일반적으로 IT 조직의 사람들은 데이터베이스를 더 많이 인식하고 있습니까?"라는 질문에 대한 대답 일뿐입니다. 아마도 대답은 "예"라고 생각합니다. 나는 아마도 내가 어디에 있는지에 따라 매일 그것을 많이 보지 못하지만, 당신의 질문을 이해하고 있다면 그것이 내 대답이라고 생각합니다.
Dez Blanchfield : 예, 괜찮습니다. 아마도 당신의 세계에 대한 당신의 주요 관심사는 기술적 인 측면이기 때문에 아마도로드 된 질문 일 것입니다. 나는 일상적인 활동에서 조직이 대화를 매우 빨리 시작하기 시작한다는 것을 알고 있습니다. 따라서 새로운 이니셔티브, 새로운 프로젝트, 새로운 작업 프로그램에 대해 이야기 할 때 "곧 모니터링하는 방법, 추적하는 방법, 발생하는 문제를 처리하는 방법, 발사하는 것과는 달리 생방송을 하는가? "
Bullett Manale : 그런 말을하겠습니다 –
Dez Blanchfield : 죄송합니다.
Bullett Manale : 나는 내가 말해야 할 경향을 보게 될 것이라고 말하려고했는데, 과거에는 많은 문제가있었습니다. "우리는 문제가 있었으므로 이제 도구가 필요합니다. " 그리고 우리는 문제가 발생하기 전에 도구를 제자리에 두는 것에 대해 조금 더 수용하고 있다고 생각합니다. "이것은 우리가 모니터링 툴이 필요하고 무언가가 필요합니다." 새로운 인스턴스를 추가하려면이를 관리 할 수있는 것이 필요하며, 이를 관리하는 데 도움이되는 것이 필요하기 때문에이 제품과 관련하여 많은 수용이 이루어지고 있습니다.
Dez Blanchfield : 빠른 질문입니다. 이것이 어디에서 살아야합니까? 데이터베이스 환경에 최대한 가깝게 LAN, 데이터 센터 내에서 LAN에 대한 백번에 바로 앉아야합니까, 아니면 클라우드에있을 수 있습니다. VPN 터널 또는 다양한 환경에 대한 원격 액세스 환경과 모니터링에 관한 한 어디에 앉아야합니까?
Bullett Manale : 아키텍처 측면에서 백엔드 저장소가 있으며 이는 SQL Server 데이터베이스입니다. 우리는 팻 클라이언트 또는 씬 클라이언트가 될 수있는 콘솔을 가지고 있습니다. 우리는 둘 다의 옵션을 제공합니다. 또한 모바일 장치를 위해 특별히 설계된 씬 클라이언트도 있습니다. 그러나 이것이 실제로 앉을 수있는 위치와 관련하여; 그것은 우리가 수집해야 할 많은 정보로부터, 관리 권한을 요구하는 경우, 또는 많은 경우에, 환경에 대한 까다로운 부분 일 수 있습니다. 이제는 그렇게하지 않습니다. 원하는 경우 데이터를 수집 할 수 있으며 수집 할 수없는 항목에 대해서만 관리 권한이 없기 때문에 해당 정보를 선택하지 않으면 해당 정보를 볼 수 없습니다.
취향에 따라 AWS에 대해 이야기하는 것처럼 일부 환경은 다른 환경보다 더 효과적이지만 실제 환경 자체는 일반적으로 SA 인증을 사용하여 인스턴스에 대한 데이터를 수집하는 것이 필요합니다. 또는 신뢰할 수없는 도메인 인 경우 일반적으로 여러 도메인을 원합니다. 그들 사이에 신뢰가있는 한, 우리는 그것들에 대해 수집 할 수 있습니다. LAN 또는 WAN에 있는지 여부는 실제로 중요하지 않습니다. 실제 수집 자체는 수집하는 데이터 양 측면에서 무시할 수 있습니다. 충분한 크기의 WAN 연결이 있으면 문제가되지 않습니다. 미국 전역에 SQL Server가있는 지점이있는 환경을 보았습니다. 그리고 서로 다른 위치에있는 하나의 서버이며 중앙에서 모니터링합니다. 까다로운 부분은 적절한 연결을 유지하는 것입니다. 바라건대, 그것은 당신의 질문에 대답합니다.
Dez Blanchfield : 그렇습니다 . 감사합니다. 오늘 아침에 참석자들에게 닥친 두 가지 질문이 있습니다. 그 중 하나는 다음과 같습니다. 영향은 무엇입니까 – 종종 시스템 모니터링 도구는 사물을 모니터링하여 자체적으로 부하를 생성하는 것을 볼 수 있습니다. 따라서 문제는 화면에서 스크롤되어 죄송하지만이를 역설적으로 표현하는 것입니다. 모니터링을 통해 자체 부하를 생성하고 있습니까? 환경을 관찰하는 것만으로 도구가 측정 할 수있는 영향이 있습니까, 아니면 무시할만한 영향입니까?
Bullett Manale : 데이터를 가져 오기 위해 SQL Server 인스턴스를 쿼리해야하기 때문에 항상 약간의 영향이 있습니다. 당신이 말한 질문은 "그건 무시할 만한가 아니면 중요한가?"입니다. 인스턴스를 가리키는 즉시 무시할 수 있습니다. 우리는 내가 말했듯이 꽤 오랫동안 이것을 해왔습니다. 우리는 20, 000 명 이상의 고객을 보유하고 있으며, 성능에 중대한 영향을 줄 경우 비즈니스에 있지 않을 것이라고 확신 할 수 있습니다. 이를 통해 사용자는 모니터링 할 대상을 결정할 수 있습니다. 이것이 중요한 것은 모든 환경이 약간 다르다는 것입니다.
예를 들어, 쿼리 모니터링 구성 요소를 사용하여 수행 할 수있는 기능 중 하나는 정상 경계로 간주하는 대상의 임계 값을 설정할 수 있다는 것입니다. 따라서 쿼리 실행 시간을 기반으로 할 수 있습니다. CPU, I / O를 기반으로 할 수 있지만, 예를 들어 실행 시간을 0 밀리 초로 설정했다고 가정 해 봅시다. 실제로 내가 도구에 지시하는 것은 마지막 당기기 간격 이후에 실행 된 모든 쿼리를 수집하고 해당 기록 컬렉션의 일부를 만드는 것입니다.
이제 우리는 마지막 폴링 이후 상자에서 실행중인 쿼리 양을 수집 할 것입니다. 이제는 선택적이고, 사용자는 그렇게 할 수 있습니다. "우리가해야 할 일"이라고 말합니까? 아니요.하지만 정보를 수집 할 수있는 데이터 샘플을 원할 경우이를 수행 할 수있는 옵션도 제공합니다. 도구를 사용하여 원하는 내용에 따라 원하는 방식으로 정확하게 조정할 수 있지만 원하는 경우 실제로 열 수 있으며 정기적으로 필요하지 않은 추가 정보를 많이 수집 할 수 있습니다 말이된다면 말이다.
Dez Blanchfield : 그렇습니다. 나는 우리가 조금 오래 달리고 있다는 것을 알고 있지만, 마무리하기 전에 당신에게 던지고 싶은 두 가지 큰 질문이 있습니다. 둘 다 저에게 직접옵니다.하지만 대답하면 가장 좋습니다. 문제는 일반적으로 "기존 시스템에 대한 지식이있는 한이 도구의 범위는 무엇입니까?"였습니다. 따라서 플러그를 꽂고 거기에있는 플랫폼을 자동으로 감지하고 해당 플랫폼에 대한 정상적인 상황을 즉시 알 수있게 할 수 있습니다 Mark가 앞서 이야기했듯이, 플랫폼에 대한 기본 지식 중 일부는 Microsoft Dynamics가 될 수 있다는 것을 알고 있습니다. 플랫폼에 대한 지식의 범위는 무엇입니까? 비즈니스에 사용되는 최신 상용 도구 중 일부에서
Bullett Manale : 일반적으로 SQL 인스턴스에서 데이터 수집을 시작할 때 임계 값과 설정 위치와 관련하여 모범 사례를 사용하여 시작한다고 말하고 싶습니다. 또한 모범 사례와 관련하여 대화하는 사람마다 환경이 다릅니다. 처음에 수행 할 작업은 데이터를 수집하고 사람들이 권장하는 작업으로 필요한 경우 14 일 더 제품을 사용해 볼 수 있습니다. 그러나 이틀 정도 지나면 기본 데이터가 채워지기 시작합니다. 작업하기에 충분한 샘플 정보가 있으면 기준선, 범위 및 모든 종류의 항목에 대한 컨텍스트를 제공하기 시작합니다. 그런 다음 원하는 경우 수집 된 정보에서 임계 값을 자동으로 설정할 수 있습니다. 초기 값 수집 및 폴링에 약간의 시간이 소요되어 정상을 판별하기 시작하여 임계 값 이동을 시작할 수 있습니다.
그러나 내가 생각할 가치가 있다고 생각하는 것은 임계 값을 변경하면 인스턴스별로 그룹별로 수행 할 수 있다는 것입니다. 하나의 인스턴스에만 적용되거나 모든 인스턴스에 대해 수행 할 수있을뿐만 아니라 템플릿과 같은 것을 생성하는 기능을 통해 "이것은 프로덕션 인스턴스이지만이 템플릿은 원하는 템플릿입니다" 할당 할 수 있습니다. " 따라서 새로운 프로덕션 인스턴스가 온라인 상태가되면 동일한 유형의 하드웨어와 일반적으로 동일한 작업 부하를 가지므로 이러한 임계 값을 자동으로 적용합니다. 따라서 동일한 방식으로 수행 할 수 있습니다. 잘하면 그것은 질문의 측면에서 도움이됩니다.
Dez Blanchfield : 그렇습니다 . 사실, 당신은 실제로 나에게 온 또 다른 질문에 대답했습니다. "시험판이 있습니까?" 나는 대답 할 수있다. 무료 다운로드가 있음을 확인한 후 웹 사이트에서 14 일이 지난 것 같습니다. 다운로드하여 사용할 수 있습니다. "시험을 실행하려면 어떤 종류의 환경이 필요합니까? 랩톱에서 실행하고 게임을하거나 서버가 실제로 필요한가요?"
Bullett Manale : 필요한 것은 2005 년 이상의 SQL Server 데이터베이스 인 리포지토리입니다. 그 외에도 최소한의 리소스 요구 사항, .NET 요구 사항이 있습니다. 따라서 제품을 설치하고 데이터베이스를 작성하면됩니다.
Dez Blanchfield : 완벽합니다. 마지막 질문은, 우리는 지금 시간이 촉박했기 때문에 두세 사람이 나에게 물었다. "실제로 일을 시작할 수 있으려면 DBA가되어야합니까? 이거 랑 같이 놀아?”
Bullett Manale : 아니요. DBA 인 경우 도구를 다르게 사용할 수 있습니다. 노련한 DBA라면 아마 조금 더 가치가있을 것입니다. 활용할 수있는 도구의 깊이를 훨씬 더 많이 보게 될 것입니다. 또한 새로운 DBA 또는 DBA가 아닌 사람으로서도 많은 권장 사항이 있으며 현재 해당 페이지에 있습니다. 이러한 권장 사항은 정기적으로 제공되며 권장 사항에 대한 정말 좋은 점은 권장 사항을 제시하는 이유를 제공한다는 것입니다. 그러나 그 외에도 권장 사항이 작성된 이유에 대해 더 자세히 설명하는 외부 콘텐츠에 대한 링크가 있습니다. 외부 Microsoft 웹 사이트, 블로그 및 모든 종류의 사이트에 연결됩니다.
그러나 귀하의 질문에 대답하기 위해, 당신이 고위 DBA라면, 여기에 물건이있을 것입니다. 아마도 초보자 DBA가 아닐 것입니다. 그러나 동시에 이러한 권장 사항도 학습 도구의 일종입니다. 이러한 권장 사항을 수행 할 때 권장 사항을 사용하여 자체적으로 일부를 선택하기 시작합니다.
Dez Blanchfield : 환상적입니다. 감사합니다. 나는 데모 부분을 정말로 즐겼다. 프레젠테이션은 훌륭했습니다. 데모는 환상적이었습니다. 메모리에서 빠르게 웹 사이트에 사람들이 살펴볼 것을 권장하는 전체 리소스 센터가 있습니다. 나는 지난 밤에 세부 사항을 얻기 위해 겪었던 것을 기억합니다. 블로그와 데이터 및 대화에서 메모리에 이르기까지 모든 범위의 제품을 가지고 있으며 대부분의 제품 설명서도 온라인으로 이용할 수 있습니다.
Bullett Manale : 네, 맞습니다. 그리고 여러분이 참조한다고 생각하는 형식은 community.idera.com 웹 사이트입니다. 그리고 앞서 언급 한 한 가지는 "환경을 인식 할 것입니까?" 새 인스턴스 또는 인스턴스 추가와 관련하여 인스턴스 검색을 수행하는 또 다른 도구가 있습니다. 그리고 그것은 재고와 재고 관리에 관한 것입니다. 실제로 인스턴스를 발견한다는 관점에서 그 방향으로 당신을 가리 키려고합니다. 그러나 실제로 성능 및 모니터링과 관련하여 우리가 이야기 한 모든 종류의 내용은 진단 관리자가 사용하는 곳입니다.
Dez Blanchfield : 환상적입니다. 보세요 당신의 프리젠 테이션을 정말로 즐겼습니다. 라이브 데모를 좋아했으며 오늘 아침 10 분이 지났음을 알았습니다. 에릭, 다시 돌려 줄게
에릭 카바나 흐 : 좋습니다. 나는 단지 데모를 좋아했다. 데모를하게되어 기쁩니다. Q & A를 진행하면서이 점을 잘 살펴 봐야합니다.
불릿 관리 : 훌륭합니다.
Eric Kavanagh : 이것은 사람들에게 당신이보고있는 것에 대한 아이디어를 제공하기 때문에, 우리가 컴퓨터에 바로 접근 할 때 우리가 여전히 이러한 컴퓨터와 대화하는 방법에 대해 배우고 있다고 생각하는 것은 정말 놀랍습니다. 내 말은, 이 수준의 진단은 매우 정교하며 매일 나아지고 있습니다. 실제로 무슨 일이 일어나고 있는지 더 많은 통찰력을 얻고 있습니다. 그러나 당신은 정말로이 물건을 내려다보고, 읽고, 인지 능력을 당신이하고있는 일의 뒤에 놓는 사람이 필요합니까?
Bullett Manale : 그렇습니다. 많은 경우에 의미가 있습니다. 이것이 박스에 들어있는 DBA라고 말할 수 있기를 원하지만 너무 많은 일이 일어나고 있습니다. 우리는 지침을 제공하고 도움을 제공하지만 하루가 끝나면 사람들이 우리가 제시하는 데이터에 대한 결정을 내려야합니다. 나는 그것이 곧 변할 것이라고 생각하지 않습니다.
에릭 카바나 흐 : 사람들에게 좋은 소식입니다.
Bullett Manale : 맞습니다.
에릭 카바나 흐 (Eric Kavanagh) : 당신은 누군가 이것을보고, 팀이 이것을보고 싶어 할 것입니다. 그리고 여기 Bullett에서 들었던 것처럼, 여러분이 무슨 일이 일어나고 있는지에 대한 권장 사항을보고 배울 것입니다. 그리고 나는 그 역사에서 추측하고 있습니다. 그리고 여러분이 이것에 대해 언급했다고 생각합니다. Bullett, 그러나 아주 빨리, 그 역사는 당신이 중요한 패턴을 인식하고 미래에 일어날 때 그것들을 식별 할 수있게 해줍니다.
Bullett Manale : 맞습니다. 우리가 할 수있는 것 중 하나는 시간이 지남에 따라 쿼리의 성능을 추적하는 것입니다. 우리는 또한 기준선과 같은 다른 것들을 분명히보고 변화하는 것을 볼 수 있으며, 그러한 일이 발생했을 때 경고와 같은 것을 분명히 얻을 수 있습니다.
에릭 카바나 흐 : 잘 들립니다. 우리는 오래 가지 않았지만 그 질문에 도달하고 싶었습니다. 시간과 관심에 감사드립니다. 우리는이 모든 웹 캐스트를 보관합니다. Techopedia.com 또는 InsideAnalysis.com에 온라인으로 연결하면 두 곳의 링크가 표시됩니다.
그리고 우리는 당신에게 작별을 고합니다. 다시 한 번 감사드립니다. 다음 주, 화요일, 수요일, 목요일에 3 번 더 웹 캐스트를 진행하겠습니다. 다음 주에 얘기하겠습니다. 조심해 안녕.
Techopedia 컨텐츠 파트너
Techopedia 직원은 Bloor Group과 제휴하여 오른쪽 옵션을 사용하여 연락 할 수 있습니다. 업계 파트너와 협력하는 방법에 대한 자세한 내용을 보려면 여기를 클릭하십시오.- 프로필
- 웹 사이트
