Sitemap
Eren Akpulat

Eren Akpulat

Senior Business Analytics Consultant https://www.linkedin.com/in/erenakpulat/

Case Study: SAP Datasphere Remote Table Oluşturma Hatası — errorgetCSNDefinition: invalid remote object name

5 min readNov 6, 2025
  1. Giriş

SAP Datasphere üzerinde çalışırken, harici veritabanlarına Data Provisioning Agent (DP Agent) aracılığıyla bağlantı kurarak remote table oluşturmak oldukça yaygındır.

Bu durum çalışmasında, IBM DB2 LUW veritabanından JDBC bağlantısı kullanarak remote table oluşturma sırasında karşılaşılan spesifik bir hata incelenmiştir.

İçe aktarma(import) işlemi sırasında tablo durumu “Import Failed” olarak görünmüş ve aşağıdaki hata mesajı alınmıştır:

“errorgetCSNDefinition: invalid remote object name”

Press enter or click to view image in full size
Press enter or click to view image in full size

Bu doküman, hatanın kök nedenini, teknik arka planını ve uygulanan çözümü ayrıntılı biçimde açıklamaktadır.

2. Teknik Bağlam

  • SAP Datasphere, DP Agent üzerinden CamelJDBCAdapter kullanılarak IBM DB2’ye bağlanmıştır.
  • DB2 JDBC sürücüsü (db2jcc4.jar) DP Agent kurulumundaki camel/lib dizinine yerleştirilmiştir.
  • Bağlantı ve kimlik doğrulama işlemleri başarıyla tamamlanmıştır— “connection validation successful”.
  • Ancak, belirli DB2 tabloları remote table olarak içe aktarılmaya çalışıldığında yukarıdaki hata mesajı alınmıştır.

3. Sorunun Tanımı

SAP Datasphere’de DB2’den CamelJDBCAdapter aracılığıyla remote table oluşturulurken, bazı tablolar için aşağıdaki hata ile içe aktarma işlemi başarısız olmuştur:

errorgetCSNDefinition: invalid remote object name: Exception occurred during execution on the exchange:
line 0 col 0 (at pos 0), Code: 476, SQL State: HY000

Dikkat çekici olan durum, aynı DB2 şemasındaki benzer tabloların başarıyla içe aktarılabilmesidir. Bu durum, problemin JDBC sürücüsünden veya bağlantı yapılandırmasından kaynaklanmadığını göstermektedir.

4. Kök Neden Analizi

DP Agent loglarının detaylı incelenmesi sonucunda, hatanın geçersiz şema veya tablo adından değil, meta veri okuma aşamasında yaşanan bir karakter kodlama (encoding) sorunundan kaynaklandığı görülmüştür.

Başarısız içe aktarma sırasında loglarda aşağıdaki kritik hata mesajı kaydedilmiştir:

[ERROR] JdbcMetadataBrowser | ExceptionUtil.newAdapterException [] 
Failed to import metadata due to exception.
com.ibm.db2.jcc.am.SqlException
Caught java.ilo.CharConversionException.
ERRORCODE=-4220, SQLSTATE=null

Bu logdaki kritik satır:

Caught java.io.CharConversionException (ERRORCODE=-4220)

Bu mesaj, IBM DB2 JDBC sürücüsünden kaynaklanmaktadır ve sürücünün karakter dönüşümünde hata aldığını — yani beklenen UTF-8 karakter kümesine göre çözümlenemeyen bayt dizileriyle karşılaştığını ifade eder.

DP Agent’taki CamelJDBCAdapter, meta veri içe aktarma aşamasında tabloların kolon tanımlarını ve bu tanımlarla ilişkili örnek değerleri (örneğin, metin uzunlukları ve tür bilgileri) okur.
Eğer bu aşamada herhangi bir kayıt geçersiz (non-UTF-8) karakterler içeriyorsa, DB2 JDBC sürücüsü bir CharConversionException hatası döndürür ve DP Agent meta veriyi tamamlayamaz.

Sonuç olarak, SAP Datasphere bu alt seviye hatayı genelleyerek şu mesajı döndürür:
“errorgetCSNDefinition: invalid remote object name”

Bu ifade, sistemin kaynak tablodan geçerli bir tablo tanımı oluşturamadığını gösterir. Sorun tablo adı veya şemayla ilgili değil, verinin okunması sırasındaki karakter seti uyuşmazlığıdır.

