Di mana mulai memahami database yang tidak dikenal

12

Jadi, judulnya merangkumnya.

Saya punya database SQL Server dengan 28 tabel dan 86 prosedur tersimpan yang harus direkayasa balik. Saya cukup yakin bahwa beberapa tabel tidak pernah digunakan dan tidak semua procs digunakan juga.

Masalah terbesar adalah bahwa semua Layanan Windows yang dibuat untuk digunakan dengan DB ini dan semua perangkat lunak dan dokumentasi basis data hilang, dan orang yang merancang seluruh sistem tidak dapat ditemukan.

Saya sudah berhasil membuat diagram ER untuk membantu saya memahami hubungan, tetapi karena saya tidak berpengalaman dalam administrasi basis data, saya tidak tahu harus mulai dari mana.

Saya juga minta maaf jika pertanyaan semacam ini tidak dimaksudkan untuk ditanyakan di sini.

sql-server documentation Manusia_Setelah Semua
sumber
1
Saya tidak mengikuti. Anda memiliki akses penuh ke db dan Anda tahu Anda memiliki 86 prosedur toko untuk merekayasa balik. Jadi ini adalah prosedur tersimpan terenkripsi? Apa sebenarnya yang Anda butuhkan untuk merekayasa balik?
paparazzo
Oh benar Pertanyaan Anda masuk akal: db berfungsi, tetapi benar-benar berantakan. Indeks yang buruk, tipe data yang salah, tidak dinormalisasi, dan itu semua diringkas sebagai kinerja yang buruk ... Tapi berhasil.
Human_AfterAll
Pastikan Anda juga siap secara emosional. Merangkul dan menerima tantangan Anda. Gagal melakukannya akan menyebabkan gesekan mental dalam seluruh perjalanan Anda.
Christiaan Westerbeek
Tentu! Terima kasih atas tipnya! Persiapan emosional adalah salah satu langkah terpenting (jika tidak paling penting).
Human_AfterAll

Jawaban:

5

Tiga langkah sangat cepat untuk memulai:

1)

USE DatabaseName

SELECT    [TableName] = OBJECT_NAME(object_id),
last_user_update, last_user_seek, last_user_scan, last_user_lookup
FROM    sys.dm_db_index_usage_stats
WHERE    database_id = DB_ID('DatabaseName')

Akan memberi tahu Anda kapan terakhir kali setiap indeks digunakan, termasuk indeks berkerumun. Jadi setidaknya memberi Anda rasa yang tabelnya sedang diakses (dan yang tidak.)

2) Aktifkan sesi Peristiwa Diperpanjang (atau jejak Profiler sisi server jika Anda menjalankan pra-SQL 2012) selama satu jam atau lebih saat aplikasi sedang digunakan. Anda juga dapat meminta pengguna untuk melakukan berbagai tindakan dalam aplikasi dalam urutan tertentu sehingga Anda dapat menghubungkannya dengan jejak / sesi.

Saran yang sangat membantu: jika Anda dapat memodifikasi string koneksi yang digunakan aplikasi sama sekali, tambahkan "; Nama Aplikasi = AppNameGoesHere" sehingga Anda dapat menjalankan pemfilteran jejak pada Nama Aplikasi tersebut. Latihan yang bagus.

3) Dapatkan versi aplikasi yang berfungsi pada server non-produksi. Kembangkan daftar tes yang didorong perilaku untuk aplikasi ("Ketika pengguna mengklik tombol Item Baru, itu menciptakan item baru untuk pengguna itu," dll.) Mulailah menghapus objek yang Anda rasa tidak ada hubungannya dengan tes dengan mengubah nama mereka (Saya menggunakan format seperti objectName_DEPRECATED_YYYYMMDD - dengan tanggal adalah hari saya berencana untuk benar-benar menghapusnya.) Verifikasi ulang semua tes Anda.

Melalui kombinasi sesi Peristiwa Diperpanjang, DMV penggunaan indeks, dan penghapusan lunak Anda, Anda harus dapat mengidentifikasi objek utama yang digunakan oleh aplikasi dan konsensus umum yang baik tentang objek mana yang melakukan apa.

Semoga berhasil!

Kyle Hale
sumber
7

Taruhan terbaik Anda untuk memulai adalah mendokumentasikan database Anda menggunakan SQL Power Doc

SQL Server & Dokumentasi Windows Menggunakan Windows PowerShell

SQL Power Doc adalah kumpulan skrip dan modul Windows PowerShell yang menemukan, mendokumentasikan, dan mendiagnosis instance SQL Server serta konfigurasi OS & mesin Windows yang mendasarinya. SQL Power Doc bekerja dengan semua versi SQL Server dari SQL Server 2000 hingga 2014, dan semua versi Windows Server dan konsumen Sistem Operasi Windows dari Windows 2000 dan Windows XP melalui Windows Server 2012 R2 dan Windows 8. SQL Power Doc juga mampu mendokumentasikan Windows Azure SQL Database.

Catatan: Saya telah menggunakannya dan ini akan memberi Anda awal yang sangat baik dalam mendokumentasikan dan memahami contoh server database Anda.

Kin Shah
sumber
Terima kasih. Ini pasti akan menambah serangkaian langkah yang harus saya buat untuk memahami DB terkutuk ini
Human_AfterAll
Hei! Saya benar-benar buruk dengan PowerShell dan tidak bisa melewati New-Item -type directory -path "$([Environment]::GetFolderPath([Environment+SpecialFolder]::MyDocuments))\WindowsPowerShell\Modules"langkah itu pada SqlServerInventory ReadMe.txtfile. Saya tidak tahu di mana saya harus memasukkan jalur ke folder yang baru dibuat dan di mana saya harus memasukkan nama folder yang baru dibuat.
Human_AfterAll
3

