오늘 우리 기사는 초보자가 인터넷에 많은 전자 메일 서비스의 미로를 이해하도록 돕기 위해 고안되었습니다. 우리는 Gmail, Yandex, Rambler 및 Mail.Ru 서비스에서 보내는 편지에 파일을 첨부하는 방법과 같은 다소 사소하지만 많은 사람들이 우려하는 질문을 고려할 것입니다.

(mosloadposition 디버그)

지메일

Gmail에서 새 이메일을 만들 때 Google, "파일 첨부" 링크를 클릭한 다음 컴퓨터에서 원하는 파일이나 아카이브를 찾아 두 번 클릭하면 됩니다.

이메일에는 파일이나 아카이브만 첨부할 수 있다는 점을 기억하세요. 이 규칙은 Gmail뿐만 아니라 다른 이메일 서비스에도 적용됩니다. 보내는 이메일에는 폴더를 첨부할 수 없습니다! 여러 개의 파일을 보내야 하는 경우 하나의 아카이브로 패키지해야 합니다. 예를 들면 다음과 같습니다. RAR 형식또는 ZIP을 사용하여 편지에 첨부할 수 있습니다. 폴더의 각 파일을 별도로 첨부할 수도 있습니다.

부착하기 위해서는 다음 파일"다른 파일 첨부" 링크를 클릭하고 이미 익숙한 단계에 따라 파일을 선택하세요.

편지에 파일 첨부를 해제하려면 옆에 있는 상자를 선택 취소하면 됩니다.

에게 Gmail 이메일원하는 만큼 파일을 첨부할 수 있습니다. 모든 첨부 파일을 포함하여 편지의 전체 크기가 25MB를 초과해서는 안 된다는 점만 기억하면 됩니다.
배송도 참고하세요 실행 파일예를 들어 EXE 형식의 경우 지메일 서비스금지. 그러나 파일을 아카이브에 압축하는 것도 도움이 되지 않습니다. 그러나 어떤 상황에서도 벗어날 수 있는 방법이 있습니다. 예를 들어 EXE에서 EX로 파일 확장자를 변경하고 수신자에게 컴퓨터에 저장한 후 파일 이름을 다시 변경해야 한다고 알릴 수 있습니다.

Yandex의 메일

Yandex 메일 서비스에서 편지에 파일을 첨부하는 것도 마찬가지로 쉽습니다. "파일 첨부..." 버튼을 클릭하고 컴퓨터에서 원하는 파일이나 아카이브를 선택한 다음 두 번 클릭하세요.

매번 “파일 첨부...” 버튼을 클릭하면 한 편지에 여러 개의 파일을 첨부할 수 있습니다. 기억해야 할 것은 최대 크기모든 첨부 파일이 포함된 발신 이메일은 22MB를 초과할 수 없습니다. 그렇지 않으면 추가 파일삭제해야 할 것입니다.

그러나 이것은 매우 쉽습니다. 불필요한 파일 옆에 빨간색 십자가가 있는 아이콘을 클릭하여 편지에서 고정을 해제합니다.

Yandex 메일에는 매우 흥미로운 옵션, 파일을 편지에 첨부하는 대신 Yandex.People에 업로드할 수 있습니다. 메시지에 첨부된 파일의 크기가 허용 한도를 초과하는 경우 파일은 자동으로 People에 업로드되며, 편지 수신자는 파일을 다운로드할 수 있는 링크를 클릭하게 됩니다.

필요한 경우 파일을 People에 독립적으로 업로드할 수 있습니다. "파일 첨부" 버튼 옆에 있는 화살표를 클릭하고 이 방법파일 전송. Yandex.People에 업로드되는 최대 파일 크기는 5GB입니다.

Rambler의 메일

Rambler 메일 서비스는 보내는 편지에 파일을 첨부하기 위한 유사한 표준을 제공합니다. "파일 첨부" 버튼을 클릭하고 찾아 선택해야 합니다. 필요한 파일컴퓨터 디스크에.

메시지에 여러 파일을 첨부할 수 있습니다. 하지만 총 크기는 20MB를 초과할 수 없다는 점을 기억하세요.
편지에 첨부된 파일을 삭제하려면 삭제할 파일 이름 옆에 있는 빨간색 십자가 아이콘을 클릭하세요.

메일.루

