SUP:OcrGerais

Voltar a Página Inicial - Menu Sistemas

Ocorrências Gerais

• Auditoria (25/05/2010): Havia mais um problema na Auditoria que foi resolvido pelo Marcio. Se um usuário tivesse fechado o sistema de forma anormal, o ID da conexão ficava perdido na Tabela e, quando novo usuário acessava qualquer outro sistema, pegava este ID e ficava no NOME do usuário anterior. Exemplo: A Dirce (SGPj) fechou o sistema anormalmente e a Margarida (Academus) estava com o ID da Dirce.
• Auditoria (15/02/2012): Havia mais um problema na Auditoria. Uma Transação pode ficar perdida na tabela Usuario_Transacao, por término anormal de Sistema. Quando um usuário acessa uma tela de algum sistema, uma conexão perdida pode ser reusada. Para tanto, é rodada a spCnfAuditoria que atualiza os dados da conexão em Usuario_Transacao. Porém, se uma conexão perdida fosse reusada por algum usuário via SQLManager, a spCnfAuditoria não é rodada e, desta forma, na tabela Usuario_Transacao ficava os dados da conexão perdida e, quando a Auditoria era executada, gravava com os dados errados. Foi criado um Job jDeletaConexoesPerdidas que é rodado a cada 5 minutos, a fim de excluir conexões perdidas e minimizar o problema via SQLManager. Porém, ainda estão ficando perdidas conexões dos sistemas web...
• Login único nos sistemas Desktop (30/08/2013): Implementado o esquema de login único no SGRH.
• PssFisica (13/09/2013): Foi criada uma função para validar os emails, a qual foi inserida na mesma trigger que valida o CPF, para barrar emails inválidos diretamente no banco de dados.
• PssFisica (23/09/2013): A tabela ficou com as triggers desativadas desde a sexta-feira, 20/09, até o dia 23/09, as 14:30, por um erro do Marcio, que desativou as triggers para executar uma operação para remover os espaços do final do campo do email, e depois não habilitou as triggers novamente.
• Servidor Tomcat 170 (24/09/2013): Configurado para fazer compressão do conteúdo usando gzip.
• Login único (05/02/2014): Todos os sistemas em Delphi (com exceção do Apolo e CCS) foram configurados para utilizar login único.
• Incluído mais um servidor para os relatórios:200.201.88.173 (20/02/2014).
• Servidor da Fisio (26/02/2014): Configurado o Glassfish para que utilize melhor a memória do computador e evite erros de Permgen.
• Trigger da PssFisica gerando logins duplicados (28/02/2014): A função gerava o novo login baseado na chamada da função dbo.fnGeraLogin para todos os usuários que já tinham login parecido com o login sendo gerado. Foi alterado para utilizar o valor do campo PssFsc_LoginUnioeste.
• Login único autenticando no AD (24/03/2014): Todos os sistemas em Delphi (com exceção do Apolo e CCS) foram configurados para utilizar login único, com autenticação no AD, sem precisar criar os usuários no SQL Server; ainda vai funcionar o login com usuário SQL Server.
• Swapp nos servidores Java (31/03/2014): Os servidores de relatório foram configurados com o fator de swapp em 20 (antes estavam com 60), com o objetivo de diminuir a ocorrência de swapp (vamos deixar a memória encher mais antes de começar a fazer swapp). Para mudar a configuração de swapp: http://askubuntu.com/questions/103915/how-do-i-configure-swappiness
• Bug nas triggers de auditoria (26/09/2014): Foi descoberto um bug nas trigger, fazendo com que registros em massa dessem erro de chave em alguns casos, pois os select TOP das triggers estava sem order by; alteramos o SSM para gerar as triggers colocando order by; todas as triggers foram re-geradas.
• Trigger de update da PssFisica desabilitada (28/09/2015): A trigger foi desabilitada para resolver um problema e o Marcio esqueceu de habilitar novamente, ficando desta forma do dia 2015-09-18 15:43 até 2015-09-28 13:17
• Instalar .net para poder instalar ManagementStudio posteriormente: inserir mídia de instalação do Windows 10 e executar a seguinte linha de comando no promp (como administrador):

