Ajanı yükseltmek yönettiği veritabanlarını yükseltmez. Bir veritabanının güncel duruma getirilme sırası nereden geldiğine bağlıdır; başlamadan önce üç soru yanıtlanır:

Aşağıdaki betikler iki yoldan çalıştırılır: msql -U SYSDBA -W <parola> -f yukselt.sql (çalışan hizmetin /ivedi oturumu üzerinden, yani açtığı veritabanı hizmetin MASTER'ında kayıtlı kalır) ya da yönetim arayüzünün Yükseltme ve SQL sayfalarından (yine /ivedi). Paket ve yedek dosyalarının yolları (UPGRADE LEVEL … FROM, EXPORT LEVEL … TO, BACKUP TO) her iki yolda da sunucunun dosya sistemindedir; msql ile paket yolu 'client:<yol>' yazılırsa paket istemci makinesinden okunur ya da oraya yazılır. Komutların ayrıntısı — sözdizimi, seçenekler, yetkiler — bu kılavuzun kapsamı dışındadır ve IVEDI SQL Kullanıcı Kılavuzu belgesindedir.

Paket dosyası kendini tanıtır. EXPORT LEVEL'in yazdığı .ivdpkg dosyasının başında düz metin bir başlık durur: dosyayı bir metin aracıyla açtığınızda ilk satırda IVDPKG1 imzasını, ardından ürün kodunu, seviyeyi, o seviyenin sürümünü ve üretim damgasını, kaynak veritabanının adını, katalog sürümünü, üreten motorun sürümünü ve bütünlük özetini görürsünüz. Bir paketi uygulamadan önce doğru ürüne ve doğru sürüme ait olduğunu böyle denetleyebilirsiniz; gerisi sıradan bir zip arşividir.

10.2.1 Senaryo A — kataloğu hiç olmayan eski üretim veritabanı

Ürünün isql/psql ile kurulmuş, IVEDI'nin hiç dokunmadığı bir veritabanı. Düz OPEN DATABASE bunu açmaz, STORAGE_HAS_NO_CATALOG hatasıyla durur; CREATE DATABASE de var olan depoyu yaratmayı reddeder. Giriş noktası OPEN DATABASE … CREATE CATALOG'dur: katalog tabloları var olan veritabanının içine kurulur, ürünün tablolarına dokunulmaz, veritabanı kaydedilir ve “yükseltme gerekiyor” durumunda kalır. Dağıtımın depoya kurduğu, sistem nesnesiyle aynı adlı tablo, görünüm, dizi ya da domain (ivd$, emr$, iot$ …) katalog nesnesi tarafından ezilir: verisiyle düşürülür, katalog tanımıyla yeniden kurulur ve uyarıda adlandırılır. Böyle bir tabloya bağlı bir ürün görünümü varsa depo düşürmeyi reddeder, kurulum yarım kalmadan geri sarılır. Yönetim arayüzünün Veritabanları sayfası OPEN sırasında bu durumu tanır ve katalog tablolarını oluşturmayı sorar.

--  1) katalog var olan deponun içine kurulur, veritabanı yükseltme bekler
OPEN DATABASE urun_db STORAGE ENGINE firebird
  PARAMETERS 'Server Name=localhost; User Name=SYSDBA; Password=…; Database Name=C:\URUN\URUN.FDB'
  CREATE CATALOG;
COMMIT;
SET CATALOG urun_db;
ALTER DATABASE urun_db UPGRADE;
COMMIT;

--  2) ürünün seviye 3'ü uygulanır: paketteki tablolar DEPODAN benimsenir, sonra pakete hizalanır
SET CATALOG urun_db;
ALTER DATABASE urun_db UPGRADE LEVEL 3 FROM 'urun_5.2.0.1541.ivdpkg' PREVIEW;
ALTER DATABASE urun_db UPGRADE LEVEL 3 FROM 'urun_5.2.0.1541.ivdpkg' CONFIRMED;
COMMIT;

--  3) paketin tanımadığı nesneler (kullanıcının kendi tabloları, görünümleri, yordamları) istenirse kataloğa alınır
--     (öndeğer kaynak şema EKLENTI; başka bir şema için ADOPT LEVEL 4 SCHEMA <şema>)
ALTER DATABASE urun_db ADOPT LEVEL 4 PREVIEW;
ALTER DATABASE urun_db ADOPT LEVEL 4;
COMMIT;

