신속한 대응 : 데이터베이스 디버깅 및 구조 프로파일 링

작성자 : Techopedia Staff, 2017 년 3 월 15 일

테이크 아웃 : 호스트 Eric Kavanagh는 Dr. Robin Bloor, Dez Blanchfield 및 IDERA의 Bert Scalzo와 데이터베이스 디버깅 및 프로파일 링에 대해 논의했습니다.

현재 로그인하지 않았습니다. 비디오를 보려면 로그인 또는 가입하십시오.

에릭 카바나 흐 : 좋아, 신사 숙녀 여러분, 수요일은 수요일 4:00 동부 표준시입니다.

로빈 블로어 : 안 들려, 에릭

에릭 카바나 : 전 며칠 전에 있었기 때문에 당신은 혼자가 아닙니다. 그러나 오늘날의 주제는 정말 흥미로운 것입니다. 당신이하고있는 사람이 아닌 한, 회사의 배경에서 일어나고 싶은 것은 당신이 제대로하고 있는지 확인하고 싶을 때입니다. 우리는 디버깅에 대해 이야기하고 있기 때문에. 누구도 버그를 좋아하지 않으며, 소프트웨어가 작동을 멈출 때 아무도 좋아하지 않습니다. 그 좋지 않다. 그래서 우리는 "신속한 응답 : 데이터베이스 디버깅 및 구조 프로파일 링"에 대해 이야기 할 것입니다.

트위터에 @eric_kavanagh를 알려주십시오.

올해는 덥습니다. 그리고 무엇이든 디버깅은 뜨겁습니다. 실제로는 결코 사라지지 않을 이러한 문제 중 하나가 될 것입니다. 우리 가이 물건을 얼마나 잘 얻든 항상 문제가있을 것이므로 열쇠는 이러한 문제를 신속하게 해결할 수있는 방법에 도달하는 방법입니다. 이상적으로는 프로그래머가 많고 환경이 좋지만 너무 잘못되지는 않지만 이전의 말처럼 "사고는 최고의 가족에서 발생합니다"라고 말하면 조직에도 마찬가지입니다. 그래서, 이런 일이 일어나고, 일어날 일이며, 문제는 그 문제를 해결하고 그 문제를 해결하기위한 당신의 해결책은 무엇입니까?

우리는 Dr. Robin Bloor, 그리고 우리 자신의 Dez Blanchfield와 아래에서 IDERA의 좋은 친구 Bert Scalzo를들을 것입니다. 그리고 실제로, 열쇠를 Robin Bloor에게 건네 주겠습니다. 바닥은 당신입니다.

로빈 블로어 : 좋습니다. 이것은 흥미로운 주제입니다. Dez가 디버깅에 대한 실제 기술과 전쟁 이야기에 대해 계속 논의 할 것이기 때문에 배경 토론을 수행하여 진행 상황에 대한 완전한 그림을 얻을 것이라고 생각했습니다. 나는 이것을 오랫동안했고 코더로 사용 했으므로 오픈 소스 아이디어에 대해 서정적 인 서정을 시작하기 위해이 프레젠테이션에 거의 유혹을 받았지만 다른 사람에게 맡길 것이라고 생각했습니다.

다음은 유명한 버그 목록이며, 대부분 버그 목록은 기본적으로 마지막 2 개를 제외한 1 억 달러 이상입니다. 첫 번째는 화성 기후 궤도 (Mars Climate Orbiter)였으며 우주에서 길을 잃었고 사람들이 미터 단위를 (웃음) 피트와 인치와 혼동하는 코딩 문제 때문이었습니다. Ariane Five Flight 501에 장착 된 엔진과 로켓이 발사 될 당시의 컴퓨터 사이에 불일치가있었습니다. 여러 컴퓨터 오류, 로켓 폭발, 헤드 라인 뉴스. 1982 년 소련 가스 파이프 라인은 지구 역사상 가장 큰 폭발이라고 말했다. 나는 확실하지 않다. 러시아인들은 자동화 된 제어 소프트웨어를 훔 쳤고 CIA는 그 일을하고 버그를 넣을 것이라는 것을 깨달았고 소련은 테스트하지 않고 그것을 구현했습니다. 그래서 파이프 라인을 폭발 시켰습니다.

모리스 웜은 코딩 실험으로 갑자기 모든 사람을 돌며 다량의 웜이되었으며 1 억 달러의 피해를 입었습니다. 물론 추정치입니다. 인텔은 1993 년에 Pentium 칩에 대한 수학 명령 인 maths 칩으로 유명한 오류를 일으켰습니다. 애플의지도 프로그램은 아마도 애플이 한 일 중 최악의 최악의 일이다. 그것을 사용하려고 시도한 사람들은 누군가 101 세를 운전하고 있었고 애플 맵이 샌프란시스코 베이의 한가운데에 있다고 말한 것을 발견했습니다. 그래서 사람들은 Apple Maps 앱을 iLost라고 부르기 시작했습니다. -1990 년에 가장 긴 정전 – AT & T는 약 9 시간 동안 나가고 장거리 전화에 약 6 천만 달러가 들었습니다.

저는 영국의 보험 회사에 있었고 데이터베이스에서 새로운 버전의 데이터베이스를 구현하여 데이터를 삭제하기 시작했습니다. 그리고 나는 그 때문에 어떤 종류의 데이터베이스 선택에 참여하라는 요청을 받았기 때문에 그것을 매우 잘 기억합니다. 그리고 그들이 새로운 버전의 데이터베이스를 가져 왔고 모든 테스트를 통과 한 새로운 버전의 데이터베이스에 대해 수행 한 테스트가 매우 흥미 롭습니다. 데이터를 지우는 정말 모호한 방법을 찾았습니다.

어쨌든 그게 다야 임피던스 불일치와 SQL 발행에 대해 이야기 할 것이라고 생각했습니다. 관계형 데이터베이스는 데이터를 테이블에 저장하고 코더는 실제로 테이블에 잘 매핑되지 않는 객체 구조의 데이터를 조작하는 경향이 있습니다. 그리고 그 때문에, 당신은 임피던스 불일치라고 불리는 것을 얻습니다. 그리고 누군가는 어떤 식 으로든 그것을 처리해야합니다. 그러나 실제로는 어떤 모델, 코더의 모델 및 다른 모델의 데이터베이스가 특별히 정렬되지 않았기 때문에 어떤 일이 발생합니까? 업계에서 함께 작동하는 것들을 만들었을 때 발생하지 않는 버그가 생겼습니다. 따라서 기본적으로 코더 측에서는 계층 구조를 얻을 때 유형이 될 수 있고 결과 집합이 될 수 있으며 API 기능이 좋지 않을 수 있으며 데이터베이스와의 상호 작용이라는 측면에서 문제를 던지는 많은 일이 될 수 있습니다. 그러나 나에게 가장 중요한 것은 정말 흥미 롭습니다. 코더와 데이터베이스가 서로 작동하는 방식으로 일종의 임피던스 인이 SQL 장벽이 있다는 사실에 항상 놀랐습니다. 따라서 SQL에는 데이터 인식 기능이 있으며 선택, 프로젝트 및 조인에 대한 DML이 있습니다. 이를 통해 데이터베이스에서 데이터를 가져 오는 측면에서 많은 기능을 사용할 수 있습니다. 그러나 작업을 수행하는 데 필요한 수학적 언어는 거의 없습니다. 그것은 이것과 약간의 것을 가지고 있으며, 시간 기반의 것들이 거의 없습니다. 그리고 그 때문에 SQL은 불완전합니다. 원한다면 데이터를 얻는 수단이 아닙니다. 따라서 데이터베이스 사용자는 데이터베이스에 저장하기 위해 저장 프로 시저를 작성했으며 저장 프로 시저가 존재하는 이유는 실제로 프로그램에 데이터를주고 받기를 원하지 않았기 때문입니다.

일부 기능의 경우 데이터에 매우 특화된 것이기 때문에 참조 무결성 및 계단식 삭제 등이 아니라 데이터베이스가 갑자기 기능을 데이터베이스에 넣는 것을 데이터베이스가 처리하고있었습니다. 응용 프로그램의 기능은 코더와 데이터베이스 자체간에 분리 될 수 있습니다. 그리고 그것은 어떤 종류의 기능을 구현하는 일을 정말로 어려워서 오류가 발생하기 쉽도록 만들었습니다. 예를 들어, 그것은 관계형 데이터베이스에 관여했다는 것을 의미하기 때문에 데이터베이스 게임의 한 측면입니다. 실제로 처리되는 저장 프로 시저에있는 엄청나게 많은 코드가 있습니다. 응용 프로그램에있는 코드와 별도로 그리고 그것은 매우 이상한 일처럼 보입니다. 다양한 일을하는 데 상당히 똑똑해야합니다.

