따라서 우리는 내부 회사 데이터베이스를 가지고 있습니다. 고객, 전화 통화, 판매 거래 및 고객 계약 / 체계를 관리합니다.
Access 2000 프런트 엔드 및 SQL Server 2000 표준 백 엔드입니다. 단일 서버, 이중 Xeon 3.2GHz, 2GB RAM, Windows Server 2003은 하루에 약 40 %의 CPU 부하를 받고 OS (HT)에 표시되는 4 개의 코어에 분산됩니다.
백엔드 데이터베이스는 제대로 설계되지 않았으며 숙련도가 낮은 개인이 유지 관리하는 10 년 이상 유기적으로 성장했습니다. 잘 정규화되지 않았으며 명백한 문제 중 일부에는 기본 키 또는 인덱스가없는 수만 행의 테이블이 포함되는데,이 테이블은 시스템에서 가장 많이 사용되는 일부 부분에 대해 다중 테이블 조인에도 많이 사용됩니다 (예 : 하루 8 시간 동안 모든 사람의 두 번째 모니터에 앉아 몇 초마다 큰 비효율적 인 쿼리를 실행하는 통화 관리자 응용 프로그램).
프런트 엔드는 그다지 좋지 않습니다. 수백 개의 양식, 중첩 된 저장된 쿼리, VBA 코드에 잘못 작성된 Embedded SQL, 수십 가지 “질문”등이 있으며 변경 될 때마다 관련이없는 것으로 보입니다. 우리는 “충분히 작동”하는 하나의 MDB를 설정했으며, 사내에 Access 헤비급이없고 (하나를 고용 할 계획도 없음) 그에 대한 변경 정책이 없습니다.
회사는 현재 천천히 성장하고 있으며 클라이언트, 전화 등의 수가 증가하고 동시 사용자 수가 약간 증가했으며 최근에 성능이 현저하게 악화되었습니다 (양식 간 이동 대기, 목록 채우기 대기 등) )
퍼프 먼의 말 :
- 초당 디스크 전송 : 0에서 30 사이, 평균 4.
- 현재 디스크 큐 길이 : 약 1
SQL Server의 프로파일 러는 1 분마다 수십만 건의 쿼리를 봅니다. 클라이언트의 CPU 사용량은 거의 제로이므로 서버 측 쿼리가 실행되기를 기다리고 있습니다. 이 워크로드를 DB Engine Tuning Advisor를 통해 테스트 백업에 적용했지만 그다지 큰 차이는 없었습니다.
그런데 100MB와 기가비트 이더넷이 모두 하나의 서브넷에 있고 2 층에 40 명의 ish 사용자가 있습니다.
질문에.
내가 알다시피 우리는이 상황을 해결 / 개선하기위한 두 가지 선택이 있습니다.
- 이를 폐기하고 맞춤형 또는 부분 맞춤형으로 완전히 새로운 CRM 시스템으로 교체 할 수 있습니다.
- 하드웨어를 척킹하여이 시스템의 수명을 연장 할 수 있습니다.
소프트웨어를 교체하는 것보다 훨씬 적은 비용으로 성능이 뛰어난 Intel i7 시스템을 구축 할 수 있습니다.
새로운 시스템이 개발 될 때이 시스템에서이 시스템을 호스팅 할 수 있으므로 낭비되는 하드웨어가 없습니다. 새로운 CRM 시스템이 계속 발전하고 있습니다. 1 년 이상 그런 일이 일어나지 않습니다.
이 상황에 대한 생각, 특히 당신이 여기에 있었다면 가장 감사하겠습니다.
감사
답변
나는 여기의 모든 사람들과 동의하지 않을 것입니다. 그것에 약간의 하드웨어 척. 저렴하고 빠르며 쉬우 며 적절한 CRM 솔루션을 구현하는 데 필요한 시간을 사게됩니다. 내가이 보드뿐만 아니라 스택 오버 플로우의 모든 사람들에게 혐오스러운 것을 옹호하는 이유는 프로젝트 관리자 / 관리자 였고 잠시 동안 “비즈니스”쪽에 있었기 때문입니다. 단어에 대한 나의 미움으로 인해 따옴표 안에 있습니다). 소프트웨어에 대한 설명을 바탕으로 다른 것을 재구성하는 데 1 년 정도 걸립니다. 비즈니스 규칙 / 질문을 발견 / 문서화하는 데 2 개월이 소요될 수 있습니다. 개발 비용도 엄청나게 비쌉니다. 특히 트릭 아웃 서버 비용과 비교할 때.
실제로 그 이유 때문에 회사를 위해 일련의 웹 앱을 호스팅하려고합니다. 내부 IT 부서는 새로운 플랫폼에서 다시 개발하기를 원하기 때문에 더 나은 하드웨어로 옮기지 않습니다. 이 비용은 새로운 하드웨어로 이동하는 데 드는 비용의 약 3 배입니다. 회사가 1 년 안에 계약을 갱신하지 않았을 수도 있음을 언급하지 마십시오.
답변
둘 다 할 필요는 없습니다. 내 제안은 단순히 테이블에 인덱스 / 키를 추가하는 것입니다.
기본 키 또는 인덱스가없는 수만 개의 행이있는 테이블 (멀티 테이블 조인에도 많이 사용됨)
많은 돈이나 시간을 소비하기 전에 몇 시간이 걸리고 특히 조인에 사용되는 열의 경우 조인에 관련된 테이블에 인덱스 (또는 가능한 경우 기본 키)를 추가하십시오. 몇 시간 만에 10 배나 쉽게 성능을 향상시킬 수 있습니다.
답변
디스크 I / O가 없다는 것은 쿼리가 RAM에서 대부분 공급된다는 것을 의미합니다. 핫 테이블이 더 이상 RAM에 맞지 않고 서버가 디스크 작업을 시작하면 잘못 타고있을 수 있습니다. 2GB 또는 RAM은 요즘별로 많지 않지만 SQL2000 시대에는 크기가 커졌을 것입니다. 응용 프로그램이 일반적으로 조작하는 데이터의 양이 가지고있는 RAM보다 작습니다. 데이터 파일에서 “사용 된”공간의 양을보고 싶을 수 있습니다. 이것은 데이터베이스가 얼마나 많은 RAM을 소비 할 수 있는지에 대한 아이디어를 제공합니다. SQL Server는 RAM에 필요하지 않은 데이터를 유지하지 않지만 어떤 테이블이 언제 사용되는지 알기가 어려울 수 있습니다.
하이퍼 스레딩이 SQL Server에서 항상 도움이되는 것은 아닙니다. 더 나은 성능을 얻을 수 있습니다. 전원을 껐다 켜는 데는 재부팅이 필요하기 때문에 테스트하기가 어렵고 프로덕션 서버에서는 큰 번거 로움이 있습니다.
“분당 수십만 개의 쿼리”는 초당 수천 개의 쿼리로 변환됩니다. 그것은 꽤 바쁘게 들리지만, 그 트래픽의 대부분은 Access에 의해 커서를 가져올 수 있습니다. 액세스는 SQL에서 결과 세트를 효율적으로 검색하는 데 특히 나쁩니다. SQL Server 병렬화 설정을 해제하면 성능이 향상 될 수 있습니다.
또한 차단을 찾고 싶습니다. 블로킹 문제에서 하드웨어를 던지는 것이 항상 기대했던 극적인 개선을 만들어내는 것은 아닙니다. 디스크가 아닌 RAM이 많은 블로킹이없고 쿼리가 만족하는 경우 기본적으로 프로세서의 불만과 메모리 채널을 통해 데이터를 가져 오는 기능에 의존합니다. 이 경우 하드웨어가 빠를수록 좋은 개선이 필요합니다. 서두르고 (이 문제를 극복하기 위해) 천천히 성장하고 있다면 충분할 것입니다.
솔루션으로 하드웨어 추가 및 데이터베이스 개선은 확장되지 않습니다. 성장이 급증하면 새로운 하드웨어에 어려움을 겪을 수 있습니다. 또 다른 생각은 성공적인 응용 프로그램이 사용자를 끌어들이는 것입니다. 응용 프로그램의 응답 속도가 빨라지면 사용자는 보고서가 끝나기를 기다리는 동안 커피를 마시 러 갈 때보 다 더 많은 보고서를 실행할 가능성이 높습니다.
데이터베이스 스키마가 실제로 나쁘면 테이블의 인덱싱을 보면 성능이 약간 향상 될 수 있습니다. 자주 문의하는 테이블에 집중하십시오. 프로파일 러를 사용하여 서버에 대해 실행중인 쿼리를보고, 100,000 페이지와 같은 많은 데이터를 읽는 쿼리를 찾은 다음 많이 읽지 않는 쿼리를 처리하도록 지시 할 수 있습니다. 일부 테이블에는 키가 없다고 언급했습니다. 제약 조건이나 고유 인덱스에 의해 강제되지 않는 데이터에 자연 키가 있습니까?
테이블에 클러스터 된 인덱스가 있습니까? 클러스터형 인덱싱이 없으면 모든 종류의 보조 효과가 발생할 수 있습니다.
열이 많은 비 클러스터형 인덱스가 많이 있습니까? 이는보다 효과적인 인덱싱 전략을 구현하기보다는 많은 커버링 인덱스를 구축하려는 시도 인 경우가 많습니다. SQL Server는 쿼리 중에 의미있는 인덱스를 작성하고 클러스터되지 않은 클러스터 된 인덱스를 지원할 경우 효과적으로 인덱스를 효과적으로 구축 할 수 있습니다.
마지막으로 물어볼 가치가 있습니다. 테이블에서 유지 관리 (재 인덱싱 및 / 또는 업데이트 통계)가 수행되고 있습니까?
답변
이것은 기술적 질문이 아닌 비즈니스 질문입니다.
사업주로서 :
시스템은 사업에 얼마나 전략적입니까? 전략이 적을수록 관리 및 수정 비용이 적게 들며 다른 곳에서 비즈니스를 성장시키는 데 사용할 수있는 돈입니다.
컴퓨터 사람들은 모두 큰 방에 들어가서 디자인에 대해 논쟁하고 돈을들이면서 나를 두려워합니다. 시스템을 계속 진행하십시오! 이것이 성능 조정 (재 아키텍처없이)을 의미하는지 또는 더 많은 하드웨어를 던지는 지 여부에 관계없이 작동을 중지하는 경우에만 우선 순위입니다.
IT 컨설턴트 :
시스템은 레거시이며 숨겨진 운영 비용이 있습니다. 당사는 고객에게 적합한 시스템을 설계하여 향후 성장 및 전략적 이점을위한 확장 및 플랫폼을 제공 할 수 있습니다. 여기에 서명하면 모든 꿈이 이루어질 것입니다.
IT 직원으로서 :
나는 여기서 슈퍼 히어로가 될 수 있으며이 일에서 지옥을 최적화함으로써 임박한 재난을 피함으로써 회사를 구할 수 있습니다! 내가 회사를 수천 명 구했을 때 내 매니저는 선물과 칭찬으로 나를 샤워합니다.
답변
나는 둘 다 말한다.
지금 당신의 40 % 정도의 CPU로 말했습니까? 사용자가 아직 불평하고 있습니까? 그렇지 않은 경우 여전히 호흡 공간이 있습니다. 한동안 더 많은 메모리가 충분할 수 있습니다.
갈 길에 대한 질문, 사내 소프트웨어 개발자가 있습니까? 대답이 아니오이면 다시 시도하지 마십시오. 당신은 지금 어디에 있는지 정확하게 알게 될 것입니다.
사내 개발자가 있다고 가정하면 사내 개발자가 프로젝트를 올바르게 수행 할 수 있습니까? 나는 기본적으로 고객의 프로젝트와 동일하게 완전하고 적절하게 (상대적인) 타임 라인을 규정하고 있다고 말하고있다. 그렇지 않다면 귀찮게하지 마십시오. 그렇지 않으면 현재 위치로 돌아갑니다.
회사가 자신을 고객으로 발표하고 내부 프로젝트에 동일한 리소스를 제공해야 할 때까지 현재 위치를 정확하게 파악할 수 있습니다. 거기에 있었고, 티셔츠의 전체 옷장을 얻었습니다.
따라서 제대로 할 수 없다면 박스 턴키에서 두 가지 선택을 할 수 있습니다. 직원이 구매 시스템의 금형에 맞아야하는 이유가 바로 직원입니다. 또는 커스터마이징이 가능하고 커스터마이징에 여전히 PROJECT 시간을 소비해야합니다.
또는 당신이 가진 것을 리팩터링하십시오. 사람들은 새로운 기능이 등장 할 때 완전히 동일한 기능을 기대할 것이므로 다른 방법으로 모든 것을 한 번에 수행해야하는 이유를 기억하십시오. 리팩터링하면 작동 방식을 파악한 다음 임시 변경 사항을 여러 소규모 하위 프로젝트로 계획 할 수 있습니다.
시스템을 보지 않으면 백엔드에서 최대한 많은 정규화를 수행하고 SQL의 많은 부분을 Stored procs로 옮길 수 있습니다. 그런 다음 C # Forms 또는 webapp에서 새 프런트 엔드를 빌드하십시오. 비즈니스 로직과 SQL을 프론트 엔드에서 제거 할 수 있으면 나중에 다시 쉽게 수행 할 수 있습니다. 소규모 프로젝트에 수행 한 작업을 유지함으로써 언제라도 제쳐 놓거나 중단되면 사용할 수있는 진전이 있습니다.
답변
여기에 좋은 대답이 있지만 (집 개발자가 있다고 가정 할 때) 비교적 적은 양의 작업이 큰 영향을 줄 것입니다-기본 키를 추가하십시오 (모든 쿼리를 변경하지 않아도됩니다) 사용) 필드에 색인을 추가하고 쿼리를 약간 조정하면 크게 증가 할 수 있습니다. 문제 해결에 필요한 시간과 헤드 룸을 구입하기 위해 지금 RAM을 구입하십시오.
“고정 또는 도랑”이라는 주제에서 시스템 기능이 기본적으로 작동하고 필요한 작업을 수행하는 경우 휠을 다시 쓰지 마십시오. 사용자가 필요에 맞지 않기 때문에 체조를 사용해야하는 경우에는 노력을 기울일 필요가 없습니다.
답변
글쎄 … 지금은 얼마 전이지만 여기에 결과를 기록 할 것이라고 생각했습니다.
결국, 다른 문제를 해결하기 위해 VBA를 단계별로 단계별로 진행했습니다. 그런 다음 행 집합을 가져 오기위한 일부 호출이 20-30 + 초 동안 차단되고 있음을 깨달았습니다.
내가 그들을 파고 들었을 때 행 집합이 MS Access 쿼리를 기반으로한다는 것을 알았습니다.
그것은 다른 Access 쿼리에서 데이터를 선택하는 것이 었습니다.
그것은 또 다른 Access 쿼리에서 데이터를 선택하는 것이 었습니다.
쿼리 디자이너를 사용하여 모두 드래그 앤 드롭 한 것처럼 보입니다.
나는 상위 6 개 사용자의 고통을 겪었고, 틀림없이 이것들과 완전히 동일하다는 것을 알았습니다.
따라서 체인 쿼리 스택을 완전히 제거하고 각 쿼리를 T-SQL로 작성하여 서버에서 직접 실행할 수있는 단일 통과 쿼리로 대체했습니다.
개선은 모든 경우에 절대적으로 광범위하게 이루어졌으며 더 이상 누군가를 위해 더 이상 쿼리를 기다리지 않았습니다.
그런 다음 회사를 떠났습니다. 그것이 아직 있는지 모르겠지만 … 나는 그것을 놓치지 않습니다.