마지막으로 오늘 살펴볼 마지막 이메일 서비스는 우편 서비스 Mail.Ru. Yandex와 마찬가지로 편지에 직접 첨부하거나 [email protected]에 업로드하는 두 가지 방법으로 파일을 보낼 수 있습니다. 후자의 경우 메시지 수신자에게 파일을 다운로드할 수 있는 링크가 전송됩니다.

편지에 파일을 첨부하려면 “파일 첨부” 버튼을 클릭한 후 컴퓨터에서 필요한 파일을 선택하세요. "더 첨부" 버튼을 클릭하면 여러 파일과 아카이브를 이메일에 첨부할 수 있습니다.

편지에 첨부된 모든 파일의 총 크기는 22MB를 초과할 수 없습니다. 전송을 위해 준비된 파일이 30MB보다 큰 경우 [email protected] 서버에 업로드해야 합니다. 이렇게 하려면 "변경" 링크를 클릭하고 "모든 파일을 [email protected]에 업로드하고 링크 형식으로 편지에 첨부"라는 파일 첨부 방법을 선택하십시오. 이 경우 수신자는 서버에서 파일을 다운로드하기 위해 자동으로 생성된 링크가 포함된 편지를 받게 됩니다.

보내는 편지당 최대 20개의 파일을 첨부할 수 있습니다. 이 경우 각 파일의 크기는 1GB를 초과할 수 없습니다.

애플리케이션에서 파일을 삭제해야 하는 경우 삭제할 파일 이름 옆에 있는 빨간색 십자가 아이콘을 클릭하면 됩니다. 목록에서 사라집니다.

그래서 다양한 방법으로 첨부파일이 포함된 이메일을 보내는 방법을 살펴보았습니다. 우편 서비스. 각 서비스에는 고유한 뉘앙스가 있으므로 보내는 편지를 작성할 때 첨부된 파일의 허용되는 수, 크기 및 형식에 주의하는 것이 좋습니다.

특히 Yachainik의 경우 Elena Carlton

(Mosload위치 패널)

데이터베이스 아카이브를 생성했고 이제 이를 파일로 다운로드하려고 한다고 가정해 보겠습니다. 처음에는 모든 것이 잘 진행되지만 어느 시점에서 오류가 발생합니다.

"로드 오류 정보 기반. 다음 이유로 인해 일부 데이터가 정보 베이스에 로드되지 않았습니다. DBMS 오류: 최대값 초과 허용되는 크기 내부 파일 "D:\1CBASES\NewDB/1Cv8.1CD" "

저는 개인적으로 이 문제에 대한 해결책을 찾기 위해 많은 시간을 보냈고 결국 해결책을 찾았습니다. 이를 통해 18GB 크기의 데이터베이스 파일 복사본을 만들 수 있었고 궁극적으로 약 일주일의 시간을 절약할 수 있었습니다. 어땠는지 설명하지만 지금은 볼륨에 대해 이야기하지 않습니다.)

따라서 이 오류에는 여러 가지 이유가 있을 수 있습니다.

1. 데이터베이스에 있는 ANY 테이블의 크기가 다음에 대한 크기 제한을 초과합니다. 파일 버전(4GB). 솔직히 말해서 이러한 과잉을 피하기 위해 " " 처리(또는 유사)를 사용하여 데이터베이스 테이블의 크기를 미리 확인했습니다.
2. 이 오류는 플랫폼 기능의 결함과 관련이 있으며 업로드된 구성 메타데이터의 특정 구조로 인해 발생합니다.

첫 번째 경우에는 모든 것이 명확합니다. 기본 측정기에 일부 데이터베이스 테이블에 대한 제한이 초과된 것으로 표시되면 해당 테이블을 정리해야 합니다. 만약에 우리 얘기 중이야디렉토리 또는 비주기적인 정보 등록에 대한 정보가 있는 경우 거기에서 불필요한 요소/기록을 제거해야 합니다. 표 형식의 부분이 포함된 "무거운" 문서에도 동일하게 적용됩니다. 가장 먼저 해야 할 일은 표시된 개체를 제거하는 것입니다.

누적 레지스터 - 별도의 주제. 전체 테이블의 크기는 레지스터 입력 테이블의 크기를 초과할 수 있으며 종종 상당히 커질 수 있습니다. 때로는 결과를 간단히 다시 계산하는 것조차 도움이 될 수 있습니다.