2. adımda şema paketten kurulur, paketin adını taşıyan her tablo depodan benimsenir ve paketin tanımına getirilir; satır verisi korunur. Kataloğun bilmediği tablolara dokunulmaz — onlar 3. adımın işidir. Bu veritabanının seviye 3 damgası olmadığı için LEVEL3_UPDATE durumuna hiç girmez; damga 2. adımın sonunda yazılır.

10.2.2 Senaryo B — sürümler arası geçiş yapan üretim veritabanı

Kataloğu yerinde, damgalı bir veritabanı yeni bir ürün sürümüne geçiyor.

--  0) yapım sunucusunda: yeni sürümün paketi
SET CATALOG yeni_db;
EXPORT LEVEL 3 TO 'urun_5.2.0.1541.ivdpkg';

--  1) müşteride: motor sürümü değiştiyse önce KATALOG BİÇİMİ
OPEN DATABASE urun_db STORAGE ENGINE firebird PARAMETERS '…';
SET CATALOG urun_db;
ALTER DATABASE urun_db UPGRADE PREVIEW;
ALTER DATABASE urun_db UPGRADE BACKUP TO 'C:\yedek\urun_yedek.fbk';
COMMIT;

--  2) planı oku
ALTER DATABASE urun_db UPGRADE LEVEL 3 FROM 'urun_5.2.0.1541.ivdpkg' PREVIEW;

--  3) uygula
ALTER DATABASE urun_db UPGRADE LEVEL 3 FROM 'urun_5.2.0.1541.ivdpkg' CONFIRMED;
COMMIT;

1. adım katalog biçimini motorun güncel metadatasına getirir; damga taşıyan bir veritabanı bu adımın sonunda LEVEL3_UPDATE durumuna geçer ve yalnız sahibine, SYSDBA'ya ve SYSADMIN üyelerine açılır — yani kullanıcılar bu arada bağlanamaz. 3. adım da koşu boyunca aynı durumu kurar (yükseltme yarı uygulanmış bir veritabanına kimse yazmasın diye) ve hatasız biterse kaynağın damgası birebir kopyalanır, durum ACTIVE'e döner. Kullanıcının kendi nesneleri (seviye 4) bu adımların hiçbirinde pencereye girmez.

