작성자 : Techopedia Staff, 2016 년 5 월 26 일
테이크 아웃 : 호스트 Eric Kavanagh는 최신 Hot Technologies 에피소드에서 Robin Bloor, Dez Blanchfield 및 Bullett Manale과 데이터베이스 관리 및 인스턴스 검색에 대해 논의합니다.
현재 로그인하지 않았습니다. 비디오를 보려면 로그인 또는 가입하십시오.
에릭 카바나 흐 : 괜찮아요 신사 숙녀 여러분. 다시 한 번 환영합니다. 제 이름은 Eric Kavanagh입니다. 상황이 뜨겁습니다. 여기에 물건이 뜨거워지고 있습니다. 무슨 일인지 모르겠어요 아 맞다, 핫 테크놀로지의 시간이다. 사실, 내 이름은 다시 한번 Eric Kavanagh입니다. 트위터 @eric_kavanagh에서 저를 찾을 수 있습니다. 이것은 시장에서 가장 뜨거운 것에 대해 이야기하도록 설계된 쇼입니다. 오늘의 제목은 "왕국의 열쇠 : 동적 검색을 통한 SQL Server 관리"입니다. 당신이 있습니다. 좋아요, 그 사진은 몇 년 전의 사진입니다. 나는 거짓말을하지 않을 것입니다, 나는 지금 조금 나이가 들었 습니다만, 괜찮습니다.
그래서 우리는 기술과 SQL Server가 실제로, 정말, 정말, 뜨거운 방법에 대해 이야기하고 있습니다. 오늘은 많은 콘텐츠를 보유하고 있으므로 즉시 배포하겠습니다. 대기하겠습니다. 스피커가 있습니다. 그리고 Robin Bloor가 먼저갑니다.
로빈 블로어 : 그렇습니다. 프레젠테이션은 데이터베이스 관리에 대해 심층적으로 다룰 것이므로 사람들을 데이터베이스의 정신으로 끌어 들이기 위해 데이터베이스 관리 또는 데이터베이스 미로를 통해 진행할 것이라고 생각했습니다. 저는 DBA를 사용했습니다. 약 20 년 전에 데이터베이스 컨설턴트로 일했다고 말할 수 있다고 생각합니다. 실제로 데이터베이스에 대해 저를 놀라게하는 것은 크게 바뀌지 않았다는 것입니다. 많은 양의 데이터와 그와 같은 측면에서 속도 측면에서 많은 것들이 변경되었지만 실제로는 이전에 일어난 것과 매우 유사합니다.
제 생각에 데이터베이스는 특정 워크로드에 최적화되고 데이터 관리 기능을 제공 할 수있는 체계적으로 확장 가능한 데이터 모음입니다. 파일의 데이터를 관리하려는 경우 엄청나게 어려운 작업 이었기 때문에 주로 존재했습니다. 그리고 1970 년대에 IBM 메인 프레임에 무작위로 액세스하자마자 거의 모든 작업을 수행 할 수있는 소프트웨어를 구성한다는 아이디어는 거의 즉시 시작되었습니다.
관계형 데이터베이스는 70 년대에 발명되었으며 80 년대 프로토 타입 측면에서 존재하게되었으며 90 년대 초반부터 시장에서 그 인기를 끌었습니다. 그리고 관계형 데이터베이스는 여전히 전체적으로 지배적입니다. 언론을 읽으면 SQL 데이터베이스에 대해 많은 이야기를 듣게되며 최근에는 그래프 데이터베이스에 대해 많은 소음이 발생합니다. 그리고 흥미롭지 만 실제로 최신 판매량을 유지하고있는 관계형 데이터베이스는 시장의 95 %를 차지합니다. 오늘 심도있게 논의 할 Microsoft SQL Server는 Oracle에서 두 번째로 많이 사용됩니다.
엔진과 관련하여 비정상적인 관계형 데이터베이스에 관한 것은 OLTP 및 쿼리 워크로드 모두에서 작동 할 수 있다는 것입니다. 그렇게하려면 다르게 조정해야하지만 실제로 두 가지 유형의 작업을 모두 수행 할 수 있습니다. 그중 하나는 짧은 임의 트랜잭션이며 다른 하나는 많은 데이터에 걸친 긴 쿼리입니다. 대안으로 NoSQL 데이터베이스와 그래프 데이터베이스는 주로 분석 용이며 상당히 최근에 증가했습니다. NoSQL이 먼저 나타 났으며 최근에는 그래프가 약간의 견인력을 갖기 시작했습니다. NoSQL은 트랜잭션 활동에 사용될 수 있지만 그래프는 트랜잭션 활동에 거의 사용되지 않습니다. 그 이유는 실제로 소프트웨어 인벤토리를 살펴보면 대부분의 회사에 3 개 이상, 실제로는 3.5 개의 다른 브랜드 데이터베이스가 있다고 말하는 통계가 10 년 이상 된 것입니다.
그러나 실제로 대부분의 회사는 특정 데이터베이스를 표준화합니다. 그리고 대부분의 회사는 SQL Server와 Oracle을 표준 데이터베이스에 가장 널리 사용되는 두 가지로 표준화했습니다. 예를 들어, 다른 데이터베이스가 필요한 소프트웨어 패키지를 얻거나 존재하는 일부 빅 데이터 분석 목표를 따르는 예외적 인 상황에서만 대안을 사용합니다.
우리는 또한 원하는 경우 하둡의 간섭을 받았습니다. 어떤 식 으로든 하둡은 파일 시스템 이상이되었지만 아직 데이터베이스는 아닙니다. 그러나 SQL 위에는 SQL이 있습니다. 그러나 실제로 세계의 마음과 생각을 얻은 관계형 데이터베이스를 대체하거나 그 근처에 있지 않다는 증거가 있습니다. 그리고 그 이유는 관계형 데이터베이스가 실제로는 20 년이 걸렸고 실제로는 20 년이 더 오래 걸리기 때문입니다. 또한 아주 짧은 시간 안에 실제로 성능이 뛰어난 쿼리 엔진이나 SQL 엔진을 구축하지 않습니다. 그것은 일어나지 않습니다.
이 슬라이드의 결론은 데이터베이스가 전략적이며 진화하여 더 나아진다는 것입니다. 오라클과 Microsoft SQL Server의 경우도 마찬가지입니다. 아마도 데이터베이스가 처음 등장했던 시절을 기억하는 사람은 거의 없었지만 그때 나는 소년이었습니다. 원래의 아이디어는 하나의 데이터베이스가 존재한다는 것이었고 절대적으로 뿌리를 내리지 않은 개념적 아이디어였습니다. IBM은 AS / 400을 사용하여 실제로 데이터베이스 기반 파일 시스템을 사용하려고 시도했지만 그 중 어느 것도 지배하지 않았습니다. 데이터베이스는 자연스럽게 조각화된다는 사실을 알게되었습니다. 실제로 자연스럽게 여러 인스턴스가 있습니다. 확장 성 문제가 있습니다. 데이터베이스는 특정 크기로만 확장되며, 수년에 걸쳐 크기가 증가했지만 한계가있었습니다.
그리고 워크로드 문제가있었습니다. 주요 워크로드 문제는 OLTP 워크로드와 대규모 쿼리 워크로드가 서로 호환되지 않는다는 것입니다. 그리고 그렇게하는 엔진을 만드는 것은 불가능했습니다. 우리가 흥미를 느끼는 것은 최근 수천 가지가 넘는 Oracle 인스턴스가있는 사이트를 발견 한 것입니다. DBA가 몇 개인 지 정확히 기억할 수는 없지만 실제로 DBA가 모니터링하는 데이터베이스 수에 대해 실제로 이야기 한 경우 10과 비슷했습니다. 그들은 기본적으로 데이터베이스를 찬장으로 사용하고 있었고 적어도 당신이 계획을 가지고 있었고 파일 시스템보다 더 체계적으로 구성되어 있었기 때문에 데이터를 던져 넣었습니다. 그러나 아무도 기본 구성을 제공하고 설정하는 것 외에는 아무것도하지 않았습니다. 느슨하게.
그게 좋은 생각인지 잘 모르겠습니다. 제 생각에는 데이터베이스를 다룰 때마다 데이터베이스에 출석이 필요하고 어떤 식 으로든 어떤 일이 벌어지고 있는지 정확히 알 필요가 있었기 때문에 솔직히 말해서 기괴하게 들립니다. 그리고 수많은 시스템 상호 의존성은 특정 종류의 서비스 수준이 절대적으로 충족되어야하거나 그렇지 않으면 문제가 발생한다는 것을 의미합니다.
최근에 이야기가있었습니다. 자기 조정이라고 주장하는 다양한 데이터베이스를 보았습니다. 인덱스와 관련하여 두 가지 선택이 필요하기 때문에 쿼리 트래픽에 대해 설정된 열 저장소 인 항목은 대부분 자체 조정됩니다. 그러나 특정 영역을 제외하고 데이터베이스를 조정해야합니다. 또한 많은 관계형 트랜잭션에는 조인이 포함되므로 특정 관계형 데이터베이스를 조정해야합니다. 조인은 값 비싼 활동입니다. 올바른 인덱스를 올바른 위치에 두지 않으면 조인이 필요하지 않은 시간이 많이 걸립니다.
현재 자체 튜닝 데이터베이스는 워크로드가 잘 알려진 영역에만 존재합니다. 제 경험에 따르면 대부분의 회사는 DBA를 거의 사용하지 않으며 비싸기 때문입니다. 따라서 DBA의 기능을 대체 할 수 있으면 더 좋습니다. 이것은 내가 이해하는 DBA의 활동입니다. 데이터베이스의 설치, 구성 및 업그레이드를 수행합니다. 그건 그렇고, 업그레이드가 반드시 사소한 활동은 아닙니다. 데이터베이스를 업그레이드하는 이유는 항상 작동하는 규칙이 작동하면 데이터베이스를 건드리지 않고 데이터베이스를 특정 새 버전으로 업그레이드하려는 경우 테스트 모드에서 수행한다는 것입니다. 먼저 그 후에 모든 것을 업그레이드하십시오. 항상 같은 버전을 다루고 있습니다. 그러나 실제로 내가 접한 많은 사이트는 그렇게되지 않습니다. 공정한 엔트로피가 있다고합시다. 라이센스 관리는 문제이며, 보유한 라이센스에 따라 다릅니다. ETL 및 데이터 복제
데이터베이스의 트릭 중 하나는 분할해야하는 쿼리 워크로드가있는 경우 두 개의 인스턴스를 생성하고 복제 할 수 있으며 필요한 경우 사람들이 복제본을 핫 백업으로 사용하는 경우에 종종 수행됩니다. 그런 다음 스토리지 및 용량 계획은 물론 데이터가 증가하고이를 추적해야하기 때문에 DBA 활동의 일부입니다. 그런 다음 다양한 하드웨어 업그레이드 또는 하드웨어 기능 보강을 계획해야합니다. 대부분의 DBA에게 어려운 활동 인 문제 해결이 있습니다. 문제가 발생하고 백업이 완벽하게 작동하지 않는 경우 소매를 감아 로그 파일에서 물건을 가져 와서 복구해야합니다. 그것은 내가 생각하는 것보다 더 자주 발생합니다. 글쎄, 나는 그 일이 일어 났음을 기억하지만 적어도 10 년 동안 게임에서 빠져 나왔지만, 당신이 예상했던 것보다 더 자주 일어났다는 것을 기억합니다. 성능 모니터링 및 튜닝은 DBA 작업의 핵심입니다. 그러나 액세스 관리, 백업 및 복구 측면에서도 보안이 유지되므로 실제 시스템과 비슷한 소프트웨어 테스트 시스템을 만들 수 있습니다. 그리고 전체 데이터 수명주기에 관한 것입니다. 제 생각에 DBA의 직업 목록은 다른 것들과는 별개입니다. 작동 역학. 궁극적으로 데이터 무결성 및 서비스 수준 관리는 DBA의 주요 책임입니다. 그리고 보통 그들은 비판적입니다. 그리고 그것이 내가 말해야 할 전부입니다. 데즈에게 넘겨 줄 게요
Dez Blanchfield : 대단히 감사합니다. 오늘의 주제가 그 어느 때보 다 중요하고 중요한 이유에 대한 약간의 재미 있고 일화적인 여정을 안내해 드리겠습니다. 얼마 전 저는 라이센스 등록 및 차량 등록에 사용 된 주 정부 플랫폼과 A + Addition이라는 것을 실행하는 Fujitsu 메인 프레임 플랫폼에서 해당 주제와 관련된 모든 것을 마이그레이션하는 프로젝트에 참여했습니다. 솔라리스 운영 체제, 즉, 유닉스, 오라클을 실행하고 아주 잘 수행합니다. 그리고 그 견해는이 것이 늙어 가고 다른 것으로 옮겨야 할 시점이었습니다. 우리는 메인 프레임에서 유닉스를 실행하는 데 많은 즐거움을 얻었으며 SDL 플랫폼은 매우 안정적이며 매우 안전하고 이상하게도 매우 빠르며 매우 빠릅니다. 그러나 지혜는 메인 프레임에서 내리고 움직일 때였 다.
데이터베이스에 대한 모든 시스템과 비즈니스 로직 및 SQL 환경을 매핑하고 새로운 홈을 설계하고 엔지니어링하는 방법을 살펴 보는이 중대한 과제. 그리고 몇 년 전 이었지만 Sun 랙 시스템 Starfire 서버의 최고급 중 하나에 도달했습니다. 그리고 이들은 아마도 하나의 큰 상자와 대칭 멀티 프로세싱 서버에 사는 지구상에서 구입할 수있는 가장 큰 주석 중 하나 일 것입니다. 우리 세계의 중급 시스템이었습니다. 유닉스를 실행했고 기본적으로 Oracle을 실행했으며 "무엇이 잘못 될 수 있는가?"라는 견해가있었습니다. 글쎄요.
예를 들어, 당시에, 우리는 오래 전에 이야기하지 않았지만, 우리는 메인 프레임 플랫폼에 무엇이 있는지 발견하기 위해 매우 수동적 인 과정을 거쳐야했습니다. 특히 실제 데이터베이스 환경 및 SQL 논리. 따라서 뷰는 Oracle에서 Oracle로, 데이터베이스에서 데이터베이스로 이동하는 것이 매우 간단합니다. 모든 비즈니스 로직이 등장하고 대부분의 비즈니스 로직은 내장 된 쿼리 및 트리거로 작성되었으며 얼마나 어려울 수 있습니까? 그러나 몇 달이 걸리기로되어 있었지만 1 년이 걸리지 않았습니다. 메인 프레임 환경에서 물리적으로 그리고 수동으로 유닉스의 모든 부분을 살펴보기 위해 모든 데이터베이스가있는 위치와 실행중인 인스턴스 수 및 해당 인스턴스에서 실행중인 항목을 발견하고 사소한 연습이었고 결국 우리는 그것을 해냈습니다. 우리가 모든 것을 포착했는지 확인하기 위해 세 번. 우리가 필요한만큼 깊이 파고 들었다고 생각할 때마다 표면 아래에 더 많은 것이 있다는 것이 밝혀졌습니다.
우리가 겪었던 또 다른 과제는 어떤 인스턴스가 실행 중이고 어떤 상태입니까? 이것이 개발 환경입니까? 테스트 환경입니까? 통합 프로세스의 일부입니까? 시스템 통합인가? 사용자 승인 테스트 인 UAT입니까? 생산입니까? DR 환경입니까? 메인 프레임의 장점은 우리 모두가 당연한 것으로 생각하는 작은 가상 환경을 구축하고 주변을 움직일 수 있다는 것입니다. 그리고 당신은이 사람이 생산 등급의 개발 및 테스트를하고 있는지, 또는 생산 생산을하고 있습니까? 실제 사용자가 있습니까? 이 일은 운전 면허증과 자동차 등록 및 사람들의 삶에 실제로 중요한 것들을 실시간으로 발행한다는 것을 기억하십시오.
그리고이 작업에 대한 백업을 실행하는 데 오랜 시간이 걸렸으므로 실제로 작업을 수행하고 어떤 일이 발생했는지 확인하는 유지 관리 기간이 없었습니다. 다시 라우팅하는 것은 없었습니다. 또한 실행중인 인스턴스와 위치 및 대상을 찾는 것이 아니라 실행중인 버전의 버전을 해결해야했습니다. 그리고 이것은 내가 줄거리를 거의 잃어버린 곳입니다. 다양한 수준의 테스트를 통해 2 ~ 3 개의 프로덕션 환경 버전이 실행되고 있음을 깨닫기 시작했을 때 툴 방식과 체계적인 접근 방식은 거의 없었습니다. 우리는 문자 그대로 코드와 실행중인 인스턴스를 조사해야했으며, 경우에 따라 잠시 동안 오프라인 상태로 전환 할 위험이 있습니다. 우리는이 모든 것의 맨 아래에 도달했고 그것을 매핑했으며, 내가 말한 것처럼 매우 수동적 인 프로세스였습니다. 그리고 마침내 우리는 전체 ETL 교대를 만들어 한 곳에서 다른 곳으로 옮기고 다른 곳으로 옮겼습니다. 우리는 기능적이며 만족 스럽습니다.
그러나 우리는 수많은 매우 단단한 단단한 벽돌 벽에 부딪쳤다. 특히 성능 문제가 발견되었습니다. 그리고 오늘의 현명한 생각은 더 크고, 더 좋고, 더 빠르고, 더 단단한 하드웨어로 넘어 갔으며, 데이터베이스 수준의 응용 프로그램에서 성능이 좋지 않은 이유가 없으므로 다른 곳을 살펴 보겠습니다. 그래서 우리는 네트워크를 완전히 두 번 재 설계했습니다. 모든 라우터, 모든 스위치, 모든 케이블, 우리는 경우에 따라 이더넷에서 파이버로 갔고 소프트웨어를 업그레이드하고 패치를 보았습니다. 기본적으로 성능 문제라고 생각한 네트워크를 두 번 재 구축했습니다. 그리고 마치 마치 마치 느껴졌습니다. 우리는 다른 보안 시스템과 다른 방화벽을 통과했습니다. 우리는 운영 체제를 패치했습니다. 한 컴퓨팅 블레이드에서 다른 컴퓨팅 블레이드로 물건을 옮겼습니다. 그리고 우리는 그 인프라를 살펴 보는 데 많은 시간을 보냈습니다.
그런 다음 서버의 연결을 끊고 다른 응용 프로그램을 실행하여 네트워크가 제대로 작동한다는 것을 알았습니다. 그래서 우리는 운영 체제를 분리하기 시작했습니다. 같은 문제입니다. 그러나 흥미로운 것은 네트워크 수준과 운영 체제 수준, 도구가 있었기 때문에 실제로 각 부분이 제대로 작동했는지 벤치마킹하고 테스트하고 증명하는 것이 비교적 간단했습니다. 그러나 그때도 SPARC 하드웨어 플랫폼의 중간 범위에있는 Solaris에서는 데이터베이스 환경을 진단하기위한 도구가 없었습니다. 모든 인스턴스를 가져 왔는지 여부를 매핑합니다. 그래서 우리는 실제로 우리 자신의 도구를 만들고 일부를 작성하고 데이터베이스 스크립트 자체가 기본 스크립팅 언어로되어 있는지 또는 일련의 쉘 스크립트인지 또는 일부 경우 C 프로그램인지 여부를 결정해야했습니다.
우리는 마침내 SQL 계층 아래의 논리, 실제 데이터베이스 엔진 자체에 대해 매우 흥미로운 문제에 대해 조사했습니다. 오라클의 메인 프레임 버전에서 실행되는 무언가에 대해 특정 방식으로 구축 된 것이 SPARC의 Solaris로 마이그레이션되었다는 것이 밝혀졌습니다 Oracle 버전에서는 동일한 성능을 즉시 바꾸지 않았습니다. 그래서 이것은 처음에는 우리에게 아주 고통스러운 여정이었습니다. 단지 그것을하고 모든 것을 찾아 냈지만, 이제 우리는 새로운 생산 시스템에서 진단해야했고, 다시 한 달의 가치를 거의 1 년으로 옮겼습니다. 그리고 그것은 우리가 도구를 가지고 있지 않다는 사실에 간단히 도달했습니다. 메타 데이터 매핑과 같은 작업을 수행합니다.
어느 시점에서 우리는 무작위로 가리키고 찌르는 것이 더 쉬울 것이기 때문에 Ouija 보드가 필요하다고 거의 결정했습니다. 이전 시스템에 액세스 할 수있는 사람과 해당 액세스 권한을 가진 이유를 찾는 것과 같은 간단한 것. 그리고 누가 새로운 것에 액세스하고 확인해야했고, 누군가 사인 오프하고 확인하고 그것을 맵핑했습니다. 데이터베이스 크기만큼 단순한 것도 두 플랫폼에서 일관성이 없었습니다. 우리는이를 수행 할 수있는 툴을 구축해야했고 시스템 A와 시스템 B의 데이터베이스 용량은 원시 메가 바이트 또는 테라 바이트 단위로 얼마나 큰지를 비교해야했습니다. 그리고 성능과 성능 환경에 대해 더 자세히 살펴 보았습니다. 다시, 새로운 도구를 만들어야했습니다. 우리에게는 기성품이 없었습니다.
그리고 당신은 이것으로부터 모든 메시지를 얻습니다. 우리가 일을 끝내고 안정을 얻었을 때 모든 단일 조각은 매우 수동적 인 과정이었습니다. 우리가 무언가를 자동화하면 무언가를 자동화 할 수있는 유일한 방법이었습니다. 새로운 도구 또는 새로운 스크립트. 오늘날 우리가 이용할 수있는 도구가 있다면 인생은 훨씬 더 쉽고 훨씬 좋을 것입니다. 그리고 우리는이 프로젝트에서 수백만 달러를 절약했을 것입니다. 그러나 우리가 오늘 이야기하려고하는 것은 현재 도구를 사용할 수 있으며 훨씬 쉽게 생활 할 수 있다는 사실입니다. 많은 함정이 여전히 남아 있습니다. 외부에있는 데이터베이스와 어떤 인스턴스를 실행 중인지 감지합니다. 그들이 어떤 주에 있습니까? 얼마나 많은 사람들이 달리고 있습니까? 왜 뛰고 있는지 그들이 잘 달리고 있는지. 그들은 백업되고 있습니까?
이것들은 우리가 여러 가지 방법으로 올바른 도구를 사용하여 당연한 것으로 받아 들일 수있는 모든 것입니다. 그러나 제가 말한 것처럼이 특별한 일화에는 기간이있었습니다. 그곳에서 많은 사람들이 머리카락을 많이 잃어 버렸을 것입니다. 아마도 15 년이 걸렸을 것입니다. . 오늘 손님으로부터 많은 정보를 얻을 수 있기를 기대하고 있습니다. 그래서, Bullett, 나는 당신에게 전달할 것이고, 나는 당신 이이 문제를 어떻게 해결했는지 듣고 싶습니다.
글 머리 기호 관리 : 알겠습니다. 잘 들린다. 에릭, 여기서 슬라이드로 넘어 가서 제품 자체에 들어가기 전에 회사 Idera에 대해 조금 빨리 이야기하겠습니다. 참고로, 이것은 우리가 사용할 수있는 다양한 제품 포트폴리오입니다.
Eric Kavanagh : 오디오가 매우 뜨거우므로 헤드셋을 사용하는 경우 조금만 올리십시오.
Bullett Manale : 문제 없습니다. 더 낫습니까?
에릭 카바나 흐 : 훨씬 좋습니다. 멀리 가져.
글 머리 기호 관리 : 알겠습니다. 오늘 우리는 인벤토리 관리자에 초점을 맞출 것입니다. 인벤토리 관리자는 우리가 논의하고있는 이러한 많은 주제와 분명히 일치합니다. 이 제품이 어디에 있는지 어떻게 이해했는지 조금 알려 드리고자합니다. 우리는 우리의 제품 라인에서 매일 매일 살펴 보았습니다. 진단 관리자라는 성능 모니터링 도구가 있습니다. 규정 준수 관리자 도구가 있습니다. 따라서 SQL Server와 관련하여 다양한 도구가 필요하며 라이센스 부여를 위해 항상 "현재 조직 내에서 관리하는 인스턴스 수는 몇 개입니까?" 그리고 흥미로운 점은 우리가 그것에 대해 확실한 답을 얻을 수 없다는 것입니다. 누구와 대화했는지는 문제가되지 않았습니다. 그것은 항상 "우리는이 숫자 주위에 있다고 생각합니다." 이런 종류의 일은 항상 들어 왔고 우리가 관리하는 인스턴스와 관련하여 라이센스를 얻고 자하는 것이 무엇인지 정확히 파악하는이 과정을 거쳐야했습니다.
우리는 많은 DBA와 관련하여 약간의 고통이있는 것으로 보인다는 것을 정말로 빨리 알아 냈습니다. 분명히 DBA로서 그들이 담당하는 것 중 하나는 Microsoft와 SQL Server의 경우 라이센스 계약에 대해 걱정해야하기 때문입니다. 분명히 그들은 그들이 책임지고있는 다른 많은 다른 영역을 가지고 있지만, 그것은 당신의 일반적인 책임이 무엇인지 DBA와 관련하여 일종의 큰 티켓 항목 중 하나입니다. 우리가 결론을 내린 것은 DBA가 그 숫자를 쉽게 이해할 수 있도록하는 도구가 필요하다는 것입니다. 그것을 호출하려는 경우 SQL 스프롤이 있기 때문에 여러 가지 이유로 발생합니다. 누가 소프트웨어를 설치하는지와 그런 종류의 것들을 제어 할 수는 없습니다.
그리고 일어날 수있는 최악의 상황은 누군가 SQL Server 사본을 가져 와서 설치하고 회사의 다른 조직이나 부서에 대한 지식없이 작업을 시작한 다음 다음에 아는 것입니다. 데이터가 백업되지 않고 발생할 수있는 일이 있습니다. 이제 다른 문제가있는 경우, 인스턴스가 처음에 존재한다는 사실을 모르기 때문에 실제로 중요한 데이터를 잃을 상황이 발생합니다.
우리가해야했던 것 중 하나는 그것의 발견 부분을 알아 봅시다. 그리고 그 위에 우리가 수집하는 정보를 비즈니스가 수행하는 작업에 따라 합리적으로 논리적으로 구성하고 관리 할 수 있습니다. 그리고 분명히 그 정보를 중심으로 결정을 내릴 수 있고 그런 종류의 일을 할 수 있습니다. 그것은 도구가 시작된 곳과 시작된 곳입니다. DBA와 정기적으로 대화 할 때 실제로 보유하고있는 것은 인스턴스 수를 알지 못하는 문제입니다.
측정 할 수없는 것을 관리 할 수없고, SQL 진단 관리자와 같이 항상 우리가 가지고있는 성능 도구를 생각해 냈지만 그 사실을 모르면 아무것도 관리 할 수 없기 때문에 재밌습니다. "그것"도 처음부터. 이 도구의 큰 부분이기도합니다. 도구가 있다는 것을 알 수 있습니다.
이제 그 메모에서 SQL Server를 사용하여 일부 대규모 조직이나 엔터프라이즈 상점과 대화하면서 많은 사람들이 발견 한 흥미로운 사실은 그들이 실제로 연도 중에 시간을 설정했다는 것입니다. 그들은 실제로 한 장소에서 다른 장소로 실제로 걸어 가서 그 수의 모습을 결정하려고 시도했습니다. 어떤 경우에는 한 대의 기계에서 다른 기계로 실제로 걸어 다니기 위해 많은 돈을 지불하고 있다고 DBA로 상상할 수 있습니다. 놀랍게도 우리는 내가 이름을 짓지 않을 꽤 큰 회사로부터 듣게 될 것입니다. 그러나 1 년에 2 주 동안 이러한 종류의 연습을 수행하여 라이센스 수가 올바른지 알아내는 데 흥미로운 점이 있습니다.
이 도구는 모두이 도구와 관련이 있으며 어떻게 도움이되지만 우리가 해결 한 방식은 SQL Server의 여러 특성을 기반으로 검색을 수행 할 수있는 기능을 통해 이루어졌습니다. 첫 번째 질문은 무엇을 가리키고 무엇을 먼저 보려고합니까? 우리가 말한 방식은 IP 범위별로 수행하거나 도메인 구성원 인 컴퓨터 측면에서 도메인 자체 구성원 자격으로 수행 할 수 있습니다. 그것이 우리가 그 부분을 다루는 방법의 일종입니다. 단지 이것이 발견의 관점에서 우리가 집중하고 싶은 영역이라고 말할 수 있습니다.
그리고 그 다른 부분은 이러한 특성, 포트 및 기타 사항, WMI 레지스트리 키 및 이러한 종류의 것들을 기반으로 SQL이 해당 인스턴스 또는 특정 환경에서 실행되고 설치되어 있는지 확인할 수 있습니다. 운동화 방법이나 운동화 표현 방법보다 훨씬 나은 방법입니다. 이제 멋진 점은 인스턴스에 대해 수집하는 모든 정보가 리포지토리에 보관되고 환경이 변경됨에 따라 변경 될 수 있다는 것입니다. "인스턴스가 있습니다. 여기에 우리가 찾은 목록이 있습니다."가 아니라 DBA 또는 인스턴스를 관리하는 사람으로서 인벤토리의 해당 부분을 만들지 여부를 결정할 수 있습니다. 해당 인스턴스를 해제 할 수 있도록 인벤토리의 일부가 아닙니다. 따라서 도구 내에서 SQL Server 인스턴스의 전체 프로세스 수명주기를 쉽게 이해할 수 있습니다.
인스턴스를 발견 한 후에는 어떻게해야합니까? 다른 것은 인스턴스에 대한 많은 정보입니다. 수동으로 가져 와서 스프레드 시트 또는 그 종류의 물건에 넣지 않아도됩니다. 그리고 인벤토리 프로세스와 라이센싱에 관해 DBA와 대화 할 때 흥미로운 점이 또 있습니다.“재고를 어떻게 유지합니까?”라고 물어볼 때 DBA가 몇 명이나 이야기했는지 놀라게 될 것입니다. 우리는 DBA와 정말 아이러니 한 부분에 대해 이야기하고 있습니다. 내가 말했듯이, 당신이 그것에 대해 잠시 생각하면 매우 아이러니합니다. 그러나 그것은 많은 경우에 있었고, 여전히 많은 조직들이 그것을 관리하는 방법입니다. 그들이 어떻게 지키는 지 그것은 떠 다니고 정기적으로 업데이트되어야하는 Excel 스프레드 시트의 마스터 사본입니다.
그것들은 도전이었던 것들이므로 인스턴스를 등록하고 인벤토리의 일부로 만들면 그렇게 할 수 있고 정보를 얻을 수 있습니다. 인벤토리, 버전, 에디션 등으로 할 수 있는지 여부를 자동화하도록 할 수 있습니다. 다른 방법으로 목록이나 Excel 스프레드 시트를 수동으로 추가 할 수 있습니다. 이를 SQL Inventory Manager라는이 도구로 가져올 수 있습니다. 확신이 있다고 생각되는 시작점이 이미있는 경우 해당 인스턴스를 가져 와서 제품 내에서 관리되는 인벤토리의 일부로 만들 수 있습니다. 일단 인스턴스가 있고 그것이 존재한다는 것을 알게되면, 그 인스턴스가 있다는 것을 알고, 나가서 정보를 수집함으로써 활용할 수있는 많은 정보를 얻습니다.
그리고 라이센스 목적 이상의 것이 필요한 많은 정보가 필요합니다. 많은 정보는 정보가 획득 된 후이 정보를 검색 할 수 있도록 사물이 어디에 있는지 정확히 알기 위해 사용될 수 있습니다. 그러나 중요한 것은 서버, 하드웨어 자체입니다. 모델 또는 제조업체, 메모리, 메모리 양, 실제 또는 가상 시스템, 특히 물리적 소켓 또는 코어 및 CPU 수 및 해당 유형의 유형 등 어떤 유형의 시스템인지 이해할 수 있습니다.
코어 수, 특히 SQL Server의 경우 라이센싱을 수행하는 방법을 아는 것은 최신 버전의 SQL에서 코어 당 계산입니다. 이것은 실제로 중요한 부분이되며 현재 가지고있는 것이 아닙니다. 외출하고 실제로 발굴합니다. 인스턴스가 식별되면 해당 정보를 제공하고 가져 와서 정보를보고 이해할 수있게하여 분명히 활용할 수 있습니다.
다음 계층은 인스턴스에 있으며, SQL Server 인스턴스가 표준이든 엔터프라이즈이든, 심지어 그 문제를 표현하거나 무료 버전의 SQL Server인지에 관계없이 SQL Server 인스턴스가 많이 다릅니다. 해당 인스턴스에 어떤 응용 프로그램이 연결되어 있는지 이해할 수 있으므로 자동으로 수행 할 수 있습니다. SQL Server 인스턴스와 관련된 다른 정보뿐만 아니라 구성 설정과 그 종류의 것들을 이해할 수 있습니다.
그런 다음 실제 데이터베이스로 이동하여 구성 설정, 해당 데이터와 연결된 공간의 양, 위치, 이 모든 것들이 자동으로 채워 지므로 시간을 크게 절약 할 수 있습니다. 다시 한 번, 동적으로 나가고 매일 새로운 인스턴스를 식별하기 때문에 인벤토리 측면에서 생생한 것입니다. 제품의 목표는 그런 방식으로 만드는 것입니다. 동적으로 변화하는 것을 만드는 것입니다.
이제이 정보를 모두 사용할 수있게되고이 데이터를 모두 가져올 수있게되면 경우에 따라 이러한 인스턴스와 관련된 고유 한 메타 데이터를 생성하기 시작하고 메타 데이터를 이러한 방식으로 생성 할 수 있습니다. 비즈니스 방식에 맞 춥니 다.
따라서 인스턴스를 지리적 위치, 애플리케이션 소유자 또는 DBA 소유자 등으로 그룹화 한 경우 해당 인스턴스를 그룹화하는 방법, 논리적으로 인스턴스를 이해하려는 방식 등의 측면에서 볼 수 있습니다. 도구 내에서 해당 기능을 제공하는 두 영역 중 하나입니다.
첫 번째는 인스턴스 태그 또는 태그를 만드는 기능입니다. 본질적으로 서버, 인스턴스 또는 데이터베이스에 대한 연결을 생성하여 일상적으로 발생할 수있는 뷰를 작성하고 질문에 답변 할 수 있으므로 실제로 가지고있는 것을 처리하는 데 도움이됩니다. 관리하고있는 정보와 그 정보로 나아가고 자하는 방법.
우리가 가진 또 다른 것은 인벤토리 필드 또는 사용자 정의 인벤토리 필드라고하는 것으로, 드릴 다운 할 수있는 정보의 종류 (예 : 데이터베이스 계층)에 드롭 다운 목록을 추가하기로 결정할 수도 있습니다. 모든 DBA와 나는 그 상황의 유형에 따라 그 데이터베이스를 담당하는 사람을 누구에게나 둘 수 있습니다. 어떤 데이터베이스를 책임지고있는 사람이든 데이터베이스를 선택할 수있어서 그들이 책임이있는 사람임을 알 수 있습니다 인벤토리에 파고 들어가면 아주 쉽게
따라서 이러한 정보는 특히 환경이 큰 경우 해당 정보를 이해하고 보유하고있는 정보와 수행 방식을 아는 데 도움이되므로 매우 유용합니다.
계속해서 다음 슬라이드로 전환하겠습니다. 제가 지금 여러분에게 보여 드리는 것은 우리가 수집하는 모든 정보, 메타 데이터를 수집하고 적용하는 모든 정보 및 데이터를 통해보다 쉽고 빠른 결정을 내릴 수 있다는 것입니다. 엔터프라이즈 볼륨 라이센스 또는 Microsoft의 소프트웨어 보험에서 Microsoft의 라이센스를 강화하십시오.
따라서 수동으로 데이터를 수집하고 수동으로 수집해야하는 것이 아니라 실제로 전체적으로 처리하는 것이 훨씬 수월합니다. 따라서 이는 DBA가 라이선싱과 관련한 의사 결정을보다 쉽게 내릴 수 있도록하는 제품의 임무 중 하나입니다.
이제 우리가 DBA와 대화하고 실제로 알게되고 알게 된 또 다른 것은 SQL Server 환경에 300 개의 인스턴스가있을 수 있지만 실제로는 하위 집합 만 있다는 것입니다. 기존의 성능 모니터링 유형의 도구에서 실제로 완전히 모니터링되고 관리되는 도구 중 하나입니다.
따라서 실제로 DBA와 함께 앉아 다음과 같이 말합니다.“이러한 툴을 사용하여 모니터링하고이를 준수하도록 설계된 20 개의 인스턴스 또는 300 개의 인스턴스 중 10 개의 인스턴스가 있습니다. SOA를 통해 경고와 모든 종류의 좋은 점을 얻을 수 있습니다.”또한 요청한 경우“이러한 280 개 인스턴스는 어떻습니까? 당신은 그것들에 관심이 있습니까?”그리고 그들은 그들에 관심이 있지만, 실제로 10 또는 20 대에 해당하는 인스턴스로 수행 할 수있는 깊이 수준의 사람들을 모니터하기 위해 투자를하고 싶지는 않습니다. 정말 중요한 제품 인스턴스.
따라서이 도구를 사용하는 등식의 다른 부분은 기본 수준에서 인스턴스 상태 측면에서 보장되도록하는 데 도움이된다는 것입니다. 이제 교착 상태가 있는지 또는 교착 상태의 피해자가 누군지 알려주지 않습니다. 세션 자체의 수준과 쿼리의 세부 사항에 도달하지는 않습니다. 그러나 동시에 서버가 다운되었거나 볼륨이 가득 찼거나 데이터베이스 백업을 수행해야한다는 것을 알 수 있습니다. 이는 DBA의 중요한 부분입니다.
따라서 이러한 종류의 것들이 여전히 중요하며, 이 도구를 사용하면 많은 중요한 가치가있는 매우 중요한 인스턴스를 잡을 수 있습니다. 아래로 즉시 알아야합니다. 그들은 더 높은 수준의 모니터링을 할 수 있고 그런 종류의 일을 할 수 있지만, 환경에 추가되는 새로운 인스턴스를 선택하여 계정을 확인하고 만들 수 있습니다. 기본적인 건강 검진이 이루어지고 있는지 확인하십시오.
Inventory SQL Import Manager의 핵심은 바로 이것입니다. 이제 데모를 보여 드리겠습니다. 그렇게하기 전에, 여기에 아키텍처 슬라이드가 있음을 보여 드리고 있습니다. 그리고 이것을 보여주기 위해, 우리가 관리하고있는 SQL 인스턴스는 SQL 2000에서 새로운 것까지 모든 것을 발견 할 수 있습니다. SQL 버전.
따라서 인스턴스 자체에 에이전트를 배포 할 필요없이 그렇게 할 수 있습니다. 수집 서비스를 통해 정보를 수집하고 정보를 수집하여 리포지토리에 넣은 다음 Tomcat 웹 서비스 프런트 엔드 콘솔에서 해당 데이터와 상호 작용하고 볼 수 있습니다. 매우 간단한 아키텍처입니다.
계속해서 넘어 가서 실제로 제품 자체로 가져 가서 제품에 대한 느낌과 작동 방식에 대한 이해를 얻을 수 있습니다. 이를위한 가장 좋은 방법은 먼저 인터페이스 자체를 소개하는 것입니다. 여기에서 우리가보고있는 일종의 대시 보드가 있습니다.
관리중인 인스턴스 수는 그다지 많지 않습니다. 그러나 백 포켓에 전체 데이터 센터가 없습니다. 여기에 6 개의 인스턴스가 있습니다. 이제 저는 제가하고자하는 것은 발견 과정을 안내하고 그것이 어떻게 작동하는지 보여줍니다.
이제 가장 먼저 할 일은 관리 섹션에서 인스턴스 검색 방법을 지정할 수 있습니다. IP 주소 범위를 통해 수행 할 수있는 정보를 여기에 다시 입력 할 수 있습니다. 도메인이나 서브 도메인을 가리킬 수 있으며 해당 도메인의 구성원 인 머신에서만 해당 점검을 수행 할 수 있으며 SQL을 점검하기 위해 실행할 때 여러 가지 다른 특성을 선택할 수 있습니다.
그런 다음 일단 완료하면 매일 실행하여 해당 데이터를 수집하고 수집하도록 자동화 할 수 있습니다. 필요한 경우 임시로 수행 할 수도 있습니다. 그러나 일단 시작하면, 그 발견 프로세스는 여기서 인스턴스보기로 넘어갈 때 나타납니다. Discover 탭이 있고 Discover 탭에 최근에 검색된 인스턴스가 표시됩니다. 우리의 경우 여기에 숫자가 있습니다. 제가 계속 진행할 것은 예제로 사용할 것을 추가하는 것입니다. 이 경우 시카고 사례입니다. 맞습니까? 계속해서 인벤토리에 해당 인스턴스를 추가하겠습니다.
좋습니다. 여기 몇 가지를 살펴 보겠습니다. 계속 진행하면 자격 증명을 설정할 수 있습니다. 내 자격 증명이 좋을 것입니다. 계속 진행하겠습니다. 원하는 경우 소유권을 할당 할 수 있습니다. 위치를 지정할 수도 있습니다. 이제 위치 자체도 추가 할 수 있으며 다음에 기억할 것입니다.
다시 한 번, 메타 데이터와 이러한 SQL 인스턴스, 특히이 인스턴스를 삽입하려는 버킷에 넣는 방법과 관련하여 태그를 이것에 연결할 수 있습니다. 따라서 현재 태그 인 인기 태그가 있습니다. 이므로 이미 포함했을 수있는 다양한 태그를 볼 수 있습니다. 나는 이들 중 일부를 무작위로 고를 것입니다. 그리고 우리는 그것을 적용 할 수 있습니다.
이제 계속해서 인벤토리에 추가합니다. 이제 추가되었으므로 이제이 관리보기 아래에 표시되므로 여기에 바로 표시됩니다. 따라서 이것이 첫 번째 단계이며 방금 보여 드린 것은 일상적으로 처리 할 때 주로 해당 인스턴스를 추가하는 방법이었습니다. 경우에 따라 엔터프라이즈 버전의 SQL Server 인 경우 자동으로 내 인벤토리에 추가하려고하는지 알고 싶습니다. 수동으로 가서 선택하지 않아도됩니다.
Jocelyn : 나는 당신을 정말 빨리 방해 할 것입니다. 데모가 보이지 않습니다.
Bullett Manale : 그렇지 않습니까?
조슬린 : 아니요.
Bullett Manale : 글쎄요, 보자.
Eric Kavanagh : 왼쪽 상단으로 이동하면 시작을 클릭하고 클릭하십시오.
Bullett Manale : 아, 알겠습니다 .
에릭 카바나 : 이제 화면을 공유합니다.
Bullett Manale : 죄송합니다. 예.
에릭 카바나 흐 : 좋습니다. 잘 잡아요, 프로듀서 조슬린
Bullett Manale : 좋습니다. 지금보고 있습니까?
로빈 블로어 : 그렇습니다.
Bullett Manale : 좋습니다. 이제 우리가 실제로 어디로 왔는지 안내해 드리겠습니다. 이전에 발견 된 인스턴스가 발견되었습니다. 방금 시카고 인스턴스를 추가 했으므로 이제 여기에 나열되어 있습니다. 이미 많은 추가 정보를 가져 왔습니다. 인스턴스 자체를 클릭하면 해당 인스턴스에 대해 이미 수집 한 모든 종류의 정보가 표시됩니다. 이제 여기에있는 모든 데이터베이스의 목록이 있습니다. 크기 및 활동을 가장 많이 사용하는 데이터베이스의 크기 및 활동별로 데이터베이스를 분석 할 수 있습니다.
다시 한 번, 인스턴스에서 실행되는 워크로드에 따라 해당 인스턴스에서 실행중인 애플리케이션을 바로 알 수 있습니다. 따라서 자동으로 수행 할 수있는 것이 좋습니다. 나는 신청서를 발병률에 묶을 필요가 없습니다. 우리가보고있는 것에 기초하여 우리는 그것을 채울 수 있습니다. 이제 수동으로 응용 프로그램을 추가하려는 경우 절대 그렇게 할 수 있습니다. 그러나 인스턴스와 데이터베이스의 연관성을 보여줄 수있는 좋은 방법입니다. 죄송합니다.
또한 화면 오른쪽에는 즉시 요약이 있고 그 아래에는 서버 요약이 있습니다. 여기서 우리는 인스턴스 키 정보에 대해 이야기하고 있습니다. SQL Server 2012 버전뿐만 아니라 실제 버전 번호, 어떤 핫픽스가 연결되어 있는지, 어떤 서비스 팩인지 알려주는 실제 버전 번호 그것에 묶여 있다는 것은 매우 중요합니다. 분명히 메모리 요구 사항이 중요합니다. 클러스터링이든, 모든 정보이든, 정보를 넣을 필요는 없습니다. 이미 수집 및 수집 중이며, 발견 된 인스턴스임을 확인하면 인벤토리의 일부가 될 것입니다.
여기에 표시 될 또 다른 것은 –이 인스턴스보기 아래에 있습니다. 앞서 언급 한 이러한 속성, 추가 할 수있는 사용자 지정 속성이 있습니다. 우리는 개방형 텍스트 상자 필드를 추가 할 수 있습니다. 우리는 10 억 종류의 선택에 대해 예 / 아니요를 할 수 있습니다. 드롭 다운리스트도 할 수 있습니다. 데이터베이스 인스턴스 나 서버 수준에서이를 수행 할 수 있습니다.
그런 다음 조금 아래로 스크롤하면 서버와 관련된 모든 정보를 볼 수 있습니다. 모든 종류의 자료가 수집되고 수집되어 재고의 일부로 만들기로 결정하자마자 바로 도움이 될 것입니다. 여기서 우리는 CPU, 논리 대 물리적 수, 메모리 양의 차이점을 보여줄 수 있습니다. 따라서 많은 작업을 수행하지 않고도 정말 좋고 풍부한 정보를 얻을 수 있습니다.
제가 말했듯이 이것의 다른 부분은 서버 수준의 인스턴스에서이 데이터를 수집하는 것입니다. 우리가 데이터베이스로 내려 가면 많은 것들이 우리에게도 분해되는 것을 볼 수 있습니다. 규정 준수 저장소로 이동하면이 문제를 처리하고 있음을 알 수 있습니다. 규정 준수 데이터베이스는 규정 준수 수준 또는 규제 요구 사항과 관련이 있고 관련이있을 수있는 규정 준수 데이터베이스입니다. SOX 준수 또는 PCI 준수. 따라서 어떤 규정을 준수해야하는 데이터베이스를 선택하거나 해당 규정 요구 사항에 따라 유지 관리하고 있는지 확인할 수 있습니다.
따라서 이런 종류의 것들이 DBA에 매우 도움이되는 것으로 판명되었습니다. 왜냐하면 이러한 메타 데이터를 중앙 집중식으로 환경에 쉽게 유지할 수 있고 내가 말한 것처럼 비즈니스를 준수 할 수있는 장소가 있기 때문입니다. 그들이 사업을하는 방식으로 다시하고 있습니다. 우리가 지금까지 본 모든 내용을 살펴보면 인스턴스에 대해 자세히 살펴보면 인스턴스에 대한 훌륭한 개요를 얻게됩니다.
또한 검색 할 수 있으므로 인벤토리 전체에서 해당 준수 저장소를 찾아 보겠다고 말했습니다. 그러면 여기에서 볼 수있는 것은 이러한 것들을 검색하여 식별 할 수 있다는 것입니다. 나는 무엇을 확신하지 못합니다. 이동 버튼이 작동하지 않습니다. 괜찮아. 보자, 다시 해보자. 우리는 거기에 갈. 그래서 우리는 우리가 준수하고있는 것을 볼 수있는 곳의 고장을 볼 수 있으며, 드릴 다운하여 그 관점에서도 볼 수 있습니다. 따라서이 데이터를 파헤칠 수있는 정말 빠르고 쉬운 방법이 있습니다.
앞에서 언급했듯이 인스턴스 서버 및 데이터베이스에 대해 메타 데이터를 생성하는 다양한 방법이 있습니다. 그것의 다른 부분은 당신이 그것을 묶은 방식과 그와 관련된 방식으로 그것을 이용할 수 있다는 것입니다. 익스플로러 뷰로 이동하면됩니다. 위치별로 데이터베이스 수를 계산하고 싶다고 말할 수 있습니다. 그래서 내가 지원하는 환경의 각 위치에있는 데이터베이스 수. 또는 아마도 인스턴스 수와 관련하여 내가 가지고있는 인스턴스를 소유 한 소유자를 기반으로 할 수도 있습니다. 그래서 우리는 그것을 볼 수있을 것입니다. 그래서 당신은 그 당시에 대답하려고하는 질문에 기초하여 당신을 위해이 그림들을 그릴 수있는 정말 좋고 쉬운 방법을 얻습니다.
그런 다음 원하는 정보를 원하는 방식으로 생성 한 후 PDF 또는 다른 형식으로 내 보내서 활용하여 동료에게 보내거나 필요한 모든 작업을 수행 할 수 있습니다. 여러분은 그런 종류의 일을 할 수 있다는 것을 알고 있습니다. 다시 돌아가 보자 – 내가 잃어 버렸는가? 우리는 거기에 갈. 자, 이것이 지금까지 이야기 한 관점에서 이것은 의미가 있습니다. 우리가 수집 한 데이터는 라이센스와 기타 여러 가지 이유로 분명히 중요합니다.
마지막으로 언급 할 것은 여기이 관리 섹션으로 넘어가는 것입니다. 여기에서 이메일과 알림을 구성하고 실제로 알고 싶은 사항에 대해서도 설정할 수 있습니다. 따라서 이메일 알림을 설정하고 특정 기능을 설정하고 특정 기능을 해제 한 다음 해당 이메일을받을 사람을 결정하고 원하는 사람과 연결할 수있는 알림을 구독 할 수있는 기능을 설정할 수 있습니다 그런 종류의 것들에 대해 알고 싶어하는 사람이 되십시오.
그러나 앞서 말했듯이, 이것은 전체 엔터프라이즈 SQL 인스턴스에 대해 알고 있고 최소한의 상황에서도 최적의 상태로 실행되도록하는 것에 대해 전체적으로 안심할 수있는 정말 좋은 방법입니다. t, 해당 인스턴스를 관리하기 위해 강력한 타격 성능 모니터링 도구에 투자하기로 결정하지 않았습니다. 외출하는 매우 저렴한 방법이기 때문에 많은 경우에 이러한 인벤토리를 수행하고 매우 광범위한 종류의 일반적인 모니터링 수준을 수행하여 마음의 평화를 얻고 무슨 일이 일어나고 있는지 알고 있습니다.
우리가 설명하고 그것을 당신에게 보여준 방식으로 이해가 되길 바랍니다. 나는 그 관점에서 내가 다시 그것을 통과하고 우리가 더 이야기 할 수 있다고 생각합니다.
에릭 카바나 흐 : 그거 좋은 데요. 로빈? 데즈? 질문 있나요?
로빈 블로어 : 글쎄요. 질문이 있습니다. 실제로 매우 흥미 롭습니다. DBA뿐만 아니라 네트워크 담당자, 스토리지 담당자, 가상 머신 관리 담당자 사이에있는 거의 모든 곳에서 의견을 남기고 싶었습니다. 모든 스프레드 시트 작업.
에릭 카바나 흐 : 그렇습니다 .
Dez Blanchfield : 여러분은 그것이 숫자라는 것을 알고 있습니다. 숫자가 움직이기 시작할 때까지는 괜찮습니다. 숫자가 움직이기 시작하면 문제가 생길 것입니다. 그래서 지금 질문에 관심이 있고 대답하기가 어려울 것이라는 것을 알고 있지만 스프레드 시트 작업을 위해 이것과 같은 것이없는 곳으로 가면 어떻습니까? DBA는 매우 똑똑한 사람입니다. 이런 식으로 구현하면 어떤 ROI를 얻을 수 있을까요? 그에 대한 수치 나 그에 대한 지침이 있습니까?
Bullett Manale : 환경이 약간 다를 수 있기 때문에 ROI가 무엇인지 말하기 어렵습니다. 분명히 기업 규모가 클수록 환경이 커질 것입니다. ROI가 현재 수동 방법을 사용하고 있다면 ROI가 더 커질 것입니다.
저는 수많은 직원들과 수천 명에 이르는 대규모 조직과 수천 명에 이르는 사람들과 대화를 나 when습니다. 내 시간의 2 주. 나는 그 말을 두 번 이상했다. 따라서 구매로 인한 실제 달러 금액으로 말하기는 어렵지만 환경이있을 때 상당히 중요합니다.
내가 말했듯이, 그것은 꽤 일관성이 있습니다. 그것은 사람들입니다. 제가 이야기하는 사람들의 대부분은이 자료를 스프레드 시트에 보관하고 있습니다. 모든 환경이 라이선싱 방식과 Microsoft와 라이센싱을 수행하는 방식이 조금씩 다르기 때문에 매우 주관적인 것입니다. 그러나 그들이 매년 또는 3 년마다 진정한 업을해야한다면, 3 년마다 최대 3 년 동안 마이크로 소프트가 최대로 생각한다고 생각합니다.
그렇다면 당신은 그것의 상당한 것을 알고 있으며, 그것이 훨씬 더 쉽게 만드는 것임을 알고 있습니다. 항상 바뀌는 역동적 인 것이므로 구절을보고있는 측면에서 조금 더 유효합니다 .6 개월 또는 1 년 안에 스프레드 시트를 실제로 업데이트하지 않았습니다. 따라서 스프레드 시트를 얼마나 자주 업데이트하고 있습니까? ROI에 대한 답을 이해하기위한 또 다른 질문입니다.
Dez Blanchfield : 예, SQL 라이센싱입니다. 라이센싱은 정말 악몽이지만, 마이크로 소프트와 오라클과 데이터베이스 작업을 수행하는 다른 사람과 라이센싱이 동일하지 않기 때문에 특히 악몽입니다. 실제로 실제로 발생하는 경향이있는 스프레드 시트에 물건을 보관하는 경우 실제로 라이센스를 인식하기 전에 라이센스 시간이 다가오고 실제로 의미를 알면 쉽게 얻을 수있는 데이터가 없다는 것을 알고 있습니다. 그 정보.
어쨌든, 지적한 것처럼 역동적이며 실제로 Microsoft와 협상 할 필요가 없었기 때문에 개인적으로 전혀 알지 못합니다. 그래도 사람들은 테스트 데이터를 자주 내려 받아 테스트하는 데이터베이스가 있습니다. 라이센싱을 수행하는 경우 환경이 가시적이라고 생각합니다. 그게 너야?
글 머리 기호 : 예, 예. 많은 경우에 대해 잊어 버린 다음 파악하려고 시도하기 시작합니다. 좋습니다. 좋아요. 이러한 각 인스턴스의 코어 수를 알아 내야하는 핵심 라이센스가 있습니다. 당신이 하드웨어를 현명하게 구매하는 것에 대한 표준의 관점에서, 당신은 꽤 좋은 하드웨어를 구입할 수있을 것입니다. 만약 당신이 그 하드웨어를 사용하지 않으면 그것을 사용해야하는 방식으로 과잉 지불하고 있기 때문에 이러한 코어를 활용하지 않을 때 코어 가격을 지불하면 문제가됩니다.
따라서 각 버전의 SQL은 라이센스가 적용되는 방식이 다르기 때문에 약간 혼란스러워집니다. 그래서 당신은 그 문제에 대해 약간의 어려움을 겪고 있습니다.이 정보가 어떤 버전인지 알 수 있기 때문에이 정보가 매우 도움이되는 이유 중 큰 부분입니다 .SQL의 이전 버전 인 경우 가지고있는 코어 수를 분명히 알 수 있습니다 그것은 소켓 당 가격이었습니다. 우리는 여전히 그것을 분명히 보여줄 수 있습니다. 그것은 단지 그 일을 실현할 시간이되었을 때 거쳐야하는 일상의 과정을 훨씬 간단하게 만듭니다.
Dez Blanchfield : 저에게 떠오르는 한 가지, 죄송합니다.
로빈 블로어 : 괜찮습니다. 당신은 데즈에갔습니다. 아마도 관련이없는 질문을하려고했습니다.
Dez Blanchfield : 현재 진행중인 주제에 대해 매우 빠르게 설명합니다. 클라우드 환경이 훨씬 더 많이 채택되고 있으며, 데이터 센터, 자체 환경, 그들은 기어 다니면서 발견하고, 물건을 발견하는 것이 비교적 간단합니다.
우리는 어떻게, 우리는 세 개의 데이터 세트, 두 개의 클라우드 및 이러한 환경에 대한 가시성이 방화벽과 파이프 또는 VPN의 끝에 데이터 세트가있는 시나리오에 어떻게 대처 하는가. 프론트 엔드에서 발견해야하거나 포트 개방을 시작하기 위해 필요한가?이 플랫폼이 실행되는 클라우드와 구내 사이의 특정 환경에서 스캔 할 수 있습니까?
Bullett Manale : 예, 포트 측면에서 약간의 고려가있을 것입니다. 불행히도 나는 모든 환경을 돌파 할 것이라고 말할 수 있기를 희망하지만 이것으로 할 수있는 몇 가지 다른 옵션이 있습니다. 분명히, Amazon EC2와 같은 작업을 수행하는 경우 포트가 열려 있다고 가정하고 연결된 IP 주소 또는 도메인을 지정할 수 있다고 가정하면 연결을 통해 해당 환경에 액세스 할 수 있습니다. 수집 및 발견 시작.
이런 환경에서는 실제로 문제가되지 않습니다. RDS와 같은보다 구체적인 유형의 환경이며, 해당 유형의 정보를보고 발견하기가 조금 더 어려운 데이터베이스 자체를 얻는 것입니다.
Dez Blanchfield : 여기부터 데이터베이스와 데이터베이스가 있습니다. 예를 들어, 과거에 공유했던 일화와 같은 매우 큰 데이터베이스 엔진을 가진 좋은 옛날 시절은 단지 하나의 거대한 플랫폼이며 공유하는 것은 데이터베이스를 제공하는 것입니다. 요즘 데이터베이스는 모든 것에 내장되어 있습니다. 사실, 2 ~ 3 개 정도는 내 폰에서 앱 뒤에서 실행되는 것과 같습니다.
Lotus Notes에서 오는 환경, 그 뒤에 앱, 다양한 인터넷의 데이터베이스가있는 SharePoint 등의 환경에서 어떤 문제가 발생합니까? 기본적으로 모든 것은 백엔드의 데이터베이스로 구동됩니다. 당신은 어떤 종류의 것들을보고 있고 사람들이 그러한 종류의 세계를 매핑하려고 시도하는 것에 직면하고있는 어떤 종류의 도전과 당신의 도구가 그들을 위해 무엇을하는 것을보고 있습니까?
Bullett Manale : 글쎄요 . 당신이 말한 것 – 모든 것이 지금 데이터베이스를 필요로하기 때문에 많은 시간이있을 것입니다. DBA 자체가 환경에 도입되는 많은 데이터베이스가있을 것입니다. 환경에 SQL 서버를 설치하는 것은 그리 어렵지 않기 때문에 알지 못합니다.
이 도구는 Express 데이터베이스와 같은 SQL Server의 무료 버전도 식별합니다. 재밌게도, DBA와 대화 할 때 다시 한 번, 거기에있는 무료 데이터베이스에 대해 일관된 답변을 얻지 못합니다. 당신이 말하는 이러한 많은 어플리케이션들은 무료 버전의 데이터베이스를 사용할 것입니다. 그러나 조직 자체는 사용자와 대화하는 사람에 따라 해당 데이터베이스를 담당하는 사람에 따라 다른 태도를 갖습니다.
필자가 말하는 일부 DBA는 시애틀에있는 SQL Server PASS에 마지막으로 있었을 때“익스프레스 데이터베이스에 관심이 있습니까?”라는 질문을했을 때를 생각해 볼 수 있습니다. 일부 사람들은 DBA로 알고 싶어했습니다. 왜냐하면 그들은 여전히 중요한 정보를 포함 할 수있는 표현 된 데이터베이스조차도 책임의 일부라고 생각했기 때문입니다. 그들은 여전히 백업 과정을 거쳐야하며 여전히 모든 것이 건강에 대한 관점에서 작동하고 있는지 확인해야합니다. 그러나 그들이 존재한다는 것을 아는 것만 큼 중요하지는 않습니다.
나머지 절반은 "이봐, 우리는 그 데이터베이스에 대해 책임을지지 않는다"며 "데이터베이스를 설치 한 사람은 데이터베이스를 설치 한 사람을 조심해야한다"고 말했다. 현재는 거의 모든 응용 프로그램에 응용 프로그램이 연결되어있어 해당 정보를 인벤토리로 작성해야하는 복잡성과 혼란에 더 많이 기여하고 있습니다.
Dez Blanchfield : 예, 정부 사이트는 제가 가장 좋아하는 것으로 보이나 지금은 엔터프라이즈 환경에서 볼 수있는 것보다 더 자주 보았습니다. 자체 교환과 같이 원하는대로 무료 버전을 제공하므로 신속하게 설치하고 라이센스를 구매할 필요가 없기 때문에 무료 버전이 제공됩니다.
그런 다음 규모가 커지고 누군가가 성능에 대해 불평하기 시작합니다.“오래된 서버, 스토리지, 네트워크 등 무엇이든”DBA가 호출되고“글쎄요. ve는이 무료 버전의 데이터베이스에 모든 것을 넣었습니다.
특히 Project Manager 및 Office와 같은 시나리오를 사용하면 대기업이나 회사에서 수천 개의 프로젝트가 아닌 경우 수백 개의 프로젝트를 실행하고 Microsoft Project Server와 함께 SharePoint를 사용하고 있으며 모든 PMO 항목을이 데이터베이스에 덤프합니다. 그러나 프론트 엔드는 마치 웹 인터페이스와 같습니다. 그러나 실제로 데이터베이스와 데이터베이스가 있습니다.
총알 관리 : 예.
Dez Blanchfield : 여기 사람들이하는 첫 번째 단계 중 하나 인 우리는 청중들로부터 우리가 가져오고 싶은 몇 가지 질문이 있다고 생각합니다. 첫 번째 질문 중 하나는 사람들이 어디서 시작합니까? 그들이 가야 할 첫 번째 자연스런 단계는 무엇입니까?“알코올 릭 익명 버전을해야합니까?”
우리는 우리가해야 할 일보다 많은 데이터베이스를 가지고 있습니다. "좋아, 이걸 가져 와서 달리기 시작 해봐야 해?" ?
Bullett Manale : 글쎄, 그들이 환경을 매핑해야한다고 생각합니다. 이제 Microsoft는 무료 평가 도구 인 Microsoft Assessment Planning Tool을 제공합니다.이 도구는 무료 도구이지만 정적 인 도구입니다. 당신은 발견을하고 그게 전부입니다. 당신은 거기에있는 것들의 목록을 얻습니다. 우리는 그것을 가지고 한발 더 나아가 보자. 발견을하고, 거기에 무엇이 있는지 찾아서 저장소에 넣고, 역동적이고 추가 할 수 있도록 만들어 봅시다.
그러나 전반적으로 가장 큰 첫 번째 단계는 발견하고 발견하는 것입니다. 시험판으로 제품을 다운로드해야하는지 여부에 관계없이이 제품을 다운로드하여 14 일 동안 시험판으로 사용할 수 있으며 환경을 지적하고 수집 할 수 있습니다.
정보가 정확하다고 확신하는 정보가 많은 스프레드 시트가 이미있는 경우 모든 정보가 포함 된 스프레드 시트를 CSV로 가져 와서 원하는 부분을 만들 수 있습니다. 이미 가지고 있습니다. 그러나 당신이 모르는 것을 알아내는 관점에서, 그것을하는 유일한 방법은 수동으로 나가거나, 또는 이와 같은 유형의 것을 찾는 도구를 갖는 것입니다. 그것은 당신이 어떤 시점에서해야 할 결정입니다.“저는 그 발견을 자동화하려고하거나 적어도 무엇을 먼저 찾은 다음 예외에 대해 걱정할 것입니까?”입니다. 대부분 도구가 필요할 것입니다.
Dez Blanchfield : 빨리. 사람들은 어디에서 이것을 시작합니까? 그들은 당신의 웹 사이트를 공격? 그들은 어떻게 빨리 이것에 도달하고 시작합니까?
Bullett Manale : IDERA.com, Idera에 가면 실제로 볼 수 있으며 실제로 실제로 빠르게 표시 할 수 있습니다. Idera 웹 사이트에서 제품으로 이동하고 재고 관리자로 이동하십시오. 여기에 다운로드 링크가 있습니다. 64 또는 32 비트에 설치할 빌드를 결정하기 만하면됩니다. 그러면 거기서 발견을 시작할 수 있습니다.
Robin Bloor : 환상적이고 훌륭하고 훌륭한 프레젠테이션입니다. 대단히 감사합니다.
Bullett Manale : 감사합니다.
에릭 카바나 흐 (Eric Kavanagh) : 우리는 청중으로부터 몇 가지 질문을했고 오늘 우리는 열심히 막아야하기 때문에 이메일을 보낼 것입니다. 그러나 다시 한번 Bullett는 데모에 대한 훌륭한 직업입니다. t 표시.
Bullett Manale : 죄송합니다.
Eric Kavanagh : 아니요. 좋은 일입니다. 비즈니스의 핵심에 대한 가시성을 제공하고 있습니까? 비즈니스가 데이터를 실행하고 핵심을 바로 파악할 수 있기 때문입니다. 더 이상 손을 흔들지 않습니다. 이제 실제로 사물을 가리키고 해결할 수 있습니다. 당신을 위해 좋은.
Bullett Manale : 감사합니다.
로빈 블로어 : 그러나 그것이 너무 잘 살아가는 것을 보는 것이 좋았습니다.
Eric Kavanagh : 예, 나중에 볼 수 있도록이 웹 캐스트를 보관 한 다음 약 1 시간 또는 2 시간 내에 초기 보관소가 올라가는 경우가 있습니다. 때로는 그보다 약간 길어질 것입니다. 알고있다. 그것으로 우리는 당신을 보내 줄 것입니다. 브리핑 실에 다시 참석해 주셔서 감사합니다. 실제로 Hot Technologies입니다. 다음에 연락 드리겠습니다. 잘 가세요
