Blog Pengauditan Cognos - Petua dan Trik untuk Persekitaran Volume Besar & Tinggi

Blog oleh John Boyer dan Mike Norris.

Pengenalan

Penting untuk mempunyai kemampuan Pengauditan Cognos untuk mengetahui dan memahami bagaimana Cognos digunakan oleh komuniti pengguna anda dan membantu menjawab soalan seperti:

• • Siapa yang menggunakan sistem ini?
  • Laporan apa yang mereka jalankan?
  • Berapa masa laporan dijalankan?
  • Dengan bantuan alat lain, seperti MotioCI, kandungan apa yang tidak digunakan?

Memandangkan betapa pentingnya menjaga persekitaran Analisis Cognos yang sihat, tidak banyak yang ditulis mengenai pangkalan data pengauditannya di luar dokumentasi produk standard. Mungkin, ini dianggap tidak wajar, tetapi organisasi yang menggunakannya tahu bahawa lama-kelamaan menyoal jadual Pangkalan Data Audit akan mula perlahan - terutama jika organisasi anda mempunyai banyak pengguna yang menjalankan banyak laporan dan mempunyai banyak sejarah. Lebih-lebih lagi, aktiviti audit pembalakan itu sendiri mungkin tertunda kerana sedang dalam antrian ketika tidak dapat ditambahkan ke pangkalan data dengan cepat, misalnya. Ketika itulah anda mula memikirkan prestasi pangkalan data seperti yang anda lakukan dengan pangkalan data operasi yang mempunyai keperluan pelaporan.

Jadual besar biasanya memperlihatkan prestasi pertanyaan. Semakin besar jadual, semakin lama masa yang diperlukan untuk memasukkan dan membuat pertanyaan. Ingat bahawa jadual ini dan Pangkalan Data Audit pada dasarnya adalah pangkalan data operasi; penulisan berlaku dengan kerap dan menentang kami kerana kami tidak dapat memfokuskannya hanya untuk operasi baca seperti yang anda lakukan dengan data mart.

Sama seperti kedai kandungan, kesihatan persekitaran Cognos juga mesti mengambil kira kesihatan Pangkalan Data Audit. Pertumbuhan Pangkalan Data Audit yang tidak terbatas dapat menjadi masalah dari masa ke masa dan akhirnya dapat mempengaruhi prestasi keseluruhan persekitaran Cognos. Di banyak organisasi yang mempunyai peraturan luaran, mereka tidak mempunyai rekod audit penuh dapat menyebabkan mereka berada dalam situasi ketidakpatuhan dengan akibat yang berat. Oleh itu, bagaimana kita menangani perlu menyimpan begitu banyak data untuk tujuan pengauditan sejarah - dalam beberapa kes hingga 10 tahun - namun masih mendapat pelaporan yang kita perlukan untuk menjaga persekitaran dan membuat pengguna senang dengan prestasi tersebut?

Cabaran

• • Pertumbuhan Pangkalan Data Audit yang tidak terbatas memberi kesan negatif terhadap kesihatan persekitaran Cognos
  • Melaporkan Pangkalan Data Audit menjadi lambat atau tidak dapat digunakan
  • Cognos mengalami kelewatan rekod yang ditulis ke Pangkalan Data Audit
  • Pangkalan Data Audit kehabisan ruang cakera

Semua ini bermaksud bahawa bukan hanya laporan yang bergantung pada Pangkalan Data Audit yang menderita, tetapi selalunya keseluruhan sistem. Sekiranya Pangkalan Data Audit berada di pelayan yang sama dengan kedai kandungan Cognos, prestasi semua perkara yang akan dipengaruhi oleh Cognos di persekitaran tersebut.

Persediaan

Kami menganggap:

1. 1. Cognos Analytics dipasang dan dijalankan
   2. Cognos dikonfigurasi untuk log ke Pangkalan Data Audit
   1. • Mempunyai Pangkalan Data Audit
      • Tetapkan tahap pembalakan Audit yang sesuai dalam pentadbiran Cognos
      • Rekod sedang ditulis ke pangkalan data oleh Cognos
   3. Pangkalan Data Audit telah digunakan lebih dari setahun
   4. Persekitaran sangat aktif dengan pengguna dan pelaksanaan
   5. Pakej Audit digunakan untuk menampilkan data penggunaan Cognos
   6. Kami berusaha untuk meningkatkan prestasi pelaporan Pangkalan Data Audit
   7. Memulakan atau menghapus rekod lama tidak selalu menjadi pilihan

Jika belum, Cognos Audit dipasang dan dikonfigurasi, Lodestar Solutions, a Motio rakan kongsi, mempunyai yang cemerlang hantar untuk membolehkan Audit di Cognos BI / CA.

Penyelesaian

Terdapat beberapa kemungkinan penyelesaian yang muncul dengan cepat:

1. 1. Kurangkan jumlah data dengan:
   1. • Memindahkan beberapa data lama ke pangkalan data lain
      • Memindahkan beberapa data lama ke jadual lain dalam pangkalan data yang sama
   2. Cukup padam atau arkahive sebahagian data dan jangan risau
   3. Hidup dengannya. Menendang tin ke bawah road dan mendorong Pentadbir Pangkalan Data untuk prestasi
      penambahbaikan sambil memborgolnya dengan tidak membenarkan perubahan skema atau
      indeks

Kami tidak akan berurusan dengan pilihan 3. Pilihan 2, menghapus data, bukanlah pilihan yang baik dan saya akan mengesyorkan untuk mengekalkan nilai sekurang-kurangnya 18 bulan. Tetapi, jika anda cenderung, IBM menyediakan utiliti, AuditDBCleanup (Cognos BI) atau a skrip (Analisis Cognos) yang akan melakukan perkara itu. Utiliti untuk Cognos BI menghapus rekod berdasarkan cap waktu sementara skrip untuk Cognos Analytics hanya menghapus indeks dan jadual.

Cadangan yang kami buat kepada pelanggan sebelum ini adalah untuk memisahkan kepada dua pangkalan data:

1. 1. Audit - Langsung: mengandungi data bernilai minggu terakhir
   2. Audit - Sejarah: mengandungi data sejarah (hingga N tahun)

Ringkasnya, proses ini dijalankan setiap minggu untuk memindahkan rekod terkini dari Audit Live ke Audit Historical. Live Audit bermula sebagai slate kosong setelah proses ini dijalankan.

1. 1. Live DB cepat dan ketat, membolehkan sisipan berlaku secepat mungkin
   2. Pertanyaan audit ditujukan secara eksklusif ke DB Sejarah

Dengan menggunakan pendekatan ini, tidak ada "penyatuan bersama" secara langsung dari data Langsung dan data Sejarah. Saya berpendapat bahawa anda mungkin mahu menyimpannya seperti itu.

Dalam Pentadbiran Cognos, anda boleh menambahkan dua sambungan berbeza untuk Sumber Data Audit. Apabila pengguna menjalankan laporan terhadap pakej Audit, mereka akan diminta untuk sambungan mana yang ingin mereka gunakan:

Jika anda ingin melihat data audit langsung dan bukannya data audit sejarah, anda hanya memilih sambungan "Audit - Langsung" ketika diminta (harus menjadi pengecualian, bukan norma.)

Sekiranya anda BENAR-BENAR juga ingin memberikan gambaran gabungan mengenai Live dan Historical, anda boleh melakukannya, tetapi ini akan mempengaruhi prestasi.

Sebagai contoh, anda boleh membuat Pangkalan Data ke-3 yang disebut "Audit - Gabungan Paparan" dan kemudian, untuk setiap jadual dalam skema Audit: buat pandangan bernama yang sama dengan SQL antara jadual di DB langsung dan jadual di DB sejarah. Begitu juga, ini dapat dicapai dalam model Framework Manager, tetapi, sekali lagi, prestasi akan menjadi pertimbangan utama.