잔액 레지스터가 잘못 닫힐 수 있으며(모든 차원에 대해 해당되는 것은 아님), 이로 인해 총계 테이블이 매우 중요하고 빠르게 증가할 수 있습니다. 누적 레지스터의 "고착된" 잔액을 기록하면 나중에 총계를 다시 계산하는 동안 최대 몇 GB까지 절약할 수 있습니다. 자신의 경험"부주의한" 고객으로부터.))

데이터베이스의 각 테이블 크기가 4GB 미만인데 오류가 계속 발생하는 경우 어떻게 해야 합니까?

이는 문제가 있는 구성 메타데이터 구조라는 두 번째 경우가 있음을 의미합니다. 대부분 인덱스 생성 단계에서 오류가 발생합니다.

간단히 말해서 1C의 Viktor Sosnovsky의 말로 상황을 전체적으로 설명하여 명확하게 설명하겠습니다. 다음은 파트너 포럼의 인용문입니다.

"파일 버전에서 인포베이스를 로딩할 때 모든 테이블의 데이터를 먼저 로딩한 후 인덱스가 생성됩니다. 인덱스 생성 시 오류가 발생하면 에러로 생성된 인덱스가 생성되고 이후의 모든 인덱스가 생성되지 않는 현상이 발생합니다. 데이터베이스에 데이터가 많으면 생산성이 크게 저하됩니다. 정규직그런 기반으로는 불가능할 겁니다."

인덱스를 생성할 때 어떤 테이블이 오류를 일으키는지 알아내야 합니다.

"폴더에 기술 저널을 포함합니다. C:\Program Files (x86)\1cv82\__PlatformVersionNumber__\bin\conf\"(또는 유사한 __플랫폼버전번호__당신의 것을 삽입하십시오) 파일을 넣으십시오 logcfg.xml대략 다음과 같습니다:

덤프 및 로그용 디렉터리가 다음과 같은지 주의 깊게 확인합니다.

1. 있었다
2. 다름
3. 읽고 쓸 수 있었습니다 윈도우 사용자, 누구를 대신하여 구성기를 실행합니다.

구성기를 다시 시작하고(기술 로그가 켜짐) .DT를 다시 로드해 봅니다.오류가 발생하면 로그 디렉터리로 이동하여 오류가 포함된 로그 파일을 찾아 주의 깊게 읽습니다.

내 경우에는 로그에서 EXCPCNTX가 처음으로 발생하여 오류를 일으킨 명령을 가리켰습니다. 인덱스 생성 _Accum27148_ByDims_TRRRRRRRRSSR(인덱스 이름은 다를 수 있습니다).

인덱스 이름의 숫자를 사용하고 " " 처리(또는 인덱스를 표시할 수 있는 유사체)를 사용하여 이 인덱스가 속한 테이블을 찾습니다. 나에게 그것은 비표준 누적 레지스터 중 하나의 회전 테이블로 밝혀졌습니다.

먼저 인덱스에 어떤 필드가 포함되어 있는지 살펴봐야 합니다. 알고 보니 플랫폼은 키 인덱스 필드의 전체 크기가 커지는 것을 정말 좋아하지 않습니다. 특히 그녀는 색인 생성을 좋아하지 않습니다. 긴 줄- 제 경우에는 STRING(500) 유형의 차원이 인덱스에 들어가 오류가 발생했습니다. 1C 회사의 또 다른 대표는 2007년 파트너 포럼에서 다음과 같이 연설했습니다.

"키 길이가 2K에 가까우면 인덱스 크기의 급격한 증가로 인해 여러 가지 불쾌한 결과가 발생합니다."

그리고 실제로 2013년에는 아무것도 변한 것이 없습니다. 유사한 사례지수 규모가 눈사태처럼 증가하고 있습니다. 파일 데이터베이스. 그리고 인덱스 테이블이 4GB 제한을 초과하면 loading.DT가 오류와 함께 중지됩니다.

개인적으로 문제가 있는 차원에 대해 "총계에 사용" 확인란을 비활성화하는 것이 도움이 되었습니다. 실제로는 결과가 필요하지 않았습니다. 더 이상 회전 테이블 자체에 표시되지 않으며 결과적으로 회전 테이블의 인덱스에도 표시됩니다. 예를 들어, 선 크기를 보다 엄격하게 제한하는 다른 방법도 있습니다. 나는 그것이 일부 도움이 되었다고 읽었습니다.

이러한 변경 사항은 테이블을 재구성하는 정보베이스에 적용되어야 합니다.