1. ve 3. adımın sonuna BACKUP CYCLE eklenirse (Yükseltme sayfasının Standart yedek döngüsü) yükseltme veritabanının kopyasında koşar: urun_db_yedek1 önceki hâl olarak kalır, başarısız koşuda yeniden urun_db olur. Yarıda kalan döngü ALTER DATABASE urun_db BACKUP CYCLE STATUS ile görülür, … BACKUP CYCLE CONTINUE ile sürdürülür ya da … BACKUP CYCLE ROLLBACK ile geri alınır (üçü de MASTER'dan çalışır; döngü bitene kadar veritabanı açılmaz).

2. adımın raporundaki VERSION satırı geçişin yönünü söyler (1.0.0 → 2.0.0). Yön geriye işaretliyorsa — paketin sürümü veritabanınınkinden eskiyse — uygulama reddedilir; bu neredeyse her zaman yanlış paket dosyası demektir.

10.2.3 Senaryo C — seviye 3'ü baştan kurmak

Katalog geçişi bozulmuşsa ya da ürünün seviyesi sıfırdan üretilecekse, o seviyenin katalog bilgisi silinir ve yeniden kurulur. Depo bu işlemlerin hiçbirinde değişmez: tablolar, indeksler ve satırlar yerinde kalır.

SET CATALOG urun_db;
ALTER DATABASE urun_db DROP LEVEL 4 PREVIEW;     -- ne silinecek
ALTER DATABASE urun_db DROP LEVEL 4;             -- (seviye 4 varsa önce o)
ALTER DATABASE urun_db DROP LEVEL 3;
COMMIT;

--  katalog satırları gitti, yüklü nesneler süreçte duruyor: kapat / yeniden aç
CLOSE DATABASE urun_db;
OPEN DATABASE urun_db STORAGE ENGINE firebird PARAMETERS '…';

SET CATALOG urun_db;
ALTER DATABASE urun_db UPGRADE LEVEL 3 FROM 'urun_5.2.0.1541.ivdpkg' CONFIRMED;
COMMIT;

10.2.4 Senaryo D — kullanıcının depodaki tablolarını kataloğa almak

Depoda olup katalogda olmayan tabloları kataloğa almanın iki yolu vardır: tek tek ADOPT TABLE <ad> [LEVEL 3 | 4] (öndeğer seviye 4) ve şemadaki hepsini birden ALTER DATABASE <db> ADOPT LEVEL 3 | 4 [SCHEMA <şema>]. Seviye 3 yalnız NETSIM şemasından benimser; seviye 4 verilen şemadan, verilmezse EKLENTI'den (seviye 4 NETSIM olamaz). Yükseltme sayfasında seviye 4 seçiliyken kaynak şema kutusu EKLENTI ile gelir.

10.2.5 Koşu nasıl ilerler, rapor nasıl okunur

Yükseltme eylemleri sabit bir sırayla uygular — önce düşecek kod nesneleri, sonra şema/dizi/domain, benimseme, tablolar, indeksler, düşürmeler, kod nesneleri, tohum verisi, haklar, en sonda damga. Bu sıranın adım adım dökümü komutun kendi davranışıdır ve IVEDI SQL Kullanıcı Kılavuzu belgesindedir. İşletmeci açısından önemli olan üç şey vardır:

• Her deyim kendi COMMIT'iyle çalışır. Bir nesnenin hatası ötekileri durdurmaz; rapora bir ERROR satırı olarak girer ve koşu devam eder.
• Hata varsa damga yazılmaz. Veritabanı LEVEL3_UPDATE durumunda kalır, yani kullanıcılara kapalıdır — hataları giderip aynı paketle yeniden koşmak güvenlidir.
• Rapor OBJECT_NAME, OBJECT_KIND, ACTION, DETAIL kolonlarından oluşur; sonunda SUMMARY (kaç yaratma / düşürme / değişiklik), VERSION (eski → yeni damga) ve APPLY (kaç deyim, kaç hata) satırları gelir. Önce PREVIEW ile aynı listeyi hiçbir şey yazmadan alın.

Ürünün kendi yükseltme komutları (ivd$upgrade) bu adımların arasındaki olay noktalarında çalışır, yani veri göçü eski kolon hâlâ dururken yapılabilir. Bir komut açık onay isterse koşu önizlemeyi okumanızı ve deyimi CONFIRMED ile yinelemenizi ister.

10.2.6 Ne zaman ne koşulmuş: yükseltme geçmişi

Kataloğa ya da bir seviyeye dokunan her işlem veritabanının kendi SYS.IVD$UPGRADE_HISTORY tablosuna bir satır yazar — işlem, seviye, başlangıç/bitiş zamanı (UTC), çalıştıran kimlik, paket dosyası, önceki ve yeni sürüm, verilen onaylar, eylem ve hata sayıları, sonuç ve raporun tamamı. Önizleme yazmaz. Destek çağrısında ilk bakılacak yer burasıdır:

SELECT ivd$started, ivd$operation, ivd$level, ivd$from_version, ivd$to_version, ivd$result, ivd$login
  FROM sys.ivd$upgrade_history ORDER BY ivd$history_id DESC;

Satırın ivd$report kolonu o koşunun eylem listesinin tamamını taşır — ekranda görülenin aynısı — standart bir ZIP dosyası olarak (ilk girdi: upgrade-report.txt; işlemde hata satırı varsa ikinci girdi agent-log.txt: işlemin başından bu yana ajan günlüğüne yazılanlar, en çok son 4 MB), yani kolon indirilip herhangi bir arşiv aracıyla açılabilir. SQL'den okumak için:

SELECT Metadata.UpgradeReportText(ivd$report)
  FROM sys.ivd$upgrade_history WHERE ivd$history_id = 3;

Geçmiş veritabanının içinde durur, yani yedekten dönen ya da kopyalanan bir veritabanı geçmişini de taşır.

10.2.7 Yükseltmenin reddettiği durumlar

Sürüm gerilemesi CONFIRMED ile geçilmez, kendi anahtarı vardır (ALLOW DOWNGRADE): eskimiş bir tabloyu düşürmek için verilen onay, yanlış paketin uygulanmasını da onaylamış olmasın diye. Geri dönüş, önceki sürümün eklediklerini silmek demektir — sağlıklı yol yedekten geri yüklemektir; ALLOW DOWNGRADE yalnızca bilerek geri alınan bir kurulum içindir.