Data Management:Data Disaster Recovery (DBS) için yaygın hatalar ve sorun giderme

Hatalar

Yedekleme zamanlaması yapılandırma hataları

Kaynak veritabanı bağlantı testi başarısızlığı

Yedekleme ve geri yükleme ön kontrol hataları

• Kaynak veritabanı bağlantı denetimi başarısızlığı

• Kaynak veritabanı izinleri denetimi başarısızlığı

• OSS bağlantı denetimi başarısızlığı

• Kaynak veritabanı binlog durumu denetimi başarısızlığı

• Kaynak veritabanı ikili günlük biçimi denetimi başarısızlığı

• binlog_row_image parametresi denetimi başarısızlığı

• Kaynak veritabanı sunucu kimliği denetimi başarısızlığı

• Kaynak veritabanı binlog dosyası denetimi başarısızlığı

• Depolama altyapısı denetimi başarısızlığı

• MySQL parola biçimi denetimi başarısızlığı

• Nesne adı çakışmaları

Gelişmiş indirme görevi hataları

• DBS-DownloadTask.Region

• DBS-DownloadTask.InstanceInfo

• DBS-DownloadTask.DbType

• DBS-DownloadTask.CustinId

• DBS-DownloadTask.CustinName

• DBS-DownloadTask.user

• DBS-DownloadTask.Instance.Version

• DBS-DownloadTask.Instance.Storage.Type

• DBS-DownloadTask.Instance.Param

• DBS-DownloadTask

Görev yürütme hataları

• DBS-000000

• DBS-000001

• DBS-000002

• DBS-000003

• DBS-000004

• DBS-000005

• DBS-000006

• DBS-000007

• DBS-002003

• DBS-002009

• DBS-102001

• DBS-105001

• DBS-106001

• DBS-202002

• DBS-203101

• DBS-203102

• DBS-203103

• DBS-203104

• DBS-203201

• DBS-203202

• DBS-203203

• DBS-203205

• DBS-203206

• DBS-203240

• DBS-203301

• DBS-203302

• DBS-301005

• DBS-301502

• DBS-301503

• DBS-301504

• DBS-301505

• DBS-302035

• DBS-400001

• DBS-999999 veya hata kodu yok

Yedekleme zamanlaması hataları

Kaynak veritabanı bağlantısı başarısız oldu

Senaryo: Bir yedekleme zamanlaması yapılandırırken bağlantı testi başarısız olur.

Yedekleme ve geri yükleme ön kontrol hataları

Kaynak veritabanı bağlantısı başarısız oldu

Bu hata, bir yedekleme zamanlaması veya geri yükleme görevi için ön kontrol sırasında oluşur.

Çözüm: Yedekleme zamanlaması yapılandırması için yaygın hatalar bölümünde açıklanan kaynak veritabanı bağlantı testi başarısız çözümüne bakın.

Veritabanı izni denetimi başarısız oldu

Senaryo: Bu hata, bir yedekleme zamanlaması veya geri yükleme görevi için ön kontrol sırasında oluşur.

OSS denetimi başarısız oldu

Senaryo: Bir yedekleme zamanlaması veya geri yükleme görevi için ön kontrol başarısız olur.

Kaynak veritabanı binlog ön kontrolü başarısız oldu

Senaryo: Kaynak veritabanı binlog ön kontrolü başarısız olur.

Çözüm: Bu ön kontrol, kaynak veritabanında ikili günlük özelliğinin etkin olduğunu doğrular. Başarısız bir ön kontrol, özelliğin devre dışı bırakıldığını gösterir. Bu sorunu çözmek için şu adımları izleyin.

1. Kendi yönetiminizdeki MySQL kaynak veritabanınızı barındıran sunucuda oturum açın.

2. MySQL yapılandırma dosyası my.cnf içindeki aşağıdaki ayarları değiştirin.

   log_bin=mysql_bin
   binlog_format=row
   server_id=2 # Must be an integer greater than 1. This is an example value.
   binlog_row_image=full # This parameter is required if the source database runs MySQL 5.6 or later.

   Not

   my.cnf yapılandırma dosyasının varsayılan yolu /etc/my.cnf şeklindedir. Gerçek yol, kurulumunuza bağlı olarak değişebilir.

3. Aşağıdaki komutları çalıştırarak MySQL hizmetini yeniden başlatın.

   [$Mysql_Dir]/bin/mysqladmin -u root -p shutdown
   [$Mysql_Dir]/bin/safe_mysqld &

   Not

   [$Mysql_Dir] ifadesini MySQL kurulum diziniyle değiştirin.

4. Kendi yönetiminizdeki MySQL kaynak veritabanınızda oturum açın ve ikili günlük özelliğinin etkin olduğunu onaylamak için aşağıdaki SQL ifadesini çalıştırın.

   SHOW variables LIKE '%log_bin%';

   Aşağıdaki çıktı, özelliğin etkin olduğunu gösterir:

   MariaDB [pro1]> show variables like '%log_bin%';
   +----------------------------------+-------+
   | Variable_name                    | Value |
   +----------------------------------+-------+
   | log_bin                          | ON    |
   | log_bin_trust_function_creators  | OFF   |
   | sql_log_bin                      | ON    |
   +----------------------------------+-------+
   3 rows in set (0.00 sec)

