Perché abbiamo funzioni non documentate e non supportate in SQL Server?
Dopo aver letto un articolo, datato 2012 , sulle funzioni non documentate fn_dblog e fn_dump_dblog mi chiedevo perché siano ancora prive di documenti e non supportate se esistono da molto tempo e sono piuttosto utili. Lo stesso con questo articolo sp_msforeachtable e sp_msforeachdb del 2004 .
Potrei trarre vantaggio da uno di loro per rispondere a una domanda sul forum ( durante un backup del log i dati vengono sottoposti a backup all'inizio o alla fine dell'operazione? ), Ma mi piacerebbe sapere perché vengono forniti con SQL Server fino ad ora in modo non documentato e non supportato.
Capisco che non siano affidabili, ma se questo fosse l'unico motivo, in 16 anni avrebbero potuto essere corretti. Quindi ci deve essere un'altra spiegazione.
Risposte
Come qualcuno che lavora per un grande fornitore di software, posso dire che le funzionalità 1 non documentate e non supportate rientrano in genere in una di queste tre categorie:
Strumenti ad uso esclusivo dei tecnici dell'assistenza del fornitore. Sono raramente necessari, in genere richiedono una conoscenza approfondita degli interni, difficili da configurare e utilizzare e spesso abbastanza pericolosi da essere protetti da password o chiavi monouso che dovrebbero essere fornite esplicitamente dal fornitore. Non sono mai destinati a diventare caratteristiche del prodotto. Sono lì per aiutare il supporto durante la risoluzione dei problemi di difficile debug.
Correzioni e soluzioni alternative per bug esoterici. Sono implementati come hot fix per situazioni critiche. Tali bug sono rari e le loro cause alla radice vengono alla fine risolte, quindi queste "funzionalità" perdono la loro utilità a quel punto e non è nell'interesse del fornitore fornire loro un supporto continuo.
Funzionalità beta e sperimentali. In genere vengono prima resi disponibili e scarsamente documentati per una piccola coorte di beta tester e importanti clienti che li hanno richiesti. Alcuni di questi alla fine saranno pienamente supportati, altri saranno lasciati lì a marcire quando le parti interessate perdono interesse o quando entrano in conflitto con altre caratteristiche che sono ritenute più importanti o utili.
Come menzionato nei commenti alla tua domanda, ogni funzionalità completamente supportata e documentata comporta un costo per il fornitore e tale costo deve essere giustificato dal beneficio atteso. Se c'è poco vantaggio per il fornitore nel mantenere una certa funzionalità, non c'è motivo di supportarla.
1 - Non sono realmente totalmente privi di supporto; sono supportati in base al "massimo sforzo", che significa "Potremmo avere una nota tecnica da qualche parte che descrive brevemente la funzione, ma non dedicheremo molto tempo ad aiutarti a farla funzionare, e se non funziona o se cancella i tuoi dati, beh, duro ".
Ricordo di averne dovuto usare uno molto tempo fa. Hai mai provato a cambiare il livello di compatibilità SQL di un database dall'interno di una transazione? Risulta che puoi, se copi il contenuto del sp_comando che lo ha fatto. (Dichiarazione di non responsabilità: questo codice doveva funzionare solo esattamente su SQL 2005 e il suo ultimo service pack era già stato rilasciato.)
In passato, le funzionalità a cui dovevi accedere solo dall'interfaccia utente venivano implementate utilizzando vari tipi di sp_comandi o xp_comandi di chiamata con sintassi non standard . xp_i comandi erano cablati, ma in realtà non ce n'erano molti. sp_i comandi contenevano solo TSQL che faceva cose. Il modo in cui sono stati effettivamente implementati non era documentato, ma potresti usarlo sp_helptextper leggere il codice. Farlo di solito era una cattiva idea.
Poi c'è un'altra funzionalità non documentata che le persone usano ancora. Le vecchie funzioni di hash della password di SQL 7 sono ancora presenti e richiamabili. Sono privi di documenti da tempo e nessuno dovrebbe più usarli, ma se hai un'applicazione antica che deve ancora controllare le ultime password modificate nel secolo precedente, è l'unico modo.
E c'era ALTER DATABASE SET EMERGENCYqualcosa di ancora più selvaggio anche nelle versioni precedenti. MS è stata costretta a eseguire un comando documentato appropriato a causa delle persone che hanno trovato il comando non documentato e hanno perso il resto della procedura per usarlo. In questo caso, la pigrizia li ha raggiunti.