성능 오류는 종종 버그로 간주되기 때문에 데이터베이스 성능에 대해서도 이야기한다고 생각했지만 기본적으로 CPU, 메모리, 디스크, 네트워크의 병목 현상이 발생할 수 있으며 잠금으로 인해 성능 문제가 발생할 수 있습니다 . 코더는 실제로 성능에 대해 걱정할 필요가 없으며 데이터베이스는 실제로 실제로 성능이 좋을 것입니다. 코더가 알 필요가 없도록 설계되었습니다. 그러나 잘못된 데이터베이스 디자인, 잘못된 프로그램 디자인, 워크로드 믹싱의 동시성이 발생하여 성능 문제가 발생할 수 있습니다. 로드 밸런싱, 용량 계획, 데이터 증가가 발생하여 데이터베이스가 중지되거나 속도가 느려질 수 있습니다. 데이터베이스가 거의 가득 차면 속도가 느려집니다. 또한 복제, 복제 필요성 및 백업 및 복구 수행 측면에서 데이터 계층 문제가 발생할 수 있습니다. 어쨌든, 그것은 일반적인 개요입니다.

내가 말하고 싶은 유일한 것은 데이터베이스 디버깅이 번거롭고 사소한 것일 수 있다는 것입니다. 그리고 많은 일을했기 때문에 디버깅을하는 모든 상황과 비슷하다는 것을 종종 알게 될 것입니다. 당신이 이제까지 본 것은 엉망입니다. 그리고 당신은 엉망에서 어떻게 엉망이 생겼는지 해결하기 위해 노력해야합니다. 그리고 종종 데이터베이스 문제를보고있을 때보고있는 모든 것은 손상된 데이터이며 "도대체 어떻게 그런 일이 있었습니까?"라고 생각하고 있습니다.

어쨌든, 나는 데즈에게 넘어갈 것입니다. 데즈는 아마도 내가 나온 것보다 더 많은 지혜의 말을 할 것입니다. 공을 어떻게 넘겨 줄지 모르겠어, 데즈

에릭 카바나 흐 : 나는 그것을 지나갈 것이다.

자동 음성 : 참가자 회선이 음소거되었습니다.

에릭 카바나 흐 : 좋아, 잠깐만, 데즈에게 공을 줘.

Dez Blanchfield : 감사합니다, Eric. 네, 로빈 블로어 박사님, 당신은 실제로 가장 정확합니다 : 이것은 주제입니다, 당신이 말장난을 용서한다면 평생 벌레가 될 것입니다, 미안하지만 저를 도울 수 없었습니다. 바라건대 첫 번째 화면, 상단의 글꼴 크기 문제에 대한 사과를 볼 수 있기를 바랍니다. 버그에 대한 주제는 하루 종일 강의이며, 대부분의 경우 내 경험에 있습니다. 매우 광범위하고 광범위한 주제이므로 두 가지 주요 영역, 특히 버그로 간주되는 개념이지만 프로그래밍 문제에 중점을 둘 것입니다. 요즘 버그 자체를 도입하는 것은 일반적으로 통합 개발 환경에서 오래 걸리는 버그 일 수 있다고 생각합니다. 그러나 종종 코드 프로파일 링의 경우가 더 많으며 버그가 있어야 작동하는 코드를 작성할 수 있습니다. 제목 슬라이드가 여기에 있습니다. 실제로 고해상도 A3로이 사본을 가지고 있었지만 불행히도 집안에서 파괴되었습니다. 그러나 이것은 1945 년경 프로그래밍 시트에 손으로 쓴 메모입니다. 미국 하버드 대학교의 일부 사람들은 Mark II라는 두 번째 기계를 만들었습니다. 그들은 공통 언어로 문제를 디버깅하고 있었지만 결함을 찾으려고 노력했으며 하드웨어 및 소프트웨어 문제와 약간 다른 것으로 나타났습니다.

따라서 도시 신화는 1945 년 9 월 9 ^일경 하버드 대학교의 한 팀이 기계를 떼어 내고“릴레이 칠십”이라는 것을 발견 한 것입니다. 그 당시 프로그래밍은 물리적 의미에서 이루어졌습니다. 보드 주위에, 그것은 당신이 기계를 효과적으로 프로그램하는 방법이었습니다 – 그리고 그들은이 릴레이 번호가 70 번이라는 것을 발견했습니다. 그리고 그것은 실제로 "버그"가 문자 그대로 나방 이었기 때문에 나왔을 것입니다. 한 곳에서 다른 곳으로가는 구리 철사 조각 사이에 나방이있었습니다. 그리고 이야기는 전설적인 그레이스 호퍼 (Grace Hopper)라는 제목으로“제 1의 실제 버그 발견”이라는 인용문을 인용 한 인용구입니다.

그러나 Robin이 첫 번째 슬라이드에서 앞서 강조한 것처럼 버그의 개념은 패치와 같은 개념 인 컴퓨팅을하는 사람을 상상할 수있는 한 멀리 거슬러 올라갑니다. "패치"라는 용어는 펀치 카드의 구멍에 테이프로 고정 된 실제 테이프에서 비롯된 것입니다. 그러나 이것의 핵심은“디버깅”이라는 용어는 물리적 시스템에서 버그를 찾는 개념에서 나온 것입니다. 그 이후로 우리는 컴파일되지 않는 프로그램의 코딩 문제뿐만 아니라 제대로 실행되지 않는 프로그램과 같은 문제를 다루기 위해 그 용어를 사용해 왔습니다. 그리고 특별히 프로파일 링되지 않았으며 끝없는 루프와 같은 것을 찾을 수 있습니다.

그러나 우리는 시나리오도 가지고 있으며, 좀 더 자세히 설명하기 전에 몇 가지 재미있는 슬라이드를 넣을 것이라고 생각했습니다. 다음은 웹에서 XKCD라는 클래식 만화입니다. 만화가는 전 세계에서 꽤 재미있는 견해를 가지고 있습니다. 그리고 이것은“작은 바비 테이블”이라는 아이에 관한 것이며 아마도 그의 부모는이 어린 소년을 Robert라고지었습니다.); DROP TABLE 학생;-그리고 그것은 일종의“안녕하세요, 이것은 여러분 학교의 컴퓨터 문제를 겪고있는 당신의 아들 학교입니다.”그리고 부모님은“아, 자기가 무언가를 깨뜨 렸습니까?”하고 대답합니다. 어떤 식 으로든”그리고 교사는“당신은 정말로 당신의 아들 로버트의 이름을 지었습니까?”라고 묻습니다. DROP TABLE 학생;-?”그리고 부모님은“아, 우리가 그를 부르는 작은 바비 테이블”이라고 말합니다. 어쨌든, 그들은 이제 올해의 학생 기록을 잃어 버렸다고 말하면서 계속 행복해지기를 바랍니다. 그리고 응답은 "글쎄, 당신은 데이터베이스 입력을 정리하고 소독해야합니다."그리고 저는 코드에서 데이터를 찾을 때 발생하는 몇 가지 문제에 대해 이야기하기 위해 여러 번 사용합니다. 게다가.

또 다른 재밌는 사람, 이것이 진짜인지 아닌지 모르겠습니다. 스푸핑 인 것 같지만 다시는 내 재미있는 뼈에 닿습니다. 누군가 자동차 앞면의 번호판을 자동차의 번호판을 캡처하는 속도 카메라 등을 떨어 뜨리는 유사한 진술로 변경했습니다. 그리고 나는 항상 프로그래머가 실제 자동차에 의해 코드의 히트와 실행을 예상 한 것은 의심하지만 화난 괴짜의 힘을 결코 과소 평가하지는 않는다고 항상 언급합니다.

(웃음)

그러나 이것은 내 요점으로 이어지고, 한 번에, 우리는 단순한 필사자로 코드를 디버깅하고 프로파일 링 할 수 있다고 생각합니다. 그러나 나는 그 시간이 지났다는 내 견해를 매우 잘 알고 있으며, 내 경험상 처음으로 – 그리고 이것이 나에게 끔찍하게 노화 될 것이라고 확신합니다. 로빈 당신은 이것에 대해 나에게 재미를 찌르는 것을 환영한다 – 그러나 역사적으로 나는 도시의 끝을 방황하고 14 세의 나이에 배경에서왔다. 그리고 New에서“Data Com”이라는 데이터 센터의 문을 두드렸다. 뉴질랜드에서 매일 25km의 통근 버스를 타거나 학교에 종이를 프린터에 넣고 테이프를 테이프 드라이브에 넣고 일반 관리자가되어 학교에서 돈을 벌 수 있는지 물어 봅니다. 그리고 흥미롭게도 그들은 나에게 직업을 주었다. 그러나 시간이 지남에 따라 나는 스태프에 들어가 프로그래머를 찾고 코딩을 좋아하고 스크립트와 배치 작업을 실행하는 프로세스를 거치는 것을 보았습니다. 미니 프로그램처럼 보이는 스크립트 및 배치 작업을 작성하고 직접 코드를 작성하는 3270 터미널에 앉아 전체 프로세스를 수행해야합니다.