5. DBS ön kontrolünü tekrar çalıştırın.

Kaynak binlog biçimi denetimi başarısız oldu

Senaryo: Kaynak veritabanının ikili günlük biçimi için ön kontrol başarısız olur.

Çözüm: Bu kontrol, kaynak veritabanının ikili günlük biçiminin ROW olarak ayarlandığını doğrular. Ön kontrol başarısız olursa, biçim ROW olarak ayarlanmamıştır. Bu sorunu çözmek için şu adımları izleyin.

1. Kendi yönetiminizdeki MySQL kaynak veritabanınızın çalıştığı sunucuda oturum açın.

2. MySQL yapılandırma dosyası my.cnf dosyasını değiştirerek binlog_format parametresini ROW olarak ayarlayın.

   log_bin=mysql_bin
   binlog_format=ROW  # Set the binary log format to ROW.
   server_id=2 # This must be an integer greater than 1. This is an example value.
   binlog_row_image=full # This parameter is required if the source database runs MySQL 5.6 or later.

   Not

   my.cnf yapılandırma dosyasının varsayılan yolu /etc/my.cnf şeklindedir. Gerçek yol, kurulumunuza bağlı olarak değişebilir.

3. Aşağıdaki komutları çalıştırarak MySQL'i yeniden başlatın.

   [$Mysql_Dir]/bin/mysqladmin -u root -p shutdown
   [$Mysql_Dir]/bin/safe_mysqld &

   Not

   [$Mysql_Dir] ifadesini MySQL kurulum diziniyle değiştirin.

4. Kendi yönetiminizdeki MySQL kaynak veritabanınızda oturum açın ve ikili günlük biçiminin ROW olarak ayarlandığını doğrulamak için aşağıdaki SQL ifadesini çalıştırın.

   SHOW variables LIKE "%binlog_format%";

   Aşağıdaki çıktı, ikili günlük biçiminin ROW olarak ayarlandığını gösterir:

   MariaDB [(none)]> show variables like "%binlog_format%";
   +-----------------+-------+
   | Variable_name   | Value |
   +-----------------+-------+
   | binlog_format   | ROW   |
   +-----------------+-------+
   1 row in set (0.01 sec)

5. DBS ön kontrolünü tekrar çalıştırın.

binlog_row_image denetimi başarısız oldu

Senaryo: Kaynak veritabanının binlog_row_image parametresi için ön kontrol başarısız olur.

Çözüm: Bu kontrol MySQL 5.6 veya üstü sürümler için geçerlidir. binlog_row_image parametresinin full olarak ayarlanıp ayarlanmadığını doğrular. Başarısızlık, ikili günlüğün tam satır görüntülerini kaydetmediğini gösterir. Bu sorunu çözmek için şu adımları izleyin.

1. Kendi yönetiminizdeki MySQL kaynak veritabanınızı barındıran sunucuda oturum açın.

2. MySQL my.cnf yapılandırma dosyasını değiştirerek binlog_row_image parametresini full olarak ayarlayın.

   log_bin=mysql_bin
   binlog_format=row  # Set the binlog format to row.
   server_id=2 # Must be an integer greater than 1. This is an example value.
   binlog_row_image=full # This parameter is required if the source database is MySQL 5.6 or later.

   Not

   my.cnf yapılandırma dosyasının varsayılan yolu /etc/my.cnf şeklindedir. Gerçek yol değişebilir.

3. MySQL'i yeniden başlatmak için aşağıdaki komutları çalıştırın.

   [$Mysql_Dir]/bin/mysqladmin -u root -p shutdown
   [$Mysql_Dir]/bin/safe_mysqld &

   Not

   [$Mysql_Dir] ifadesini MySQL kurulum dizininizle değiştirin.

4. Kendi yönetiminizdeki MySQL kaynak veritabanınızda tekrar oturum açın ve binlog_row_image parametresinin full olarak ayarlandığını onaylamak için aşağıdaki SQL ifadesini çalıştırın.

   show variables like "%binlog_row_image%";

5. Ön kontrolü tekrar çalıştırın.

Kaynak veritabanı server_id denetimi başarısız oldu

Senaryo: Kaynak veritabanı için server_id denetimi başarısız olur.

Çözüm: Bir MySQL artımlı veri geçişi görevi başlattığınızda, ön kontrol aşamasında kaynak veritabanında bir server_id denetimi gerçekleştirilir. Aşağıdaki bölümde, kendi yönetiminizdeki bir MySQL kaynak veritabanı için server_id denetimi başarısızlığının nasıl çözüleceği açıklanmaktadır.

1. Kendi yönetiminizdeki MySQL veritabanı sunucusunda oturum açın ve server_id parametresinin değerini kontrol etmek için aşağıdaki SQL ifadesini çalıştırın.

   SHOW variables LIKE '%server_id%';

