We have recently been having issues with mounting windows shares. It occasionally doesn’t work. We don’t have access to fix it. The playbook fails at this step. This is really annoying, because if it tried again it would probably work fine, and the playbook could complete. It turns out that Ansible does have a way to retry. I got the idea from this Stack Overflow question The solution is the Ansible retries keyword.
Oracle Auditing Oracle have a number of different types of auditing, and in recently created databases they all coexist. I looked at this recently and thought I had better make some notes before I forget. There are three types of auditing: Traditional auditing. This is the way things worked before 12.1 Unified auditing. This is the new rewrite of auditing, but needs some effort to get working. Fine grained auditing.
Logical Standby Databases We use a logical standby database. The logical standby database is inherently fragile, because it mines the primary logs, and attempts to rebuild the SQL to apply on the logical. This rebuilt SQL is fine most of the time, but if an application release has altered a table, or updated most of the rows in a large table, this generated SQL often performs very poorly. Logical Standby Failure Modes Typically there are two failure modes for the logical standby database.
The initial investigation of this issue is written in the Production Emergency post. You might want to read that first if you haven’t already. Addressing the underlying problem We had identified the source of the problem. The SQL text can be extracted from the database as follows: 1 2 3 4 5 6 set linesize 300 set pagesize 0 set long 30000 set longchunksize 300 select sql_text from v$sql where sql_id = '67bqun92ngrsj'; This displays the SQL text.
Recently our PeopleSoft system locked up. Nobody could do anything, they just got a blank page in the browser. The System Model The approach to use in this situation is to consider how the application works. In our case a user’s web browser will connect to the load balancer, which will connect to a web server. The web server will pass the query to an available application server out of the pool, which will then pass the query to the database.
GitLab Organization It seemed reasonable when specifying the repositories, to have three (at first): One to hold the Ansible roles to build the VMs One to hold the custom code that the above repository will deploy One to define what the environments look like, things like Memory Number of VMs at each tier The names of the VMs Passwords And so on. Problem The problem is that when the developer commits code to his repository, they would like it to be deployed to an environment so they can test it.
Introduction Copying large numbers of files around - you would have thought this would be easy using Ansible. Most of what we do with Ansible is copying files and editing them. It turns out to be rather difficult to get right. Copy module The copy module seems like the correct thing to use at first glance. It copies files from the build host to remote locations. So I can clone the repository of files to deploy and send them off to where they need to go?
We had a process error with the above error message. I believe this is related to Oracle bug 27496360 which is a duplicate of 29942554, which is apparently in QA, but is targeted for database 20.1. It being 2019, Oracle haven’t released Oracle 20 yet, so we have no fix. We note it seems to be triggered by applying critical patches. We have an SR open for this which is attached to the bug.