알 수없는 데이터베이스를 이해하기 시작하는 위치

제목이 요약됩니다.

리버스 엔지니어링되어야하는 28 개의 테이블과 86 개의 저장 프로 시저가있는 SQL Server 데이터베이스가 있습니다. 일부 테이블은 사용되지 않으며 모든 procs도 사용되지는 않습니다.

가장 큰 문제는이 DB와 ​​함께 사용하기 위해 만들어진 모든 Windows 서비스와 모든 소프트웨어 및 데이터베이스 설명서가 손실되고 전체 시스템을 설계 한 사람을 찾을 수 없다는 것입니다.

관계를 이해하는 데 도움이되는 ER 다이어그램을 이미 만들었지 만 데이터베이스 관리 경험이 없어서 어디서부터 시작해야할지 모르겠습니다.

또한 이런 종류의 질문이 여기에 요청되지 않은 경우 죄송합니다.

시작하는 세 가지 매우 빠른 단계 :

1)

USE DatabaseName

SELECT    [TableName] = OBJECT_NAME(object_id),
last_user_update, last_user_seek, last_user_scan, last_user_lookup
FROM    sys.dm_db_index_usage_stats
WHERE    database_id = DB_ID('DatabaseName')

클러스터형 인덱스를 포함하여 각 인덱스가 마지막으로 사용 된 시간을 알려줍니다. 따라서 적어도 테이블에 액세스하고 있지 않은 맛을 제공하십시오.

2) 앱을 사용하는 동안 확장 이벤트 세션 (또는 SQL 2012 이전 버전을 실행중인 경우 서버 측 프로파일 러 추적)을 1 시간 정도 켜십시오. 추적 / 세션과 연관시킬 수 있도록 사용자에게 응용 프로그램에서 다양한 조치를 특정 순서로 수행하도록 요청할 수 있습니다.

유용한 제안 : 앱이 사용하는 연결 문자열을 수정할 수있는 경우 "; Application Name = AppNameGoesHere"를 추가하여 해당 특정 애플리케이션 이름에서 추적 필터링을 실행할 수 있습니다. 어쨌든 좋은 연습.

3) 비 프로덕션 서버에서 작동하는 응용 프로그램 버전을 가져옵니다. 응용 프로그램에 대한 동작 기반 테스트 목록을 개발합니다 ( "사용자가 새 항목 단추를 클릭하면 해당 사용자에 대한 새 항목이 생성됩니다"등). 이름을 바꾸어 테스트와 관련이 없다고 생각되는 개체를 소프트 삭제하기 시작합니다. (objectName_DEPRECATED_YYYYMMDD와 같은 형식을 사용합니다. 날짜는 실제로 삭제하려는 날짜입니다.) 모든 테스트를 다시 확인하십시오.

확장 이벤트 세션, 인덱스 사용법 DMV 및 소프트 삭제를 조합하여 애플리케이션이 사용중인 기본 오브젝트와 어떤 오브젝트가 어떤 역할을 수행하는지에 대한 일반적인 합의를 식별 할 수 있어야합니다.

행운을 빕니다!

가장 좋은 방법은 SQL Power Doc을 사용하여 데이터베이스를 문서화하는 것입니다.

Windows PowerShell을 사용하는 SQL Server 및 Windows 설명서

SQL Power Doc은 SQL Server 인스턴스와 기본 Windows OS 및 컴퓨터 구성을 검색, 문서화 및 진단하는 Windows PowerShell 스크립트 및 모듈 모음입니다. SQL Power Doc은 SQL Server 2000에서 2014까지의 모든 버전의 SQL Server와 Windows Server 2012 R2 및 Windows 8을 통해 Windows 2000 및 Windows XP의 모든 버전의 Windows Server 및 소비자 Windows 운영 체제에서 작동합니다. Windows Azure SQL 데이터베이스 문서화

참고 : 나는 이것을 사용했으며 데이터베이스 서버 인스턴스를 문서화하고 이해하는 데 정말로 도움이 될 것입니다.