2. server_id parametresi 1'den büyük bir tamsayıya ayarlanmalıdır. server_id değerini değiştirmek için aşağıdaki SQL ifadesini çalıştırın.

   SET global server_id=[$ID];

   Not

   • [$ID] ifadesini 1'den büyük bir tamsayıyla değiştirin. Kimliğin benzersiz olduğundan ve başka bir veritabanı sunucusu tarafından kullanılmadığından emin olun.

   • Kendi yönetiminizdeki veritabanı birincil/ikincil moddaysa, bu değişikliğin birincil-ikincil çoğaltmayı etkilemediğinden emin olun.

   • Bu ifadeyi çalıştırdıktan sonra, yapılandırma dosyasındaki server_id değerini de değiştirmeniz gerekir. Aksi takdirde, bir yeniden başlatma bu değişikliği geri alır.

3. Ön kontrolü tekrar çalıştırın.

Kaynak veritabanı ikili günlük denetimi başarısız oldu

Senaryo: Kendi yönetiminizdeki bir MySQL veritabanı için bir yedekleme zamanlaması başlattığınızda, ikili günlük denetimi başarısız olur.

Çözüm:

1. İkili günlüğün etkin olup olmadığını kontrol etmek için MySQL CLI'da aşağıdaki komutu çalıştırın:

   SHOW variables LIKE 'log_%';

2. Çıktıda 'log_bin' değeri 'OFF' ise, ikili günlük devre dışıdır. Bunu bir Linux sisteminde etkinleştirmek için 'vim' komutunu kullanarak my.cnf yapılandırma dosyasını düzenleyin:

   mysql> show variables like 'log_%';
   +-----------------------------------------+---------------------+
   | Variable_name                           | Value               |
   +-----------------------------------------+---------------------+
   | log_bin                                 | OFF                 |
   | log_bin_basename                        |                     |
   | log_bin_index                           |                     |
   | log_bin_trust_function_creators         | OFF                 |
   | log_bin_use_v1_row_events               | OFF                 |
   | log_builtin_as_identified_by_password   | OFF                 |
   | log_error                               | /var/log/mysqld.log |
   | log_error_verbosity                     | 3                   |
   | log_output                              | FILE                |
   | log_queries_not_using_indexes           | OFF                 |
   | log_slave_updates                       | OFF                 |
   | log_slow_admin_statements               | OFF                 |
   | log_slow_slave_statements               | OFF                 |
   | log_statements_unsafe_for_binlog        | ON                  |
   | log_syslog                              | OFF                 |
   | log_syslog_facility                     | daemon              |
   | log_syslog_include_pid                  | ON                  |
   | log_syslog_tag                          |                     |
   | log_throttle_queries_not_using_indexes  | 0                   |
   | log_timestamps                          | UTC                 |
   | log_warnings                            | 2                   |
   +-----------------------------------------+---------------------+
   21 rows in set (0.00 sec)

   # Open the /etc/my.cnf file.
   vim /etc/my.cnf
   
   # Press i to enter edit mode.
   # Add the following parameters.
   log_bin = mysql_bin
   binlog_format = row
   server_id = 2
   expire_logs_days = 30
   
   # Press Esc to exit edit mode, and then enter :wq to save your changes and exit.

3. Kendi yönetiminizdeki MySQL veritabanını yeniden başlatın.

   systemctl restart mysqld

   Not

   Yapılandırma dosyası değişiklikleri yalnızca veritabanı örneğini yeniden başlattıktan sonra etkili olur. Kendi yönetiminizdeki veritabanı örneğini yoğun olmayan saatlerde yeniden başlatmanızı öneririz.

   MySQL yeniden başladıktan sonra, ikili günlüğün etkin olduğunu doğrulamak için 1. Adımdaki komutu çalıştırın. Ardından, yedekleme zamanlamasını yeniden başlatın.

Depolama altyapısı denetimi başarısız oluyor

Çözüm: Bu denetim, kaynak veritabanının artımlı veri geçişi için desteklenmeyen bir depolama altyapısı kullanıp kullanmadığını belirler. MySQL'den MySQL'e artımlı veri geçişi FEDERATED ve MRG_MyISAM depolama altyapılarını desteklemez. Denetim başarısız olursa, geçirilecek tabloların bu depolama altyapılarından birini kullandığı anlamına gelir.

MySQL parola biçimi denetimi

Senaryo: Bir yedekleme zamanlaması veya geri yükleme görevi için ön kontrol başarısız olur.

Çözüm: Eski bir parola biçimi algılandı. Bkz. old_passwords.

Nesne adı çakışması

Senaryo: Geri yüklemek için seçtiğiniz nesne, hedefteki mevcut bir veritabanı nesnesiyle aynı ada sahiptir.

Gelişmiş indirme görevleri için yaygın hatalar

