Oracle 19c DBA Serisi— Database Management and Data Protection Strategies: An In-Depth Technical…
Oracle veritabanı ekosisteminde veri bütünlüğü ve sürekliliğinin korunması, modern bilgi teknolojileri altyapılarının temel taşını…
Oracle 19c DBA Serisi— Database Management and Data Protection Strategies: An In-Depth Technical Analysis of the RMAN Utility and Backup Architecture (Part 12)

Oracle veritabanı ekosisteminde veri bütünlüğü ve sürekliliğinin korunması, modern bilgi teknolojileri altyapılarının temel taşını oluşturmaktadır. Bu bağlamda, Recovery Manager (RMAN) yardımcı programı, basit bir yedekleme aracının ötesine geçerek, veritabanı motoruyla derinlemesine entegre olmuş, blok düzeyinde zekaya sahip bir veri koruma çerçevesi sunmaktadır. RMAN mimarisi, geleneksel kullanıcı yönetimli (user-managed) yedekleme yöntemlerinin aksine, veritabanı dosyalarını yedekleme moduna sokma zorunluluğunu ortadan kaldıran ve yedekleme sırasında oluşan redo yükünü minimize eden bir yapıya sahiptir.
Kurulum ve Konfigürasyon Dokümanım için;
RMAN Yardımcı Programı: Mimari ve Temel Kavramlar
RMAN, Oracle veritabanı dosyalarının (datafiles, control files, archived redo logs ve server parameter files) yedeklenmesi, geri yüklenmesi ve kurtarılması için tasarlanmış ana komut satırı arayüzüdür. Yazılımın en ayırt edici özelliği, işletim sistemi seviyesindeki kopyalama işlemlerinden farklı olarak, Oracle veri bloğu yapısını tanımasıdır. Bu blok farkındalığı, RMAN’in yedekleme sırasında blok düzeyinde corruption taraması yapmasına ve unused block compression depolama verimliliği sağlamasına imkan tanır.
RMAN İçerik ve Bileşen Mimarisi
RMAN mimarisi, operasyonel esneklik ve merkezi yönetim sağlamak amacıyla katmanlı bir yapıda kurgulanmıştır. Bu yapının merkezinde Target Database yer alırken, çevresinde RMAN istemcisi, kurtarma kataloğu ve auxiliary instances bulunur.
Hedef veritabanı, yedekleme ve kurtarma işlemlerinin odağındaki asıl veritabanıdır. RMAN, bu veritabanının control file kullanarak veritabanı yapısı, veri dosyası konumları ve geçmiş yedekleme kayıtları hakkında meta veriler toplar. Kontrol dosyası, RMAN için authoritative repository işlevi görür. Bu durum, kontrol dosyasının korunmasını yedekleme stratejisinin en kritik unsurlarından biri haline getirmektedir.
Recovery Catalog, isteğe bağlı ancak kurumsal ortamlarda şiddetle tavsiye edilen bir bileşendir. Kataloğun temel işlevi, hedef veritabanının kontrol dosyasında sınırlı bir süre (varsayılan 7 gün) saklanan RMAN meta verilerini ayrı bir Oracle veritabanı şemasında daha uzun süreli ve merkezi olarak depolamaktır. Katalog kullanımı, birden fazla veritabanının yedekleme geçmişinin tek bir noktadan raporlanmasına, stored scripts yönetilmesine ve kontrol dosyasının tamamen kaybolduğu durumlarda felaket kurtarma süreçlerinin kolaylaştırılmasına olanak tanır.
Auxiliary Database ise genellikle DUPLICATE komutuyla veritabanı klonlama veya Tablespace Point-in-Time Recovery (TSPITR) gibi işlemler sırasında RMAN tarafından geçici olarak oluşturulan bir veritabanı örneğidir.
Rman — Genel Bilgiler ve Çalışma Prensibi
RMAN’in çalışma prensibi, istemci tarafındaki komutların hedef veritabanı sunucusunda çalışan shadow processes dönüştürülmesine dayanır. RMAN istemcisi başlatıldığında, hedef veritabanına bir bağlantı kurar ve sunucu tarafında her bir yedekleme channel için birer veritabanı oturumu başlatır. Bu oturumlar, RMAN istemcisinden gelen PL/SQL paket çağrılarını yürüterek fiziksel okuma ve yazma işlemlerini gerçekleştirir.
RMAN, yedekleme işlemleri sırasında veritabanının açık (open) veya kapalı (mounted) olmasına bakmaksızın consistent veya inconsistent yedekler alabilir. Tutarlı bir yedekleme, veritabanı düzgün bir şekilde kapatıldıktan (shutdown immediate/normal) sonra alınan yedeği ifade eder ve geri yükleme sonrası recovery gerektirmez. Ancak çoğu production ortamında veritabanı 7/24 açıktır; bu durumda alınan tutarsız yedekler, geri yükleme sonrasında arşivlenmiş redo log dosyalarıyla kurtarma işlemi yapılarak tutarlı hale getirilir.
Mimari Kavram | Açıklama | Operasyonel Etki
Server Process | Sunucuda RMAN adına çalışan işlem | Kanal başına bir oturum oluşturulur.
Channel | Veri iletim yolu (Disk veya Tape) | Yedekleme hızını belirleyen temel birimdir.
Media Manager | Üçüncü taraf Tape yazılımı arayüzü | Type yedeklemeleri için MML katmanı gereklidir.
Repository | Meta verilerin saklandığı yer | Kontrol dosyası veya Kurtarma Kataloğu.
Rman — Özellikler ve Teknik Avantajlar
RMAN, geleneksel yedekleme yöntemlerine kıyasla veritabanı yöneticilerine geniş bir yetkinlik yelpazesi sunmaktadır. Bu özelliklerin başında blok düzeyinde operasyon yapabilme kabiliyeti gelmektedir. Geleneksel dosya sistemi yedeklemeleri veri dosyasını bir bütün olarak görürken, RMAN blok bazlı çalıştığı için yalnızca değiştirilmiş blokları yedekleyebilir (incremental backup).
RMAN’in öne çıkan diğer teknik özellikleri şunlardır:
- Bozulma Tespiti (Corruption Detection): RMAN, yedekleme sırasında her veri bloğunun başlık ve son bilgisini kontrol ederek fiziksel ve isteğe bağlı olarak mantıksal bozulmaları tespit eder.
CHECK LOGICALparametresiyle etkinleştirilen bu özellik, veritabanı yöneticisine potansiyel veri kayıpları hakkında erken uyarı sağlar. - Blok Medya Kurtarma (Block Media Recovery — BMR): Tüm veri dosyasını geri yüklemek yerine, yalnızca bozulmuş olan belirli blokların onarılmasına imkan tanır. Bu işlem sırasında veri dosyası online kalmaya devam eder ve veritabanı erişilebilirliği maksimize edilir.
- Paralel İşleme: RMAN, birden fazla kanalı aynı anda kullanarak yedekleme ve geri yükleme işlemlerini paralel olarak yürütebilir. Bu, terabaytlarca büyüklükteki veritabanlarının yedekleme pencerelerine sığdırılması için elzemdir.
- Platformlar Arası Taşınabilirlik: RMAN, tablespace’lerin farklı platformlar (örneğin Windows’tan Linux’a) arasında taşınmasına yardımcı olan “Cross-platform Transportable Tablespace” özelliğini destekler.
Rman — Database Bağlantısı ve Güvenlik Protokolleri
RMAN bağlantıları, veritabanı yönetimi ve güvenliği açısından stratejik bir öneme sahiptir. Bağlantı kurmak için RMAN istemcisine hedef veritabanı, isteğe bağlı olarak kurtarma kataloğu ve yardımcı veritabanı bilgileri sağlanmalıdır.
Bağlantı yöntemleri temel olarak işletim sistemi kimlik doğrulaması (OS authentication) ve parola dosyası kimlik doğrulaması (password file authentication) olarak ikiye ayrılır.
Yerel sunucuda rman target / komutuyla yapılan bağlantılarda işletim sistemi yetkileri kullanılırken, uzak sunuculardan yapılan bağlantılarda TNS servis isimleri ve SYSDBA veya SYSBACKUP yetkilerine sahip kullanıcı parolaları gereklidir.
Güvenli Bağlantı ve Oracle Wallet Kullanımı
Kurumsal güvenlik standartları, yedekleme scriptlerinde plain text parolaların bulunmasını yasaklamaktadır. Bu sorunu aşmak için Oracle “Secure External Password Store” (Wallet) teknolojisi kullanılır. Wallet kullanımı, DBA’lerin veritabanına bağlanırken bir alias kullanmasına olanak tanır ve gerçek kimlik bilgileri şifrelenmiş bir dosya içinde saklanır.
Wallet yapılandırması için izlenen temel adımlar şunlardır:
sqlnet.oradosyasındaENCRYPTION_WALLET_LOCATIONveSQLNET.WALLET_OVERRIDE=TRUEparametrelerinin ayarlanması.mkstoreyardımcı programı kullanılarak wallet dosyasının oluşturulması ve veritabanı kimlik bilgilerinin eklenmesi.tnsnames.oradosyasında veritabanı servisinin tanımlanması.
Bağlantı çeşitliliği şu tablo ile özetlenebilir:
Bağlantı Tipi | Örnek Komut | Kimlik Doğrulama | Kullanım Senaryosu
Yerel (Local) | rman target / | OS Authentication | Yerel sunucu operasyonları
Uzak (Remote) | rman target sys/pass@tns | Password File | Merkezi yönetim sunucuları
Kataloglu | rman target / catalog user/pass@cat | Database User | Kurumsal yedekleme yönetimi
Wallet | rman target /@alias | Oracle Wallet | Betik otomasyonu ve güvenlik
RMAN ayrıca “Pipe Mode” adı verilen bir çalışma moduna sahiptir. Bu modda RMAN, komutları işletim sistemi standart girdisi yerine bir database pipe hattından pkur. Bu özellik, RMAN’in diğer uygulama yazılımları veya PL/SQL süreçleri tarafından programatik olarak kontrol edilmesine olanak tanır.
Rman Parametreleri ve Konfigürasyon Derinliği
RMAN’in davranışını belirleyen konfigürasyon ayarları, CONFIGURE komutuyla yönetilir ve bu ayarlar hedef veritabanının kontrol dosyasında kalıcı olarak saklanır. DBA'lerin bu parametreleri veritabanının iş yüküne ve kurtarma hedeflerine (RTO/RPO) göre optimize etmesi beklenir.
Rman Parametreleri (1): Saklama Politikası ve Cihaz Türleri
Yedekleme stratejisinin en temel bileşeni, yedeklerin ne kadar süreyle saklanacağını belirleyen “Retention Policy”dir. RMAN iki farklı saklama politikası sunar:
- Recovery Window : Veritabanının belirli bir gün sayısı kadar geriye dönük kurtarılabilmesini sağlar.
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 14 DAYS;komutu, son 14 günün herhangi bir anına dönmeyi garanti edecek yedeklerin silinmemesini sağlar. - Redundancy : Her bir dosyanın kaç adet güncel yedeğinin tutulacağını belirler.
CONFIGURE RETENTION POLICY TO REDUNDANCY 3;ayarı, her veri dosyasının en az 3 farklı yedek kopyasını korur.
Cihaz yapılandırması ise yedeklerin nereye yazılacağını belirler. CONFIGURE DEFAULT DEVICE TYPE TO DISK; veya CONFIGURE DEFAULT DEVICE TYPE TO SBT; komutları ile varsayılan ortam seçilir.
Rman Parametreleri (2): Paralellik ve Kanal Yönetimi
Büyük ölçekli veritabanlarında yedekleme süresini kısaltmak için kanal paralelizm ayarları hayati önem taşır. CONFIGURE DEVICE TYPE DISK PARALLELISM 4; komutu, RMAN'in yedekleme sırasında aynı anda 4 farklı sunucu süreci başlatmasını ve iş yükünü bu kanallar arasında dağıtmasını sağlar.
Kanal yönetimi sırasında dikkat edilmesi gereken teknik hususlar şunlardır:
- Dosya Başına Kanal Oranı: Çok sayıda küçük kanal mı yoksa az sayıda büyük kanal mı kullanılacağı, alttaki depolama mimarisinin (LUN yapısı, ASM disk grupları vb.) I/O kapasitesine göre belirlenmelidir.
- Max Piece Size: Bazı dosya sistemleri çok büyük dosyaları desteklemeyebilir.
CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 10G;ayarı, RMAN'in oluşturduğu yedek parçalarının boyutunu sınırlandırarak yönetilebilirliği artırır.
Rman Parametreleri (3): Optimizasyon ve Otomatik Yedekleme
RMAN optimizasyonu (CONFIGURE BACKUP OPTIMIZATION ON;), RMAN'in daha önce yedeklenmiş ve üzerinde değişiklik yapılmamış dosyaları (özellikle salt okunur tablespace'ler ve daha önce yedeklenmiş arşiv logları) tekrar yedeklemesini engeller. Bu özellik, gereksiz I/O ve depolama kullanımını minimize eder.
Kontrol dosyası ve SPFILE’ın otomatik yedeklenmesi (CONFIGURE CONTROLFILE AUTOBACKUP ON;), veritabanı yapısında meydana gelen her değişiklikten sonra ve her yedekleme işleminin sonunda bu kritik dosyaların bir kopyasının alınmasını sağlar. Bu, felaket anında kontrol dosyası olmadan bile veritabanını kurtarabilmek için en önemli emniyet mekanizmasıdır.
Rman Parametreleri (4): Sıkıştırma ve Şifreleme Algoritmaları
Veri miktarının hızla arttığı günümüzde, yedeklerin sıkıştırılması ve güvenliği için şifrelenmesi modern DBA’lerin vazgeçilmezidir.
Sıkıştırma (Compression) Algoritmaları
RMAN, yedek kümelerini (backup sets) oluştururken çeşitli algoritmalarla sıkıştırma yapabilir. Sıkıştırma işlemi CPU yoğun bir süreçtir; bu nedenle hız ve sıkıştırma oranı arasında bir denge kurulmalıdır.
Algoritma | Açıklama | Lisans ve Kullanım
BASIC | BZIP2 tabanlıdır. Yüksek sıkıştırma sağlar ancak CPU kullanımı fazladır | Ücretsizdir (Standard/Enterprise)
LOW | LZO tabanlıdır. En hızlı algoritmadır, CPU üzerindeki etkisi minimaldir | Advanced Compression Option gerektirir.
MEDIUM | ZLIB tabanlıdır. Hız ve sıkıştırma oranı arasında iyi bir denge sunar. | Advanced Compression Option gerektirir.
HIGH | Maksimum sıkıştırma oranına odaklanır. Çok yüksek CPU tüketir. | Advanced Compression Option gerektirir.
Şifreleme (Encryption) Yapılandırması
Yedeklerin yetkisiz erişime karşı korunması amacıyla AES128, AES192 veya AES256 algoritmalarıyla şifreleme yapılabilir. CONFIGURE ENCRYPTION FOR DATABASE ON; komutuyla aktif edilen bu özellik, özellikle Tape yedeklerinin fiziksel olarak çalınması durumunda verinin okunamaz olmasını garanti eder.
RMAN Backup: Fiziksel Yapılar ve Stratejiler
RMAN yedekleme süreci, veritabanı yöneticisinin belirlediği stratejiye göre fiziksel olarak iki farklı formatta gerçekleşebilir: “Backup Sets” ve “Image Copies”.
Backup Sets ve Backup Pieces
RMAN’in varsayılan yedekleme formatıdır. Bir “Backup Set”, bir veya birden fazla veri dosyasının veritabanı bloklarının sıkıştırılmış ve boş bloklardan arındırılmış bir koleksiyonudur. Backup setler fiziksel olarak “Backup Piece” adı verilen işletim sistemi dosyalarından oluşur.
Bu parçalama işlemi, özellikle çok büyük veri dosyalarının (Bigfile Datafiles) paralel kanallar tarafından aynı anda yedeklenebilmesi için “Section Size” parametresiyle desteklenir.
Image Copies
Veri dosyalarının bit-bit kopyalarıdır. Image copy formatı sıkıştırmayı desteklemez ancak “Switch to Copy” komutuyla veritabanının bir veri dosyası bozulduğunda saniyeler içinde yedek kopyasına geçiş yapmasına olanak tanır. Bu, kurtarma süresi hedefi (RTO) çok düşük olan sistemler için idealdir.
Incremental Backup Stratejileri
RMAN’in en güçlü yanlarından biri, yalnızca değişen veri bloklarını içeren artımlı yedekleme yapabilmesidir. Bu strateji, günlük yedekleme pencerelerini ve ağ trafiğini optimize eder.
- Level 0 (Baz Yedek): Artımlı yapının temelidir. Fiziksel olarak tam bir yedekleme (full backup) ile aynıdır ancak kataloğa artımlı yedeklemenin başlangıç noktası olarak kaydedilir.
- Level 1 Differential (Diferansiyel): En son alınan Level 0 veya Level 1 yedeklemesinden sonra değişen blokları yedekler. Varsayılan artımlı yedekleme türüdür.
- Level 1 Cumulative (Kümülatif): En son alınan Level 0 yedeklemesinden sonra değişen tüm blokları yedekler. Kurtarma sırasında daha az dosya gerektirdiği için daha hızlıdır ancak yedek dosyası daha büyük olabilir.
Kurumsal ortamlarda genellikle Pazar günleri Level 0, diğer günler Level 1 diferansiyel yedekleme alınarak dengeli bir yapı kurulur.
Performans Optimizasyonu ve Darboğaz Analizi
Yedekleme performansını etkileyen üç ana faz vardır: Okuma (Read), Kopyalama (Copy) ve Yazma (Write). DBA’lerin bu fazlardaki darboğazları teşhis etmesi gerekir.
- Read Phase: Veri bloklarının diskten okunması aşamasıdır. Asenkron I/O kullanımı (
DISK_ASYNCH_IO=TRUE) veMAXOPENFILESparametresi ile optimize edilir. - Copy Phase: Verinin bellek tamponları (buffers) arasında taşınması ve sıkıştırılması aşamasıdır. CPU kaynakları ve Large Pool alanı bu aşamada kritiktir.
- Write Phase: Verinin nihai yedekleme ortamına (disk veya Tape) yazılmasıdır. Tape birimleri için “Tape Buffer” ayarları ve blok boyutları bu aşamada rol oynar.
V$BACKUP_SYNC_IO ve V$BACKUP_ASYNC_IO görünümleri, I/O süreçlerinin etkinliğini izlemek için kullanılır. Eğer V$BACKUP_SYNC_IO içinde çok sayıda satır görülüyorsa, sistemin asenkron I/O'dan yararlanamadığı ve disk kölesi (I/O slaves) yapılandırmasına (DBWR_IO_SLAVES) ihtiyaç duyabileceği anlaşılır.
RAC Ortamlarında RMAN ve Snapshot Controlfile
Oracle Real Application Clusters (RAC) ortamlarında RMAN kullanımı, tüm düğümlerin veriye ve yedekleme dosyalarına ortak erişimini gerektiren ek karmaşıklıklar sunar. RAC ortamındaki en yaygın hatalardan biri olan ORA-00245, snapshot controlfile'ın paylaşımlı bir alanda bulunmamasından kaynaklanır.
RMAN, yedekleme sırasında kontrol dosyasının tutarlı bir anlık görüntüsünü (snapshot) oluşturur. 11gR2 ve sonraki sürümlerde, herhangi bir RAC düğümü yedekleme işlemini başlatabileceğinden, bu snapshot dosyasının tüm düğümler tarafından görülebilen ASM veya NFS gibi paylaşımlı bir depolama alanında olması zorunludur. Varsayılan olarak yerel dizinde ($ORACLE_HOME/dbs) oluşturulan bu dosyanın paylaşımlı alana taşınması CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+DATA/DB/snapcf_prod.f'; komutuyla gerçekleştirilir.
Sorun Giderme ve RMAN Bakım Komutları
Yedekleme dosyalarının bütünlüğü ve kataloğun güncelliği, periyodik bakım işlemleriyle sağlanmalıdır. DBA’lerin elindeki en önemli bakım araçları CROSSCHECK ve DELETE komutlarıdır.
- CROSSCHECK: RMAN kataloğundaki kayıtlar ile disk/Tape üzerindeki fiziksel dosyaları karşılaştırır. Dosya yerinde yoksa kaydı “EXPIRED” olarak işaretler.
CROSSCHECK BACKUP;veCROSSCHECK ARCHIVELOG ALL;komutları bu işlem için kullanılır. - DELETE EXPIRED: Fiziksel olarak silinmiş ancak katalogda kaydı kalmış olan “EXPIRED” statüsündeki kayıtları temizler.
- DELETE OBSOLETE: Retention policy’e göre artık ihtiyaç duyulmayan ve kurtarma penceresinin dışında kalmış yedekleri fiziksel olarak siler.
ARCHIVE LOG dosyalarının manuel olarak işletim sistemi üzerinden silinmesi durumunda RMAN yedeklemeleri RMAN-06059 hatasıyla kesilebilir. Bu durumda CHANGE ARCHIVELOG ALL CROSSCHECK; komutu ile RMAN'in eksik dosyaları fark etmesi ve yedekleme işlemine devam etmesi sağlanır.
Kaynaklar
RMAN Database Backup and Recovery Essentials — Bacula Systems
RMAN Backup Concepts — Oracle Help Center
8 RMAN Backup Concepts — Oracle Help Center
Recovery Manager Architecture — Oracle Help Center
Mastermind of Oracle Database Backup: Oracle RMAN — ijirset
RMAN Recipes for Oracle Database 12c
Oracle Compression: Concepts & Usage
Configure RMAN Recovery Catalog — DBA Genesis Support
RMAN : CONFIGURE YOUR RMAN ENVIRONMENT — Expert Oracle
Enabling the Oracle RMAN Recovery Catalog
How to configure an RMAN catalog for backup of an Oracle database.
Preparing the RMAN DUPLICATE Auxiliary Instance: Basic Steps
2 Connecting to Databases with RMAN
24 Troubleshooting RMAN Operations — Oracle Help Center
Monitoring RMAN Through V$ Views
3.4 Setting Up a Database for RMAN Backup
RMAN Commands Overview1 — Full And Incremental Backup | by …
23 Tuning RMAN Performance — Oracle Help Center
RMAN | PDF | Backup | Oracle Database — Scribd
19 Performing Block Media Recovery — Database — Oracle Help Center
PowerProtect Data Manager 19.9 Oracle RMAN Agent User Guide
Secure External Password Store for RMAN Backup — Datavail
Oracle Create a Wallet to Store Secure User Credentials for RMAN …
RMAN Configure Command — Julian Dyke
Configuring the RMAN — Oracle DBA solutions — WordPress.com
Configuring RMAN | Technology Blog — WordPress.com
Recovery Manager (RMAN) Performance Tuning Best Practices
Enhancing RMAN Performance: Key Concepts and Practical Tips
6 Configuring the RMAN Environment: Advanced Topics
RMAN real usage of MAXSETSIZE, MAXPIECESIZE, FILESPERSET …
New RMAN Compression Algorithm in 11g | Oracle-Hands-On
RMAN Backup Compression — Am I using Advanced … — Oracle Forums
Oracle Licensing and the Advanced Compression Option
RMAN and Advanced Compression | Kevin Kempf’s Blog
12 Managing Backup Encryption — Oracle Help Center
Encryption RMAN Backup — Pythian
RMAN Incremental Differential vs Cumulative & Demo
Oracle RAC Administration : Backing up your RAC with RMAN
Cannot catalog snapshot controlfile in Recovery Area, RAC 11g
ORA-00245: Control File Backup Failed; Target is Likely on a Local …
SNAPSHOT CONTROLFILE Is Not a Backup Copy of a Control File
RMAN Issues after Switchover or Failover — Dbvisit Support
Reporting and Monitoring RMAN Backups | PDF — Scribd
RMAN-06059: expected archived log not found — Veritas
RMAN-06059: expected archived log not found … — POiSON WORLD
Oracle RMAN-06059 expected archived log not found, loss of …
Useful RMAN Backup & Recovery & Restore Scripts | Oracle DBA …
Oracle 19c & 21c: New Features Every DBA Should Know — Medium
2 New Features in 19c Release Updates — Oracle Help Center
메타데이터
- post_id
- c6ccf66a67ec
- slug
- oracle-19c-dba-serisi-database-management-and-data-protection-strategies-an-in-depth-technical-c6ccf66a67ec
- url
- https://medium.com/@muratculum/oracle-19c-dba-serisi-database-management-and-data-protection-strategies-an-in-depth-technical-c6ccf66a67ec
- canonical_url
- https://medium.com/@muratculum/oracle-19c-dba-serisi-database-management-and-data-protection-strategies-an-in-depth-technical-c6ccf66a67ec
- author_url
- https://medium.com/@muratculum
- status
- ok
- fetched_at
- 2026-06-21 07:44:09