SQLServer OLTP 전문가를 고용하면 어떤 경험 또는 요구 사항을 찾아야합니까? [닫은

Question

나는 내가 작업중 인 OTLP 프로젝트를 통해 DB 성능 문제를 해결하고 있습니다. 다른 개발자와 저는 누적 된 성과 지식의 끝에 도달했으며 개인을 찾고 팀에 가입하여 응용 프로그램 속도를 높이는 데 도움이됩니다.

일부 배경의 경우 스키마 변경을 수행하여 데이터를 제거하고 모든 쿼리를 최적화하고 여러 데이터베이스 튜닝 어드바이저를 실행하여 인덱스를 올바르게 가져오고 MSSQL의 서버 옵션을 조정했습니다.

우리는 누군가가 들어올 필요가 없으며 우리에게 합류가 느리게 될 수 있으며 교착 상태가 무엇인지, 우리는 위에 나열된 모든 단계를 소진 한 후 무엇을 해야하는지 알고있는 사람이 필요합니다.

공유 할 OLTP DBA를 고용하는 팁이나 경험이 있습니까? 인터뷰 과정에서 어떤 종류의 질문을 할 수 있습니까?

우리는 현재 팀보다 더 많은 것을 아는 사람이 필요하다는 것을 알고 있지만, 다음 단계가 무엇인지 모르기 때문에 어떤 질문을 해야하는지 모르겠습니다. 말이 돼?

Answer 1

좋아, 이것은 나에게 뭔가를 말해줍니다.

일부 배경의 경우 스키마 변경을 수행하여 데이터를 제거하고 모든 쿼리를 최적화하고 여러 데이터베이스 튜닝 어드바이저를 실행하여 인덱스를 올바르게 가져오고 MSSQL의 서버 옵션을 조정했습니다.

당신은 이미 DBA라고 부르는 사람들의 90%가 할 수있는 일을 이미 일치 시키거나 초과했습니다.

문제는 많은 DBA가 실제로 프로그래머가 아니라 시스템 관리 측면에 더 많은 DBA가 있다는 것입니다. TSQL에 능숙 할뿐만 아니라 다른 프로그래밍 언어도 알고있는 DBA 프로그래머가 필요합니다.

이와 같은 데이터베이스 튜닝 문제에 시간의 상당 부분을 소비하며 솔루션에는 종종 프론트 엔드에서 데이터베이스 스키마로의 상당한 재 설계가 포함됩니다. 이러한 문제를 분리하여 해결할 수 없으며 전체 아키텍처에 대한 완전한 제어 (및 전체 이해) 없이는 필요한 성능을 얻지 못할 것입니다.

너 직장에 가장 적합한 사람 일 수 있으며, OLTP 성능 문제에 집중할 수 있도록 누군가를 접시에서 꺼내는 사람을 고용하는 것이 더 똑똑 할 수 있습니다.

Answer 2

여기서 조심해야합니다. 구루 DBA를 고용하고 데이터베이스 성능을 크게 향상시키고 아키텍처에 뿌리를 둔 응용 프로그램에 여전히 문제가 있습니다.

몇 가지 아이디어 :

1. 최적화 된 가장 복잡한 쿼리를 QA로 후보 DBA에 제공하고 다시 최적화하도록하십시오. 그들이 한 일과 어떻게했는지 설명하도록하십시오.

2. 이 사람이 하드웨어를 이해하는지 확인하십시오. 여러 파일 그룹, RAID 어레이, 데이터 파티셔닝, 64 대 32 비트 성능 등을 사용할 때 ...

3. 소프트웨어 아키텍처 배경이있는 사람을 찾으십시오.

4. 몇 가지 더 어려운 SQL 서버 질문을 물어보십시오. 오버 진술은 무엇입니까? Guids가 좋은 기본 키입니까? 왜 INT Identity가 바람직합니까?

Answer 3

자신의 최적화 전에 DB를 조금 뒤로 돌리고 그들에게 제공하십시오. 변경 사항에 비해 성능이 좋거나 더 잘 수행되도록 조정할 수 있는지 확인하십시오.

그들이 왜 그 기술을 선택했는지 물어보십시오.

참고 문헌을 작성하고 자신이 자신의 일치 할 가능성이 가장 높은 환경에 대해 알아보십시오.

Answer 4

좋은 DBA는 인터뷰에서 다음에 어떤 단계를 수행 할 것인지 높은 수준에서 당신에게 알려줄 수 있습니다. 문제에 대한 해결책보다는 사고 과정에 더 많은주의를 기울여야합니다. DBA가 몇 가지 해결책을 제시했을 때 돌아가서 퀴즈를 뚫고 왜 그런 식으로 문제가 해결되어야하는지 물어보십시오.

이 방법은 남자를 소년들과 매우 빠르게 구별 할 것입니다.

Answer 5

DB의 최대 성능에 얼마나 가깝습니까? 이 기술로 해결할 수없는 OLTP 문제를 만드는 것은 매우 쉽습니다. 에릭이 말했듯이, 총 아키텍처 재 설계가 순서대로있을 수 있습니다. 더 많은 램, 더 많은 램을 추가합니다 :)