사실, 나의 첫 경험은 텔레타이프 터미널에서 132 열의 실제 프린터였습니다. 본질적으로 CRT 튜브가 없었기 때문에 종이를 스크롤 한 오래된 타자기를 생각하십시오. 그리고 그 코드를 디버깅하는 것은 매우 사소한 문제였습니다. 따라서 모든 코드를 손으로 작성한 다음 타이피스트처럼 행동하여 몰래 오류가 발생하지 않도록 최선을 다하는 것이 가장 실망 스럽습니다. 한 줄 편집기를 사용하여 특정 줄로 이동 한 다음 줄을 인쇄 한 다음 다시 입력하십시오. 그러나 한 번에, 그것은 코드를 작성하는 방식이었고, 그것이 우리가 디버깅하는 방식이었습니다. 사실, 그것은 우리에게 아주 좋은 프로그래밍 기술을 요구했습니다. 왜냐하면 그것을 고치는 것은 정말 번거롭기 때문입니다. 그러나 그 여정은 그 과정을 거쳤습니다. 그리고 우리 모두는이 점에 익숙합니다. 제 세계의 3270 터미널 경험에서 화면의 내용을 볼 수있는 Digital Equipment VT220으로 갔지만 다시는 똑같은 일을하고있었습니다. CRT에서 인쇄 된 형식의 종이 테이프를 사용했지만 더 쉽게 삭제할 수 있었고 "dit dit dit dit"사운드가 없었습니다.

그리고 Wyse 150과 같이 Wyse 150과 같은 컴퓨터에서 가장 좋아하는 인터페이스, 그리고 PC와 Mac, 그리고 오늘날에는 웹 기반의 최신 GUI와 ID가 있습니다. 그리고이를 통해 다양한 프로그램, 하나 및 어셈블러 및 PILOT, 로고 및 리스프, Fortran 및 Pascal로 프로그래밍, 사람들을 울부 짖게 할 언어. 그러나 이들은 좋은 코드를 작성하도록 강요 한 언어입니다. 그들은 당신이 나쁜 습관을 피하게하지 못했습니다. C, C ++, Java, Ruby, Python – 그리고 프로그래밍 단계를 더 발전시키고, 스크립트와 비슷해지며, SQL을 호출하는 데 사용되는 PHP와 같은 언어 및 Structured Query Language에 더 가까이 다가갑니다. 내 배경에서 왔을 때 나는 여러 가지 방법으로 스스로를 배웠고, 배우는 데 도움이되는 것들을 배우고 디자인과 프로세스에 대해 훌륭한 프로그래밍 실습과 훌륭한 실습을 가르쳐서 내가하지 않도록했습니다. 버그가있는 코드를 소개합니다.

요즘 프로그래밍 방법, 예를 들어 구조적 쿼리 언어, SQL과 같은 것은 매우 강력하고 간단한 쿼리 언어입니다. 그러나 우리는 그것을 프로그래밍 언어로 바꾸었고 SQL이 현대 프로그래밍 언어로 설계되었다고 생각하지는 않지만 그 언어로 기울어졌습니다. 그리고 그것은 두 가지 관점, 즉 코딩 관점과 DBA 관점에서 생각할 때 많은 문제를 야기합니다. 프로그래밍 기술이 열악하고 코드 작성에 대한 게으른 노력, 경험 부족, 예를 들어 SQL 사람들이 Google에서 점프하고 무언가를 검색하고 웹 사이트를 찾는 것과 같은 고전적인 애완 동물 친구들과 같은 버그를 쉽게 소개하고 소개 할 수 있습니다. 예를 들어 기존 코드를 복사하여 붙여 넣습니다. 그런 다음 잘못된 코딩, 과실을 복제하고 생산에 투입하면 원하는 결과를 얻을 수 있기 때문입니다. 예를 들어, 요즘 우리는 경쟁을 제로로 돌리기 위해 요즘 우리 모두에게 달려 가고 있습니다. 저렴하고 빠른 모든 것을하려고 노력하면서 우리는 더 낮은 고용률을 갖지 않는 시나리오를 가지고 있습니다. 유료 직원. 그리고 나는 의미없는 방식으로, 그러나 우리는 가능한 모든 직업에 전문가를 고용하지 않습니다. 옛날 옛적에 컴퓨터와 관련된 것은 로켓 과학이었습니다. 그것은 쾅하고 매우 시끄러운 일에 관여했거나 우주로 갔거나 엔지니어는 학위를 받았으며 엄격한 교육을 받아 미친 일을하지 못하게하는 자격을 갖춘 남성과 여성이었습니다.

요즘에는 수년간의 경험이 없었고 반드시 동일한 교육이나 지원을받지 못한 개발 및 디자인 및 데이터베이스에 많은 사람들이 있습니다. 그래서 당신은 전통적인 아마추어 대 전문가의 시나리오로 끝납니다. 유명한 선이 있는데, 실제로 누가 견적을 작성했는지 기억이 나지 않습니다.“전문가를 고용하는 데 비용이 많이 든다고 생각되면 문제를 일으키는 아마추어를 고용 할 때까지 기다리십시오. SQL은 그 문제를 가지고 있으며, 배우기가 매우 쉽고 사용이 매우 쉽습니다. 그러나 제 생각에는 완벽한 프로그래밍 언어는 아닙니다. 어디에서나 별을 선택하고 PHP 및 Ruby 또는 Python과 같이 더 편한 프로그래밍 언어로 모든 것을 가져오고 기본적으로 익숙한 프로그래밍 언어를 사용하여 수행하는 것이 매우 쉽습니다. SQL에서보다 복잡한 쿼리를 수행하는 대신 데이터 조작. 그리고 우리는 이것을 많이보고 사람들은 왜 데이터베이스가 느리게 실행되는지 궁금해합니다. 백만 명의 사람들이 온라인 발권 시스템에서 티켓을 구매하려고하기 때문에 어디에서나 별표가 표시됩니다.

자, 그것은 정말로 극단적 인 예입니다. 그러나 당신은 그 모든 점에서 요점을 얻습니다. 자, 그 지점을 실제로 펀치하기 위해 여기에 제가 많이 가지고 다니는 예가 있습니다. 나는 수학의 열렬한 팬이고, 혼란 이론을 좋아하고, 만델 브로트 세트를 좋아합니다. 오른쪽에는 Mandelbrot 세트의 표현이 있으며, 우리 모두에게 익숙합니다. 그리고 왼쪽에는 실제로 그것을 렌더링하는 SQL 조각이 있습니다. 지금, 나는 이것을 어딘가에 스크린에 놓을 때마다, 나는 이것을 듣는다.“오 나의 신, 누군가 누군가가 SQL로 Mandelbrot 시리즈를 렌더링 했습니까? 글쎄, 그것의 요점은 내가 방금 요약 한 것을 설명하는 것이며, 실제로는 거의 모든 것을 SQL로 프로그래밍 할 수있다. 매우 강력하고 현대적인 프로그래밍 언어입니다. 원래는 쿼리 언어 였을 때 데이터를 가져 오도록 설계되었습니다. 이제 우리는 매우 복잡한 구조를 가지게되었고 저장 프로 시저를 가지게되었고, 프로그래밍 방법론을 언어에 적용하게되었으므로 프로그래밍 실습이 부족하고 경험이 부족하고 잘라 내기 및 붙여 넣기 코드, 저임금 직원 고임 급 직원이 되려고 노력하는 사람들은 자신이 알고있는 척하지만 직업을 배워야합니다.

코드 프로파일 링과 디버깅이라고하는 모든 것. 프로그램 작동을 멈추는 버그를 찾는 것이 아니라 시스템을 손상시키고 구조화 된 코드를 손상시키는 버그를 찾는 것입니다. 지금이 화면을보고 생각할 때, 그것은 단지 귀엽고 "와우, 정말 멋진 그래픽, 나는 그것을 실행하고 싶습니다."라고 생각합니다. 그러나 어떤 비즈니스 로직에서 실행한다고 상상해보십시오. . 깔끔하게 보이지만 수학적으로 그래픽으로 렌더링 된 혼돈 이론을 말하지만, 일부 비즈니스 로직에서 잠재적으로 사용될 수있는 것에 대해 생각하면 매우 빠르게 그림을 얻을 수 있습니다. 그리고 사실을 설명하기 위해 – 색상이 반전되어 죄송합니다. 검은 색 배경이되고 녹색 텍스트는 녹색 화면이어야하지만 여전히 읽을 수 있습니다.

나는 당신이 정말로 미쳤고 전혀 경험이 없다면 다른 프로그래밍 배경에서 왔고 C ++과 같은 것을 SQL에 적용하여 내 요점을 실제로 설명하기 위해 잠재적으로 할 수있는 일에 대한 예를 살펴 보았습니다. IDERA에서 배운 손님에게 건네줍니다. 이것은 C ++처럼 작성되었지만 SQL로 코딩 된 구조화 된 쿼리입니다. 실제로 실행되지만 약 3-5 분 동안 실행됩니다. 그리고 여러 데이터베이스, 여러 조인에서 표면적으로 한 줄의 데이터를 가져옵니다.

다시 말하지만, 올바른 도구가 없으면 이러한 플랫폼을 확보 할 수있는 올바른 플랫폼과 환경이없고 생산에 들어간 다음 100, 000 명이라는 사실이 중요합니다. 매일, 몇 시간, 몇 분마다 시스템에 충돌하면 곧 큰 철분이 녹아서 행성의 핵심에 묻히는 체르노빌 경험이 생깁니다. 왜냐하면 그 코드 조각은 결코 생산에 들어 가지 않아야하기 때문입니다. 실례합니다. 테스트 프로세스, UAT 및 시스템 통합을 통해서도 UAT 및 시스템 통합을 통해 시스템과 도구가 근처로 이동하기 전에 그 코드를 선택하고 강조 표시해야하며 누군가는 옆으로 가져와야합니다. “이것은 정말 좋은 코드이지만 솔직히 말해서 불쾌한 구조이기 때문에 DBA가 구조화 된 쿼리를 올바르게 작성하는 데 도움을 주도록하겠습니다.”그리고 URL이 있습니다. 가장 복잡한 SQL 쿼리. 왜냐면, 실제로는 컴파일하고 실행합니다. 그리고 잘라서 붙여 넣기 만하면 데이터베이스를 조롱 할 수 있습니다. 데이터베이스를 볼 수있는 도구가 있다면 3 ~ 5 분 동안 녹여서 한 줄의 텍스트를 다시 불러 오십시오.

