Pass Amazon AWS Certified Database - Specialty Exam in First Attempt Guaranteed!

All Amazon AWS Certified Database - Specialty certification exam dumps, study guide, training courses are Prepared by industry experts. PrepAway's ETE files povide the AWS Certified Database - Specialty AWS Certified Database - Specialty practice test questions and answers & exam dumps, study guide and training courses help you study and pass hassle-free!

Amazon RDS and Aurora

33. Exporting RDS logs to S3

Now let's understand how to export your RDS logs to S 3. Now you already know that you can export your RDS database logs to Cloud Watch logs. So exporting it to S3 is very simple. Simply export it to S3 from theCloud Watch Logs. So database log files can be accessed via the RDS console. Or you can use the CLI or API as well. The important thing to remember here is that database logs can be accessed, but transaction logs cannot.

Alright? So to export your database logs to S3, first you have to enable the export to Cloud Watch Logs. and from Cloud Watch logs. You can export it to S Three.So you can export the log data from Cloud Watch logs to S3 by creating an export task in Cloud Watch. You can also use the Create Export Task CLI command, or you can create an export task directly from the Cloud WatchLogs Dashboard. Okay, and another way to move the log files from RDS to S3 could be by using the AWS SDK. Or you can also use lambda functions to write your own code and use the RDS API to upload the log files to S 3. Right, so you can use the RDS API to download the logs and upload them to S 3. And you can achieve this using the AWS SDK as well as using Lambda, right?

34. RDS Enhanced Monitoring

Let's take a look at RDS enhanced monitoring now. Now, enhanced monitoring is available on top of the standard monitoring features available in RDS. And you have to enable enhanced monitoring. So this is used to analyse real-time OS-level metrics, that is, CPU metrics, memory usage metrics, and so on. These leaks look something like this. And you can use these to monitor different processes or threads that are using the CPU. So the enhanced monitoring can help you identify performance issues. Another important thing is that with enhanced monitoring, you can have increased granularity, okay? So you can have granularity from 1 second to 60 seconds.

Standard metrics give you 1 minute of granularity. But with enhanced monitoring, you can choose an even higher level of granularity, like 1 second, 5 seconds, and so on, okay? And when you enable enhanced monitoring, what it does is install an agent to collect these metrics. The agent is installed on the database server to collect these metrics. And all these metrics are available within the RDS console. And you can also use the CloudWatch console to monitor your RDS metrics. You can create additional dashboards as per your requirements and use those dashboards to monitor your RDS databases. Alright, so let's continue to the next lecture.

35. RDS Performance Insights

In this lecture, let's look at the Performance Insight Stool that's available with RDS. The Performance Insight Stool is a visual dashboard that you can use for performance tuning, analysis, and monitoring. It looks something like this, and what it does is help you monitor the database or DB load for your database instance. If your instance has multiple databases, you will see aggregated metrics, and this is a really useful tool to pinpoint any performance bottlenecks in your database. Okay, so what exactly is this database load? It is the average number of active sessions for your database instance, abbreviated as AAS (Average Active Sessions), and that represents the DB load on your instance. The performance issues will appear as spikes in the Dbloado graph. So anything that you see on this graph that goes above the max CPU line (the black dashed line) is a likely performance bottleneck. All right, so it really helps you identify these performance bottlenecks, expensive sequel statements, and so on. You can see your database load here, and you can also filter this graph by weights, by SQL, by users, by hosts, and so on. Weights represent your CPU's wait space, IO locking conditions, and so on. SQL is simply the sequel statement, so it will show you what are the top SQL statements that are causing the Slurry performance or are waiting on something, and so on. Then you can also filter by host and by users as well. And you can definitely use the top sequel to see which are the queries that are the slowest on your database and which queries are resulting in table locks. So here you can see different weight states, like IO, exactly the same CPU, lock, and so on. So these are the different weight states, which are colour-coded, so you can identify what different weights your database is waiting on. Right then, at the bottom half, you can see the top SQL queries. You can find out which queries are slowing down and causing performance issues on your database. So, for example, if you see the blue coloured graph, the first option in the waiting stage, the Iowa Sync, as you can see, refers to the blue colour in the graph. And the corresponding sequel statement can also be identified by the same color. So you can see that this particular statement corresponds to those high IO Xact Sync wait times. And if you look at the third sequel statement, which is all orange in color, it refers to the SQL with a high CPU because, in the wait state, you can see that the CPU is colour coded as orange. So this statement represents a very high CPU sequel, and the green one is Lock Tuple. So that is indicating that the second SQL statement is actually resulting in a lock. So these are like nifty things that are really useful in fine-tuning your database's performance. And Performance Insights is really a very useful tool; it integrates well with the third-party tools as well. And for your performance analysis, you can definitely use the AAS or the database load along with the maximum CPU to make your assessments. For example, you can see that the horizontal dotted line is the maximum CPU, while the y axis is the DB load or average active sessions. And if you see that the a is less than one, then that means that your database is performing well. It's not blocked; a value equal to zero means your database is sitting idle. And if it is under the maximum CPU range, then that means that your CPU is available. You're well within your provisioned resources, but when AWS talks about the max CPU line, that's when it indicates that there are some performance issues. And if it is way above the maximum CPU line or stays about the maximum CPU line for a longer duration, then it definitely indicates a performance bottleneck. So you can use performance insights in this manner to pinpoint the performance bottlenecks, and then you can take appropriate actions to resolve those issues. You can also use performance insights for sizing. For example, if your CPU load is slightly less than the maximum CPU, then it means that your instance is oversized because you have provisioned a lot of CPUs, but the load on your system is very low, so it indicates that you have probably oversized your instance. And similarly, on the other hand, if CPU load is higher than the maximum CPU, it indicates that you have undersized your instance, which is causing your CPU to go above the maximum CPU range. So it definitely indicates that you've got to scale up your instance to get better performance. And you can see different weight times, and if you don't understand what they mean, simply hover over them, and RDS will show you what it means. If you look at IO Xact sync, for example, it may not make much sense unless you have extensive experience with the Postgres SQL database. So simply hover over that, and AWS will show you what that means. So in this particular case, Oxact Sync is a wait state in Postgres SQL where a session is issuing commits or rollbacks and the RDS or Aurora is waiting for storage to acknowledge persistence. In other words, what this means is that the database is waiting on commits, and that's causing the rates.

