Especialistas Murex.
Desempenho Murex & # 8211; o sistema está lento?
Desempenho do Murex: Meu sistema está lento ou é só eu? Quando você apresenta o sistema para novos usuários, é uma pergunta que você ouve com frequência.
Existem muitas respostas que podem surgir:
& # 8211; Servidor é um pouco pequeno.
Mas a única boa resposta é: "É tudo relativo!". Na verdade, o que você chama de lento ou rápido depende principalmente do usuário.
Por exemplo, se a abertura de um ticket leva 3s, isso é lento? é tão rápido assim? De acordo, se levar 2 minutos, é lento!
Portanto, o problema com o desempenho é que há uma grande quantidade de subjetividade. Mas eu não quero fingir ou mesmo tentar fazer psicologia e checar o que a mente humana considera lenta ou rápida. Pelo contrário, gostaria de obter exemplos precisos do que os usuários relatam frequentemente:
& # 8211; Início da sessão real. Como a nova GUI, login, senha, grupo são quase instantâneos, mas a sessão real começa quando você entra em um menu e geralmente fica lento.
& # 8211; Detalhes de abertura: obrigações, negócios, contrapartes, etc & # 8230;
& # 8211; A sensação de que o sistema é às vezes um pouco pegajoso, onde as ações levam cerca de um segundo quando você espera que sejam instantâneas.
Existem, na minha opinião, 2 tipos de problemas de desempenho do Murex: o tipo de experiência do usuário e os estruturais. Pode-se argumentar que eles são os mesmos, mas deixe-me explicar:
As UXs são aquelas que 1s ou 2, para as quais o timing é difícil ou impreciso. Na lista acima, estou me referindo a detalhes de abertura, aderência. Este é geralmente esse tipo de desempenho que é ignorado como 1s para abrir uma negociação ou .1s não parece ser uma grande mudança para o usuário. Mas o que o usuário nem sempre entende é que quando você pressiona a barra de espaço para abrir uma transação, muitas e muitas coisas estão acontecendo no Murex: o número de negociação é enviado do cliente para o servidor de aplicativos. E, em seguida, o servidor de aplicativos está enviando solicitações de banco de dados para obter todas as informações. Não é um único pedido, estamos mais perto de centenas do que de alguns: obtenha o cabeçalho comercial, obtenha o corpo comercial, obtenha detalhes do contrato, obtenha fluxos adicionais, verifique os direitos de acesso. Se assumirmos que a comunicação entre o banco de dados e o aplicativo é de 3ms, 100 solicitações trazem isso para .3s, adicionam o tempo de CPU (para decidir se o comércio é parte de um pacote, requer a abertura de outras tabelas), adicionar tempo real de solicitação do banco de dados e, em seguida, enviando todas as informações de volta para o cliente. E aqui você vai 1s, 2s são muito facilmente alcançados.
Portanto, os problemas de desempenho da Experiência do Usuário também são estruturais e não há muito a ser feito em termos de otimização de código. (bem, pelo menos não no meu não PAC-cérebro).
Os estruturais reais, aqueles que você espera que sejam lentos, são basicamente como os compostos acima, muitas vezes, calculados com um cálculo extra para o risco. O bom é que, quando você chega a esse nível, normalmente é possível encontrar otimizações no lado do banco de dados quando não no lado do código para melhorar a velocidade e carregar / processar mais informações de uma só vez. Normalmente, quando você pode entrar em contato com o suporte para o desempenho do Murex, as pessoas esperam ajudar nesse tipo de problema.
Então, voltando à nossa pergunta original: o sistema está lento? É de fato relativo. Existem implementações do Murex onde o sistema é muito rápido. Mas tudo foi otimizado com esse objetivo. Para obter seus tempos de ping de 1ms a .1ms não é uma tarefa fácil, ter um banco de dados grande e solicitações muito rápidas exigem um grande e otimizado poder de banco de dados, etc. & # 8230; Portanto, isso pode ser feito e feito, mas as pessoas tendem a ser sensíveis ao custo, por isso, duplicar (bem, suspeito muito mais que duplicar) seu orçamento de hardware / manutenção para que uma operação abra em .1s em vez de 1s não seja realmente faz sentido.
E a Murex também trabalha duro em termos de melhorar a experiência do usuário onde eles podem: Livebook é um ótimo exemplo. Livebook significa que os dados são agitados durante todo o dia por processos, de modo que quando você insere Livebook no lugar da simulação, não espere de 5 a 10 minutos, mas alguns segundos para obter as informações; O screenset é outro ótimo exemplo: definir screensets permite que você tenha todas as sessões abertas de uma só vez, em vez de iniciá-las uma a uma.
Para concluir, o desempenho do Murex é endereçado onde o Murex pode fazer algo ou pensar em algo inovador. Mas existem alguns limites devido ao hardware que é praticamente impossível melhorar do ponto de vista do Murex. Então o sistema está lento? Não, a Murex trabalhou e está trabalhando duro nisso, mas no final, tudo depende da sua implementação e da rapidez que você quer (pode pagar).
Atualizando SSIs em massa & # 8211; Como eu fiz isso.
Caso prático: hoje, alguém me perguntou se eu poderia ajudar: alguns negócios foram importados e, para esses, tudo tem que ser considerado bem: mesmo que as SSIs estejam faltando, os fluxos futuros devem estar ok e não aparecer como faltando SSIs. Novos negócios, por outro lado (mesmo que estejam na mesma contraparte), precisam ter SSIs adequadas ou devolver uma mensagem SSI ausente.
Colocar alguns SSIs falsos (catch & # 8217; all) não funcionaria, pois isso também afetaria novos negócios. Até mesmo colocar uma validade até ontem não funcionaria como pagamentos futuros de negociações existentes não devem mostrar nenhum erro de SSI ausente.
Então a única solução que eu pensei: SSIs específicas para negócios importados. Eu não estava completamente certo da mesa segurando SSIs (eu tive que confirmar), então eu entrei em um trade com SSIs customizadas e coloquei em um dos campos uma string muito específica (se você é curioso ABCDE, sim eu sabe, muito muito original). Em seguida, procurei no arquivo de rastreio do BD (consulte as postagens anteriores para saber como) para localizar a tabela.
O problema que tive então foi que a tabela tinha um número de negociação de campo que não estava de acordo com o meu número comercial (mesmo se eu tivesse certeza de que era o negócio certo). Por isso, procurei no arquivo de rastreio o número comercial que eu não conhecia e consegui localizá-lo no cabeçalho da transação. Então, eu tinha tudo: do número do meu negócio até a referência intermediária (no meu caso, era apenas 1, mas poderia ter sido múltiplo) para os dados finais.
Transformar isso em um script foi, então, uma brisa (para pessoas curiosas o suficiente eu estou usando as mesmas SSIs fictícias específicas para todos os negócios importados) e voila! Agora você tem SSIs específicas para todas as negociações importadas e novas serão obtidas automaticamente das atribuições de SSIs.
Isso é uma solução perfeita? Claro que não, você pode ter problemas ao realizar eventos, mas ainda assim, é muito válido.
Limpeza de primavera, limpar o banco de dados.
Limpeza de primavera, eu sei que eu sou um mês mais cedo, mas a limpeza é uma tarefa importante e, às vezes, você precisa ter certeza de que ela está adaptada ao seu ambiente e às suas necessidades.
Limpar o banco de dados permitirá manter o crescimento do banco de dados sob controle e garantir que você obtenha o desempenho máximo do sistema. Mas, muitas vezes, existe o temor de que a depuração resulte na perda de dados e, rapidamente, você se encontra com períodos de retenção massivos, sete anos para o comércio, dois anos de dados diários do mercado e todos os registros.
O primeiro a ter em mente: Murex é um sistema de produção para negociação e processamento, não é um sistema de repositório de dados. Você precisa mantê-lo funcionando em sua melhor forma para maximizar os benefícios que você obtém do sistema. Se você precisar reter alguns dados armazenados no Murex, exporte e armazene em seu próprio sistema. É muito mais barato e mais apropriado.
Isso pode parecer óbvio, mas quando se fala em purga, a regulamentação é muitas vezes o primeiro tópico que vem e bloqueia qualquer discussão adicional, desde que uma solução para armazenar todos os dados a serem purgados não tenha sido implementada.
Uma vez que todos estejam convencidos da importância da limpeza, há vários itens a serem eliminados por importância:
& # 8211; Documentos e suas entradas (geralmente estão no número 1 no uso do banco de dados)
& # 8211; Dados de mercado (normalmente classificados no número 2)
& # 8211; Os esquecidos: visão, layouts, filtros.
Purgar Mxmlexchange é realmente bastante simples e é feito através de scripts fornecidos pela Murex. Apenas tenha muito cuidado com os scripts e assegure-se de que os testes adequados sejam feitos nos ambientes de teste antes de serem implementados na produção.
Mas se você testá-lo corretamente e apenas purgar os documentos intermediários, é bastante direto sem surpresas.
Dados de mercado.
Dados de mercado são feitos de 2 partes. O lado visível do iceberg onde você limpa dados de mercado para datas que não são mais necessárias (boas práticas tendem a permitir que as pessoas mantenham o final do mês apenas para datas mais antigas e dados diários do mercado por alguns meses (1-3 dependendo de sua agressividade). pode ser feito através da GUI, se você quiser, bem direto.
Mas também há uma segunda parte da limpeza de dados de mercado que ajuda muito: instrumentos expirados (leia principalmente Obrigações e opções listadas). Por padrão, o Murex copia automaticamente todas as entradas de dados do mercado de hoje para amanhã como parte do EOD. Essa cópia automática significa que você também tem entradas para opções listadas vencidas (ETOs), futuros ou títulos que continuam sendo processados. Pode não parecer muito, mas os ETOs podem rapidamente fazer uma bola de neve, especialmente se você trocar os mais curtos, como os de hoje e da noite para o dia. Aqui, a Murex pode fornecer um script para limpá-los. Sintoma para este segundo são tabelas como MP * _GLOB e MP * _PRIC sendo grandes em tamanho.
Purga comercial faz sentido, especialmente quando você faz negociação de volume. A limpeza do comércio é feita através da GUI (muito importante) e de tal forma que todas as posições eliminadas estão sendo agregadas para evitar qualquer salto nos saldos de caixa.
A purga do comércio ocorre em 2 etapas: uma lógica, em que a negociação não é mais lida para relatórios e simulações, mas ainda está presente no banco de dados. Todas as suas contribuições são armazenadas e agregadas com outras transações removidas. Pode ser desfeito, se necessário.
A purga física removerá efetivamente a troca do sistema, você não poderá mais consultá-la e ela não poderá ser revertida.
Os testes de posição e saldos de caixa precisam ser realizados após cada etapa de limpeza. Após a limpeza lógica, é o mais importante, pois a Murex não irá mais avaliar o negócio, mas lerá diretamente sua contribuição armazenada. Após a eliminação física quase poder ser ignorada, uma vez que não afeta mais os resultados agregados, é simplesmente remover os registros comerciais não utilizados.
A depuração do comércio depende da complexidade do comércio; os forwards spot simples podem (e devem) ser eliminados de forma muito mais agressiva do que transações mais estruturadas.
Logs e auditoria.
Murex lhe dará os scripts para estes, purgar conforme solicitado e fazer uma cópia, se você sentir a necessidade inicial. Eles não consomem muito espaço, mas os logs limpos facilitam a navegação por eles!
Dados estáticos.
Na verdade, sou um defensor contra a eliminação de dados estáticos. Muitas vezes, o Murex faz referência a dados estáticos sob as contribuições de transação removidas ou em outros locais e, ao removê-los, removerá esse link para o Murex. Pode-se sempre tentar corrigir todos os problemas que garantem fora dele, mas na minha opinião, simplesmente não vale a pena. A quantidade de problemas gerados (e que pode vir depois durante ou após uma atualização) não vale a pequena quantidade de DB que ele ocupa.
Filtro, layouts, visualizações, etc & # 8230;
Esses itens não devem ser purgados per se, mas devem ser mantidos sob controle. Restringir usuários de criar, duplicar é provavelmente o caminho a percorrer.
Para limpá-los provavelmente não teria muito impacto no banco de dados, mas você corre o risco de que um relatório EOD ou um processo falharia. Exceto se você tiver mantido uma lista muito precisa de quais itens são usados por qual processo (e se você o fez, parabéns!), Você provavelmente terá que deixá-los onde estão ou iniciar uma campanha massiva identificando e descomissionando os indesejados.
Em resumo, se você se concentrar nos 4 principais itens dessa lista, seu banco de dados deve crescer como esperado quando o hardware for planejado com o Murex e os desempenhos permanecerem ótimos. Apenas fique de olho no uso do banco de dados por tabela e se algo crescer muito rapidamente, a Murex sempre terá prazer em resolver você!
Se eu esqueci alguma coisa ou se você sentir vontade de adicionar algo, por favor sinta-se à vontade!
Sybase vs Oracle.
Esta é a pergunta que muitas vezes se ouve quando a decisão foi ir com Murex: Sybase vs Oracle. Qual é o melhor? Qual deles você recomenda, etc. & # 8230;
Para repetir primeiro o que foi dito inúmeras vezes: o Murex funciona muito bem com qualquer um e se você precisar usar um ou outro devido à política do banco ou qualquer motivo, você não pode errar. Murex entregará resultados e tudo será OK.
Mas existem diferenças e ambos têm prós e contras. Historicamente, a Murex suportava apenas a Sybase e muitos clientes acham que obterão um suporte melhor da Murex se usarem a Sybase. A Oracle é bem conhecida na Murex atualmente e não há mudança na qualidade do suporte em relação à Oracle. A equipe do PAC é especialmente experiente em ambas as frentes e pode fornecer recomendações de configuração para ambos os sistemas.
Mesmo na performance, não é onde a diferença vai realmente estar (muitas pessoas discordariam aqui e dariam razão para escolher uma ou outra). Eu sinto a diferença é bonita no uso real de cada um: cada um deles trabalha um pouco diferente. Não de um front end da Murex, é claro, para o usuário final, Sybase ou Oracle não faz diferença, o sistema parece o mesmo, as funções funcionam da mesma maneira. É realmente quando você começa a usar o SQL, onde você pode ver as diferenças.
Eu me formei na escola de SQL com a Sybase como professor, então eu sei mais sobre a Sybase do que com a Oracle.
Sybase sábio, os identificadores são diretamente atribuídos (o bom e velho Middenity). Ao escrever SQL, não há necessidade de cuidar desse campo, ele cuida de si mesmo. Com a Oracle, é uma história diferente, é preciso chamar a seqüência (TABLENAME_DBFS) para recuperar o número mais recente para atualizá-lo. Um pouco mais doloroso.
Clientes SQL com Oracle são, por alguma razão, sempre mais trabalhosos, especialmente se você misturar comandos diretos e procedimentos armazenados. Eu usei desenvolvedor SQL e não ver os resultados dos meus procedimentos armazenados é uma dor. Eu também uso muito SQuirreL. O posterior funciona muito bem para tudo, EXCETO a conexão inicial com os servidores Oracle. Quando o servidor está distante, a carga inicial das tabelas levou alguns minutos (começou aos 15 minutos e desceu para 2-3 minutos depois que o link para outros escritórios foi atualizado). O Oracle também foi uma dor com o nome de usuário / senha para cada esquema. Não sei bem por que foi assim, mas enquanto estiver no Sybase, é possível alternar facilmente de um banco de dados para outro com o mesmo usuário, da maneira como ele é configurado para trabalhar com as forças do Oracle Murex para fazer logout / login (ou fazer login várias vezes) para cada esquema).
Mas eu tive meu quinhão de problemas com a Sybase. A corrupção do banco de dados aconteceu algumas vezes (suspeito que isso também aconteça com o Oracle, mas não o experimentei em primeira mão). A pior corrupção do banco de dados foi ao receber um dump de um cliente que continha um gatilho (os gatilhos não são seus amigos). Esse gatilho foi anexado a um id de usuário diferente que não tínhamos quando carregamos o dump. Então tivemos que redefinir o ID do usuário para esse gatilho antes de excluí-lo. Ao atualizar esse ID de usuário, ele causou uma corrupção do banco de dados que só poderia ser resolvida ao parar / reiniciar o servidor. Havia outros casos, mas nada se repetia tão facilmente como esse.
Eu estaria interessado em ouvir de especialistas da Oracle para me dar todos os lados bons da Oracle, do meu ponto de vista, eu geralmente acho Sybase mais fácil de trabalhar e muitas vezes perdi algumas horas tentando adaptar um procedimento armazenado que eu escrevi em Sybase para trabalhar com a Oracle. Normalmente, a equipe do PAC era capaz de me esclarecer e fazer o procedimento funcionar.
Desempenho Murex & # 8211; a história do ovo e da galinha.
O desempenho do Murex geralmente está no centro das atenções: com que rapidez o Murex pode fazer o XXX ou criar o YYY. (Substitua XXX e YYY pela sua escolha de tarefas)? O problema é que a lista de requisitos entre dois clientes varia e resulta em tempos muito diferentes.
Então, para tirar a questão principal primeiro (se você é do tipo que prefere uma resposta curta): Você consegue bons desempenhos fora do Murex? Absolutamente!
O modo como você vai conseguir depende de poucas coisas (o que faz com que responder à pergunta quanto tempo leva para fazer algo impossível de responder):
Hardware é o primeiro a se lembrar. Com ótimo hardware vem ótimo desempenho. Bem, na verdade não, você também precisa ajustá-lo corretamente, mas sim, é um fator importante. Este tende a ser ignorado: "Eu quero obter theta real para todo o meu portfólio ao longo dos próximos 10 dias, juntamente com um choque no local e a qualquer momento reescrever os níveis spot. E precisa ser rápido! & # 8221; (você tem perguntas semelhantes com entrada comercial, relatórios, etc & # 8230;). Claro, se você pedir tarefas demoradas (ou colocar muitas verificações de consistência), você irá desacelerar os processos. Manutenção. Se tudo funcionar bem no primeiro dia, mas não dez dias depois, é evidente que há alguma manutenção que não foi feita corretamente. Eu coloquei este último porque é muito raro o software o problema. Muito raramente (é bom repetir)
Para a maioria dessas questões, a equipe do PAC é a equipe responsável. Eles podem dimensionar o hardware que você precisa com base no uso do sistema, aconselhá-lo sobre os procedimentos de manutenção e depurar se algo ficar lento demais.
Em geral, se você acredita que um processo está demorando demais, considerando a configuração (inserir um acordo leva 5 minutos, relatório ainda em execução após 1h, etc & # 8230;), é necessário fazer o seguinte.
Se for uma ocorrência isolada, pode muito bem ser um bloqueio no nível do banco de dados ou no nível do sistema. Para bloqueios no nível do banco de dados (raro, mas isso acontece), verifique com o dbas, verifique também se nenhum processo pesado está em execução no momento. Para bloqueios em nível de software, o Murex o cobre com o ipmonit. Faça o login no ipmonit da ferramenta monit e você pode acessar um relatório de bloqueio mostrando todos os bloqueios colocados pelo sistema (por exemplo, se alguém estiver editando uma negociação, ele será bloqueado para evitar duas modificações ao mesmo tempo). Verifique a documentação do ipmonit, pois as capturas de tela são muito úteis ao navegar pelas telas.
Se isso acontecer o tempo todo, é improvável que seja um bloqueio e você precisa gerar rastreamentos de desempenho. Os primeiros são gerados com o comando / TIMER slash. Este comando slash irá gerar arquivos mxtiming em seu diretório de log (você pode colocar o comando slash, se necessário, nos lançadores de serviços). O arquivo mxtiming mostrará o tempo gasto na CPU e enquanto espera pelo banco de dados. Se o tempo gasto no banco de dados for muito alto, os índices podem estar faltando nas tabelas. Então você precisa executar um banco de dados DB (link sem vergonha para o meu post mais antigo para saber como). Esses rastreios de banco de dados podem ser enviados para o Murex e eles fornecerão o número de logicamente lido em cada tabela. Um número muito alto indica (provavelmente) que uma tabela não está indexada. A indexação dessa tabela deve melhorar o desempenho.
Se o sistema estiver lento, o motivo está no hardware ou na configuração. Raramente o problema é devido a um erro.
Há também casos em que a Murex desenvolve um novo recurso para acelerar um processo que é conhecido por ser sempre lento devido à enorme quantidade de processamento de dados / computação que requer. Paralelização ou pré-processamento são os dois grandes métodos para fazê-lo. Mas isso se aplica quando você começa a ter um volume: inserir uma única oferta deve ser sempre rápido!
Comentários, experiências são bem vindas!
Banco de dados Murex & # 8211; Elimine seus problemas!
Tudo bem, hoje vamos abrir essa caixa preta que é o banco de dados Murex! Embora todos vocês saibam que a Murex não publica sua organização de banco de dados, às vezes não há outra alternativa senão ir diretamente para onde os dados estão.
Minha regra é que, se alguém puder evitá-lo, ir direto para o banco de dados deve ser evitado. Qualquer problema causado durante a navegação terá impactos e causará problemas no ambiente. Para relatórios, tabelas dinâmicas ou relatórios de espectadores são seus amigos. Para filtragem, a lista de campos é realmente bastante exaustiva. Em muitos casos, você encontrará todas as informações necessárias sem abrir nenhum cliente SQL. Mas às vezes, para alguns filtros (de volta ao post do RQWHERE!), Para alguns relatórios ou para alguma limpeza de banco de dados, você precisará passar pelo banco de dados.
Trabalhar com o banco de dados Murex é o mesmo que trabalhar com qualquer outro banco de dados de sistema comercial: backup, teste em ambientes de teste, teste novamente, backup e deve funcionar. O problema é que, às vezes, alguns campos não são muito claros sobre quais são seus papéis e, ao tentar preencher linhas (inserção ou atualização), isso pode se tornar um problema real. Os consultores da Murex são os mais adequados para ajudá-lo, especialmente se você não tiver certeza de que sua solicitação é segura. No caso de migrações, novamente, os consultores da Murex devem ser os únicos a fornecer os scripts corretos, apenas escrever os seus quando você estiver absolutamente seguro do que você está fazendo.
Agora, do ponto de vista de um consultor da Murex, nem sempre é fácil determinar quais campos têm quais funções. Mas o primeiro passo é entender o que a outra parte está tentando fazer. Talvez o SQL não seja o melhor caminho a seguir e poderia haver uma solução mais fácil?
Então você pode verificar o que outras pessoas fizeram. É raro ter um problema com apenas 1 cliente que não tenha sido encontrado por outra pessoa.
Eu aprendi SQL enquanto trabalhava na Murex e muitas vezes acelerava processos tremendamente:
& # 8211; Inserindo em massa alguns dados (ou duplicando registros)
& # 8211; Limpar dados indesejados. Especialmente logs (ou dados de mercado, muito mais rápidos)
& # 8211; Construindo minhas próprias extrações ao fazer relatórios de reconciliação.
Mas também aconteceu que meus scripts não funcionaram como esperado (e sorte eu tinha um backup e estava fazendo isso em um ambiente de teste): atualizações / excluir sem uma condição correta onde. Uma vez eu removi todos os registros do cabeçalho da transação!
Se você estiver trabalhando em um conjunto limitado de tabelas e não quiser chamar os DBAs para fazer o backup, use as seguintes ferramentas: Ajuda-Monitor-DPI info-Transfer from RDB para DBF. Você precisará de um código de autorização para continuar, mas poderá transferir a tabela do banco de dados para um arquivo no sistema de arquivos do servidor de aplicativos. A etapa Transferir do DBF para o RDB faz exatamente o oposto. Assim, você terá a flexibilidade de fazer backup de qualquer tabela que desejar do banco de dados para o sistema de arquivos e trazê-la de volta sempre que necessário.
Note que você pode usar jokers no nome da tabela que você deseja transferir e você não deve colocar _DBF mas. dbf.
E você? Qual é a sua relação com o SQL? Comentários e experiências abaixo, se desejar!
Se divertindo com o sistema.
Para um clima mais leve nesta sexta-feira, vamos falar sobre as maneiras de se divertir com o sistema. O Murex é um sistema complexo, nem sempre fácil de configurar ou de se familiarizar.
Mas quem diz sistema complexo também diz muitos lugares para colocar este pequeno toque engraçado que trará um sorriso quando manchado.
Aqui estão alguns que eu encontrei:
Clássico, mas sempre bom: o comentário engraçado no código (pré-procedimento ou procedimento armazenado, por exemplo). Um dos melhores, foi / * Adicionado para agradar a Sra. Princesa enquanto isso não serve para nada * / Tive que dizer a essa pessoa que este código iria cut e tirá-la provavelmente seria uma boa idéia UDF rules rules messages: & # 8220 Por que você esqueceu de digitar XXX & # 8221; (isso foi ao entrar em títulos). Eu poderia dizer que a pessoa que escreveu esse pedaço deve ter ficado tão frustrada que teve que liberar alguma raiva na mensagem. Teve um sorriso naquele que reconstruiu a história Nome de vistas e filtros. Um dos meus ex-colegas estava sempre colocando insultos em seus rótulos de filtro (e normalmente estava excluindo-os após o uso). Bem, digamos que alguns bancos de dados ainda têm essas palavras em poucos lugares. Eu tenho que admitir que este é melhor usado em dados estáticos que só suportam as pessoas acessadas, nem todos podem concordar com isso! Documentação e etiqueta de objetos usados. Lembrou que o título chamado NOTABOND, clássico, mas de ouro 🙂
Você encontrou alguns também? Você colocou alguns de vocês mesmos (voluntariamente ou não)?
Tenha um bom fim de semana!
RQWHERE é provavelmente o filtro de função mais útil no Murex. Basicamente, permite filtrar com base em instruções SQL. Isso lhe dá liberdade total quanto aos critérios que você deseja usar para escolher uma determinada população de resultados.
RQWHERE também é uma dor no pescoço para usar os primeiros tempos (e os tempos depois!), Pois é puramente baseado no modelo de dados (que, como discutimos anteriormente, não está documentado). Com base no modelo de dados, você precisa entender como os dados são estruturados e como as diferentes tabelas são relacionadas. Isso também significa que, se o modelo de dados for alterado, o filtro precisará ser adaptado.
Então, se você marcar as seguintes caixas:
& # 8211; Saiba como fazer instruções SQL simples.
& # 8211; Saiba como os dados que você precisa estão organizados.
& # 8211; Não é possível criar o filtro que você precisa com as funcionalidades existentes.
RQWHERE é para você!
Basicamente, RQWHERE chama 2 argumentos, o primeiro sendo uma string e a instrução de seleção real que você deseja usar e a segunda sendo também uma string, mas que eu nunca usei. Se alguém o recomendar, sinta-se à vontade para comentar abaixo 🙂
A maneira como você estrutura sua instrução de seleção é um pouco para você e, embora eu não possa ajudá-lo (o seu consultor Murex preferencial pode e vai embora), há uma coisa muito bacana que pode tirar seu filtro de ser bom para ser muito bom: funções do analisador.
De fato, você pode enriquecer sua instrução de string com variáveis interativas ou funções de analisador. Isto significa que o filtro pode solicitar ao usuário final uma string / número / data antes de ser executado, o qual será então usado ao construir a string que será enviada para a função.
Por exemplo, você deseja recuperar com um número maior que x. Seu primeiro argumento será algo como "[início de sua declaração] onde NUMBER & gt; & # 8221; + & lt; variável numérica interativa & gt; + & # 8221; [fim de sua declaração & # 8221 ;. Se você estiver usando strings ou datas, certifique-se de usar aspas simples e duplas corretamente: & # 8220; [início da sua declaração] onde STRING = '& # 8221; + & lt; variável da string interativa & gt; + & # 8221 ; & # 8216; [fim da sua afirmação] & # 8221; (sim que STRING = & lt; cotação única & gt; & lt; aspas duplas & gt;). A sequência de instruções criada será então "início de sua declaração" onde STRING = "& lt; input variable & gt; & # 8217; [fim da sua afirmação] & # 8221 ;. Um RQWHERE perfeitamente construído!
Como depurar RQWHERE?
Às vezes, seu RQWHERE não funcionará como esperado. Ele não retornará nada sem erro ou, às vezes, causará erros de spam. Se o último, Murex irá mostrar-lhe as declarações que estão falhando e você pode corrigir o seu RQWHERE, olhando para o resultado final.
Se não houver erro, ative um rastreio de BD (na tela ou em logs) e verifique a instrução SQL criada, se for a desejada ou não.
Perguntas, comentários, sinta-se livre!
Rastreios de banco de dados.
O rastreamento de banco de dados é muito útil quando você está tentando entender o que está causando um erro e suspeita que algo está errado na configuração (uma configuração incorreta da segurança, dados de mercado, etc. & # 8230;) ou está tentando criar uma consulta SQL e precisa ter um pouco melhor entendimento do modelo de dados (note que eu não encorajo você a usar SQL, relatórios e tabelas dinâmicas devem ser sua primeira parada, mas às vezes isso não é suficiente).
No Murex, há alguns rastreamentos de banco de dados e alguns são mais úteis do que outros.
O primeiro que usei é o que vem pela interface gráfica. Cada pedido aparece na tela e pressionando escape é executado. É simples de usar, simples de ativar e não precisa recuperar o arquivo do servidor de aplicativos. Infelizmente, às vezes causa falhas devido às janelas pop-up que interferem no aplicativo ou, às vezes, você simplesmente tem muitas solicitações para que elas sejam úteis.
Para ligá-lo, você precisa ir para o Pedido de Informações do Help-Monitor-DBX. Você pode inserir critérios para filtrar as solicitações: Da ação (atualizar, excluir, inserir, selecionar) para uma pesquisa de string (por exemplo, TRN_HDR ou BOND001).
Quando comecei no mundo Murex, adorei essa ferramenta, pois me ajudou a montar as peças do quebra-cabeça.
O segundo é ativar os rastreios despejados em um arquivo de log. Para fazer isso, vá para as estatísticas Help-Monitor-DBX Info-RDB. Você pode escolher o nível de depuração de que precisa. O básico é bom o suficiente se você precisa olhar para as consultas executadas. O verbose completo (além do plano) é necessário se você estiver tentando rastrear DBIndices ausentes ou precisar entender quais solicitações estão custando muito tempo. Esse rastreio, por padrão, despeja arquivos em logs / mxsession / mx, mas o caminho padrão pode ser modificado dentro do ativador.
Também é possível ativar esse rastreio com um comando slash: / RDXSTATISTICS: & lt; prefixo & gt ;: & lt; nível de rastreio & gt;
Você pode acabar usando as informações fornecidas nos rastreios para:
& # 8211; Construindo um relatório.
& # 8211; Construindo um filtro RQWHERE.
& # 8211; Reduzir um problema.
& # 8211; Construindo um procedimento SQL (útil ao atualizar / reconciliação, mas sempre verifique com o Murex se tudo estiver bem)
Os vestígios de banco de dados não são a marca de prata e, às vezes, não lhe dão as informações que você procura. Também no caso de investigar uma falha, lembre-se de que a última solicitação pode não ser a responsável pela falha e talvez seja necessário voltar nos registros para encontrar a causa raiz.
Se você tiver dúvidas, histórias engraçadas ou se sentir assim, por favor, comente abaixo!
Murex movimenta o principal sistema de negociação e risco para a nuvem.
Fornecedor espera mais demanda de bancos espremidos; O movimento também sugere um futuro modular para os sistemas de risco.
Clive Davidson 12 de dezembro de 2017.
A Murex está disponibilizando seu principal sistema de negociação e risco, o MX.3, através da plataforma de nuvem da Amazon, em uma tentativa de cortar custos para seus usuários.
A mudança é significativa porque poucos sistemas de risco em larga escala deram o salto para a nuvem até agora. Os analistas citam os obstáculos gêmeos - tornar um software complexo disponível dessa forma envolve muita reengenharia, para que os usuários possam se beneficiar do poder de processamento escalável que é o principal ponto de venda da nuvem, enquanto os vendedores hesitam em realizar esse trabalho, se c.
Para continuar lendo.
Inicie um teste de risco.
Registre-se para uma avaliação de negócios de risco para acessar este artigo. Inscreva-se hoje e tenha acesso a:
Vídeo patrocinado: Philip Moyer, Amazon Web Services.
16 de novembro de 2017.
Controle de nuvem.
18 de maio de 2017.
Execução algorítmica: aproveitando a tecnologia para gerenciar riscos.
03 de maio de 2016.
Entrevista: Zar Amrolia sobre prestação de liquidez.
28 de dezembro de 2015.
Tecnologia - Resolvendo a nova equação dos mercados de capitais.
24 de setembro de 2015.
Mesas de produtos estruturados juntam-se à revolução do AAD.
08 de julho de 2015.
Opções de painelistas: Algos são a nova esperança - e alvo - em guerras cibernéticas.
13 de maio de 2015.
Plataforma de compartilhamento de dados une bancos contra crimes cibernéticos.
14 de novembro de 2014.
7 dias em 60 segundos.
Perdas de CCP, guerras holdco e margem de derivativos de ações.
A semana de risco, de 24 a 29 de março de 2018.
Você precisa entrar para usar este recurso. Se você não tiver uma conta do Risk, registre-se para uma avaliação.
Комментариев нет:
Отправить комментарий