Yapılan inceleme, hatalı tabloların non-UTF-8 karakterler içerdiğini, aynı şemadaki diğer tabloların ise yalnızca geçerli UTF-8 veriler barındırdığı için sorunsuz içe aktarılabildiğini ortaya koymuştur.
Dolayısıyla hata, bağlantı veya yapılandırmadan değil, karakter kodlama uyuşmazlığından kaynaklanmıştır.

Özetle:

  • errorgetCSNDefinition hatasının temel nedeni, bazı DB2 tablolarında bulunan non-UTF-8 karakterlerdir.
  • DP Agent loglarında görülen CharConversionException (ERRORCODE=-4220) hatası tetikleyici durumdur.
  • Çözüm, tüm metin kolonlarının UTF-8 ile uyumlu hale getirilmesidir. Bu durum, DB2 tarafında hatalı karakterlerin temizlenmesiyle veya kolonların CCSID 1208 olarak dönüştürüldüğü bir view oluşturularak sağlanabilir.

5. DB2’de Non-UTF-8 Karakterlerin Tespiti

İçe aktarma hatasının karakter kodlamasından kaynaklandığı belirlendikten sonra, bir sonraki adım SAP Datasphere’e yeniden aktarmadan önce DB2’deki kaynak tablodaki non-UTF-8 verileri tespit edip temizlemektir.

5.1 Non-UTF-8 Karakterleri Tespit Etme

Get Eren Akpulat’s stories in your inbox

Join Medium for free to get updates from this writer.

Hangi kayıtların veya kolonların geçersiz karakterler içerdiğini belirlemek için aşağıdaki sorgu çalıştırılmıştır:

SELECT
TEST1,
LENGTH(TEST1) AS length_total,
LENGTH(REGEXP_REPLACE(TEST1, ‘[ -~]’, ‘’)) AS length_non_ascii_chars,
REGEXP_REPLACE(TEST1, ‘[ -~]’, ‘’) AS invalid_chars
FROM TestTable
WHERE LENGTH(REGEXP_REPLACE(TEST1, ‘[ -~]’, ‘’)) > 0
FETCH FIRST 100 ROWS ONLY;
Press enter or click to view image in full size
Bu sorgu, sütunlarda standart ASCII yazdırılabilir aralığı ([ -~]) dışındaki karakterleri bulur. Bu tür karakterler genellikle non-UTF-8 veya özel binary karakterlerdir.

Sorgu çıktısı:

  • length_total → Kolondaki toplam karakter sayısı
  • length_non_ascii_chars → ASCII aralığı dışındaki karakter sayısı
  • invalid_chars → Soruna neden olan geçersiz karakterlerin kendisi

Bu sorguda dönen satırlar, DP Agent meta veri okuma sırasında kod dönüşüm hatasına yol açabilecek non-UTF-8 karakterler içerir.

Not: DBeaver veya DataGrip gibi üçüncü parti SQL istemcileri, geçersiz karakterleri hata yerine “?” ya da boşluk karakteriyle değiştirerek gösterebilir. Bu nedenle veri incelemesi sırasında sorun fark edilmeyebilir. Ancak SAP Datasphere, karakter kodlaması doğrulamasında daha katı davranır ve yalnızca geçerli UTF-8 karakterlerini desteklediğinden bu tür kayıtları kabul etmez.

5.2 Karakter Seti Kısıtlamasını Anlamak

SAP Datasphere (ve genel olarak SAP HANA) yalnızca UTF-8 karakter setini destekler.

Bu da şu anlama gelir:

  • Kaynak sistem Latin-1, Windows-1254, EBCDIC veya UTF-16 gibi başka bir kodlama kullanıyorsa, veri erişiminden önce UTF-8’e dönüştürülmelidir.
  • DP Agent ve JDBC driver karakter seti dönüşümünü otomatik olarak yapmaz.
  • Non-UTF-8 veriler, CharConversionException veya benzeri encoding hatalarına neden olabilir.

DB2 veritabanının aktif karakter kodlamasını kontrol etmek için:


db2 get db cfg for <dbname>

Aşağıdaki satıra bakılmalıdır:
Database code page = 819 (veya 1252, vb.)

Eğer code page 1208 değilse, veritabanı UTF-8 kullanmıyor demektir ve karakter dönüşümü gereklidir.