Answer 6

확실히 데이터베이스를 보지 않으면 최적화하는 가장 좋은 방법이 무엇인지 말하기는 어렵습니다. 당신이 한 일을 감안할 때, 당신은 데이터베이스 디자이너를 고용해야 할 것입니다. 그들이 문제에 어떻게 접근 할 것인지 묻는다면 면접관이 처음으로 성능이 저조한 쿼리를보고 프로파일 러를 실행하여 무슨 일이 일어나고 있는지 확인하고 식별 할 수 있는지 확인하십시오. 그 사람은 매개 변수 스니핑 및 피하는 방법, 커서를 피하기 위해 사용할 수있는 방법, 통계를 업데이트 해야하는 이유, 쿼리를 수행 할 수있는 이유에 대한 구체적인 질문에 대답 할 수 있어야합니다. 성능 튜닝에서 볼 수있는 몇 가지 일반적인 것들이 있습니다. 네트워크가 최대화 되었습니까 (때로는 데이터베이스가 아님), 전반적인 설계가 잘못 생각되지 않으며, 일반적으로 잘못 수행하는 SQL 코드를 사용하고 있습니까? 모든 검색에서 예를 들어 첫 번째 캐릭터로 와일드 카드를 허용하는 경우 빠르게 빠르게 진행할 수는 없습니다. 당신의 결합이 다중 열 자연 키에 있다면, 그것들보다 느립니다. 필드에 두 개 이상의 정보를 저장하고있는 많은 조작이 데이터를 다시 가져 오게하고 있습니까? 커서를 사용하고 있습니까? 기능을 사용하고 있습니까? 당신은 안되는 경우 코드를 재사용하고 있습니까? 항상 필요한 최소 정보를 반환하고 있습니까? 연결을 닫고 있습니까? 교착 상태를 얻고 있습니까? 테이블 행이 너무 넓습니까? 특정 테이블에 레코드가 너무 많습니까 (오래된 레코드를 제거하거나 아카이브 데이터베이스에 넣으면 큰 차이를 만들 수 있음)? 코드의 얼마나 많은 코드가 방향 지향되고 지향되지 않습니까? 이것들은 숙련 된 데이터베이스 사람이 볼 것들의 종류이며, 따라서 인터뷰에서 그들이 이야기해야 할 것들의 종류입니다.

일부 나쁜 코드 예제 (이미 최적화 한 내용을 알고 있음)는 조정 방법에 대한 접근 방식에 대한 좋은 아이디어를 제공 할 수 있습니다. 당신은 체계적이고 SQL 지식의 깊이있는 사람을 원합니다.

공연 튜닝에 관한 좋은 책이 있습니다. 인터뷰하기 전에 그것들을 얻고 그들과 함께 그들과 함께하는 것이 좋습니다.