Blog saka John Boyer lan Mike Norris.
Pambuka
Penting supaya kemampuan Cognos Auditing bisa digunakake kanggo ngerti lan ngerti kepiye Cognos digunakake dening komunitas pangguna lan mbantu mangsuli pitakon kaya:
-
- Sapa sing nggunakake sistem kasebut?
- Laporan apa sing ditindakake?
- Apa laporan sing mlaku kaping?
- Kanthi pitulung alat liya, kaya MotioCI, konten apa sing ora digunakake?
Ngelingi penting banget kanggo njaga lingkungan Cognos Analytics sing sehat, kaget ora ana sing ditulis babagan database audit ing njaba dokumentasi produk standar. Mungkin, iku dianggep gampang, nanging organisasi sing nggunakake ngerti ngerti manawa suwe-suwe takon tabel Database Audit bakal wiwit alon - luwih-luwih yen organisasi sampeyan duwe akeh pangguna sing mbukak akeh laporan lan duwe sejarah. Apa maneh yaiku logging kegiatan audit dhewe bisa uga ditundha amarga antri nalika ora bisa ditambahake ing basis data kanthi cepet, kayata. Nalika sampeyan wiwit mikir babagan kinerja basis data kaya ing database operasional sing ana syarat nglaporake.
Tabel gedhe biasane kinerja query alon. Tabel sing luwih gedhe, saya suwe saya suwe masang lan pitakon. Elinga yen tabel lan Database Audit iki minangka basis data operasional; nulis asring kedadeyan lan bisa nglawan kita amarga kita ora bisa fokus mung kanggo maca operasi kaya sing sampeyan lakoni karo data mart.
Kaya dene toko konten, kesehatan lingkungan Cognos uga kudu nggatekake kesehatan Database Audit. Wutah Database Audit sing ora diwatesi bisa dadi masalah sajrone wektu lan bisa uga nyebabake kinerja lingkungan Cognos kanthi sakabehe. Ing pirang-pirang organisasi sing duwe peraturan eksternal, ora duwe cathetan audit sing bisa nyebabake kahanan sing ora tundhuk karo akibat sing abot. Dadi, kepiye kita kudu njaga supaya bisa njaga akeh data kanggo tujuan audit sejarah - ing sawetara kasus nganti 10 taun - nanging isih entuk laporan sing dibutuhake kanggo njaga lingkungan lan tetep seneng karo kinerja para pangguna?
Challenge ing
-
- Wutah Database Audit sing ora diwatesi mengaruhi kesehatan lingkungan Kognos kanthi negatif
- Nglaporake ing Database Audit wis alon utawa ora bisa digunakake
- Kognos ngalami keterlambatan cathetan sing ditulis ing Database Audit
- Database Audit wis entek saka ruang disk
Kabeh tegese ora mung laporan sing gumantung ing Database Audit sing nandhang kasusahan, nanging asring kabeh sistem. Yen Database Audit ana ing server sing padha karo toko konten Cognos, kinerja kabeh perkara Kognos bakal kena pengaruh ing lingkungan kasebut.
Persiyapan
Kita nganggep:
-
- Cognos Analytics wis diinstal lan aktif
- Cognos dikonfigurasi kanggo mlebu menyang Database Audit
-
- Duwe Database Audit ing papan kasebut
- Setel level logging Audit sing cocog ing administrasi Kognos
- Rekaman lagi ditulis ing basis data dening Cognos
- Database Audit wis digunakake luwih saka setaun
- Lingkungan aktif banget karo pangguna lan eksekusi
- Paket Audit digunakake kanggo mbukak data panggunaan Cognos
- Kita ngupaya nambah kinerja nglaporake Database Audit
- Miwiti maneh utawa mbusak cathetan lawas ora mesthi dadi pilihan
Yen durung, wis nginstal lan ngatur Cognos Audit, Solusi Lodestar, a Motio mitra, duwe banget kirim kanggo ngaktifake Audit ing Cognos BI / CA.
Solution
Ana sawetara solusi sing bisa ditindakake kanthi cepet:
-
- Ngurangi volume data kanthi:
-
- Ngalih sawetara data lawas menyang database liyane
- Ngalih sawetara data lawas menyang tabel liyane ing basis data sing padha
- Cukup busak utawa busurhive sawetara data lan aja kuwatir
- Urip karo. Nendhang kaleng mudhun road lan push Administrator Database kanggo kinerja
dandan nalika mborgol kanthi ora ngidini ngowahi skema utawa
indeks
Kita ora bakal menehi hasil karo pilihan 3. Opsi 2, mbusak data, dudu pilihan sing apik lan nyaranake paling ora minimal 18 wulan. Nanging, yen sampeyan seneng banget, IBM nyedhiyakake utilitas, AuditDBCleanup (Cognos BI) utawa a script (Cognos Analytics) sing bakal nindakake persis. Utilitas kanggo Cognos BI mbusak data adhedhasar timestamp nalika skrip kanggo Cognos Analytics mung mbusak indeks lan tabel.
Rekomendasi sing wis digawe kanggo klien sadurunge yaiku pisah dadi rong database:
-
- Audit - Live: ngemot data paling anyar suwene seminggu
- Audit - Sejarah: ngemot data sejarah (nganti N taun)
Cekakipun, proses kasebut minggon kanggo mindhah cathetan paling anyar saka Audit Live menyang Audit Sejarah. Audit Langsung diwiwiti minangka papan kosong sawise proses iki mlaku.
-
- Live DB cepet lan kenceng, saéngga sisipan bisa kedadeyan cepet banget
- Pitakon audit diarahake khusus menyang DB Sejarah
Nggunakake pendekatan iki, ora ana implisit "jahitan bebarengan" kanggo data Langsung lan data Sejarah. Aku ujar manawa sampeyan bisa uga tetep tetep kaya ngono.
Ing Administrasi Cognos, sampeyan bisa nambah loro sambungan sing beda kanggo Sumber Data Audit. Nalika pangguna mbukak laporan nglawan paket Audit, dheweke bakal njaluk sambungan sing pengin digunakake:
Yen sampeyan pengin ndeleng data audit langsung lan ora data audit historis, sampeyan mung milih sambungan "Audit - Urip" nalika dijaluk (mesthine kalebu pangecualian, dudu norma.)
Yen sampeyan pancene pengin menehi tampilan gabungan babagan Live lan Sejarah, sampeyan bisa nindakake, nanging bakal nyebabake kinerja.
Contone, sampeyan bisa nggawe Database kaping 3 sing diarani "Audit - Tampilan Gabungan" banjur, kanggo saben tabel ing skema Audit: gawe tampilan sing identik minangka uni SQL ing antarane tabel ing DB langsung lan tabel ing DB sejarah. Kajaba iku, iki uga bisa ditindakake ing model Framework Manager, nanging maneh, kinerja bakal dadi pertimbangan utama.
Sawetara klien nggawe tampilan gabungan. Miturut kita, iki kemungkinan gedhe banget. Kinerja bakal dadi luwih elek ing tampilan gabungan iki lan kita durung nemokake akeh kasus panggunaan sing nggunakake set data Langsung lan Sejarah. Urip digunakake kanggo ngatasi masalah lan Sejarah kanggo nglaporake tren.
Ing Cognos Analytics 11.1.7, Database Audit wis tuwuh dadi 21 tabel. Sampeyan bisa nemokake informasi luwih lengkap ing papan liya ing Database Audit, conto laporan audit lan model Manager Framework. Tingkat ngangkut gawan Minimal, nanging sampeyan bisa nggunakake level sabanjure, Dhasar, kanggo njupuk panjaluk panggunaan, manajemen akun pangguna lan panggunaan runtime. Salah sawijining cara kanggo njaga kinerja sistem yaiku tetep level log ing level paling ngisor sing dibutuhake. Temenan, luwih akeh logging sing ditindakake server, kinerja server sing luwih umum bisa dipengaruhi.
Tabel kunci sing paling disenengi para administrator yaiku 6 tabel sing mlebu kegiatan pangguna lan nglaporake kegiatan ing sistem.
- COGIPF_USERLOGON: Simpen informasi pangguna log (kalebu log off)
- COGIPF_RUNREPORT: Nyimpen informasi babagan eksekusi laporan
- COGIPF_VIEWREPORT: Nyimpen informasi babagan panjaluk tampilan laporan
- COGIPF_EDITQUERY: Nyimpen informasi babagan mbukak pitakon
- COGIPF_RUNJOB: Nyimpen informasi babagan panjaluk proyek
- COGIPF_ACTION: Ngrekam tumindak pangguna ing Cognos (tabel iki bisa tuwuh luwih cepet tinimbang liyane)
Konfigurasi njaba kothak katon kaya iki:
Konfigurasi sing disaranake:
Cognos Audit Database - Live ngemot 1 minggu data audit. Data sing luwih lawas saka 1 minggu dipindhah menyang Cognos Audit Database - Historis.
Baris saka Cognos Audit Database - Live to Cognos Audit Database - Historis ing diagram tanggung jawab kanggo:
- Nyalin data saka Audit Langsung menyang Audit Sejarah
- Copot kabeh baris ing Audit Langsung sing luwih saka 1 minggu
- Copot kabeh baris ing Audit Sejarah sing umure luwih saka x taun
- Copot kabeh baris ing COGIPF_ACTION sing luwih saka 6 wulan
indeks
Jinis database sing beda-beda duwe jinis indeksasi sing beda. Indeks basis data minangka struktur data, digandhengake karo Tabel (utawa Tampilan), sing digunakake kanggo nambah wektu eksekusi pitakon nalika njupuk data saka tabel kasebut (utawa Tampilan). Bisa karo DBA kanggo nggawe strategi paling luweh. Dheweke pengin ngerti jawaban kanggo pitakonan kaya iki kanggo njupuk keputusan paling apik babagan kolom apa sing kudu diindeks. Temenan, administrator basis data bisa nemokake jawaban kanggo sawetara utawa kabeh pitakon kasebut tanpa pitulung sampeyan, nanging butuh riset lan sawetara wektu:
- Pira tabel sing ana ing tabel lan ukuran apa sing sampeyan kira bakal tuwuh? (Ngindeks tabel ora bakal migunani kajaba tabel kasebut akeh cathetan.)
- Apa sampeyan ngerti kolom sing unik? Apa dheweke ngidini nilai NULL? Kolom endi sing duwe jinis data bilangan bunder utawa wilangan bulat? (Kolom kanthi jinis data numerik lan sing UNIQUE lan Dudu Null minangka calon kuwat kanggo melu tombol indeks.)
- Endi masalah kinerja utama sampeyan saiki? Apa dheweke njupuk data? Apa ana pitakon utawa laporan tartamtu sing dadi masalah? (Iki bisa nyebabake administrator database menyang sawetara kolom tartamtu sing bisa dioptimalake.)
- Bidang apa wae sing digunakake ing tabel gabung kanggo nglaporake?
- Kothak apa wae sing digunakake kanggo nyaring, ngurutake, nglompokake, lan nggabungake?
Ora kaget, iki minangka pitakon sing padha sing kudu dijawab kanggo ningkatake kinerja tabel database apa wae.
Dhukungan IBM nyaranake nggawe indeks ing kolom "COGIPF_REQUESTID", "COGIPF_SUBREQUESTID", lan "COGIPF_STEPID" kanggo tabel ing ngisor iki kanggo nambah kinerja:
- COGIPF_NATIVEQUERY
- COGIPF_RUNJOB
- COGIPF_RUNJOBSTEP
- COGIPF_RUNREPORT
- COGIPF_EDITQUERY
Ditambah ing tabel liyane sing kurang digunakake:
- COGIPF_POWERPLAY
- COGIPF_HUMANTASKSERVICE
- COGIPF_HUMANTASKSERVICE_DETAIL
Sampeyan bisa nggunakake iki minangka titik wiwitan, nanging aku bakal nyoba njawab pitakon ing ndhuwur kanggo entuk jawaban sing paling apik kanggo organisasi sampeyan.
Anggit liyane
- Model FM Audit. Elinga yen model Framework Manager sing diwenehake IBM dimodelake ing tabel lan kolom default. Pangowahan sing digawe ing tabel nglaporake kudu dibayangke ing model kasebut. Gampang utawa kompleksitas pangowahan kasebut - utawa kompetensi organisasi sampeyan kanggo nggawe pangowahan kasebut - bisa mengaruhi solusi sing sampeyan pilih.
- Lapangan tambahan Yen sampeyan bakal nindakake, saiki wayahe nambah kolom tambahan kanggo konteks utawa data referensi kanggo nambah nglaporake audit.
- Tabel ringkesan. Aja mung nyalin data menyang tabel sejarah sampeyan, kompres. Sampeyan bisa nggabungake data menyang level awan supaya luwih efisien kanggo nglaporake.
- Ndeleng tinimbang tabel. Wong liya ujar, "Dadi, tinimbang duwe database 'saiki' lan basis data 'sejarah', sampeyan mung kudu duwe siji basis data, lan kabeh tabel kasebut kudu diawali karo 'sejarah'. Banjur, sampeyan kudu nggawe serangkaian tampilan, siji kanggo saben tabel sing pengin dideleng 'saiki', lan saben tampilan nyaring barisan sejarah sing ora pengin sampeyan deleng lan mung saiki sing nembus. ”
https://softwareengineering.stackexchange.com/questions/276395/two-database-architecture-operational-and-historical/276419#276419
kesimpulan
Intine yaiku kanthi informasi sing diwenehake ing kene sampeyan kudu siyap ngobrol kanthi produktif karo DBA. Kemungkinan apik yen dheweke wis ngatasi masalah sing padha sadurunge.
Owahan arsitektur Cognos Audit Database bakal nambah kinerja ing nglaporake langsung uga aplikasi pihak katelu sing gumantung, kayata Motio's ReportCard lan Inventarisasi.
Mangkene, yen sampeyan wis ngobrol karo DBA, kita bakal seneng ngrungokake. Kita uga seneng ngrungokake manawa sampeyan wis ngatasi masalah Database Audit sing ora apik lan cara sampeyan nindakake.