Automated Cell Maintenance

One of the key actives for a DBA is to well maintain the database servers and Oracle environments. In a complex Oracle environment, managing and maintaining file system space plays a very crucial role. When a FS, where Oracle binaries are stored,  runs out of space, it could lead to some sort of consequences and some situations it can cause service interruption.

One of the routine actives for a DBA in a very busy system is to maintain the FS space by regularly purging or cleaning the old log and trace files. Some DBAs perform these activities through a schedule job. However, Oracle does introduced an auto maintain jobs. For example, in a cluster environment, the logs are maintained in terms of size as well as retention of the historical copies. On Exadata too Oracle has automated the Cell maintenance in place.

In this blog post, we will run through some of useful information about automated cell maintenance activities.

The Management Server (MS) component carries the responsibility of auto space management. For example, when there is a shortage of space in ADR, the MS deletes the files as per below default policy:

• Files which are older than 7 days in ADR and LOG_HOME directories
• alert.log will be renamed once it reaches to 10MB, and the historical files are kept for 7 days
• Upon 80% of FS utilization, the MS triggers the deletion policy for / (root) and /var/log/oracle directories
• Similar, the deletion policy will be activated when the /opt/filesystem 90% utilized
• Alerts are cleared based on the criteria and policies

The default retention policy is set to 7 days. If you want to modify the default behavior, you will have to change the metricHistoryDays and dragHistoryDays attributes with ALTER CELL command.

Read the below Oracle document for more insights about auto cell maintenance tasks.

https://docs.oracle.com/en/engineered-systems/exadata-database-machine/sagug/exadata-storage-server-configuring.html#GUID-EACAE5AF-A89D-4A3D-9CC1-A99D6E6FE46E

Automated Cloud Scale Performance Monitoring capabilities with Exadata Software version 19.1

Starting with v12.2, Oracle Autonomous Health Framework (AHF) multiple components work together 24x7 autonomously to keep the database system healthy and reduces human intervention & reaction time utilizing machine learning technologies .

There is no doubt that Exadata Database Machine delivers extreme performance for all sorts of workload. However, diagnosing critical performance issues still needs some manual work and human intervention to identify root causes. This blog post highlights a new autonomous performance enhancement introduced with Exadata system software v 19.1.

Exadata software Release 19.1 comes with an automated, cloud-scale performance monitoring for a wide-range of sub-systems, such as: CPU, Memory, File System, I/O and network. This feature built with the combination of years of real-world performance triaging experience by Oracle Support, industry best practices and Artificial intelligence (AI) technologies. This feature simplifies root cause analysis without much human intervention. It can automatically detect runtime critical performance issues and also figure out the root cause without human intervention.

Taking a few real-world scenarios, as a DBA, we all have come across on many occasions where a spinning process on a database server eating up all system resources causing complete database death (poor performance). With this enhancement, Exadata System Software automatically identifies the exact process that is causing spinning and generates an alert with root cause analysis. Another typical example will be automatically detecting the misconfiguration of huge pages settings on the server and sending alerts. When how a server and perform badly if the huge pages setting is right on the system.

No additional configuration and special skill set is required for this. Management Server (MS) is responsible to perform these activities. All you need is have Exadata software version 19.1 or higher, and configure your alerts on the servers.

For more details, read the oracle documentation.

https://docs.oracle.com/en/engineered-systems/exadata-database-machine/dbmso/whats-new-oracle-exadata-database-machine-19.1.0.html#GUID-B3DE3C62-278A-48E3-889A-22B9C84B1413

Stay tuned and hunger for more Exadata software 19.1 new features.

How to manage DB and Cell servers remotely on Exadata with ExaCLI utility - (Part 1)

Whoever is working with Exadata or knew how to administrate Exadata major components like DB and Cell nodes, will certainly knows the use of CellCLI, dcli and DBMCLI utilities. This blog post is focused about managing database and cell servers remotely using the ExCLI and ExadCLI utilities.