요약하자면, 이를 염두에두고 코딩에 대한 저의 전체 배경은 사람들에게 총을 줄 수 있으며주의하지 않으면 발로 스스로 쏠 수 있다고 가르쳐주었습니다. 요령은 안전 메커니즘이 어디에 있는지 보여주는 것입니다. 올바른 도구와 올바른 소프트웨어를 사용하면 코딩을 마친 후 코드를 검토하고 코드를 프로파일 링하여 문제를 찾을 수 있으며 성능 문제인 의도하지 않은 버그를 효과적으로 찾을 수 있습니다. 이전에는 한 번에 녹색 화면을 보면서 할 수있었습니다. 더 이상 할 수 없습니다. 수십만 줄의 코드가 있고, 수만 개의 앱이 배포되고, 어떤 경우에는 수백만 개의 데이터베이스가 있으며, 심지어 수퍼맨조차도 실제로는 더 이상 수작업을 수행 할 수 없습니다. 말 그대로 올바른 소프트웨어와 올바른 도구가 필요하며 팀이 이러한 도구를 사용해야하므로 문제를 발견하고 매우 신속하게 해결할 수 있도록 Dr. 로빈 블로어 (Robin Bloor)는 강조, 일이 재앙이되거나 일이 터지거나 더 일반적으로 일이 걸리는 이유를 알아낼 수 없을 때 많은 돈과 시간과 노력을 기울이고 사기와 물건을 파괴하기 시작합니다. 실행하는 데 오랜 시간이 걸렸습니다.

그리고이를 염두에두고 게스트에게 전달할 것이며 그들이이 문제를 어떻게 해결했는지 기대합니다. 특히 우리가받을 데모라고 생각합니다. 에릭, 다시 넘어가겠습니다.

에릭 카바나 흐 : 알았어, 버트.

Bert Scalzo : 감사합니다. IDERA의 Bert Scalzo, 저는 데이터베이스 도구의 제품 관리자입니다. 그리고 디버깅에 대해 이야기하겠습니다. 로빈이 앞서 말한 가장 중요한 것 중 하나는 디버깅이 어렵고 사소하지 않다는 것입니다. 데이터베이스 디버깅을 할 때는 훨씬 더 복잡하고 사소합니다. 중요한 인용문이었습니다.

확인. 디버깅을하지 않는 사람들을 자주보고, 디버거를 사용하지 않고, 사용중인 언어로 프로그래밍하고, 여러 번 나에게 말할 것이기 때문에 프로그래밍 히스토리로 시작하고 싶었습니다., “그 디버거는 새로운 것인데, 우리는 아직 그것들을 사용하기 시작하지 않았습니다.”그리고 제가하는 것은이 타임 라인 차트, 일종의 선사 시대, 노년, 중세, 친절한 것입니다. 프로그래밍 언어의 관점에서 그리고 우리는 어셈블리 코드와 Lisp, FACT, COBOL로 1951 년에 아주 오래된 언어를 사용했습니다. 그런 다음 다음 그룹 인 Pascals와 Cs로 이동 한 다음 다음 그룹 인 C ++로 이동하여 해당 물음표가 어디에 있는지 확인합니다.이 물음표는 대략 1978 년에서 1980 년 사이에 거의 옳습니다. 우리가 사용할 수있는 디버거는“이건 새로운 것 중 하나이기 때문에 디버거를 사용하지 않습니다.”그렇다면 1950 년대에 프로그래밍을 시작했을 것입니다. 그 주장에서 벗어날 수있는 유일한 방법입니다.

이 차트에 대해 재미있는 또 다른 것은 Dez가 Grace Hopper에 대해 언급 한 것입니다. 실제로 Grace를 알고 있었기 때문에 재미있었습니다. 그리고 내가 웃었던 또 다른 것은 그가 텔레타이프에 대해 이야기하고 거기에 앉아 있다는 것입니다.“사람, 그것은 우리가 생산성에서 가장 큰 도약이었습니다. 우리가 카드에서 텔레타이프로 갔을 때 가장 큰 도약이었습니다. ”그래서 저는 아무도 들어 본 적이없는 SNOBOL을 포함하여 여기에 모든 언어로 프로그래밍했습니다. CDC 인 Control Data Corporation이기 때문에이 산업에서는 조금 나이가 들었습니다. .

Dez Blanchfield : 저는 당신이 우리를 몹시 나이 들었다고 말했습니다.

Bert Scalzo : 그래, 나는 당신에게 말하고있다, 나는 할아버지 심슨 인 것 같은 느낌이 든다. 디버깅을 살펴보고 디버깅을 수행하는 다른 방법이 있습니다. 우리는 전통적인 디버거에 들어가 코드를 단계별로 생각하는 것에 대해 이야기 할 수 있습니다. 또한 사람들은 코드를 작성합니다. 여기에서 코드에 문장을 붙이고 출력 파일, 추적 파일 또는 무언가를 생성하여 코드를 계측 할 수 있습니다. 나는 그것을 디버깅으로 계산할 것이고, 조금 더 힘들고, 그것을하는 방법이지만, 계산합니다. 그러나 우리는 유명한 print statement를 가지고 있습니다. 여러분은 사람들이 실제로 print statement를 넣었고 실제로 디버거를 사용하는 방법을 모른다면 데이터베이스 툴입니다. 버튼을 누르면 코드 전체에 인쇄 문이 붙어 있으며 완료되면 다른 버튼을 누르면 버튼이 제거됩니다. 그것이 많은 사람들이 디버그하는 방식이기 때문입니다.

그리고 우리가 디버그하는 이유는 두 가지입니다. 우선, 우리는 코드를 비효율적으로 만드는 것을 찾아야합니다. 다시 말해, 일반적으로 논리적 인 실수가 있거나 비즈니스 요구 사항을 놓 쳤음을 의미하지만 코드가 효과적이지 않습니다. 우리가 기대했던 것을하지 않습니다. 우리가 가서 디버깅을 할 때, 그것은 효율성을위한 것이며 논리적 인 실수 일 수 있습니다. 그러나 그것이 옳은 일을했다는 것입니다. 그것은 충분히 빨리 돌아 오지 않습니다. 이제 두 번째 시나리오에서 프로파일 러가 더 좋을 것이므로 디버거와 프로파일 러에 대해 이야기하겠습니다. 또한이 원격 디버깅 개념이 있습니다. 개인용 컴퓨터에 앉아 있고 디버거를 사용하는 경우 코드가 실제로 데이터베이스에서 실행되는 데이터베이스에 충돌하고 실제로 원격 디버깅을 수행하는 경우가 많기 때문에 이것은 중요합니다. 당신은 그것을 깨닫지 못할 수도 있지만, 그것은 일어나고 있습니다. 그런 다음이 디버거에서 브레이크 포인트, 감시 포인트, 스텝 인 스텝 및 기타 일반적인 사항을 갖는 것이 매우 일반적입니다. 화면 스냅 샷에 잠시 표시하겠습니다.

이제 프로파일 링 : 몇 가지 다른 방식으로 프로파일 링을 수행 할 수 있습니다. 어떤 사람들은 워크로드를 캡처하고 프로파일 링으로 간주되는 모든 것을 캡처하는 곳에서 재생한다고 말합니다. 내 경험은 샘플링을 완료하면 더 나아졌습니다. 모든 문장을 잡을 이유가 없습니다. 일부 문장은 너무 빨리 실행되어 신경 쓰지 않아도 될 수 있습니다. 실제로보고 싶은 것은 계속 반복해서 나타나는 것입니다. 그들은 너무 오래 달립니다. 따라서 프로파일 링은 전체를 실행하는 것이 아니라 샘플링을 의미 할 수 있습니다. 그리고 일반적으로 IDE 개발 환경에서 시각적으로 볼 수있는 다양한 종류의 출력을 얻을 수 있습니다. 여기서 다양한 코드 줄의 성능에 대한 히스토그램과 같은 결과를 얻을 수 있습니다. 추적 파일을 생성하기 때문입니다.