Belirti: ApsaraDB RDS konsolunda bir örnek için Backup and Restoration ayrıntılar sayfasında, gelişmiş bir indirme görevi oluşturmak üzere Download Instance Backup File düğmesine tıklayamazsınız.

DBS-DownloadTask.Region

Neden: Özellik mevcut bölgede kullanılamıyor.

Çözüm: Bu özelliği talep etmek için DingTalk grubu (ID: 35585947) üzerinden destek ekibimizle iletişime geçin.

DBS-DownloadTask.InstanceInfo

Neden: İndirme hizmeti ApsaraDB RDS örneği hakkında bilgi alamadı.

Çözüm: ApsaraDB RDS örneğinin anormal bir durumda olup olmadığını veya silinip silinmediğini kontrol edin.

DBS-DownloadTask.DbType

Neden: ApsaraDB RDS örneğinin veritabanı motoru gelişmiş indirme özelliğini desteklemiyor.

Çözüm: Gelişmiş indirme özelliği yalnızca ApsaraDB RDS for MySQL ve ApsaraDB RDS for PostgreSQL için kullanılabilir.

DBS-DownloadTask.CustinId

Neden: Bu özellik ApsaraDB RDS örneğiniz için henüz etkinleştirilmedi.

Çözüm: Bu özellik aşamalı olarak yayınlanıyor olabilir ve örneğiniz için henüz kullanılamıyor durumdadır. Gereksinimlerinizi belirterek müşteri destek grubu (DingTalk grubu ID: 35585947) üzerinden teknik destek ile iletişime geçebilirsiniz.

DBS-DownloadTask.CustinName

Neden: Bu özellik aşamalı olarak kullanıma sunulduğu için ApsaraDB RDS örneğiniz için henüz etkinleştirilmedi.

Çözüm: Erişim talebinde bulunmak için DingTalk grubu (ID: 35585947) üzerinden teknik destek ile iletişime geçin.

DBS-DownloadTask.user

Neden: Bu özellik ApsaraDB RDS örneğiniz için etkin değil.

Çözüm: Bu özellik aşamalı bir yayın döneminde olabilir ve örneğiniz için henüz kullanılamıyor durumdadır. Talebinizi göndermek için DingTalk grubu (Grup ID: 35585947) üzerinden teknik destek ile iletişime geçebilirsiniz.

DBS-DownloadTask.Instance.Version

Olası neden: ApsaraDB RDS örneğinin küçük motor sürümü eskimiş.

DBS-DownloadTask.Instance.Storage.Type

Neden: ApsaraDB RDS örneğinizin depolama türü gelişmiş indirme özelliğini desteklemiyor.

Çözüm: Yalnızca cloud disk kullanan örnekler gelişmiş indirme özelliğini destekler. ApsaraDB RDS örneğinizin Basic Information sayfasına giderek Storage Type değerinin cloud disk olduğunu doğrulayın.

DBS-DownloadTask.Instance.Param

Neden: ApsaraDB RDS örneğindeki yanlış parametre ayarları nedeniyle gelişmiş indirme özelliği kullanılamıyor.

Çözüm: ApsaraDB RDS örneğinizin küçük motor sürümünün eskimediğinden ve yedekleme verilerinin şifrelenmemiş olduğundan emin olun. Ayrıntılar için bkz. Gelişmiş indirme ön koşulları.

DBS-DownloadTask

Olası neden: ApsaraDB RDS örneği gelişmiş indirme özelliğini desteklemiyor.

Yaygın görev hataları

DBS-000000

Senaryo: Fiziksel tam yedekleme başarısız olur.

Neden: Hizmet, yedekleme zamanlamasında belirtilen yedekleme ağ geçidine bağlanamaz ve görev maksimum 100 yeniden deneme sınırına ulaştığında başarısız olur. Yaygın bir neden, çevrimdışı bir yedekleme ağ geçididir.

DBS-000000 Scheduling failed, the task has been retried, exceeding the maximum limit

Çözüm:

1. Hedef yedekleme zamanlamasının Configure Task sayfasında yedekleme ağ geçidi durumunun Offline olup olmadığını kontrol edin.

2. Sol gezinme bölmesinde Backup Gateways seçeneğine tıklayın. Backup Gateways sayfasında, hedef ağ geçidini Backup Gateway Hostname değerine göre bulun. IP adresinin, ana bilgisayar adının ve son heartbeat zamanının doğru olduğunu doğrulayın. Geçerli durum Status sütununda gösterilir.

3. Yedekleme ağ geçidinin yüklü olduğu sunucunun çalışma durumunu ve ağ yapılandırmasını kontrol edin.

   Sunucu düzgün çalışıyorsa ve ağ bağlantısı kararlıysa, yedekleme ağ geçidini yeniden başlatın. Yedekleme ağ geçidinin bazı eski sürümlerinde güvenlik açıkları olabilir. Yedekleme ağ geçidini yükseltmenizi öneririz. Daha fazla bilgi için bkz. yedekleme ağ geçidini yükseltme.

   Not

   Bu adımları tamamladıktan sonra yedekleme ağ geçidi hala başlatılamıyorsa, DingTalk grubu üzerinden teknik destek ile iletişime geçin.