나는 비슷한 상황에 있었기 때문에 이것이 불가능한 직업이 될 수 없다고 말할 수 있습니다. 나는 소스 코드 (> 100k 줄의 코드), 실행중인 서비스, 실행중인 데이터베이스 (~ 50 테이블) 및 문서가 없었 으며이 응용 프로그램의 사용자와 데이터베이스 및 서비스의 사본을 제외하고는 아무도 그것에 대해 묻지 않았습니다. 테스트 환경 (소스 코드가없는 몇 가지 버전 번호). 또 다른 요구 사항은 서비스가 고객 외부에 있기 때문에 24/7 서비스를 실행해야한다는 것입니다. 상황은 대부분의 직원이 개발자와 문서를 포함하여 거의 동시에 거의 혼란에 빠졌기 때문에 발생했습니다. 대략적인 개요 / 문서를 얻는 데 6 개월 이상이 걸렸습니다. 나중에 사용할 수 있거나 완전히 구현되지 않았기 때문에 아무런 영향을 미치지 않는 많은 테이블과 함수가있었습니다. 결함이 있거나 더 이상 사용되지 않거나 릴리스되지 않은 기능. 6 개월 후 나는 새로운 사물이나 사물 간의 관계를 발견했고 이전에 잘못된 가정을했기 때문에 문서를 다시 작성해야했습니다.

왜 내가 이것을 말하고 있습니까? 때로는 그러한 상황에서 처음부터 시작하여 이전 응용 프로그램 (또는 시간이 지남에 따라 변경되거나 새로운 주요 릴리스를 원할 경우 새로운 응용 프로그램)의 요구 사항을 가득 채우는 새 응용 프로그램을 작성하는 것이 더 쉽고 저렴합니다. 또는 무엇을 기대해야하는지 말해 줄 수 있습니다.

실제로 리버스 엔지니어링하려는 경우 다음 단계를 권장합니다.

• 전체 시스템을 백업하십시오! (첫째 : 필요할 때 알 수 없습니다. 두 번째 : 다음 단계에 필요합니다)
• 시스템 (서비스 및 데이터베이스)의 사본을 다시 작성하여 작업하고 작성 방법을 적어 두십시오. 리버스 엔지니어링 동안 여러 번 엉망이되기 때문에 다음 달에 반드시 여러 번이 작업을 수행해야하기 때문입니다.
• 테이블 간의 종속성이있는 ER 다이어그램 작성
• 각 테이블의 종속성, 저장 프로 시저 등을보고 문서화합니다. 이는 대부분 ER 다이어그램에 포함되지 않기 때문입니다.
• 사용자에게 묻고 소프트웨어를 사용하여 소프트웨어의 기능 이해 (테스트 시스템에서 가장 잘 수행)
• 서비스의 소스 코드를 사용할 수있는 경우 : 개요를보고 DB를 호출하고 문서화하십시오 (doxygen은 함수 호출 계층 구조를 가진 대략적인 문서를 얻는 데 유용한 도구입니다)
• 테이블 이름과 열을 확인하여 DB에 대한 대략적인 개요를 얻으십시오.
• 데이터베이스를 사용하면서 보면서
• 앞의 4 단계로 테이블을 3 가지 범주로 나누십시오 (응용 프로그램에 따라 다를 수 있음). 정적 데이터 (서버 구성과 같이 서버를 실행하는 동안 변경되지 않는 데이터, 외래 키를 사용하여 다른 테이블의 유효한 값을 제한하는 열거 형) , ...), 구성 데이터 (사용자 설정과 같이 거의 변경되지 않는 데이터) 및 OLTP 데이터 (채팅 서버의 사용자 메시지, 포럼의 게시물, 기계 제어 시스템의 측정 값, 온라인 게임에서의 전투, ...)
• 만족하거나 포기할 때까지 이전 5 단계를 반복하십시오.
• 마치 코드 / 시스템 / 데이터베이스를 유지 관리하는 사람이 당신이 사는 곳을 아는 폭력적인 정신병자처럼 문서와 코드를 작성하십시오.

행운을 빕니다;)

의견을 게시 할 담당자가 충분하지 않지만에 대한 귀하의 질문에 도움을주고 싶습니다

getting the SQL Power Doc to work.

설명서 페이지의 단계를 따르면 쉽게 작동합니다. 맨 위에서 시작하십시오.

https://sqlpowerdoc.codeplex.com/wikipage?title=Guide%20For%20PowerShell%20 초보자