데이터베이스의 SQL 복사본이 변경된 경우에는 .DT를 다시 언로드하고 파일 버전에서 다시 로드해야 합니다.

SQL 복사본이 준비되지 않은 경우 언더로드된 파일 복사본에서 직접 수정을 시도할 수 있습니다. 변경 사항을 적용한 후 데이터베이스 테이블 재구성 모드에서 "테스트 및 수정"을 실행합니다. 인덱스는 플랫폼에 의해 새로 생성되며, 희망적으로 오류 없이 생성됩니다.

특히 운이 좋지 않아 오류가 다시 발생하는 경우 먼저 로그 분석부터 전체 과정을 반복해야 합니다. 문제가 있는 테이블이 두 개 이상 있거나 인덱스에 포함된 필드 크기로 문제를 해결할 수 없었을 수 있습니다.

데이터베이스 아카이브를 생성했고 이제 이를 파일로 다운로드하려고 한다고 가정해 보겠습니다. 처음에는 모든 것이 잘 진행되지만 어느 시점에서 오류가 발생합니다.

"정보베이스를 로드하는 동안 오류가 발생했습니다. 다음 이유로 인해 일부 데이터가 정보베이스에 로드되지 않았습니다. DBMS 오류: 허용되는 최대 내부 파일 크기를 초과했습니다."D:\1CBASES\NewDB/1Cv8.1CD" "

저는 개인적으로 이 문제에 대한 해결책을 찾기 위해 많은 시간을 보냈고 결국 해결책을 찾았습니다. 이를 통해 18GB 크기의 데이터베이스 파일 복사본을 만들 수 있었고 궁극적으로 약 일주일의 시간을 절약할 수 있었습니다. 어땠는지 설명하지만 지금은 볼륨에 대해 이야기하지 않습니다.)

따라서 이 오류에는 여러 가지 이유가 있을 수 있습니다.

1. 데이터베이스에 있는 ANY 테이블의 크기가 파일 버전 제한(4GB)을 초과합니다.. 솔직히 말해서 이러한 과잉을 피하기 위해 " " 처리(또는 유사)를 사용하여 데이터베이스 테이블의 크기를 미리 확인했습니다.
2. 이 오류는 플랫폼 기능의 결함과 관련이 있으며 업로드된 구성 메타데이터의 특정 구조로 인해 발생합니다.

첫 번째 경우에는 모든 것이 명확합니다. 기본 측정기에 일부 데이터베이스 테이블에 대한 제한이 초과된 것으로 표시되면 해당 테이블을 정리해야 합니다. 디렉토리나 비주기적인 정보 레지스터에 대해 이야기하고 있다면 거기에서 불필요한 요소/항목을 제거해야 합니다. 표 형식의 부분이 포함된 "무거운" 문서에도 동일하게 적용됩니다. 가장 먼저 해야 할 일은 표시된 개체를 제거하는 것입니다.

누적 레지스터는 별도의 주제입니다. 전체 테이블의 크기는 레지스터 입력 테이블의 크기를 초과할 수 있으며 종종 상당히 커질 수 있습니다. 때로는 결과를 간단히 다시 계산하는 것조차 도움이 될 수 있습니다.

잔액 레지스터가 잘못 닫힐 수 있으며(모든 차원에 해당되는 것은 아님), 이로 인해 총계 테이블이 매우 중요하고 빠르게 증가할 수 있습니다. 누적 레지스터의 "고착된" 잔액을 기록하면 나중에 총계를 다시 계산할 때 "부주의한" 클라이언트에 대한 자체 경험을 통해 테스트한 결과 최대 몇 GB까지 절약할 수 있습니다.))

데이터베이스의 각 테이블 크기가 4GB 미만인데 오류가 계속 발생하는 경우 어떻게 해야 합니까?

이는 문제가 있는 구성 메타데이터 구조라는 두 번째 경우가 있음을 의미합니다. 대부분 인덱스 생성 단계에서 오류가 발생합니다.

간단히 말해서 1C의 Viktor Sosnovsky의 말로 상황을 전체적으로 설명하여 명확하게 설명하겠습니다. 다음은 파트너 포럼의 인용문입니다.