프로파일 러는 1979 년에 처음 등장했습니다. 그래서 그들은 오랫동안 주변에있었습니다. 리소스 소비 또는 성능 문제, 즉 효율성이 높은 것을 찾는 데 유용합니다. 일반적으로 말하자면 디버거와는 별개이며 구별되지만 동시에 두 가지를 모두 수행하는 디버거와 함께 작업했습니다. 그리고 프로파일 러는 두 도구 중 더 흥미 롭다고 생각하지만, 충분한 사람들이 디버그하지 못한다고 생각하면 10 명 중 하나가 프로파일 링하기 때문에 사람들이 충분하지 않다고 생각하면 그렇게 보입니다. 프로파일 링이 실제로 큰 차이를 만들 수 있기 때문에 그것은 부끄러운 일입니다. 이제 데이터베이스 데이터베이스는 앞에서 이야기했듯이 SQL을 얻었습니다. 우리는 둥근 페그를 사각형 구멍에 강제로 삽입하여 프로그래밍 언어로 만들었습니다. PL / SQL – 절차 언어 SQL – 그리고 SQL Server, Transact-SQL, SQL-99, SQL / PSM – 프로 시저 저장 모듈이라고 생각합니다. Postgres는 또 다른 이름 인 DB2, 또 다른 이름 인 Informix를 제공하지만 요점은 모두가 3GL 유형의 구성을 강요했다는 것입니다. 다시 말해, 변수 선언에서 FOR 루프와 SQL과 관련이없는 다른 모든 내용은 이제 해당 언어로 SQL의 일부입니다. 따라서 Visual Basic 프로그램과 마찬가지로 PL / SQL 또는 Transact-SQL을 디버깅 할 수 있어야합니다.

사람들이“글쎄, 데이터베이스에서 어떤 것들을 디버깅해야합니까?”라고 말할 것이기 때문에 데이터베이스 객체는 중요합니다. 그리고 대답은 데이터베이스에 코드로 저장할 수있는 모든 것입니다. T-SQL 또는 PL / SQL – 데이터베이스에 객체를 저장하고 있는데 아마도 저장 프로 시저 또는 저장 함수일 것입니다. 그러나 트리거도 있습니다. 트리거는 저장 프로 시저와 비슷하지만 어떤 종류의 이벤트에서 발생합니다. 이제 트리거에있는 일부 사람들은 한 줄의 코드를 저장하고 스토어드 프로 시저를 호출하여 모든 스토어드 코드와 프로 시저를 유지하지만 동일한 개념입니다. 여전히 트리거가 전체를 시작하는 원인 일 수 있습니다. 그리고 오라클로서 패키지라고 불리는 패키지가 있는데, 원하는 경우 라이브러리와 비슷합니다. 패키지라고하는 하나의 그룹에 50 개 또는 100 개의 저장 프로 시저를 넣으므로 라이브러리와 비슷합니다. 디버거는 예전 방식입니다. 이것은 실제로 실제로 모든 디버그 문을 코드에 고정시키는 도구입니다. 따라서 디버그 디버거를 볼 때마다 자동 디버거 시작 및 추적을 제거하지 마십시오. 그리고 그 바깥 줄은 코드의 소수이며, 비 수동 디버깅 방법입니다.

그리고 내가 이것을 가져 오는 이유는, 당신이 이것을 직접하려고한다면, 실제로 코드보다 더 많은 모든 인쇄 문에 넣을 더 많은 디버깅 코드를 입력해야하기 때문입니다. 따라서 이것이 효과가있을 수 있지만 아무것도 아닌 것이 낫지 만 디버깅하기가 매우 어려운 방법입니다. 특히이 작업을 실행하는 데 10 시간이 걸리고 문제가있는 곳은 3 번째 줄입니까? 대화식 디버깅 세션을하고 있다면 3 ~ 5 분 안에 알고 있었을 것입니다. 여기에 문제가 있습니다. 종료 할 수 있습니다. 그러나 이것으로, 나는 그것이 완성 될 때까지 실행되기를 기다려야합니다. 그런 다음에 모든 인쇄 문이 들어있는 추적 파일을보고 바늘을 찾아야합니다. 커다란 건초 더미. 다시 말하지만 이것은 아무것도 아닌 것보다 낫지 만 작동하는 가장 좋은 방법은 아닙니다. 이제이 파일은 이전 슬라이드에서 가져온 모습입니다. 다시 말해서, 나는 프로그램을 실행했고, 이 추적 파일에 많은 인쇄 문이 있고 이것을 통해 전화를 걸거나 찾을 필요가있는 것을 찾지 못할 수도 있습니다. 다시 말하지만, 이것이 당신이 일하고 싶은 방식인지 확실하지 않습니다.

이제 대화식 디버거 – Visual Studio와 같은 프로그램을 사용하여 프로그램이나 Eclipse를 작성한 경우 디버거가 있고 다른 언어와 함께 사용한 경우 데이터베이스에서 여기를 사용하려고 생각하지 않았습니다. 그리고 DB Artisan 및 Rapid SQL과 같은 도구가 있습니다. 여기에는 Rapid SQL이 있습니다. 여기에는 디버거가 있으며 왼쪽에서 볼 수 있습니다.“복제 검사”라는 저장 프로 시저가 있습니다. 기본적으로, 그냥 영화 제목이 같은 테이블에 여러 개의 행이 있는지 살펴보고 봅니다. 따라서 데이터베이스는 영화 용입니다. 오른쪽 상단에서 볼 수 있습니다. 맨 위 세 번째에는 소스 코드가 중간에 있고 시계 변수와 호출 스택 트레이가 있고 맨 아래에 있습니다. 일부 출력 메시지가 나타납니다. 여기서 중요한 것은 첫 번째 빨간색 화살표를 살펴보면 변수 위에 마우스를 놓으면 코드를 단계별로 진행하면서 해당 시점에 해당 변수에 어떤 값이 있는지 실제로 볼 수 있습니다. 그리고 그것은 정말 유용합니다. 그리고 코드를 통해 한 번에 한 줄씩 밟을 수 있습니다. 나는 말할 필요가 없습니다. 나는 한 줄씩 말할 수 있습니다. 데이터베이스 에서이 작업을 수행하고 있습니다. 그리고 내 PC에서 Rapid SQL에 앉아 있고 데이터베이스가 클라우드에 있어도 원격 디버깅을 수행하고이를보고 제어 할 수 있으며 다른 언어와 마찬가지로 디버깅을 수행 할 수 있습니다.

다음 화살표는 – DBMS 출력을 향해 오른쪽을 가리키는 화살표와 같은 작은 화살표를 볼 수 있습니다. 즉, 커서가있는 위치입니다. 즉, 나는 밟아 갔고 그 곳에 있습니다. 순간. "다시 한 번"이라고하면 다음 줄로 넘어갑니다. 그 바로 아래에 빨간색 점이 표시됩니다. “이 라인을 넘어서고 싶지 않습니다.”라고 말하는 것은 중단 점입니다. 모든 것을 뛰어 넘고 그 빨간 점으로 이동하려면 실행 버튼을 누르면 실행됩니다. 여기에서 끝으로 또는 중단 점으로 설정합니다. 중단 점이 설정되어 있으면 중지하고 다시 스테핑을 수행 할 수 있습니다. 이 모든 것이 중요하고 강력한 이유는, 내가이 모든 일을 할 때 중간과 심지어 바닥에서 일어나고있는 일 (가장 중요한 것은 중간)이 변하고 변수의 값을 볼 수 있기 때문입니다. 내 호출 스택 추적을 볼 수 있으며 코드를 단계별로 진행할 때 해당 정보가 모두 표시되므로 실제로 진행 상황과 코드의 실제 상태를보고 느끼고 이해할 수 있습니다. 실행 시간에 작동합니다. 그리고 일반적으로 문제가 있거나 문제를 발견하기에 충분하다면 문제를 찾을 수 있습니다.

이제 프로파일 러에 대해 이야기하겠습니다.이 경우 디버거를 통해 볼 수있는 프로파일 러입니다. 때때로 그들은 분리되어 있고 때로는 함께있을 수 있다고 말했던 것을 기억하십니까? 이 경우에도 Rapid SQL을 사용하고 왼쪽에 줄 번호 옆에 여백이 있음을 알 수 있습니다. 즉, 각 코드 줄을 실행하는 데 걸리는 시간은 초 또는 마이크로 초입니다. 표에서 모든 것을 선택하는이 하나의 FOR 루프에서 모든 시간이 소비된다는 것을 분명히 알 수 있습니다 . 따라서 FOR 루프 내에서 일어나는 일은 아마도 내가 봐야 할 것입니다. 더 좋게 만들 수 있다면 배당금을 지불 할 것입니다. 0.90 또는 0.86과 같은 라인에서 작업하여 개선을 얻지 않을 것입니다. 거기에 시간이별로 없습니다. 이제이 경우에도 Rapid SQL을 사용하고 있습니다. 디버깅과 혼합 된 프로파일 링을 수행하는 방법을 확인하고 있습니다. 좋은 점은 Rapid SQL을 사용하여 다른 방법으로도 할 수 있다는 것입니다. Rapid SQL을 사용하면“무엇을 알고 있습니까? 디버거에 들어가고 싶지 않다. 이것을 실행하고 그래픽이나 시각적으로 동일한 유형의 정보를보고 싶다.”

그리고 더 이상 디버거에 있지 않고 프로그램을 실행하고 실행이 완료되면 차트를 통해 나에게 물건을 알려주는 차트를 제공하므로 하나의 문장을 가지고 있음을 알 수 있습니다. 대부분의 원형 차트를 보면 23 번째 줄을 향한 그리드에서 FOR 루프가 다시 나타납니다. 가장 많은 시간을 차지하고 있습니다. 그는 실제로 모든 원형 차트를 진한 빨간색으로 표시합니다. 그리고 이것은 프로파일 링을 수행하는 또 다른 방법입니다. 우리는 도구에서이를“코드 분석가”라고 부릅니다. 그러나 기본적으로 디버거와 분리 된 프로파일 러일뿐입니다. 어떤 사람들은 첫 번째 방법으로 그것을 좋아하고 어떤 사람들은 두 번째 방법으로 그것을 좋아합니다.

