В този раздел са представени най-разпространените симптоми на проблеми при свързване, срещани при използването на DB2 Connect. При всеки случай получавате:
Забележки:
Понякога SNA кодове на състояние може да се видят при преглед на системните журнали. Дали това е конкретния случай зависи от използваната SNA подсистема, а в някои ситуации може да се наложи да създадете отново проблема, след като активирате SNA трасирането, за да получите информация за кодовете на състояние.
Съобщенията SQL0965 и SQL0969 може да се генерират с редица различни кодове на връщане от DB2 Universal Database за AS/400, DB2 Universal Database за OS/390, DB2 за MVS/ESA и DB2 за VM & VSE.
Когато срещнете някое от двете съобщения, трябва да погледнете оригиналния SQL код в документацията на сървъра на базата данни, генерирал съобщението.
SQL кодът, получен от хост базата данни не може да се преведе. Коригирайте проблема на базата на кода за грешка и след това отново предайте неуспешната команда.
Не е дефинирано или не е дефинирано правилно името на символно предназначение.
Например това може да се случи, когато се използва APPC възел, а името на символно предназначение, определено в DB2 директорията на възлите, не отговаря на CPI-C запис в конфигурацията на локалната APPC комуникационна подсистема.
Друга причина може да е, че на компютъра е инсталиран повече от един SNA стек. Може да се наложи да проверите PATH и LIBPATH, за да се уверите, че най-напред е посочен стекът, който искате да използвате.
SQL1403N Посоченото име на потребител и/или парола са неправилни.
Ако това е така, при необходимост проверете дали е въведена правилната парола в оператора CONNECT.
В противен случай записът в системната директория на базата данни трябва да е въведен неправилно със стойността AUTHENTICATION SERVER (това е стойността по подразбиране, ако изрично не е определен тип за разпознаване). В този случай трябва да запишете отново записа, като използвате тип AUTHENTICATION DCS или CLIENT.
Поддръжката на един или повече комуникационни протокола не успя да се стартира успешно. Основните функции на мениджъра на базата данни обаче са стартирани успешно.
Вероятно TCP/IP протоколът не е стартирал на DB2 Connect шлюза. Преди това може да е имало успешно свързване на клиента.
Ако diaglevel = 4, тогава db2diag.log може да съдържа подобен запис:
1997-05-30-14.09.55.321092 Instance:svtdbm5 Node:000 PID:10296(db2tcpcm) Appid:none common_communication sqlcctcpconnmgr_child Probe:46 DIA3205E адреса на сокет "30090", конфигуриран в TCP/IP сервизния файл и необходим за TCP/IP поддръжката на сървъра се използва от друг процес.
Това предупреждение е симптом, че DB2 Connect, който действа като шлюз за отдалечени клиенти, има проблеми при поддържането на един или повече комуникационни протоколи. Тези протоколи може да са TCP/IP, APPC и други и обикновено съобщението посочва, че не е конфигуриран правилно един от дефинираните на DB2 Connect комуникационни протоколи.
Често причината може да се състои в това, че не е дефинирана или е дефинирана неправилно променливата на профила DB2COMM. Като цяло проблемът се получава в резултат от несъответствие между променливата DB2COMM и имената, дефинирани в конфигурацията на мениджъра на базата данни (например svcename, nname или tpname).
Възможен сценарий е да сте имали преди това успешни свързвания и след това да получите съобщението за грешка SQL5043, без да сте променили конфигурацията. Ако се използва TCP/IP протокол, това може да възникне, когато отдалечената система неправилно прекрати свързването поради някаква причина. Когато това се случи, на клиента свързването може все още да изглежда, като че ли съществува и може да стане възможно да възстановите свързването без други интервенции, като се използват показаните по-долу команди.
Най-вероятно един от клиентите, свързващи се към шлюза, все още има указател на TCP/IP порта. На всеки компютър клиент, който е свързан към шлюза:
SQL30020N Изпълнението не бе успешно поради разпределена протоколна грешка (Distributed Protocol Error), която ще повлияе на успешното изпълнение на следващите команди и SQL оператори.
При тази грешка трябва да се обърнете към сервиз.
Проверете db2dump директорията за ffdc dump (pid.000). След това форматирайте този dump файл с db2fdump и в получения файл потърсете "ERROR". Тук може да е посочено MVS ABEND. В този случай проверете MVS конзолата за допълнителна информация и проверете кода abend в DB2 Ръководството за MVS съобщения и кодове.
SQL30060N "<ID-за-оторизация>" не притежава необходимите права, за да изпълни операцията <операция>".
При свързване към DB2 за MVS или DB2 за OS/390 не са обновени правилно комуникационните таблици на базата данни (CDB). Обърнете се към:
Свързване към грешен хост или AS/400 сървър на база данни - не е намерена база данни приемник.
Може да е определено грешно име на сървър на базата данни в записа на DCS директорията. Когато това се случи, към приложението се връща SQLCODE -30061.
Проверете DB2 възела, базата данни и записите в директорията за DCS. Полето с името на базата данни приемник в записа на директорията за DCS трябва да съответства на името на базата данни, което зависи от платформата. Например за DB2 Universal Database за OS/390 база данни използваното име трябва да е същото като посоченото в полето "LOCATION=locname" в Boot Strap Data Set (BSDS), което също така се осигурява и в съобщението DSNL004I (LOCATION=location), когато се стартира помощното средство за разпределени данни DDF (Distributed Data Facility). Вижте също Концепцията база данни и Обновяване на директории на бази данни.
Ръководството DB2 Connect Бърз старт освен това съдържа примери, които показват как да обновите DB2 каталозите. Вижте раздела "Обновяване на DB2 директории" във всяка глава, която описва SNA конфигурацията или вижте главата "Конфигуриране на хост или AS/400 база данни за DB2 Connect" и раздела "Конфигуриране на TCP/IP свързване".
Правилните команди за APPC или APPN възел са:
db2 catalog appc node <име_възел> remote <име_симв_назн> security program db2 catalog dcs database <локално_име> as <истинско_db_име> db2 catalog database <локално_име> as <псевдоним> at node <име_на_възел> authentication dcs
Правилните команди за TCP/IP възел са:
db2 catalog tcpip node <име_на_възел> remote <адрес_или_име_на_хост> server <номер_на_порт_или_име_на_услуга> db2 catalog dcs database <локално_име> as <истинско_db_име> db2 catalog database <локално_име> as <псевдоним> at node <име_на_възел> authentication dcs
След това за да се свържете към базата данни, изпълнявате:
db2 connect to <псевдоним> user <име_на_потребител> using <парола>
Генерира се съобщение SQL30073 с код на връщане 119C. Това се получава, когато сървърът на базата данни приемник не поддържа кодовата страница, използвана от DB2 клиента (който преминава през DB2 Connect). Кодовата таблица се получава от конфигурацията на операционната система, в която работи DB2 клиента.
Вижте Ръководство за администриране за допълнителна информация.
Често този проблем може да се разреши, като се инсталира корекция в сървъра на базата данни приемник. Свържете се със съответната сервизна организация, за да получите и приложите корекцията, която може да ви препоръчат при този симптом.
Като временно решение потребителят може да замени кодовата страница по подразбиране, като настрои променливата на обкръжението DB2CODEPAGE. Проверете кода на географското положение или определете DB2CODEPAGE=850.
На UNIX платформи потребителят може да има възможност да превключи към различна кодова страница, ако въведе различна стойност за променливата на обкръжението LANG.
Симптомът е следното съобщение плюс SNA код на състояние:
db2 connect to <име на база данни> user <id на потребител> Въведете парола за <id на потребител>: SQL30081N Открита е комуникационна грешка. Използван комуникационен протокол: "APPC". Използван комуникационен API: "CPI-C". Място, където е открита грешката: "". Комуникационната функция, открила грешката: "cmallc". Кодове за грешка, специфични за протокола: "1", "*", "0x10030021". SQLSTATE=08001
В този пример кодът на състояние е 10030021.
Най-често срещаните кодове на състояния, свързани с това съобщение за грешка, както и предлаганото решение при всеки отделен случай, са както следва:
SQL30081N с код на връщане 1 и sna код на състояние 0877002C
Определено е грешно мрежово име.
SQL30081N с код на връщане 1 и SNA код на състояние ffff0003
Определен е грешен MAC адрес или не е активна SNA връзката.
SQL30081N с код на връщане 1 и SNA код на състояние 10030021
Има несъответствие между тип на LU.
SQL30081N с код на връщане 1 и SNA код на състояние 084B6031
MAXDBAT в DSNZPARM (в DB2 за MVS или DB2 за OS/390 хост) е установен на 0
Други предположения:
Получено е съобщение SQL30081N с код на връщане 2 и SNA код на състояние 08120022.
Параметърът NUMILU на NCP (хост страната на връзката) може да е установен на стойността по подразбиране (0). Проверете това. При необходимост променете NCP дефиницията и опитайте отново, след като влезе в сила направената промяна.
Симптомът е следното съобщение (SNA код на състояние не е необходим в този случай):
db2 connect to <база данни> user <id на потребител> SQL30081N Открита е комуникационна грешка. Използван комуникационен протокол: "APPC". Използван комуникационен API: "CPI-C". Място, където е открита грешката: "". Комуникационната функция, открила грешката: "cmsend". Кодове за грешка, специфични за протокола: "9", "*", "0x10086021". SQLSTATE=08001
Проблемът е, че в DB2 Connect системата не е дефинирано правилно името на Транзакционната програма. Например, може да сте обновили SNA конфигурацията, но все още да не сте я проверили на DB2 Connect шлюза. За допълнителни подробности се обърнете към ръководствата DB2 Connect Enterprise Edition за OS/2 и Windows - Бърз старт или DB2 Connect Personal Edition: Бърз старт.
Симптомът е следното съобщение (SNA код на състояние не е необходим в този случай):
SQL30081N Открита е комуникационна грешка. Използван комуникационен протокол: "APPC". Използван комуникационен API: "CPI-C". Място, където е открита грешката: "". Комуникационната функция, открила грешката: "cmrcv". Кодове за грешка, специфични за протокола: "10", "*", "*". SQLSTATE=08001
Проверете дали DB2 е инсталирана правилно.
Ако използвате DB2 Connect за OS/2 шлюз, може да видите следното, ако TP името не е дефинирано правилно:
Кодове за грешка, специфични за протокола: "10", "*", "0x084C0000". SQLSTATE=08001
Например в CM/2 в този случай трябва да е дефинирано както следва:
Име на транзакционна програма = 'tpname' (дефинирано от потребителя) Пътека и име на файл на OS/2 програма = notused
и (на следващия екран за CM/2 конфигурация)
Тип представяне - фонов режим Тип работа - На опашка, предварително заредени оператори
SQL30081N Открита е комуникационна грешка. Използван комуникационен протокол: "APPC". Използван комуникационен API: "CPI-C". Място, където е открита грешката: "". Комуникационната функция, открила грешката: "xcstp". Кодовете за грешка на протокола са: "20", "*", "*". SQLSTATE=08001 SQLSTATE=08001
Проверете дали SNA подсистемата е стартирала на DB2 Connect
Получено е съобщение SQL30081N с код на връщане 27 и SNA код на състояние 800Axxxx.
Прекалено голям VTAM PIU (Path Information Unit).
SQL30081N Открита е комуникационна грешка. Използван комуникационен протокол: "TCP/IP". Използван комуникационен API: "SOCKETS". Място, където е открита грешката: "". Комуникационната функция, открила грешката: "connect". Кодове за грешка, специфични за протокола: "79", "*", "*". SQLSTATE=08001
Тази грешка може да възникне в случай, че отдалечен клиент не успее да се свърже към DB2 Connect шлюз. Освен това може да възникне при свързване от DB2 Connect шлюз към хост.
db2 update dbm cfg using diaglevel 4След като спрете и рестартирате DB2, погледнете във файла db2diag.log, за да проверите дали са стартирали DB2 TCP/IP комуникациите. Би трябвало да видите резултат, подобен на показания:
1998-02-03-12.41.04.861119 Instance:svtdbm2 Node:00 PID:86496(db2sysc) Appid:none common_communication sqlcctcp_start_listen Probe:80 DIA3000I Поддръжката на "TCPIP" протокол е стартирана успешно.
SQL30081N Открита е комуникационна грешка. Използван комуникационен протокол: "TCP/IP". Използван комуникационен API: "SOCKETS". Място, където е открита грешката: "9.21.85.159". Комуникационна функция, открила грешката: "send". Кодове за грешка, специфични за протокола: "10032", "*", "*". SQLSTATE=08001
Това съобщение за грешка може да се получи, когато се опитвате да се откачите от машина, където TCP/IP комуникациите вече са прекъснати. Отстранете проблема с TCP/IP подсистемата.
На повечето машини начинът да се коригира проблема, е просто да рестартирате TCP/IP протокола за машината. Понякога може да е необходимо да се рециклира цялата машина.