"파일 버전에서 인포베이스를 로딩할 때 모든 테이블의 데이터를 먼저 로딩한 후 인덱스가 생성됩니다. 인덱스 생성 시 오류가 발생하여 에러로 생성된 인덱스가 생성되고 이후의 모든 인덱스가 생성되지 않는 현상이 발생합니다. 데이터베이스에 데이터가 많으면 생산성이 크게 저하됩니다. 이러한 데이터베이스를 사용한 전체 작업은 불가능합니다."

인덱스를 생성할 때 어떤 테이블이 오류를 일으키는지 알아내야 합니다.

"폴더에 기술 저널을 포함합니다. C:\Program Files (x86)\1cv82\__PlatformVersionNumber__\bin\conf\"(또는 유사한 __플랫폼버전번호__당신의 것을 삽입하십시오) 파일을 넣으십시오 logcfg.xml대략 다음과 같습니다:

덤프 및 로그용 디렉터리가 다음과 같은지 주의 깊게 확인합니다.

1. 있었다
2. 다름
3. 구성기를 실행하는 Windows 사용자가 읽고 쓸 수 있었습니다.

구성기를 다시 시작하고(기술 로그가 켜짐) .DT를 다시 로드해 봅니다.오류가 발생하면 로그 디렉터리로 이동하여 오류가 포함된 로그 파일을 찾아 주의 깊게 읽습니다.

내 경우에는 로그에서 EXCPCNTX가 처음으로 발생하여 오류를 일으킨 명령을 가리켰습니다. 인덱스 생성 _Accum27148_ByDims_TRRRRRRRRSSR(인덱스 이름은 다를 수 있습니다).

인덱스 이름의 숫자를 사용하고 " " 처리(또는 인덱스를 표시할 수 있는 유사체)를 사용하여 이 인덱스가 속한 테이블을 찾습니다. 나에게 그것은 비표준 누적 레지스터 중 하나의 회전 테이블로 밝혀졌습니다.

먼저 인덱스에 어떤 필드가 포함되어 있는지 살펴봐야 합니다. 밝혀진 바와 같이 플랫폼은 키 인덱스 필드의 전체 크기가 커지는 것을 정말로 좋아하지 않습니다. 특히 긴 문자열을 색인화하는 것을 좋아하지 않습니다. 따라서 제 경우에는 STRING(500) 유형의 차원이 색인에 들어가 오류가 발생했습니다. 1C 회사의 또 다른 대표는 2007년 파트너 포럼에서 다음과 같이 연설했습니다.

"키 길이가 2K에 가까우면 인덱스 크기의 급격한 증가로 인해 여러 가지 불쾌한 결과가 발생합니다."

실제로 2013년에는 아무 것도 변경되지 않았습니다. 이러한 경우 파일 기반의 인덱스 크기가 눈사태처럼 증가하는 것이 관찰됩니다. 그리고 인덱스 테이블이 4GB 제한을 초과하면 loading.DT가 오류와 함께 중지됩니다.

개인적으로 문제가 있는 차원에 대해 "총계에 사용" 확인란을 비활성화하는 것이 도움이 되었습니다. 실제로는 결과가 필요하지 않았습니다. 더 이상 회전 테이블 자체에 표시되지 않으며 결과적으로 회전 테이블의 인덱스에도 표시됩니다. 예를 들어, 선 크기를 보다 엄격하게 제한하는 다른 방법도 있습니다. 나는 그것이 일부 도움이 되었다고 읽었습니다.

이러한 변경 사항은 테이블을 재구성하는 정보베이스에 적용되어야 합니다.

데이터베이스의 SQL 복사본이 변경된 경우에는 .DT를 다시 언로드하고 파일 버전에서 다시 로드해야 합니다.

SQL 복사본이 준비되지 않은 경우 언더로드된 파일 복사본에서 직접 수정을 시도할 수 있습니다. 변경 사항을 적용한 후 데이터베이스 테이블 재구성 모드에서 "테스트 및 수정"을 실행합니다. 인덱스는 플랫폼에 의해 새로 생성되며, 희망적으로 오류 없이 생성됩니다.

특히 운이 좋지 않아 오류가 다시 발생하는 경우 먼저 로그 분석부터 전체 과정을 반복해야 합니다. 문제가 있는 테이블이 두 개 이상 있거나 인덱스에 포함된 필드 크기로 문제를 해결할 수 없었을 수 있습니다.

정보베이스의 파일 버전을 사용할 때 "내부 파일의 최대 허용 크기가 초과되었습니다"라는 오류가 자주 나타나는데, 이는 주로 정보베이스 자체의 구현 기능과 관련이 있습니다. 파일 모드. 여기에는 4개의 파일이 포함되어 있습니다:

• 테이블 구조 설명 파일
• 인덱스 파일(메인 파일에서 이동됨)
• 값 파일
• 녹음 파일

내부 파일의 최대 크기는 4GB를 초과할 수 없고, 인덱스의 키 길이는 1920바이트를 초과할 수 없으며, 마지막으로 인덱싱을 위한 필드 수가 256개 필드를 초과할 수 없다는 제한 사항도 적용됩니다. 우리에게 가장 중요한 것은 4GB 파일 크기 제한입니다. 어떻게 그렇게 될수 있니? 당신은 말한다. 10GB와 12GB의 데이터베이스 파일이 있습니다. 예, 맞습니다. 이는 내부 파일이 4GB를 초과하지 않았음을 의미합니다. 감히 당신을 실망시키겠어요. 그럼에도 불구하고 데이터베이스의 최대 크기인 1Cv8.CD 파일 자체는 기본적으로 16GB로 제한되어 있습니다(그러나 이마저도 무시할 수 있음). 이는 로그 주소 지정 제한이기 때문입니다. 파일 시스템 NTFS(16GB보다 큰 조각에서 읽기/쓰기에 실패하면 OS가 파일 시스템의 무결성을 제어할 수 없기 때문에 16GB 파일은 Windows에 복사되지 않습니다.)

이 문제를 해결하려면 어떤 테이블이 많은 공간을 차지하고 있는지 파악해야 합니다. 이렇게 하려면 타사 소프트웨어를 사용할 수 있습니다. 1Cv8.CD 파일 내부를 볼 수 있는 Tool_1CD, 즉 테이블 크기를 결정하고 다음에 업로드할 수 있습니다. XML 형식그리고 훨씬 더.

이를 해결하려면 이 테이블 자체의 크기를 줄이거나 SQL 버전으로 변환해야 합니다. 그럼 구매방법은 SQL 서버꽤 비싸므로 경험적으로 이 테이블을 찾습니다. 일반적으로 이는 큰 표 형식의 부분, 부피가 큰 디렉토리, 특히 축적 레지스터가 있는 "무거운 문서"입니다. 먼저 데이터베이스에서 삭제 표시된 항목을 모두 제거합니다. 그런 다음 합계를 다시 계산합니다(누적 레지스터에 문제가 있으면 도움이 되는 경우도 있음). 잔액 레지스터가 잘못 닫혀 전체 테이블이 급격히 증가할 수 있습니다. 정체된 잔액을 기록하면 최대 몇 GB까지 확보할 수 있습니다.

모든 테이블이 4GB 미만인데도 오류가 계속 발생합니다. 이 상황훨씬 더 어렵습니다. 여기에 구성 matdata의 구조, 즉 인덱싱에 문제가 있습니다. dt 파일에서 정보베이스를 로드할 때 모든 테이블의 데이터가 먼저 로드된 다음 인덱스가 로드됩니다. 인덱스 생성 중 어느 시점에서 오류가 발생하고 후속 인덱스가 생성되지 않아 로딩이 중지되고 오류가 발생합니다. 인덱스 생성 시 어떤 테이블이 실패하는지 확인하려면 다음을 수행하세요.

• 기술 매거진을 켜세요
• 우리는 창조한다 빈 파일예를 들어 다음 내용이 포함된 ogcfg.xml

conf 디렉터리(예: C:\Program Files\1cv82\8.2.19.130\bin\conf)에 넣습니다.

• 로그와 파일이 생성되었는지 확인하고 구성기를 다시 시작하고 다운로드를 다시 시작합니다. 오류가 발생한 후 다음으로 이동하세요. 로그 파일 C:\log\error 폴더에서 폴더를 열고 오류가 표시된 인덱스를 찾으세요.
• 다음으로 데이터베이스 테이블 저장소 구조 프로그램을 사용하여 메타데이터 개체 자체를 찾습니다.
• 그러면 우리는 이 개체의 긴 속성이나 인덱스 구성 실패로 이어지는 속성을 경험적으로 찾고 해결책에 도달할 때까지 계속 시도하고 시도합니다.
• 성공적인 조작 후에 우리는 테스트와 수정을 시작합니다. 결과적으로 모든 인덱스가 다시 작성되고 데이터베이스가 완전히 작동됩니다. 행운을 빌어요!