왜 디버깅 및 프로파일 링을 수행합니까? 그것은 우리가 세계 최대의 코드를 작성하고 임금 인상을 받기 원하기 때문이 아닙니다. 그것이 우리의 이유 일 수도 있지만 실제로 그렇게하는 이유는 아닙니다. 당신은 사업을 올바르게하겠다고 약속했고, 프로그램이 효과적이라고 약속했습니다. 이것이 디버거를 사용할 것입니다. 또한 비즈니스 최종 사용자; 그들은 인내심이 강하지 않습니다. 키를 누르기 전에도 결과를 원합니다. 우리는 그들의 마음을 읽고 모든 것을 즉시해야합니다. 다시 말해, 효율적이어야합니다. 이것이 우리가 프로파일 러를 사용하는 것입니다. 이제이 도구가 없으면 활과 화살로 비즈니스 정장을 입은이 사람이고 목표물에 총을 쏘고 눈을 가렸다 고 믿습니다. 정적 코드를 보면서 프로그램이 어떻게 실행되는지, 정적 코드를 보면서 다시 실행하는 데 가장 많은 시간을 소비 할 줄을 어떻게 알 수 있습니까? 코드 검토는 이러한 것들 중 일부를 나타내거나 그렇지 않을 수 있지만, 코드 검토가 그것들을 모두 찾을 것이라는 보장은 없습니다. 디버거와 프로파일 러를 사용하면 이러한 모든 버그를 찾을 수 있어야합니다.

좋아, 나는 여기서 진짜 빠른 데모를 할 것입니다. 제품을 푸시하려는 의도는 아닙니다. 사람들이“이전에 한 번도 본 적이 없습니다.”라고 말하는 많은 시간을 보내기 때문에 디버거가 어떻게 보이는지 보여 드리고자합니다. 화면 스냅 슬라이드에서 예쁘게 보입니다. 하지만 움직일 때의 모습은 무엇입니까? 여기 화면에서 DB Artisan 제품을 실행하고 있습니다. 디버거도 있습니다. DB Artisan은 DBA를위한 것이며, Rapid SQL은 개발자를위한 것이지만 DB Artisan을 사용하는 개발자와 Rapid를 사용하는 DBA를 보았습니다. 따라서 제품에 얽매이지 마십시오. 여기에서 디버그를 선택할 수 있지만 디버그를 시작하기 전에이 코드를 추출하여 코드를 실행하기 전에 코드의 모양을 확인할 수 있습니다. 화면 스냅 샷과 동일한 코드가 있습니다. 이것은 중복 검사입니다. 그리고 이것을 디버깅하고 싶습니다. 그래서 디버그를 누릅니다. 이제는 시간이 걸리고“음, 왜 시간이 걸리는가?”원격 디버깅을 기억하십시오. 디버깅은 실제로 PC가 아닌 데이터베이스 서버에서 수행됩니다. 그래서 거기에 세션을 만들고, 원격 디버깅을 만들고, 내 세션을 해당 원격 디버깅 세션에 연결하고 통신 채널을 설정해야했습니다.

자, 이제 여기에 화살표가 있습니다. 맨 위, 한 줄씩, 코드에서 내가있는 곳입니다. 한 단계 씩 세 번째 아이콘을 누르면 화살표가 이동 한 것을 볼 수 있습니다. 계속 누르면 계속 움직입니다. 이제이 FOR 루프까지 내려 가고 싶다면 문제의 위치를 ​​알고 있기 때문에 중단 점을 설정할 수 있습니다. 나는 그것을 설정했다고 생각했다. 쏴, 스크린 캡처 키 중 하나가 디버거와 동일한 키에 매핑되어있어 혼란을 일으킨 것입니다. 자, 거기에 수동으로 중단 점을 설정 했으므로 이제는 단계, 단계, 단계, 단계를 수행하는 대신 실제로“이 작업을 실행하십시오”라고 말하면 중단됩니다. 그것이 브레이크 포인트가있는 곳으로 나를 완전히 움직 였으므로 이제이 루프를 실행하는 컨텍스트에 있습니다. 모든 변수가 무엇으로 설정되어 있는지 알 수 있습니다. 0으로 이제이 루프로 들어가서이 루프 내부에서 무슨 일이 일어나고 있는지 볼 수 있습니다.

이제 임대료에서 선택 카운트를 수행하고 그 사람 위로 마우스를 가져 가서 볼 수 있습니다. 그는 2, 2는 1보다 큽니다. 그래서 아마도이 코드의 다음 부분을 수행 할 것입니다. 즉, 뭔가를 발견했습니다. 계속해서 진행하겠습니다. 나는 여기서 모든 것을 겪고 싶지 않다. 내가 당신에게 보여주고 싶은 것은 디버거가 끝나면 일반 프로그램처럼 끝납니다. 중단 점을 설정 했으므로 실행한다고 말하면 다음 중단 점으로 돌아갔습니다. 디버거가 프로그램의 동작을 변경하지 않기 때문입니다. 실행이 끝나면 실행하지 않으면 정확히 동일한 결과를 가져와야합니다. 디버거 내부.

그리고 그로 인해 데모를 중단하고 질문과 답변을받을 시간이 필요하기 때문에 되돌아갑니다. 그래서 질문과 답변을 위해 열겠습니다.

에릭 카바나 흐 : 좋아, 로빈, 아마 당신에게서 질문이 있고 그런 다음 데즈에게서 질문이 있을까?

로빈 블로어 : 네, 물론, 저는이 매혹적인 것을 발견합니다. 나는 이런 것들로 일했지만 데이터베이스에서 이런 일을 한 적이 없다. 사람들이 프로파일 러를 사용하는 것에 대한 아이디어를 줄 수 있습니까? 마치 성능 문제를보고있는 것 같습니다. 데이터베이스가 시간이 걸리는 시간과 코드가 시간이 걸리는 시간을 구별하는 데 도움이됩니까?

버트 스 칼조 : 알다시피, 환상적인 질문입니다. Visual Basic에서 작업 중이고 Visual Basic에서 Transact-SQL 또는 PL / SQL을 호출한다고 가정하겠습니다. Oracle이 Microsoft 도구와 항상 잘 작동하지 않기 때문에 PL / SQL을 수행하겠습니다. Visual Basic 코드를 프로파일 링하고있을 수 있으며 "이 스토어드 프로 시저를 호출했는데 시간이 너무 오래 걸렸습니다."라는 프로파일이있을 수 있습니다. 그러나 스토어드 프로 시저로 이동하여 스토어드에서 데이터베이스 프로파일을 수행 할 수 있습니다. “여기에있는 100 가지 진술 중에서 문제를 일으킨 5 가지 진술이 있습니다.”라고 말하고 여러 프로파일 러를 사용해야하는 태그 팀을 수행해야 할 수도 있습니다.

성능 문제가 데이터베이스에 있다고 들었다면 데이터베이스 프로파일은 실제로 문제가있는 명령문이있는 건초 더미에서 바늘을 찾는 데 도움이 될 수 있습니다. 프로파일 링으로 밝혀진 또 다른 점을 알려줍니다. 백만 번 호출되는 코드 조각이 있지만 각 백만 번 마이크로 초 만 걸리지 만 백만 번 호출되면 프로파일 러가 표시하는 내용, 그 일이이 많은 시간 동안 달렸습니다. 따라서 코드가 매우 효율적일 수 있지만“오, 이 코드를 너무 자주 호출하고 있습니다. 기록을 처리 할 때마다가 아니라 자주 호출해야합니다.” 따라서 너무 자주 호출되는 효율적인 코드가있는 위치를 실제로 찾을 수 있으며 실제로 성능 문제입니다.

로빈 블로어 : 예, 훌륭합니다. 나는 이것을 한 적이 없다. 물론 데이터베이스 문제가 발생했을 때 데이터베이스를 처리하거나 코드를 처리하는 것과 같은 방식으로 나타납니다. 나는 동시에 두 가지를 다룰 수 없었습니다. 하지만 다시 한 번도하지 않았습니다. 실제로 저장 프로 시저가있는 응용 프로그램을 작성하는 데 참여한 적이 없었기 때문에 실제로 문제를 일으킨 적이 없었습니다. 데이터베이스와 프로그램간에 코드를 분할했습니다. 그러나, 모두해라. 나는 대답이 '예'라고 가정 할 것이다. 그러나 이것은 당신이 어떤 방식 으로든 깨진 것을 고치려고하거나 새로운 것을 가져 오려고 시도 할 때 개발 팀 활동의 일부이다. 함께 신청하십시오. 그러나 이것이 환경에서 기대할 수있는 다른 모든 구성 요소에 맞게 조정 되었습니까? 이 작업을 모든 테스트 팩과 함께 수행 할 수 있고 프로젝트 관리 작업과 함께 수행 할 수있는 다른 작업과 함께이 작업을 모두 수행 할 수 있습니까?