Karena saya pernah berada dalam situasi yang sama, saya dapat memberitahu Anda bahwa ini akan menjadi pekerjaan yang sulit dan mustahil. Saya hanya memiliki kode sumber (> 100k baris kode), layanan yang berjalan, database yang berjalan (~ 50 tabel) dan tidak ada dokumentasi dan tidak ada yang bertanya tentang hal itu kecuali pengguna aplikasi ini dan salinan dari database dan layanan yang berjalan di lingkungan pengujian (yang beberapa nomor versi di depan tetapi tanpa kode sumber). Persyaratan lain adalah layanan harus dijalankan 24/7 karena mereka eksternal bagi pelanggan. Situasi muncul karena sebagian besar staf pergi pada waktu yang sama termasuk pengembang dan dokumentasi lenyap dalam kekacauan. Butuh lebih dari 6 bulan untuk mendapatkan gambaran umum / dokumentasi kasar. Ada banyak tabel dan fungsi yang tidak memiliki efek karena mereka untuk digunakan di masa depan atau tidak pernah sepenuhnya diimplementasikan, fitur yang salah atau usang atau tidak dirilis. Setelah 6 bulan saya harus menulis ulang dokumentasi karena saya menemukan hal-hal baru atau hubungan antara hal-hal dan saya memiliki asumsi yang salah sebelumnya.

Mengapa saya mengatakan ini? Karena kadang-kadang dalam situasi seperti itu lebih mudah dan lebih murah untuk memulai dari awal dan menulis aplikasi baru yang memenuhi persyaratan yang lama (atau yang baru jika mereka berubah dari waktu ke waktu atau Anda ingin rilis besar baru). Atau untuk memberi tahu Anda apa yang harus Anda harapkan.

Jika Anda benar-benar ingin merekayasa balik, saya akan merekomendasikan langkah-langkah berikut:

  • Buat cadangan seluruh sistem! (Pertama: Anda tidak akan pernah tahu kapan Anda akan membutuhkannya. Kedua: Anda membutuhkannya untuk langkah berikutnya)
  • buat ulang salinan sistem (layanan dan basis data) untuk bekerja dan tulis cara membuatnya karena Anda pasti harus melakukan ini beberapa kali dalam beberapa bulan mendatang karena Anda akan mengacaukannya beberapa kali saat membalikkan rekayasa
  • membuat diagram ER dengan dependensi di antara tabel
  • melihat dan mendokumentasikan dependensi setiap tabel, prosedur tersimpan, ... karena ini sebagian besar tidak termasuk dalam diagram ER
  • memahami apa yang harus dilakukan oleh perangkat lunak dengan meminta pengguna dan menggunakannya sendiri (sebaiknya lakukan pada sistem pengujian)
  • Jika kode sumber layanan tersedia: dapatkan tinjauan umum dan panggilan ke DB dan dokumentasikan (doxygen adalah alat yang baik untuk mendapatkan dokumentasi kasar dengan hierarki panggilan fungsi)
  • cobalah untuk mendapatkan gambaran umum kasar dari DB dengan melihat nama-nama tab dan kolom-kolomnya
  • lihat database saat menggunakannya
  • dengan 4 langkah sebelumnya, bagilah tabel dalam 3 kategori (mungkin berbeda untuk Anda tergantung pada aplikasi Anda): data statis (data yang tidak berubah saat menjalankan server seperti konfigurasi server, enum untuk membatasi nilai yang valid di tabel lain dengan menggunakan kunci asing untuk itu , ...), data konfigurasi (data yang jarang berubah seperti pengaturan pengguna, ...) dan data OLTP (pesan pengguna di server obrolan, pos di forum, nilai pengukuran dalam sistem kontrol mesin, pertempuran dalam game online, ...)
  • ulangi 5 langkah sebelumnya sampai Anda puas atau Anda menyerah
  • Dokumentasikan dan kode seolah-olah orang yang pada akhirnya memelihara kode / sistem / database ANDA akan menjadi psikopat kejam yang tahu di mana Anda tinggal.

Semoga beruntung;)

H. Idden
sumber
1
-1, Siapa pun yang menganggap "lebih mudah dan lebih murah untuk memulai dari awal dan menulis ulang semua" aplikasi besar tidak pernah benar-benar melakukannya. Ini adalah saran amatir.
BlueRaja - Danny Pflughoeft
@ BlueRaja-DannyPflughoeft Tergantung pada jenis, ukuran dan keadaan aplikasi dan persyaratan untuk kompatibilitas mundur. Saya telah menulis ulang aplikasi dari awal dengan sekitar 100rb LoC. Tidak ada persyaratan untuk meniru yang asli tetapi dirilis sebagai versi utama baru dengan beberapa fungsi baru ditambahkan, beberapa fungsi lama dihapus, antarmuka pengguna yang dimodernisasi dan kemampuan untuk menggunakan data lama. Kode asli sangat kacau dan bencana keamanan sehingga kami lebih cepat dari perkiraan waktu untuk membersihkan kode lama.
H. Idden
Terutama jika kode berisi banyak solusi tidak berdokumen, sering terjadi, bahwa sedikit perubahan menabrak sesuatu yang sama sekali tidak berhubungan. Tapi saya setuju dengan Anda, bahwa banyak yang meremehkan biaya (tenaga kerja, uang, ..) untuk melakukannya dari awal karena mereka tidak tahu atau meremehkan persyaratan penuh aplikasi, terutama ketika itu telah tumbuh dan berubah selama bertahun-tahun.
H. Idden