Dism /online /enable-feature /featurename:NetFx3 /All /Source:F:\sources\sxs /LimitAccess

• Auditoria dos sistemas web consertada (14/07/2016): Tiago modificou a forma de criar as sessions dos sistemas Java, fazendo com que, na contexto de uma session, seja usada sempre a mesma conexão fornecida pelo pool, fazendo com que a auditoria funcione corretamente, sem necessitar de alteração
• Do dia 21/10/2016 até 08/11/2016 a trigger de auditoria de UPDATE da tabela PssFscTelefone ficou desabilitada
• Auditoria (30/11/2016 - Liége): Em 25/11/2016 verificamos que ainda há problemas na Auditoria dos sistemas web, pois, considerando caso analisado, usuário e transação, responsáveis pela ação, continuam errados em casos aleatórios
• Midas.ini: Em 22/02/2017 o Douglas criou uma GPO que faz a atualização dos arquivos midas.ini, trocando o ip 200.201.88.206 para o nome sql-app-desktop.unioeste.br
• Midas.ini: Em 02/03/2017 o Douglas criou uma GPO que faz a atualização dos arquivos midas.ini, trocando o endereço ftp do atualizador para ftpinterno.unioeste.br\ddesccm
• Sistemas web Java: Em 30/05/2017 foi corrigido bug que possibilitava aos sistemas conectar no banco de desenvolvimento quando a conexão com o produção deixava de funcionar
• Auditoria (19/02/2019 - Liége): Em 15/02/2019, ao criar um bdAuditoria a partir de backup de 07/09/2018, por engano, iniciei a restauração em cima do bdAuditoria às aproximadamente 10:30h; Após às 11h, percebi o erro e solicitei cancelamento do restore, que ficou até hoje restoring; Como estava demorando muito para finalizar e não era possível saber o percentual/status, Marcio cancelou o restore e restaurou o backup da meia-noite de 15/02/19; Desta forma, as auditorias ocorridas entre 15/02/19 00:00 às 15/02/2019 10:28:01.133 foram PERDIDAS; o job que transfere auditoria do bdUnioesteProducao para bdAuditoria ficou parado e, as auditorias a partir de TrnAuditoria.TrnAdt_DtHora >= 2019-02-15 10:28:01.133 foram recuperadas.
• Auditoria (22/02/2019 - Marcio): Em 22/02/2019, as 10:30 da manhã, foi restaurado um banco de concurso por cima do banco de auditoria, fazendo com que o BdAuditoria fosse perdido. Foi necessário restaurar o backup da meia-noite. Dessa forma, todos os registros inseridos no BdAuditoria neste intervalo de tempo (meia noite até 10:30) foram perdidos.
• Auditoria (07/03/2019 - Marcio): Em 28/03/2019 foi detectado um erro na transferência da auditoria, onde os dados não eram transferidos por completo. Foram perdidos registros de auditoria das 06:20 até as 17:08 do dia 07/03/2019.
• Remoção de duplicidade de pss. física (26/03/2019 à 28/03/2019 - Marcio): Foram removidas duplicidades de PssFisica para podermos criar índices únicos por Passaporte e Nacionalidade e também por RG e Órg. Expedidor.
• Ajustes no Joomla para otimização de desempenho (29/05/2019 - Marcio): Foram feitas configurações no Joomla, versão 3.6, para otimizar o tempo de resposta das páginas.
• Hora do sqlprod e sqldev (04/11/2019 - Liége): em 03/11/2019 a hora foi adiantanda automaticamente nos servidores de BD, apesar de não termos mais horário de verão. Assim, registros de Auditoria e etc ficaram em horário errado; O Christiano (Redes) corrigiu a hora nos servidores às 09:37h do horário certo
• Migração SGPU para servidor www7.unioeste.br (netsr-linuxweb22) (23/01/2020): o versionamento do sistema foi migrado para o netsr-vers01; após isso o sgpu foi corrigido para funcionar no www7; os arquivos foram comitados para o versionamento e o repositório foi exportado e inserido no /var/www
• Auditoria (Liége): Em 2020-02-19 13:36 habilitamos as triggers de Auditoria na tabela Mensagem
• spPermitePadraoTransacao - BdUnioesteProducao (Marcio): Em 18/02/2021 14:40 foi corrigido trecho do código que permitia gravar na tabela caso a transação não estivesse associada ao padrão
• Solução VirtualBox prejudica uso do Remote Desktop no computador: https://brianreiter.org/2010/09/18/fix-virtualbox-host-only-network-adapter-creates-a-virtual-public-network-connection-that-causes-windows-to-disable-services/
• Tabela Mensagem do BdUnioesteProducao (03/02/2022 09:45): Foi deixado somente a trigger de auditoria para exclusão, pois as outras estavam gerando conteúdo desnecessário para a auditoria, fazendo o arquivo crescer muito (Liége havia habilitado auditoria em 2020 para verificar problemas no envio de msg)
• 28/10/2022 - Marcio: Para resolver o problema de timeout no Academus, que acontece quando a turma é muito grande, foi configurado os balanceadores para um timeout de 3600 segundos.
• 16/04/2023 - Marcio: Alterada a configuração de timeout do servidor de balanceamento server1 para 900 segundos, para corrigir problema que ocorria na geração de listagem de acadêmicos para lançamento de notas em turmas do EaD muito grandes no Academus
• 20/07/2023 - Marcio: Remoção de registros da tabela DctEmtWeb que estavam com NULL no campo DctEmtWeb_PDF, pois estes registros são de relatórios emitidos pelos usuários e não tem necessidade de estarem na tabela
• 20/07/2023 - Marcio: Tabela ArqConteudo foi movida para o bdDcmDigitalizado, com o objetivo de diminuir o tamanho do backup do BdUnioesteProducao e também tornar possível a alteração do esquema de backup para esta tabela, a qual está ocupando atualmente 450GB
• 27/09/2023 - Marcio: Liberados os servidores de aplicação para que possam fazer qualquer tipo de conexão, pois descobrimos que nossos servidores não estavam conseguindo conectar no PagSeguro devido a uma regra no firewall Fortinet, que identificava as requisições como "shopping" e as bloqueava.
• 29/11/2023 - Marcio: Para resolver o problema de timeout no Academus, que acontece quando a turma é muito grande, foi configurado os balanceadores para um timeout de 1800 segundos (no server1 estava 300 e no server2 900).
• 18/01/2024 - Liége: as triggers tg_Adt_PssFscAdmLcnPrdAquisitivo_I e tg_Adt_PssFscAdmLcnPrdAquisitivo_U de PssFscAdmLcnPrdAquisitivo estavam desabilitadas (acho que desde a carga inicial em 08/03/2023) e habilitei em 18/01/2024 13:48
• 26/01/2024 - Marcio: alguns servidores de aplicação não estavam com a conexão TLS funcionando (problema para gerar pix do PagSeguro); tivemos que reiniciar eles para que voltassem a funcionar.
• 29/02/2024 - Marcio: Liége descobriu que a tabela UsrPdrUltAcesso não estava sendo populada desde 16/08/2023; Marcio descobriu que o problema ocorreu depois que ele fez uma manutenção na tabela Usuario_Padrao_Transacao, devido aos registros não estarem sendo transferidos; Marcio recriou a tabela, fazendo com que todos a sequencia de todos os registros fosse reiniciada; como a tabela TblUltCdgProcessado armazena o último código processado, e esse código era maior do que os novos códigos que estavam sendo gerados após o zeramento da tabela, nenhum registro estava sendo transferido para a tabela UsrPdrUltAcesso; para resolver, Marcio setou para zero o último código processado, fazendo com que os registros voltassem a ser migrados para a tabela de histórico; no entando, os registros desde o dia 16/08/2023 foram perdidos.
• 19/03/2024 - Marcio: Thomas relatou que os breakpoints do uCdsPssFscAdmissao.pas não estavam na linha correta; Elton sugeriu uma página que orientava abrir o arquivo no Notepad++, ir no menu Editar -> Conversão fina de linha, converter para Unix e depois para Windows; este procedimento resolveu o problema.
• 25/03/2024 - Marcio: Removido a restrição de relacionamento entre as tabelas Padrao e UsrPdrUltAcesso, para poder excluir padrões e manter o registro em UsrPdrUltAcesso.