Bert Scalzo : 예, 프로그래밍 또는 개발 노력을 수행하는 모든 구조화 된 프로세스의 일부가 될 수 있습니다. 그리고 지난주에 웹 애플리케이션을 구축하는 고객이 있었고 데이터베이스는 작고 역사적으로 훌륭했기 때문에 프로그래머가 아니었다는 사실은 결코 해를 끼치 지 않았습니다. 글쎄, 그들의 데이터베이스는 수년에 걸쳐 성장해 왔으며 이제 웹 페이지에서“로그인하고 볼 데이터를 제공하십시오”라고 말할 때와 화면이 실제로 나타날 때까지 20 초가 걸렸습니다. 성능 문제. 그리고 그들은 그 문제가 자바 나 다른 장소에 있지 않다는 것을 알고있었습니다. 그러나 수천 개의 저장 프로 시저가 있었으므로이 웹 페이지가 나타나는 데 20 초가 걸리는 이유를 찾기 위해 저장 프로 시저 프로파일 링을 시작해야했습니다. 우리는 실제로 그들이 엄선 된 진술 중 하나에 카티 전 조인을 가졌으며 그것을 알지 못했습니다.

로빈 블로어 : 와우.

버트 스 칼조 (Bert Scalzo) : 그러나 누군가 나에게 한 번은“글쎄, 어떻게 그들이 데카르트 조인을 가질 수 있고 그것을 알 수 없습니까?”라고 말했습니다. 때로는 SQL에 익숙하지 않은 프로그래머가 데카르트 조인을 제공하는 것과 같은 일을하지만 첫 번째 레코드 만 다시 제공하므로 무언가를 얻었고 첫 번째 레코드 만 필요합니다. 그래서 그들은 단지 10 억 개의 레코드를 가져 왔거나 10 억 개의 레코드를 살펴 본다는 것을 깨닫지 못합니다. 왜냐하면 그들이 관심있는 것을 얻었 기 때문입니다.

로빈 블로어 : 와우, 그것이 바로 그것이라고하는 것입니다. 잘 알려진 것만큼이나 숙련되지 않은 사람들의 관점에서 Dez가 진행되고있는 것입니다. 프로그래머라면 명령을 내릴 때의 의미를 알아야합니다. 사실, 그 정도의 어리 석음에 대한 변명이 없습니다. 또한 데이터베이스 측면에 중점을두기 때문에 당신이 어떤 식 으로든 언어에 관계없이 언어에 관계없이 있다고 가정합니다. 내가 맞습니까? 코딩 측에서 사용하는 것이 무엇이든 동일합니까?

Bert Scalzo : 물론, Fortran 또는 C 또는 C ++에서이 작업을 수행 할 수 있습니다. 실제로 일부 유닉스에서는 스크립팅 언어로 할 수도 있습니다. 그들은 실제로 동일한 도구를 제공합니다. 그리고 난 당신이 변명하지 않고 말한 것에 대해 잠시 뒤로 가고 싶습니다. 버스에 프로그래머를 던지는 것을 좋아하지 않기 때문에 프로그래머에게 휴식을 주려고합니다. 그러나 문제는 실제로 학업 환경입니다. 왜냐하면 프로그래머가되는 방법을 배우기 위해서는 한 번에 한 번의 사고 방식을 배우기 때문입니다. 세트 사고를 배운 것은 아니며, 이것이 구조적 쿼리 언어 또는 SQL이 세트와 작동하는 것입니다. 그렇기 때문에 우리는 노동 조합, 교차 및 빼기 연산자가 있습니다. 그리고 세트로 생각하지 않은 사람이 한 번에 한 번에 레코드 처리를 끝내고 세트로 작업하는 것은 때때로 매우 어렵습니다.

로빈 블로어 : 네, 저도 함께하겠습니다. 내 말은, 지금은 교육 문제입니다. 저는 이것이 교육 문제라고 생각합니다. 프로그래머가 절차 적으로 생각하는 것이 당연하다고 생각합니다. 그리고 SQL은 절차 적이 지 않으며 선언적입니다. 당신은 실제로“이것이 내가 원하는 것이고 어떻게하는지 상관하지 않습니다.”라고 말하는 것입니다. 프로그래밍 언어를 사용하면 종종 소매를 감아 서 루프를 관리하는 동안 카운트를 관리하는 데에도 어려움을 겪지 않습니다. 나는 계속해서 -

Bert Scalzo : 아니요. 계속하십시오.

예, 프로파일 러가 한 번에이 레코드 처리 과정을 잘 따라 잡을 수 있다는 또 다른 예를 하나 들었습니다. 한 번에 한 번의 레코드 논리에 능숙한 프로그래머가 SQL 프로그램을 수행하는 방법을 알 수없는 경우가 있습니다. 두 개의 FOR 루프를 만들고 기본적으로 조인을 수행하지만 클라이언트 측에서 수행한다고 가정 해 봅시다. 따라서 그는 조인과 동일한 효과를 수행하지만 직접 수행하고 있으며 프로파일은이를 잡을 수 있습니다. 데이터베이스 서버가 자동으로 조인하는 것보다 수동으로 조인을 수행하는 데 더 많은 시간을 소비 할 수 있기 때문입니다.

로빈 블로어 : 네, 그건 재앙 일 것입니다. 내 말은, 당신은 방황하고있을뿐입니다. 스 래싱은 항상 나쁘다.

어쨌든, 나는 Dez로 넘어갈 것이다. 나는 그가 흥미로운 질문을 가지고 있다고 확신합니다.

Dez Blanchfield : 감사합니다. 나는 버스에서 던지지 않는 프로그래머들과 함께 할 것입니다. 나는 인생에서 너무 많은 시간을 코더로, 모든 수준에서, 당신이 말한대로, 유닉스 머신의 커맨드 라인에 앉아 있는지, 그리고 어떤 경우에는, 심지어 관여했다. 하나의 하드웨어 플랫폼에서 다른 하드웨어 플랫폼으로 유닉스의 두 가지 다른 포트에서. 그리고 우리가 겪은 어려움을 상상할 수 있습니다. 그러나 현실은 전 세계의 모든 코더와 스크립터를위한 탈옥 카드입니다. 문자 그대로 로켓 과학은 항상 로켓 과학입니다. Dennis Ritchie와 Brian Kernahan과 같은 사람들의 유명한 이야기는 코드를 독립적으로 작업 한 다음 커피를 통해 코드 검토 채팅을 시작하고 정확히 동일한 프로그램에서 동일한 코드를 작성했는지 확인합니다. 정확히 같은 방식으로. 그리고 그들은 C에서 그렇게했습니다. 그러나 순수한 수준의 프로그래밍은 거의 존재하지 않습니다.

사실 매일 하루 24 시간, 일주일에 7 일만 있으면 작업을 완료해야합니다. 따라서 전통적인 프로그래머, DBA 및 코더, 스크립터, sysadmin, 네트워크 관리자 및 보안 직원뿐만 아니라 요즘 시민 데이터 측면까지 모든 것이 아닙니다. 우리는 모두가 일을하려고한다고 들었습니다. 그리고 저는이 모든 것에서 가장 중요한 것은 당신의 데모를 좋아한다는 것입니다. 그리고 얼마 전에 당신이 우리와 함께했던 테이크 아웃을 좋아했습니다. 로빈에게 이것이 사실이 있다는 사실에 대해 이야기했습니다. 틈새 – 코드와 SQL 및 데이터베이스를 수정하는 한 적용 할 수있는 넓은 공간. 그러나 나는 당신이 쉘 스크립트에서 그것을 찌를 수 있고 몇 가지 문제를 찾을 수 있다고 말하는 것을 정말 기쁘게 생각합니다. 오늘날과 나이에 우리는 항상 가장 저렴한 비용으로 일하고 있기 때문입니다.

당신이 어딘가에 6 달러짜리 셔츠를 구입할 수있는 이유는 누군가가 실제로 6 달러짜리 셔츠를 얻기 위해 실제로 제조, 선적 및 논리적으로 배달 및 판매 및 소매하고 온라인 지불을하기에 충분히 저렴한 시스템을 구축했기 때문입니다. 그리고 사람들이 완벽한 방식으로 코드를 작성하기 위해 연간 40 만 달러를받는 경우에는 일어나지 않습니다. 그것은 단지 전체 개발입니다. 그 시점에서 저는 여러분에게 더 많은 통찰력을주기 위해 여러분이 정말로 좋아하는 질문 중 하나 인 것 같습니다. 현재보고있는 사람들 유형의 폭과 범위는 무엇입니까? 코드와 성능 문제를 찾으십니까? 처음에는 역사적으로 어디에서 왔습니까? 그들은 큰 엔지니어링 하우스였습니까? 그리고 앞으로 나아가는 것이 사실입니다. 점점 더 많은 회사들이이 툴이나 툴을 구현하여 코더를 돕기 위해 노력하고 있습니다. 문 밖으로 꺼내? 때로는 감옥에서 나가는 카드가 필요합니까? 역사적으로 우리가 더 엔지니어링에 초점을 맞추고 개발했다고 생각하는 것이 맞습니까? 이제 우리는 Robin이 말한 것처럼 학문적 접근 방식이 줄어 들었고 이제는 자율적이거나 잘라서 붙여 넣거나 코드를 만들었습니까? 그리고 지금은 제품을 구매하는 사람들과 일치합니까?

