우리는 다음으로 이사했습니다. 새 서버. SQL과 1C를 실행합니다. 예전에 비하면 많이 시원해졌습니다. 그리고 Gilev의 테스트에서도 이를 확인했습니다. 기존 서버의 10-15에 비해 39를 제공했습니다. 따라서 구매 직후 데이터베이스를 전송하고 작업을 시작했습니다.
그러나 어느 시점에서 문제가 발생했습니다. 사용자는 불만을 제기하기 시작했습니다. 느린 작업. 우리는 서버와 서비스(별도 게시물의 주제)에 대한 특정 설정을 지정하고 서버를 재부팅하기로 결정했습니다. 다행스럽게도 재부팅 속도는 2분이었습니다(다른 서버에서는 최대 10분이었습니다). 그 후 1C에 로그인하면 다음 메시지가 나타납니다.
"주목!!! 마지막 구조 조정 후 데이터를 업데이트하는 동안 오류가 발생했습니다. 업데이트를 반복해야 합니까? "설마"
"예"를 클릭하면 다음이 나타납니다.
“불완전한 구성 저장 작업이 감지되었습니다. 계속하려면 작업을 완료해야 합니다."
내가 하기로 결정한 첫 번째 일은 Managment Studio의 CHECKDB였습니다. 2시간의 대기(500GB 데이터베이스) 후에 모든 것이 정상이었습니다.
동적 업데이트 중에도 동일한 오류가 발생한다는 정보를 인터넷에서 찾았습니다.
온라인에서 제안된 솔루션은 즉시 도움이 되지 않았지만 다른 조치와 함께 결과를 얻었습니다. 그래서 내가 한 일은:
해결책:
- 네트워크 솔루션에서 누락된 사항:
sp_configure '업데이트 허용', 1
재정의로 재구성
가다
2. 데이터베이스를 복구 모드로 전환
데이터베이스 세트 EMERGENCY, SINGLE_USER 변경
3. 데이터베이스 테스트를 수행합니다.
dbcc checkdb('db_name', REPAIR_ALLOW_DATA_LOSS)
4. 복구 모드에서 데이터베이스를 종료합니다.
데이터베이스 세트 ONLINE 변경, MULTI_USER
5. 원칙적으로 베이스 자체에 모든 것이 정상이라고 확신한다면 2-4번 항목을 수행할 필요가 없습니다. 다음으로 SQL 프로파일러에서 두 가지 쿼리를 실행합니다.
FileName = 'commit'인 구성에서 삭제
FileName = 'dbStruFinal'인 구성에서 삭제이러한 기록은 동적 업데이트를 담당하므로 삭제를 두려워할 필요가 없습니다.
데이터베이스 쿼리의 작업 버전에서:
WHERE FileName = 'commit' 구성에서 *를 선택하세요.
WHERE FileName = 'dbStruFinal' 구성에서 *를 선택하세요.
비어있을 것입니다.
6. 설정을 반환합니다.
sp_configure '업데이트 허용', 0
가다
7. 그 후 구성 프로그램을 시작하고 데이터베이스가 작동하기 시작했습니다.
또한 첫 번째 플래그를 제거한 후 베이스 작업을 시작할 수 있습니다.
모래 상자
권한 2013년 9월 18일 오후 03:241C, 구성 복원 정보 기반 MS SQL을 사용하여
한때 문제가 발생했습니다. 저장소에서 구성을 업데이트할 때 오류가 발생하고 1C가 닫혔습니다.
나중에 밝혀진 바에 따르면 구성 저장소가 파괴되었으며 구성을 업데이트할 때 데이터베이스 구성도 저장소에서 삭제되었습니다. 정보 보안의 동적 업데이트 중에 이전에도 유사한 오류가 발생했습니다.
왜냐하면 이 문제한 번 이상 발생하여 치료 옵션을 공유하기로 결정했습니다.
다음에 구성 프로그램을 시작하면 "주의!!!"라는 오류가 나타납니다. 마지막 구조 조정 후 데이터를 업데이트하는 동안 오류가 발생했습니다. 업데이트를 반복해야 합니까? 대답이 '예'이면 다음 메시지가 표시됩니다. “불완전한 구성 저장 작업이 감지되었습니다. 작업을 계속하려면 작업을 완료해야 합니다.' 이후 애플리케이션이 종료됩니다.
이 문제를 분석할 때 문제에 대한 여러 가지 솔루션이 발견되었으며 각 솔루션은 서로 다른 경우에 작동합니다.
옵션 1(동일한 구성의 복사본이 포함된 SQL 백업이 있는 경우):
정보 보안 사본이 배포되고 다음 요청이 실행됩니다.
GO DELETE FROM .. GO INSERT INTO .. SELECT * FROM .. GO 사용
이 경우 정보 보안 구성이 저장된 테이블이 다시 채워집니다. 이 작업 후에는 정보 보안을 테스트하고 수정하는 것이 좋습니다.
옵션 2(백업이 없는 경우):
이 옵션은 마지막 선택으로 바뀌었습니다. 왜냐하면 구성은 개발 중이었고 스토리지에 의존하여 백업을 조금 잊어버렸습니다.
데이터베이스에서 "FileName" 열의 값(dbStruFinal 및 commit)에 따라 "Config" 테이블에서 두 개의 레코드가 삭제됩니다.
다음 쿼리가 실행됩니다.
GO DELETE FROM 을 사용하세요. WHERE FileName = "dbStruFinal" GO DELETE FROM . WHERE FileName = "커밋" GO
이상하게도 베이스가 살아납니다.
태그: 1C Enterprise 8.2, SQL, 구성 복원
이 기사는 작성자가 아직 커뮤니티의 정회원이 아니기 때문에 논평 대상이 아닙니다. 작성자가 수신한 후에만 작성자에게 연락할 수 있습니다.
배경
새로운 정보 레지스터 “MessageTrackingLog”를 생성해야 했습니다. 구성에 추가하고 데이터를 로드했습니다. 그런 다음 최적화 작업이 이루어졌습니다. 레지스터 구조를 변경해야 했습니다. 그러나 그것은 거기에 없었습니다!
여기에서는 모든 것이 명확합니다. 레코드가 고유하지 않게 되었기 때문에 삭제해야 합니다!
가장 쉬운 방법은 다음과 같습니다.
NewRecord = InformationRegisters.MessageTrackingLog.CreateRecordSet(); NewRecord.Write();
이 방법을 사용하면 1C에서 레지스터를 매우 빠르게 지울 수 있습니다(그러나 이것은 또한 우리의 실수입니다).
오류
레지스터가 비어 있는 것처럼 보이며 1C를 업데이트할 수 있습니다. 놀라게 하고 싶지는 않지만 또 오류가 발생합니다.
오류는 무엇을 나타냅니까?
정보 베이스의 업데이트 프로세스 중에 치명적 오류
때문에:
고유 인덱스에 고유하지 않은 값을 삽입하려고 합니다.
마이크로소프트 SQL 서버 Native Client 11.0: 개체 이름 "dbo._InfoRgChngR34546NG" 및 인덱스 이름 "_InfoR34546_ByNodeMsg_RNTSRRRRRRNG"에 대해 중복 키가 발견되어 CREATE UNIQUE INDEX 문이 종료되었습니다. 중복 키 값은 (0x00000011,d7,, 4015년 9월 27일 오후 10시 22분, 768404,00,00,00,00,00,00).
HRESULT=80040E2F, SQLSrvr: SQLSTATE=23000, 상태=1, 심각도=10, 기본=1505, 줄=1
설명
SQL의 구조를 이해해보자. 우리에겐 등록부가 있어요 "MessageTrackingLog"는 SQL에서 테이블 "에 있습니다. _InfoR34546". 특수 처리나 "poke" 방법을 사용하여 확인할 수 있습니다(테이블 이름이 이미 오류 텍스트에 표시되어 있으므로 이를 수행할 필요는 없습니다).
이제 무슨 일이 일어났는지 설명하겠습니다. 데이터를 레지스터에 로드했을 때 SQL에서는 테이블에 기록되었습니다." _InfoR34546". 1C의 코드로 테이블을 지울 때 이 데이터가 테이블에서 삭제되었습니다." _InfoR34546", 그러나 테이블에 복사되었습니다." _InfoRgChngR34546". 이것이 문제가 되었습니다.
해결책
이 문제를 해결하려면 SQL 테이블 "_InfoRgChngR34546"을 지워야 합니다.
"Microsoft SQL Server Management Studio"를 예로 들어 말씀드리겠습니다. "로 가자 Management Studio". 데이터베이스를 찾아 테이블 탭을 열고 아무 항목이나 클릭한 후 "새 쿼리" 버튼을 클릭합니다. 이제 쿼리를 입력합니다.
테이블 "_InfoRgChngR34546" 자르기
다른 테이블이 있을 수도 있어요! 잊지 마요!
그리고 실행을 누르거나 "F5"를 누르세요. 결과는 다음과 같습니다.
이제 1C를 안전하게 업데이트할 수 있으며 오류가 발생하지 않습니다!