DBS-000001

Senaryo: Mantıksal tam yedekleme görevi başarısız olur.

Neden: Görev, maksimum yeniden deneme sınırını aştıktan sonra başarısız oldu.

DBS-000001 Scheduling failed, the task has been retried, exceeding the maximum limit or hang more than 7 hours

Çözüm: Görevi yeniden başlatın ve durumunu izleyin. Hata devam ederse, DingTalk grubu üzerinden destek ile iletişime geçin.

DBS-000002

Senaryo: Mantıksal şema yedeklemesi veya tam yedekleme sırasında başarısızlık.

Neden: Kullanılabilir hizmet kaynağı yok.

DBS-000002 Because the current system has no available resources, scheduling timeout...

Çözüm: Başarısızlığı teşhis etmek için DingTalk grubu üzerinden teknik destek ile iletişime geçin.

DBS-000003

Senaryo: Bir bağlantı görevi başarısız olur.

Neden: Görev için hiçbir örnek bulunamadı.

DBS-000003  No instance was found for this task

Çözüm: Yardım almak için DingTalk grubu üzerinden teknik destek ile iletişime geçin.

DBS-000004

Senaryo: Fiziksel bir yedekleme veya geri yükleme görevi başlatılamaz.

Neden: Fiziksel yedekleme veya geri yükleme görevi planlanırken bir özel durum oluştu.

DBS-000004 + [Detailed error message]

Çözüm: Görevi yeniden deneyin. Hata devam ederse, DingTalk grubu üzerinden teknik destek ile iletişime geçin.

DBS-000005

Senaryo: Mantıksal bir yedekleme veya geri yükleme görevi başlatılamaz.

Neden: Bir zamanlama hatası oluştu.

DBS-000005 + [Detailed error message]

Çözüm: Görevi yeniden deneyin. Hata devam ederse, DingTalk grubu üzerinden teknik destek ile iletişime geçin.

DBS-000006

Senaryo: Fiziksel bir yedekleme veya geri yükleme görevi başlamadan önce zaman aşımına uğrar.

Neden: Görev, bir zamanlama hatası veya kaynak sorunu nedeniyle başlatılamaz.

DBS-000006 + [Detailed error message]

Çözüm: Başarısız olan görevi yeniden deneyin. Görev tekrar başarısız olursa, DingTalk grubu üzerinden teknik destek ile iletişime geçin.

DBS-000007

Senaryo: Mantıksal bir yedekleme veya geri yükleme görevi başlatılırken zaman aşımı oluşur.

Neden: Görev başlatma sırasında bir zamanlama hatası veya kaynak sorunu oluşur.

DBS-000007 + [Detailed error message]

Çözüm: Başarısız olan görevi yeniden başlatın. Hata devam ederse, müşteri grubu üzerinden destek ile iletişime geçin.

DBS-002003

Senaryo: Bir SQL Server veritabanının yerel fiziksel tam yedeklemesi başarısız olur.

Neden: Veritabanına erişilemiyor. Bu durum, gereken veritabanı izinlerine sahip olmadığınızda, veritabanı mevcut olmadığında veya durumu erişim denetimlerine izin vermediğinde oluşabilir.

DBS-002003, message:User does not have permission to alter database 'UFTData305999_000002', the database does not exist, or the database is not in a state that allows access checks..
DBS-002003, message:User does not have permission to alter database 'UFDATA
DBS-002003, message:User 'guest' does not have permission to run DBCC LOGIN
DBS-002003 ["The TCP/IP connection to the host localhost, port 1433 has failed. Error: "Connection refused: connect. Verify the connection properties, check that an instance of SQL Server is running on the host and accepting TCP/IP connections at the port, and that no firewall is blocking TCP connections to the port."."].

Çözüm:

1. Veritabanının çevrimiçi olduğunu doğrulayın. Çevrimdışıysa, çevrimiçi duruma getirin.

2. Veritabanı geri yükleniyorsa, görevi yeniden başlatmadan önce geri yüklemenin tamamlanmasını bekleyin.

3. Bağlantının şifrelenip şifrelenmediğini kontrol edin.

   SELECT encrypt_option FROM sys.dm_exec_connections WHERE session_id = @@SPID

4. Transport Layer Security (TLS) şifrelemesinin etkin olup olmadığını görmek için kayıt defterini kontrol edin.

   HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.x\Server
   ## 1.x indicates the version of TLS, for example, 1.0, 1.1, 1.2, or 1.3.

   Bu kayıt defteri girdisi mevcutsa ve değeri 1 ise, TLS şifrelemesi etkindir. TLS şifrelemesini devre dışı bırakmak için şu adımları izleyin:

   1. Kayıt defteri girdisinin değerini 1'den 0'a değiştirin.

   2. Windows Başlangıç arama kutusunda Internet Options seçeneğini arayın. Advanced sekmesine tıklayın, aşağı kaydırın, Use TLS 1.0, Use TLS 1.1, Use TLS 1.2 ve Use TLS 1.3 onay kutularının işaretini kaldırın ve ardından OK seçeneğine tıklayın. Bilgisayarınızı yeniden başlattıktan sonra değişiklikler etkili olur.

   3. Bilgisayarınızı yeniden başlatın ve yedekleme görevini tekrar deneyin.