버트 스 칼조 : 네 . 맞습니다. 매우 구체적인 예를 들겠습니다. 비즈니스 사람들이 완벽을 원하지 않기 때문에 일을 끝내고 싶습니다. 그것은 일종의 컴퓨터 체스 게임과 같습니다. 체스 게임은 완벽한 해답을 찾지 않습니다. 합리적인 시간에 충분한 답변을 찾게되므로 이것이 바로 프로그래밍 방식입니다. 그러나 내가 지금 찾은 것은 대부분의 사람들이 단위 테스트의 일환으로 프로파일 러를 원한다고 말하는 대신에, 그것은 내가 그것을 낭비하는 방법이기 때문입니다. 왜냐면 그것을 시간 낭비로 보지 않기 때문입니다. 운 좋게도 통합 테스트 나 스트레스 테스트 중에 나중에 수행되기도합니다. 그러나 대부분의 경우 에스컬레이션의 일환으로 무언가가 생산에 들어가고 잠시 동안 실행되었거나 심지어 몇 년 동안 달렸을 수도 있습니다. 이제 잘 작동하지 않아 이제 프로파일 링 할 것입니다. 그리고 지금은 더 일반적인 시나리오 인 것 같습니다.

Dez Blanchfield : 그렇습니다.“기술 부채”라는 용어는 아마도 여러분이 잘 알고있는 용어 일 것입니다. 나는 로빈과 나는 확실히 알고있다. 저는 요즘, 특히 개발 및 시스템 구축에 대한 민첩한 접근 방식에서 기술 부채의 개념은 매우 현실적이며 실제로 프로젝트에서 설명합니다. 내 말은, 우리는 미디어 렌즈 및 기타 코딩 프로젝트를 매일 수행하고 있으며 Bloor Group 전체에서 다양한 일을하는 프로젝트를 가지고 있다는 것을 알고 있습니다. 그리고 우리가 무언가를 만들 때마다, 우리는 일종의보고, 그것을보고, 항상 지금이 문제를 해결하는 데 비용이 드는 것에 대한 관점에서 바라본다. 그곳에서 꺼내서이 일이 깨질 지 지켜봐 그리고이 기술 부채를 물려 받아 나중에 다시 원으로 수정해야합니다.

그리고 저는 지난 7 일 동안 그렇게했습니다. 저는 몇 가지 도구와 스크립트를 작성했고, 몇 가지 파이썬 언어를 작성했으며, 몽고 백엔드에 배포했습니다. 그것이 좋고 깨끗하고 안전하다는 것을 확신하지만, 더 큰 퍼즐을 얻기 위해서는 내가해야 할 기능을 필요로한다는 것을 알면서 필요한 쿼리를 얻습니다. 그것이 나의 진짜 고통이있는 곳입니다. 여러분은이 기술 부채를 겪게되었는데, 이것이 단지 가끔은 아니라고 생각합니다. 저는 이것이 현재 개발중인 DNA의 일부라고 생각합니다. 사람들은 단지 – 단호하게 – – 단지 기술 부채는 일반적인 방식의 문제 유형의 문제를 받아들이고, 단지 그것을 발생시켜야합니다. 기술 부채가 발생하는 곳입니다. 데모에서 우리에게 보여준 것에 대한 가장 큰 장점은 문자 그대로 프로파일 링하고 실행하는 데 걸리는 시간을 볼 수 있다는 것입니다. 그리고 그것은 아마도 내가 가장 좋아하는 것 중 하나 일 것입니다. 필자는 실제로 프로파일 링 도구를 만들었습니다. Sed와 Lex 및 Orc에서 도구를 작성하여 코드를 실행하고 이러한 도구를 사용할 수 있기 전에 루프의 위치를 ​​확인했습니다. 자신의 코드를 검토하면 자신의 코드를 검토하지 않아도됩니다. 그러나 지금은 그렇지 않습니다. 이를 염두에두고, 다른 시장보다 더 많은 시장을 차지하는 특정 시장 부문이 있습니까? 덩어리처럼 보이는 -

Bert Scalzo : 네, 알겠습니다. 여러분을 위해 비유를하고 프로그래머가 아닌 사람들이 항상 그렇게한다는 것을 보여줄 것입니다. '디버거와 프로파일 링 수업이나 세션을 가르치고 있다면 사람들에게“여기, 몇 명의 사람들이 Microsoft Word에 들어가고 의도적으로 맞춤법 검사기를 사용하지 않습니까?”라고 묻습니다. 아무도 손을 들지 않습니다. 문서를 작성할 때 영어 실수를 할 수 있다는 것을 알고 있기 때문에 모든 사람이 맞춤법 검사기를 사용하기 때문입니다. “저는 Visual Basic과 같은 IDE에서 텍스트를 작성할 때 디버거를 사용하지 않습니까? 똑같은 일인데, 맞춤법 검사기와 같습니다.”

Dez Blanchfield : 네, 사실, 그것은 훌륭한 비유입니다. 나는 실제로 생각하지 않았지만 실제로 사용하는 몇 가지 도구로 비슷한 것을 수행한다는 것을 인정해야합니다. 실제로 Eclipse에서 가장 좋아하는 ODF 중 하나는 코드를 잘라 붙여 넣은 다음 즉시 강조 표시하고 클래스 호출에서 오타가 있음을 깨닫는 것입니다. 그러나 지금은 이와 같은 도구를 사용하면 흥미로워 서 나중에 다시보고 나중에 보는 것이 아니라 실시간으로 할 수 있습니다. 그러나 그것은 텍스트를 워드 프로세서에 넣는 것과 아주 유사합니다. 왜냐하면 흥미로운 모닝콜이기 때문에 오타 나 문법 오류가 있었음을 깨달았습니다.

버트 스 칼조 : 맞습니다.

Dez Blanchfield : 이제 참가자들에게 Q & A를 던지기 전에 저의 마지막 질문이 떠오른 것 같습니다. 이 작업을 수행하는 방법에 대해 일종의 권장 사항을 제시하려는 경우 – 이것이 수사적이라고 가정합니다 – 개발하기 전에 개발 과정에서 조기에 구현하여 구현하는 경우입니까? 아니면 주로 건물을 세우고, 움직이고, 무언가를 만들고 나서 나중에 프로파일 링하는 경우입니까? 일찍 들어온 것으로 의심되며 코드가 깨끗해야합니다. 아니면 배치 후이 부분을 고려해야하는 경우입니까?

버트 스 칼조 (Bert Scalzo) : 이상적으로는 선결제로 진행하지만 모든 사람들이 방금 작업을 수행해야하는 번잡 한 소동 한 세상에 있기 때문에 해결할 수없는 성능 문제가 발생할 때까지 수행하지 않는 경향이 있습니다. 가상 머신에 더 많은 CPU 및 메모리 추가

데즈 블랑 필드 : 네. 사실, 내가 빨리 할 수 ​​있다면 실제로 흥미로운 것을 언급 했습니까? 앞에서 언급 한 내용은 어디에서나 실행할 수 있으며 백엔드에서 데이터베이스와 통신 할 수 있습니다. 따라서 이것은 우리가 지금 이야기하고있는 온-프레미스 / 오프-프레미스 클라우드에 대해 일종의 바이 모달 개념에 익숙합니다. 코드는 실제로 상관하지 않습니까?

Bert Scalzo : 맞습니다. 클라우드에서 실행할 수 있습니다.

Dez Blanchfield : 훌륭합니다. 왜냐하면 우리의 새로운 용감한 세상이 가고있는 곳이라고 생각하기 때문입니다. 에릭 나는 지금 당신에게 되돌아 가서 여기서 몇 가지 질문을 받았으며, 우리가 한 시간이 지났음에도 참석자가 여전히 우리와 함께 있기를 바랍니다.

에릭 카바나 흐 : 네, 몇 명의 사람들이 있습니다. 간단히 언급하겠습니다. 버트, 철자 검사를 사용하는 비유는 유감 스럽습니다. 솔직히 말해서 블로그의 가치가 있습니다. 왜냐하면 블로그의 내용과 가치, 그리고 디버거를 사용하는 것이 가장 좋은 방법이 무엇인지에 대한 컨텍스트를 구성하는 좋은 방법이기 때문입니다. 정기적 으로요? 나는 당신이 그것을 밖으로 던질 때 약간의 고개를 끄덕일 것입니다.

버트 스 칼조 (Bert Scalzo) : '내가 문서에 대해 맞춤법 검사를 실행하는 이유는 무엇입니까? 나는 어리석은 철자 실수로 당황하고 싶지 않습니다.”글쎄, 그들은 어리석은 코딩 실수로 당황하고 싶지 않습니다!

에릭 카바나 : 맞습니다. 네 확실합니다. 여러분, 여기 1 시간 5 분 동안 화상을 입었습니다. 시간과 관심을 가져 주신 모든 분들께 감사드립니다. 우리는 모든 웹 채팅을 보관하고 언제든지 돌아와서 확인하십시오. 해당 링크를 찾기에 가장 좋은 곳은 techopedia.com 일 것이므로이 목록에 바로 추가 할 것입니다.

그리고 우리는 여러분에게 작별 인사를 할 것입니다. 다시 한번, IDERA의 친구들에게 감사합니다. 우리는 다음에 당신과 이야기 할 것이고, 우리는 다음 주에 당신과 이야기 할 것입니다. 조심해! 안녕.