6. UTF-8 Uyumlu View’lar Oluşturma

Temel tabloyu değiştirmeden içe aktarma hatalarını önlemek için, tüm metin kolonlarının UTF-8 olarak CAST edildiği bir view oluşturulabilir.
Bu yöntem özellikle veritabanı UTF-8 kullanmıyorsa veya CAST CCSID 1208 fonksiyonu destekleniyorsa etkilidir.

Örnek:

CREATE VIEW TestTable_UTF8 AS
SELECT X_ID,
Y_ID,
TEXT_ID,
CAST(A_STRING AS VARCHAR(100) CCSID 1208) AS A_STRING,
CAST(B_STRING AS VARCHAR(100) CCSID 1208) AS B_STRING,
CAST(C_STRING AS VARCHAR(100) CCSID 1208) AS C_STRING,
TEST_F,
CAST(TEST_TRANSFER AS VARCHAR(100) CCSID 1208) AS TEST_TRANSFER,
TEST_DATE,
CAST(TEST_STATUS AS VARCHAR(50) CCSID 1208) AS TEST_STATUS,
TEST_STATUS_DATE,
CAST(TEST_INFO AS VARCHAR(750) CCSID 1208) AS TEST_INFO,
TEST_S_ID,
CAST(TEST_A_USER AS VARCHAR(100) CCSID 1208) AS TEST_A_USER,
TEST_END,
TEST_T_ID,
TEST_E_DATE,
CAST(TEST_E_USER AS VARCHAR(100) CCSID 1208) AS TEST_E_USER
FROM TestTable;

Not: Eğer şu hata alınırsa:

SQL0622N The clause “CCSID <integer>” is invalid for this database

bu durumda:

Kullanılan DB2 sürümü veya yapılandırması farklı CCSID’e CAST işlemine izin vermiyor olabilir, veya

Veritabanının kendi code page değeri UTF-8 değildir (örneğin 1252 ya da 819).

Bu gibi durumlarda alternatif yöntem, geçersiz karakterleri REGEXP_REPLACE ile temizlemektir.

CREATE VIEW TestTable_UTF8 AS
SELECT
TEST_ID,
REGEXP_REPLACE(TEST_GN, ‘[^ -~]’, ‘’) AS TEST_GN,
REGEXP_REPLACE(TEST_TYP, ‘[^ -~]’, ‘’) AS TEST_TYP,
REGEXP_REPLACE(TEST_BM, ‘[^ -~]’, ‘’) AS TEST_BM,
REGEXP_REPLACE(TEST_T, ‘[^ -~]’, ‘’) AS TEST_T,
REGEXP_REPLACE(TEST_S, ‘[^ -~]’, ‘’) AS TEST_S,
REGEXP_REPLACE(TEST_V_, ‘[^ -~]’, ‘’) AS TEST_V,
REGEXP_REPLACE(TEST_B, ‘[^ -~]’, ‘’) AS TEST_B,
REGEXP_REPLACE(TEST_USER, ‘[^ -~]’, ‘’) AS TEST_USER,
TEST_TS,
TEST_END,
TEST_T_ID,
TEST_Z_LEFT_DATE,
TEST_Z_RIGHT_DATE
FROM TestTable;

Bu yöntem, metin alanlarındaki yazdırılamayan veya geçersiz karakterleri temizler; sayısal ve tarih alanlarına dokunmaz.

UTF-8 uyumlu bu view’lar oluşturulduktan sonra, SAP Datasphere’de remote table import işlemi sorunsuz tamamlanmış ve errorgetCSNDefinition ya da CharConversionException hataları ortadan kalkmıştır.

Press enter or click to view image in full size

Sonuç

DB2 kaynak sisteminde non-UTF-8 karakterlerin tespit edilip düzeltilmesi — ister CAST(… CCSID 1208) ile, ister REGEXP_REPLACE temizliğiyle yapılsın — SAP Datasphere’e yapılan remote table aktarımını başarılı biçimde tamamlamıştır.

Bu çalışma, DP Agent aracılığıyla bağlanan tüm sistemlerde UTF-8 kodlama tutarlılığının ne kadar kritik olduğunu ve kodlama uyumsuzluklarının doğrudan veri entegrasyonu ve meta veri okuma hatalarına yol açabileceğini göstermektedir.

--

--