Database
 sql >> база данни >  >> RDS >> Database

Когато е Спешно

„Имаме спешен проблем, моля, организирайте сесия на WebEx (или NetMeeting, TeamViewer и така нататък), за да го разрешите.“

Въпреки че е разбираемо за клиентите, които имат спешен проблем с производствена система, да виждат WebEx като синоним на бързо решение, ние препоръчваме вместо да се фокусирате върху канала за поддръжка (WebEx срещу телефон срещу имейл и т.н.), да направите следното:

Ако е спешно, изпратете ни регистрационен файл.

–Или–

Ако това е грешка „Неуспешно инициализиране на лицензиране, няма валидни лицензи...“, която пречи на производствената система да функционира, поискайте пробен лиценз на проблемната машина. Това е най-бързият начин да ви накара да работите.

Регистрационни файлове — защо ни трябват и как да ги генерираме

Когато проблемът е спешен, трябва да определите възможно най-бързо дали проблемът е причинен от софтуера на Easysoft. Ако е така, само Easysoft може да реши проблема. Ето защо се нуждаем от дневник, създаден, когато се случи грешката.

(Вариант на тази тема е, когато проблемът е в приложението или базата данни. ODBC поведението в приложенията често е заложено в камък, например някои приложения все още са на ODBC 2.0. Колкото по-популярно е приложението, толкова повече потребители могат да бъдат засегнати от промените към слоя ODBC, което може да увеличи нежеланието на доставчика на приложението да промени приложението, дори ако слоят ODBC се държи неправилно, когато се измерва спрямо спецификацията на ODBC. Базата данни може да промени поведението си, когато е неправилна, но може да се наложи да изчакате известно време за корекция, която решава проблема. Получаването на регистрационен файл също е уместно и в двата случая, тъй като може да сме в състояние да предоставим заобиколно решение, въпреки че основната причина за проблема е в приложението или базата данни. Можем да предоставим решения за неподходящи приложения или бази данни, без да се засягат съществуващите потребители на Easysoft чрез добавяне на опции за конфигурация, които отменят поведението по подразбиране на драйвера.)

Възможно е да се генерират регистрационни файлове от двата компонента на слоя ODBC, драйвера и мениджъра на драйвери. В идеалния случай бихме искали и двете, но най-малкото ни изпратете регистър на драйверите. Регистърът на драйвера улавя диагностична информация, свързана с проблема, и също така ни предоставя информация за вашата настройка (операционна система, архитектура, версия на базата данни и т.н.), което ни улеснява да възпроизведем проблема ви.

Linux и UNIX

За да генерирате лог на драйвери в Linux и UNIX, във вашия източник на данни във файла odbc.ini са ви необходими редовете:

[MYDSN]
Logging = Yes
LogFile = <dir>/easysoft_driver.log

За да генерирате лог на Driver Manager на Linux и UNIX, във файла odbcinst.ini, трябва да добавите тези редове в горната част на файла:

[ODBC]
Trace = Yes
TraceFile = <dir>/unixodbc.log

Важно Заменете

с директория, в която потребителят, изпълняващ приложението ODBC, има разрешение да пише. Например, /tmp. Ако пише в съществуващ регистър, този потребител трябва да има разрешение да пише във файла вместо това.

Windows

За да генерирате лог на драйвери в Windows, отворете съответния източник на данни в ODBC администраторския файл. Диалоговият прозорец за конфигурация на драйвера на ODBC ще съдържа опция за регистриране на драйвери (или нещо с подобно име) и поле, в което да въведете пътя на регистрационния файл. Например C:\Windows\Temp\Easysoft_Driver.log.

За да генерирате лог на Driver Manager в Windows, в администратора на ODBC източник на данни изберете раздела Проследяване. Въведете пътека на регистрационния файл в предоставеното пространство. Например C:\Windows\Temp\Driver_Manager.log. Изберете проследяване в цялата машина за всички потребителски самоличности и след това изберете Стартиране на проследяване сега.

Важно Трябва да посочите директория с регистрационни файлове, в която потребителят, изпълняващ приложението ODBC, има разрешение да пише. Ако пише в съществуващ регистър, този потребител трябва да има разрешение да пише във файла вместо това.

Направете това, когато пускате производствени системи

Препоръчваме ви, дори и да не изпитвате проблеми, да се уверите, че можете да генерирате поне дневник на драйвера като част от процеса на внедряване. Да, разликата между това и възникнал проблем може да бъде месеци или години, в което време може да забравите процедурата, да загубите инструкциите или да смените персонала. Истинската цел е да провери дали приложението ви може да запише дневник, а не самия процес — инструкциите не се променят и са достъпни в мрежата. Правейки това ви дава шанс да разрешите всички проблеми с разрешенията, които предотвратяват генерирането на дневник, преди да възникнат спешни проблеми. (Друга причина да не получавате регистрационен файл е, когато приложението ви не стига до използването на ODBC драйвера, какъвто може да е случаят с Oracle® Heterogeneous Services, ако има проблем при създаването на SID за DG4ODBC (т.е. ако направите грешка при конфигурирането на различните .ora файлове, Oracle® Heterogeneous Services не стига до зареждането на ODBC драйвера и следователно няма да получите регистрационен файл на драйвера).

Кои промени в производствената система засягат драйверите на Easysoft ODBC?

  • Промени в съставните части на машина, които са от значение за лицензирането на Easysoft. Ако това спре производствена система, свържете се с нас за пробен лиценз. Това ще ви накара да работите отново бързо, докато процесът на прехвърляне на лиценз за закупения лиценз тече както трябва.
  • Промени в версията на операционната система. Драйверите на Easysoft ODBC са обвързани с определен набор от операционни системи. Надстройването на машина до различна версия на операционната система (или за машини с Linux такава, базирана на различна версия на ядрото) може да доведе до спиране на функционирането на драйвера. Новата версия на драйвера с пробен лиценз е най-бързият път за възстановяване и работа.
  • Промени във версията на базата данни. Драйверите на Easysoft ODBC може да спрат да функционират, ако целевата база данни бъде надстроена до друга версия. Отново се свържете с нас за по-нова версия на ODBC драйвера, ако това се случи, и използвайте пробен лиценз, за ​​да започнете отново.

Защо поддръжката по имейл е съвместима със спешни заявки за поддръжка

Въпреки че итеративният характер на обмена на имейли може да изглежда в противоречие с бързото разрешаване на спешен проблем, той не трябва да се разглежда като лошо отношение към канали за поддръжка като WebEx (които можем и предлагаме). Пропуските между обмените на имейли ни дават време да:

  • Разгледайте регистрите на обажданията за поддръжка, базирани на подобни проблеми.
  • Пресъздайте настройката си на виртуална машина.
  • Проучете най-добрите практики от доставчика на приложението или базата данни.

Обмените на имейли ни дават дневник, към който можем да се обърнем, ако друг член на екипа за поддръжка трябва да поеме обаждането. Обменът на имейли също предоставя полезен запис, ако трябва да проследите стъпките си в бъдеще.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Митове за ефективността:съкращаването не може да бъде върнато

  2. ERD нотации в моделирането на данни

  3. Как да използвате функцията SQL SUM

  4. Бивш изпълнителен директор на Capgemini, Сунита Рей, се присъединява към ScaleGrid DBaaS, за да разшири корпоративните продажби

  5. SQL ТАБЛИЦА