DBA SQL Server : connaissances minimales à avoir?

Salut,

Comme vous le savez je suis DBA Oracle et, b****l, j'ADOOOOOOOOOORE cette base, c'est ma PS5 à moi :bravo::bravo:

MAIS, les clients me demandent de plus en plus de connaître aussi SQL Server.
Je suis donc depuis des mois en auto-formation e, contraint et forcé de connaître cette base, j’aimerais savoir quelles sont, selon vous, les compétences minimales à connaître pour être plus ou moins autonome, sans être un expert de ce SGBD.

Actuellement j'ai bossé sur :
- prise en main de SSMS
- refresh de bases depuis la prod
- backup/restore
- utilisation du Query STore pour fixer un plan d'exécution et examiner pourquoi une requête peut régresser
- utilisation du Database Engine Tuning Advisor
- export/import de données avec BCP

Bien sur il manque plein de choses mais, avant de me lancer dans l'étude des Extended Events, de l'audit, du Data Collector... je voudrais être sur de ne pas faire fausse route.
D'où ma demande de conseils :help:

Merci pour vos retours

Regarde le plan de cours d'Orsys que j'ai mis au point...
https://www.orsys.fr/formation-sql-s...istration.html

Tous ces poins sont fondamentaux et essentiels.

Lire aussi notre livre SQL Server 2014 (1238 pages) en complément.

La philosophie SQL Server est très différentes de cette de Oracle.

• Oracle est un produit "brouillon" au niveau des outils d'administration. De nombreux outils ont été racheté, Oracle n'ayant pas fait d'éffort de ce côté là. On peut citer Golden Gate ou RMan il en résulte de grande difficultés pour les faire coopérer (c'est encore pire dans PostGreSQL).... tandis que dans SQL Server tout a été pensé et fabriqué par Microsoft.
• SQL Server est aussi très respectueux du standard SQL et est devenu un des moteurs de la norme SQL. oracle à toujours voulu faire son propre SQL (TO_CHAR, CONNECT BY, NLS...) et aujourd'hui s'en mord les doigts
• Enfin, aujourd'hui SQL Server est plus fiable, plus sécurisé et plus performant qu'Oracle... Et beaucoup moins cher ! raison pour laquelle de nombreuses boites fuient oracle au profit de PG pour les petites base et de SQL Server pour les grosses!
• C'est aussi le SGBDR le plus documenté au monde

A +

En même temps Oracle propose des fonctionnalités que SQL Server n'a pas en termes de requêtage. Le CONNECT BY justement, le PARTITIONED OUTER JOIN, la clause MODEL, le Pattern Matching, etc.
En plus en parlant doc, je pense qu'Oracle n'a pas à palir de ce côté là, et c'est plutôt bien fait. Sur SQL Server ça m'a l'air plutôt désordonné. Exemple, je veux chercher le manuel SQL pour savoir ce que je peux faire en SQL sur SQL Server (instructions, fonctions natives), je me retrouve sur ce site:

https://docs.microsoft.com/en-us/sql...l-server-ver15

Bon, maintenant j'essaie de trouver le manuel SQL. J'ai l'impression que c'est le truc qui s'appelle "Query Data", mais le sous-menu est bizarrement découpé:

Transact-SQL (T-SQL)
SQL PowerShell
Scripting
Joins
Full-text search
Synonyms

C'est quoi Transact-SQL, c'est du SQL, du pseudo PL/SQL?

Dans Oracle c'est quand même plus clair, un seul manuel SQL qui explique les concepts (opérateurs, jointures, types de données, fonctions natives, ..) ainsi que la syntaxe de toutes les instructions SQL:
https://docs.oracle.com/en/database/...lrf/index.html

Transact-SQL pour moi c'est le PL/SQL d'Oracle.

Tiens, RMAN a été racheté par Oracle, tu es sur?

SQL Server respecte la norme SQL? Je ne savais pas que dans la norme SQL le mot clé FROM était optionnel... tout fout le camp! Sous SQL Server on peut faire un

Code:

---

SELECT 'NOM', 'PRENOM';

---

chose impossible sous Oracle.

Tiens, je me demande si le lien vers la formation Orsys n'est pas celle que j'ai faite début 2019 à Rueil Malmaison.

Citation:

---

Envoyé par Ikebukuro

Transact-SQL pour moi c'est le PL/SQL d'Oracle.

Tiens, RMAN a été racheté par Oracle, tu es sur?

SQL Server respecte la norme SQL? Je ne savais pas que dans la norme SQL le mot clé FROM était optionnel... tout fout le camp! Sous SQL Server on peut faire un

Code:

---

SELECT 'NOM', 'PRENOM';

---

chose impossible sous Oracle.

Tiens, je me demande si le lien vers la formation Orsys n'est pas celle que j'ai faite début 2019 à Rueil Malmaison.

---

C'est bien pire avec oracle qui impose la table DUAL pour éviter de recourir à un SELECT sans FROM.
Principe n°1 : on ne trouve dans une base de données que ce qu'on y a mis (dixit Franck Edgar Codd). Sur ce plan Oracle viole allègrement cette règle ! Parlons du ROWID, du ROWNUM et de toutes les pseudo colonne des tables....


A +

Citation:

---

Envoyé par SQLpro

C'est bien pire avec oracle qui impose la table DUAL pour éviter de recourir à un SELECT sans FROM.

---

Code:

---

Insert into sys.dual values ('Y');

---

Et voilà comment tuer une application (en même temps si on vous a filer SYS ou SYSTEM il y a un trou de sécurité plus important à combler).

Bon depuis je ne sais plus quelle version les appels à dual sont "virtuels", la base sait qu'il n'y a rien à faire tant qu'on ne requête pas spécifiquement la colonne DUMMY.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

explain plan for select sysdate from dual; ----------------------------------------------------------------- | Id | Operation | Name | Rows | Cost (%CPU)| Time | ----------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 2 (0)| 00:00:01 | | 1 | FAST DUAL | | 1 | 2 (0)| 00:00:01 | ----------------------------------------------------------------- explain plan for select sysdate, dummy from dual; -------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 2 | 2 (0)| 00:00:01 | | 1 | TABLE ACCESS FULL| DUAL | 1 | 2 | 2 (0)| 00:00:01 | --------------------------------------------------------------------------

---

En vrai ce n'est pas très grave on s'habitue très vite à l'une ou l'autre syntaxe.

Citation:

---

Envoyé par SQLpro

Parlons du ROWID, du ROWNUM et de toutes les pseudo colonne des tables...

---

Rownum est une pseudo-colonne évaluée à la requête, ça ne me paraît pas dramatique et c'était nécessaire pour faire de la pagination avant l'introduction des fonctions de fenêtrages à la fin des années 90.
Pour le RowId il existe aussi dans SQL-Server sur les tables nonclustered, il n'est simplement pas requêtable (enfin je ne crois pas).

Citation:

---

Envoyé par Waldar

....
Pour le RowId il existe aussi dans SQL-Server sur les tables nonclustered, il n'est simplement pas requêtable (enfin je ne crois pas).

---

pas requêtable mais on peut l’obtenir par des moyens détournés !!!!! Je donne le code dans mon livre !!!!

A +