DBS-002009

Senaryo: Şema yedeklemesi başarısız olur.

DBS-002009 com.alibaba.dts.exception.message.LocalException: DBS-002009 Connect db jdbc:mysql://*:*?useSSL=false timeout.

Çözüm: Sorun giderme için bu konudaki "Kaynak veritabanına bağlantı testi başarısız oldu" bölümüne bakın. İlk olarak, bağlantının veritabanı hesap adı, parola, hesap izinleri, kaynak IP veya güvenlik duvarı kurallarındaki değişiklikler nedeniyle başarısız olup olmadığını kontrol edin. Bu ayarlar değişmediyse, ağ eşlemelerini kontrol edin ve yeniden oluşturun:

1. Hedef yedekleme zamanlamasının Configure Task sayfasına gidin ve Edit Backup Objects seçeneğine tıklayın.

2. Veritabanı hesap adı ve parolasını tekrar girin ve ardından Test Connection seçeneğine tıklayın.

   Bağlantı testi sırasında sistem gerektiğinde arka planda ağ eşlemelerini kontrol eder ve yeniden oluşturur. Yapılandırma sayfası database account name ve password alanlarını içerir. connection method için unencrypted connection veya SSL secure connection seçebilirsiniz.

   Not

   Doğru kaynak veritabanı yapılandırmasına rağmen bağlantı testi hala başarısız olursa, DingTalk grubu üzerinden teknik destek ile iletişime geçin.

3. Bağlantı testi başarılı olduktan sonra Next seçeneğine tıklayın.

4. Yedeklenecek veritabanlarını ve tabloları tekrar seçin ve yedekleme zamanlamasını güncellemek için Save seçeneğine tıklayın.

   Save seçeneğine tıkladıktan sonra yeni yapılandırma etkili olur ve hemen bir yedekleme başlar. Bu işlem kaynak veritabanınızı ve iş yüklerinizi etkileyebilir. Yapılandırmayı yoğun olmayan saatlerde değiştirmenizi öneririz.

DBS-102001

Senaryo: Çeşitli durumlarda oluşabilir.

Neden: Yedekleme tamamlanır, ancak yedekleme nesnelerinin meta veritabanına bildirilmesi başarısız olur. Bu, şema yedeklemelerinde yaygın bir sorundur. Görevi yeniden denemek sorunu çözebilir.

DBS-102001 java.lang.IllegalStateException: The RecordSplit must be in FAILED or SUCCE

Çözüm: Görevi yeniden deneyin. Sorun devam ederse, DingTalk grubu üzerinden teknik destek ile iletişime geçin.

DBS-105001

Senaryo: Bu hata çeşitli işlemler sırasında oluşabilir.

Neden: Meta veritabanına heartbeat bildirimi zaman aşımına uğrar.

DBS-105001 com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: Could not create connection to database server. Attempted reconnect 3 times. Giving up.
com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: Too many connections

Çözüm: Görevi yeniden deneyin. Sorun devam ederse, DingTalk grubu üzerinden teknik destek ile iletişime geçin.

DBS-106001

Senaryo: Bu hata çeşitli aşamalarda oluşabilir.

Olası Neden: Bir OSS iç hatası.

DBS-106001 java.lang.RuntimeException: com.taobao.amp.error.RequestError: Please conta...
DBS-106001  error task count 2 reached to the max limit.

Çözüm: Yardım almak için DingTalk grubu üzerinden bizimle iletişime geçin.

DBS-202002

Senaryo: Bir görev, müşteriye ait bir OSS paketine veri yedekleyemez.

Neden: OSS hizmeti, geciken ödeme nedeniyle askıya alındı.

DBS-202002 java.io.IOException: com.taobao.amp.error.RequestError: UserDisable

DBS-203101

Senaryo: Bir SQL Server veritabanının yerel fiziksel tam yedeklemesi başarısız olur.

DBS-203101 Connect db failure

Çözüm:

1. Port numarasını kullanarak SQL Server Management Studio (SSMS) ile oturum açın ve veritabanının mevcut olduğunu ve çalıştığını doğrulayın.

   Varsayılan olarak, bir port numarası olmadan oturum açabilirsiniz. Bir port numarası belirtmek için, bunu ana bilgisayar adından sonra virgülle ekleyin, örneğin localhost,1433.

   Not

   Yalnızca TCP bağlantıları desteklenir.

2. Veritabanı için SSL şifrelemesinin etkin olmadığından emin olun. SQL Server Configuration Manager uygulamasını açın. Sol bölmede SQL Server network configuration > protocols for MSSQLSERVER konumuna gidin. Sağ tıklayın ve properties seçeneğini belirleyin. flags sekmesinde, force encryption değerinin yes olarak ayarlanıp ayarlanmadığını kontrol edin. yes olarak ayarlanmışsa, bunu no olarak değiştirin.