Sebilangan pelanggan kami telah membuat pandangan gabungan. Kami berpendapat bahawa ini mungkin berlebihan. Prestasi akan selalu menjadi lebih buruk dalam pandangan gabungan ini dan kami tidak menemui banyak kes penggunaan yang menggunakan kedua-dua set data Langsung dan Sejarah. Siaran Langsung digunakan untuk menyelesaikan masalah dan Sejarah untuk pelaporan trend.

Sehingga Cognos Analytics 11.1.7, Pangkalan Data Audit telah berkembang menjadi 21 jadual. Anda boleh mendapatkan lebih banyak maklumat di tempat lain di Pangkalan Data Audit, contoh laporan audit dan model Framework Manager. Tahap pembalakan lalai adalah Minimal, tetapi Anda mungkin ingin menggunakan tingkat berikutnya, Dasar, untuk menangkap permintaan penggunaan, pengurusan akun pengguna dan penggunaan waktu proses. Salah satu cara untuk mengekalkan prestasi sistem adalah dengan mengekalkan tahap pembalakan ke tahap terendah yang diperlukan. Jelas, semakin banyak pembalakan yang dilakukan oleh pelayan, prestasi pelayan secara keseluruhan akan terjejas.

Jadual utama yang paling diminati oleh pentadbir adalah 6 jadual yang mencatat aktiviti pengguna dan aktiviti pelaporan dalam sistem.

• COGIPF_USERLOGON: Menyimpan maklumat log masuk pengguna (termasuk log keluar)
• COGIPF_RUNREPORT: Menyimpan maklumat mengenai pelaksanaan laporan
• COGIPF_VIEWREPORT: Menyimpan maklumat mengenai permintaan paparan laporan
• COGIPF_EDITQUERY: Menyimpan maklumat mengenai pertanyaan dijalankan
• COGIPF_RUNJOB: Menyimpan maklumat mengenai permintaan pekerjaan
• COGIPF_ACTION: Merakam tindakan pengguna di Cognos (jadual ini mungkin berkembang lebih cepat daripada yang lain)

Konfigurasi di luar kotak kelihatan seperti ini:

Konfigurasi yang disyorkan:

Pangkalan Data Audit Cognos - Live mengandungi 1 minggu data audit. Data yang lebih tua dari 1 minggu dipindahkan ke Pangkalan Data Audit Cognos - Sejarah.

Garis dari Pangkalan Data Audit Cognos - Pangkalan Data Audit Langsung ke Cognos - Sejarah dalam rajah bertanggungjawab untuk:

• Menyalin data dari Audit Langsung ke Audit Sejarah
• Keluarkan semua baris dalam Audit Langsung yang berumur lebih dari 1 minggu
• Alih keluar semua baris dalam Audit Sejarah yang lebih tua daripada x tahun
• Alih keluar semua baris dalam COGIPF_ACTION yang berumur lebih dari 6 bulan

Indeks

Jenis pangkalan data yang berbeza mempunyai jenis pengindeksan yang berbeza. Indeks pangkalan data adalah struktur data, terkait dengan Tabel (atau Tampilan), digunakan untuk meningkatkan waktu pelaksanaan pertanyaan ketika mengambil data dari tabel tersebut (atau Lihat). Bekerja dengan DBA anda untuk membuat strategi optimum. Mereka ingin mengetahui jawapan untuk soalan seperti ini untuk membuat keputusan terbaik mengenai lajur apa yang akan diindeks. Jelas, pentadbir pangkalan data dapat mengetahui jawapan untuk beberapa atau semua soalan ini tanpa bantuan anda, tetapi memerlukan sedikit penyelidikan dan beberapa saat:

• Berapakah jumlah rekod yang dimiliki oleh jadual dan berapa ukuran yang anda harapkan untuk berkembang? (Pengindeksan jadual tidak akan berguna melainkan jadual mempunyai sejumlah besar rekod.)
• Adakah anda tahu lajur mana yang unik? Adakah mereka membenarkan nilai NULL? Lajur mana yang mempunyai jenis data bilangan bulat atau bilangan bulat besar? (Lajur dengan jenis data berangka dan yang UNIK dan TIDAK BISA adalah calon kuat untuk mengambil bahagian dalam kunci indeks.)
• Di manakah masalah prestasi utama anda hari ini? Adakah mereka dalam mengambil data? Adakah terdapat pertanyaan atau laporan khusus yang lebih banyak masalah? (Ini boleh menyebabkan pentadbir pangkalan data ke beberapa lajur tertentu yang dapat dioptimumkan.)
• Bidang apa yang digunakan dalam menggabungkan jadual untuk melaporkan?
• Bidang apa yang digunakan untuk menyaring, menyusun, mengelompokkan, dan mengumpulkan?

Tidak menghairankan, ini adalah pertanyaan yang sama yang harus dijawab untuk meningkatkan prestasi jadual pangkalan data mana pun.

Sokongan IBM mengesyorkan membuat indeks pada lajur "COGIPF_REQUESTID", "COGIPF_SUBREQUESTID", dan "COGIPF_STEPID" untuk jadual berikut untuk meningkatkan prestasi:

• COGIPF_NATIVEQUERY
• COGIPF_RUNJOB
• COGIPF_RUNJOBSTEP
• COGIPF_RUNREPORT
• COGIPF_EDITQUERY

Ditambah pada jadual lain yang kurang digunakan:

• COGIPF_POWERPLAY
• COGIPF_HUMANTASKSERVICE
• COGIPF_HUMANTASKSERVICE_DETAIL

Anda boleh menggunakannya sebagai titik permulaan, tetapi saya akan menjalani latihan menjawab soalan di atas untuk mendapatkan jawapan terbaik untuk organisasi anda.

Pertimbangan lain

1. Model FM Audit. Ingat bahawa model Framework Manager yang disediakan oleh IBM dimodelkan pada jadual dan medan lalai. Segala perubahan yang anda buat pada jadual pelaporan harus ditunjukkan dalam model. Kemudahan atau kerumitan perubahan ini - atau kecekapan organisasi anda untuk membuat perubahan ini - boleh mempengaruhi penyelesaian yang anda pilih.
2. Medan tambahan. Sekiranya anda akan melakukannya, sekarang adalah masa untuk menambahkan medan tambahan untuk konteks atau data rujukan untuk meningkatkan pelaporan audit.
3. Jadual ringkasan. Daripada hanya menyalin data ke jadual sejarah anda, kompresnya. Anda boleh mengagregat data ke tingkat harian untuk menjadikannya lebih efisien untuk melaporkan.
4. Paparan dan bukannya jadual. Yang lain mengatakan, "Jadi, daripada mempunyai pangkalan data 'semasa' dan pangkalan data 'bersejarah', anda hanya perlu mempunyai satu pangkalan data, dan semua jadual di dalamnya harus diawali dengan 'sejarah'. Kemudian, anda harus membuat satu set paparan, satu untuk setiap jadual yang ingin anda lihat sebagai 'terkini', dan minta setiap paparan menyaring baris sejarah yang anda tidak mahu lihat dan membiarkan hanya yang terkini sahaja yang dilalui. "
   https://softwareengineering.stackexchange.com/questions/276395/two-database-architecture-operational-and-historical/276419#276419

Kesimpulan

Intinya adalah bahawa dengan maklumat yang diberikan di sini, anda harus bersedia untuk mengadakan perbualan yang produktif dengan DBA anda. Kemungkinan besar dia pernah menyelesaikan masalah serupa sebelumnya.

Perubahan yang dicadangkan dalam seni bina Pangkalan Data Audit Cognos akan meningkatkan prestasi dalam pelaporan langsung dan juga aplikasi pihak ketiga yang bergantung padanya, seperti Motio's ReportCard dan Persediaan.

Ngomong-ngomong, jika anda pernah berbual dengan DBA anda, kami ingin mendengarnya. Kami juga ingin mendengar sekiranya anda telah menyelesaikan masalah Pangkalan Data Audit yang kurang berprestasi dan bagaimana anda melakukannya.