A interface entre DBAs e administradores de sistemas geralmente vai se concentrar no desempenho, então eu começaria por aí.
- Os DBAs precisam entender as várias ferramentas de criação de perfil disponíveis no sistema operacional para rastrear vários problemas de desempenho do banco de dados. Idealmente, isso incluiria as ferramentas que os administradores de SAN têm para monitorar o desempenho da SAN também.
- Os administradores de sistema precisam entender a arquitetura geral do banco de dados Oracle para entender os perfis de E / S que vários arquivos terão (isto é, redo logs idealmente seriam no disco otimizado para gravações, grupos de redo log são distribuídos em vários unidades já para que não seja necessário que o subsistema de E / S do sistema forneça redundância adicional via RAID).
- Os DBAs precisam entender as várias opções que o sistema operacional / SAN oferece que podem simplificar ou acelerar backups, clones e recuperação de desastres. Por exemplo, alguns fornecedores de SAN tornam possível clonar um banco de dados dividindo o espelho e montando a cópia no servidor de teste.
- Os administradores do sistema precisam entender em alto nível como os DBAs realizam backups e recuperação, como os bancos de dados são clonados e como a recuperação de desastres está sendo feita. Isso permite que eles sugiram ferramentas que possam simplificar essas tarefas e permitir que eles entendam as ferramentas do Oracle disponíveis para essas tarefas (por exemplo, DataGuard) para entender os custos e benefícios de ambas.
- Os DBAs precisam entender as várias configurações de memória e E / S oferecidas pelo sistema (especialmente coisas como E / S assíncronas, opções de sistema de arquivos etc.) para entender como esses parâmetros podem afetar itens como desempenho e capacidade de recuperação.
- Ambos os grupos precisam entender os comportamentos e requisitos específicos do aplicativo para evitar surpresas desagradáveis. Se você tiver um data warehouse que carrega dados entre a meia-noite e quatro horas da manhã, por exemplo, os administradores precisam estar cientes disso para que não façam algo que inunda a SAN com atividade durante essa janela, presumindo que ninguém está usando o sistemas a essa hora.
Se for viável (seus grupos de DBAs e sistemas operacionais são tecnicamente sólidos, eles estão fisicamente próximos, ambos têm um nível razoável de habilidades de comunicação, etc.), eu tenderia a sugerir que os DBAs preparassem o treinamento para os administradores do sistema e vice-versa. A Oracle University, sem dúvida, oferece aulas mais completas para ensinar alguém sobre o banco de dados Oracle - você poderia, sem dúvida, criar uma classe personalizada que leva um dia ou dois de vários cursos que oferecem sobre arquitetura de banco de dados. E você provavelmente poderia fazer algo semelhante com a empresa que fornece seu sistema operacional. Isso, sem dúvida, proporcionaria uma experiência de sala de aula mais suave. Mas não incluirá todas as informações específicas da organização que provavelmente são bastante interessantes (por exemplo, porque as coisas são feitas de uma determinada maneira por causa de certos requisitos técnicos, comerciais ou políticos). E também não oferece a oportunidade de abrir as linhas de comunicação entre os grupos. Eu pessoalmente preferiria que os DBAs, por exemplo, aprendessem um pouco menos sobre uma determinada ferramenta de perfil do sistema operacional, mas se sintam mais à vontade procurando um administrador quando ele tinha uma dúvida sobre como usá-lo do que ter um DBA aprendendo pouco mais sobre a tecnologia e não construir as relações pessoais. Como um efeito colateral, ter os dois grupos treinando o outro tem a tendência de permitir que ambos os grupos passem algum tempo gerando ou atualizando a documentação que eles geralmente não têm tempo para fazer.