Simply put, ExaCLI is a command line tool which comes by default on database & cell nodes that provides the capabilities of remote management for database and cell servers on the Exadata. Unlike CellCLI only runs on cell servers and DBMCLI runs on only DB nodes, the ExaCLI can manage database or cell servers remotely.

There are two key advantages of using the ExaCLI: 1) Its useful when you can't get SSH connectivity and root user credentials to connect DB or Cell nodes. 2) With Exadata at customer or cloud, customers won't get SSH and root user access for CellCLI and DBMCLI. So, the ExaCLI could be handy to access the servers.

ExaCLI works with the non-system (default) users on the DB or cell serers. Therefore, you must create a role based user in order use the utility to connect to a DB or cell server. The utility is found under /user/local/sbin directory.



Creating users for ExaCLI




Note : not all CellCLI commands are compatible on ExaCLI. Below sections givens an overview about the limitations:

Below are some of the examples demonstrate how to establish remote connectivity with DB or cell servers using ExaCLI:




In the next blog post, you will learn how to use the Exadcli utility execute the commands on a set of DB or cell nodes at once.


References:

https://docs.oracle.com/en/engineered-systems/exadata-database-machine/dbmmn/exadcli.html#GUID-1C738F05-2A69-4B75-BB1E-B578C9081487

https://docs.oracle.com/en/engineered-systems/exadata-database-machine/dbmmn/exacli.html#GUID-3D57CDC3-561C-48CE-AB1E-0279E6D24DAE

Exadata Cloud Machine - Hardware capacity

Everyone who is aware and utilizes Exadata Database Machine is certainly knew the performance it can deliver. I have involved in many Exadata migration projects, and witnessed how customers gained the database performance and satisfied post migration. I am not talking about the cost, the need etc., as a technical guy, I knew the capabilities of the box and how it can benefit customers to fulfill their need and future demand.

We all knew about Cloud technologies, how every software company and organization trying to race with the trend and need of cloud technologies. In some countries, the cloud adoption is bit slower compare to the other part of the world. But, gradually majority of the companies would be adopting cloud technologies, this is for sure. Certainly, cloud has its own share of advantages and disadvantages. Whoever utilizes it smartly, can gain much flexibility and benefits.

To ensure and meet customers demand to have Exadata availability on cloud, Oracle started Exadata Cloud services offering to facilitate Exadata machine on cloud. Still, some organization couldn't adopt cloud due to industry regulations, corporate policies, security compliance etc. Therefore, Oracle announced Exadata Cloud Machine availability. With this model, customers who want to have cloud on-premises with Exadata hardware, can go for this model.

I would like to highlight the hardware capabilities that Exadata Could Machine (ExaCM) offers.

• 40Gbps InfiniBand Networking
• Ultra-fast NVMe Flash storage
• Up to 257GB/sec Throughput
• Up to 3.6 Million 8k I/Os per sec
• 1/4 millisecond response time
• Fastest Compute 
• Fastest x86 processors
• Large Memory Capacity - 720GB per compute node
• Complete Redundancy

Soon will talk more about Exadata Cloud Machine migrations. Stayed tuned and hunger for knowledge.

Few Exadata MOS Docs to review

If you have MOS login credentials and managing Exadata database machines, below is the list of few MOS Doc which is worth reading:

• 888828.1, "Exadata Database Machine and Exadata Storage Server Supported Versions"
• 1070954.1, "Oracle Exadata Database Machine Exachk or HealthCheck"
• 1353073.2, "Exadata Diagnostic Collection Guide"
• 1500257.1, " Exadata Write-Back Flash Cache - FAQ"
• 1553103.1, "dbnodeupdate.sh and dbserver.patch.zip: Updating Exadata Database Server Software using the DBNodeUpdate Utility and patchmgr"
• 1589868.1, "Procedure to check for corrupted root file system on Exadata Storage Servers and Linux database servers"