DBS-203102

Senaryo: Bir SQL Server veritabanının yerel fiziksel yedeklemesi başarısız olur.

DBS-203102 Could not find database ......

Çözüm:

1. Veritabanının silinip silinmediğini kontrol edin. Silindiyse, yedekleme nesnelerini yeniden yapılandırın.

   Hedef yedekleme zamanlamasının Configure Task sayfasında, Basic Information bölümündeki Edit Backup Objects seçeneğine tıklayın.

   Not

   Yeni yapılandırmayı kaydetmek hemen bir yedekleme başlatır. Bu işlem kaynak veritabanınızı ve iş operasyonlarınızı etkileyebilir.

2. Kaynak veritabanının yeniden adlandırılıp adlandırılmadığını kontrol edin. Yeniden adlandırıldıysa, yedekleme nesnelerini yeniden yapılandırmak için önceki adımdaki talimatları izleyin.

3. Veritabanının çevrimiçi olduğundan emin olun.

4. Veritabanı kurtarma durumundaysa, kurtarmanın bitmesini bekleyin ve ardından görevi yeniden başlatın.

5. Veritabanının otomatik kapatma özelliği etkinse, bunu False olarak ayarlayın. SQL Server Management Studio (SSMS) içinde hedef veritabanına sağ tıklayın ve Properties seçeneğini belirleyin. Options sayfasında, ayarı Auto bölümünde bulun.

DBS-203103

Senaryo: Bir SQL Server veritabanının tam yerel fiziksel yedeklemesi başarısız olur.

Neden: Veritabanı kapatıldı.

DBS-203103 The database server already shutdown

Çözüm: Veritabanı hizmetini başlatın.

DBS-203104

Senaryo: Bir SQL Server veritabanının yerel fiziksel tam yedeklemesi başarısız olur.

Neden: VDI bileşenleriyle ilgili bir sorun.

DBS-203104 Wait VDI timeout 30s

Çözüm: VDI bileşenlerindeki sorunları gidermek için Windows olaylarını kontrol edin. Herhangi bir sorunu çözdükten sonra görevi tekrar deneyin. Sorun bulamazsanız, bir süre bekleyin ve ardından yedeklemeyi tekrar deneyin. Hata devam ederse, yardım almak için DingTalk grubu ile iletişime geçin.

DBS-203201

Senaryo: Bu hata, bir SQL Server veritabanının yerel fiziksel tam yedeklemesi sırasında oluşur.

Olası nedenler:

DBS-203201 database xxx backupable lsn {1} exceeded limit {2}

database XXXXXX  backupable lsn 10000000000000000009 exceeded limit 10000000000000000001,,already increment backup name:,backup datetime:2024-01-19 00:00:00

DBS-203202

Senaryo: Bir SQL Server veritabanının artımlı yedeklemesi başarısız olur.

DBS-203202 BACKUP LOG {0} cannot be performed because there is no current database backup

Çözüm: Manuel olarak bir tam yedekleme çalıştırın ve ardından başarısız olan artımlı yedeklemeyi yeniden başlatın.

DBS-203203

Senaryo: Bir SQL Server veritabanının yerel fiziksel tam yedeklemesi sırasında bir hata oluşur.

Neden: Veritabanının kurtarma modeli FULL olarak ayarlanmadığı için işlem günlüğü yedeklemeleri desteklenmez.

DBS-203203 Only support increment trnsaction log backup in FULL MODE, database {0}

ALTER DATABASE [your_database_name] SET RECOVERY FULL

DBS-203205

Senaryo: Bir SQL Server veritabanının yerel fiziksel tam yedeklemesi başarısız olur.

Neden: Veritabanı çevrimdışı.

DBS-203205 database  state is； DBS-203205 database AIS20210425120342 state is {1}

DBS-203206

Senaryo: Bir SQL Server veritabanının yerel fiziksel tam yedeklemesi başarısız olur.

Neden: Veritabanı kullanılamadığı veya bozuk olduğu için açılamıyor.

DBS-203206 message:Database 'UFTData992044_000002' cannot be opened due to

DBS-203240

Senaryo: SQL Server yerel fiziksel tam yedekleme.

Neden: Hesabın sysadmin izni yok.

DBS-203240, message:User 'guest' does not have permission to run DBCC LOGIN

DBS-203301

Senaryo: Bir SQL Server veritabanının tam geri yüklemesi başarısız olur.

DBS-203301 The tail of the log for the database {0} has not been backed up. Use BACKUP LOG WITH NORECOVERY to backup the log if it contains work you do not want to lose. Use the WITH REPLACE or WITH STOPAT clause of the RESTORE statement to just overwrite the contents of the log

Çözüm:

1. Kuyruk günlüğünü yedeklemek için aşağıdaki komutu çalıştırın.

   BACKUP LOG [Name of the database to restore] TO DISK='C:\backupdir\moyun_test.trn' WITH NORECOVERY;