This can arise when there is a high rate of commits in your system. So, for example, you can see that this particular spike is due to IO exact sync, which means it's due to a high rate of commits, and the corresponding sequel statement can also be identified. Using the top SQL section, you can see that the queries that are contributing the most to this wait time are the first and fourth ones. Other queries are also making a contribution here. So, what can you do to solve this problem? So you can probably modify your application to commit transactions in batches. So you reduce the rate of commits on the system. And you should see that this rate state resolves itself. And if you see this along with a high CPU wait time, for example, in the second portion of the graph, you see the Iowa sync along with high CPU wait times.

It often means that the database load exceeds the allocated vCPUs. So you can see here that oxak sync corresponds with high CPU weight, and the query that corresponds to high CPU is this third one. So you can really make sense of these graphs by using the information presented in different sections of the Performance Inside dashboard. To address the second issue of IO xact sync with high CPU weight, for example, you can either reduce those workloads or scale up your instance to a larger number of CPUs. This particular I/O-exact sync ratestate is typical of Postgres SQL. And if you're interested in diving deeper into this, you can definitely visit this particular link to see the Commonwealth events. Now, common weight events vary by database engine, but this particular link will show you some of the events in Postgres SQL, all right? And you can also zoom in on these graphs to identify bottlenecks and their associated sequels.

If there are too many sequel statements that you see in your top sequel, you can simply zoom in on the graph to further drill down and find out the exact queries that might be associated with the particular weight states. Alright, then, Performance Insights automatically publishes the metrics to Cloud Watch, and it also integrates well with on-premises or third-party monitoring tools. And you have two options for the Performance Insights access control. So you can either use the Amazon RDS Full Access Policy or you can use a custom Im policy and attach it to the Im user or role. So here you can see a sample policy that provides permissions on the Pi Colon Start action that corresponds to performance insights on the RDS database. Alright, that's about it. Let's continue to the next lecture.

36. CloudWatch Application Insights

Now, let's quickly look at the Cloud Watch application insights. Now, this is a tool for Net and SQL Server, and it also supports DynamoDB tables. This tool identifies and configures key metrics logs and alarms for your SQL Server workloads. It uses Cloud Watch events and alarms, and it's very useful for problem detection, notification, and troubleshooting of your SQL Server workloads. All right, so that was quick on the Cloud Watch application insights.

37. RDS on VMware

Now, let's talk about RDS on VMware. So RDS on VMware really lets you deploy your RDS databases in your on-premise VMware environments. For example, you can use VMware VSphere to deploy your RDS database. So you have your on-premises data centre with RDS running on VMware, and it uses an RDS connector or VPN tunnel to talk to the RDS service on the AWS Cloud. So you get the same user interface as you see in AWS. And Arias on VMware supports my sequel, postcard sequel, and sequel server, and just like RDS, this is a fully managed database service. It uses health monitoring to detect unhealthy database instances and automatically recurs them. And it also supports manual and automatic backups with Pitr. And apart from that, you can also use Cloud Watch to monitor the RDS instances running on your on-premises VMware environments. Alright, so that's about it. Let's continue.

Amazon AWS Certified Database - Specialty practice test questions and answers, training course, study guide are uploaded in ETE Files format by real users. Study and Pass AWS Certified Database - Specialty AWS Certified Database - Specialty certification exam dumps & practice test questions and answers are to help students.