2. Başarısız olan tam geri yükleme görevini yeniden başlatın.

DBS-203302

Senaryo: Bir SQL Server veritabanının yerel fiziksel tam yedeklemesinden geri yükleme başarısız olur.

Neden: İşlem günlüğü yedeklemesi LSN {0} noktasında sonlanır; bu, geri yüklemeye devam etmek için gereken LSN {1} noktasından daha öncedir. Bu durum, günlük yedekleme zincirinde bir boşluk olduğunu gösterir.

DBS-203302 the log in this backup set terminates at LSN {0}, which is too early to apply to the database. A more recent log backup that includes LSN {1} can be restored

Çözüm: Yardım almak için DingTalk grubu üzerinden teknik destek ile iletişime geçin.

DBS-301005

Senaryo: Bir Oracle örneğinin fiziksel tam yedeklemesi başarısız olur.

Neden: Oracle örneği, fiziksel tam yedekleme için gerekli olan arşiv modunda değil.

DBS-301005, message:INNER_ERROR[301005]:database is no archive mode
DBS-301005, message:INNER_ERROR[301005]:user="" ConnectString="" standalone params= ......

Çözüm: Arşiv modunu etkinleştirin. Ayrıntılı talimatlar için bkz. Arşiv modunu etkinleştirme.

DBS-301502

Senaryo: Bir MySQL fiziksel yedeklemesi sırasında bir hata oluşur.

Neden: Yedekleme sırasında redo günlüğüne kaydedilemeyen bir DDL işlemi yürütülür.

DBS-301502, without redo logging

Çözüm: DDL işlemleri çalışmazken yedeklemeyi tekrar deneyin.

DBS-301503

Senaryo: Bir MySQL fiziksel yedeklemesi başarısız olur.

Neden: Redo günlüğü oluşturma hızı yedekleme hızını aşıyor.

DBS-301503, log copying being too slow

Çözüm: Redo dosyasının boyutunu artırın ve yedeklemeleri yoğun olmayan saatlerde planlayın.

DBS-301504

Senaryo: Bir MySQL örneğinin fiziksel yedeklemesi başarısız olur.

Neden: Bu hata, MySQL örneğindeki bir veya daha fazla tabloda şifrelemenin etkin olması nedeniyle oluşur; Database Backup Service bu özelliği desteklemez.

DBS-301504, missing encryption

Çözüm: Şifrelemeyi devre dışı bırakın ve yedeklemeyi tekrar deneyin. Şifrelemeyi devre dışı bırakmayı tercih etmiyorsanız, yedekleme zamanlaması için para iadesi talep etmek üzere müşteri hizmetleri ile iletişime geçin.

DBS-301505

Senaryo: Bir MySQL veritabanının fiziksel yedeklemesi başarısız olur.

Neden: Sistem yedekleme işlemini sonlandırır.

DBS-301505, signal: terminated

Çözüm: Görevi yeniden başlatın.

DBS-302035

Senaryo: Bir Oracle veritabanının tam fiziksel yedeklemesi başarısız olur.

Neden: Oracle örneğinin rolü alınamıyor.

DBS-302035 USER_CAN_NOT_LOAD_INSTANCE_ROLE[302035]

Çözüm:

1. Veritabanı örneğini barındıran sunucuda oturum açın.

2. Sistem yöneticisi olarak veritabanında oturum açmak için aşağıdaki komutu çalıştırın:

   sqlplus / as sysdba

3. Sonucun döndürülüp döndürülmediğini kontrol etmek için aşağıdaki SQL ifadesini çalıştırın:

   select database_role from v$database;

   Sonuç döndürülmezse, nedeni araştırın. Sonuç döndürülürse, DingTalk grubu üzerinden destek ile iletişime geçin.

DBS-400001

Senaryo: Yerel fiziksel tam yedekleme veya tam veri dönüştürme görevi başarısız olur.

Neden: Yedekleme zamanlaması teknik özellikleri yetersiz olduğu için görev bellek tükenmesi yaşar.

DBS-400001 , message :Java heap space. 
DBS-400001 java.lang.OutOfMemoryError: Java heap space

Çözüm: Yedekleme zamanlaması teknik özelliklerini yükseltin. Geri yükleme görevi gibi acil bir görev için bellek sınırını geçici olarak artırmak üzere DingTalk grubu üzerinden teknik destek ile iletişime geçin. Talimatlar için bkz. Yedekleme zamanlamasını yükseltme.

DBS-999999 veya hata kodu yok

Senaryo: Herhangi bir görev sırasında bir hata oluşur.

Neden: Özel durum tanımsız veya sistem ilgili hata kodunu döndüremedi.

DBS-999999 + [error message]

Çözüm: Hata mesajını kopyalayın ve sorunu farklı bir hata kodunun açıklayıp açıklamadığını görmek için bu konuda arayın. Bir çözüm bulamazsanız, DingTalk grubu üzerinden teknik destek ile iletişime geçin.