linux

pete.sharman's picture

Extending a Logical Volume Group

Introduction

Today I ran into the situation where I needed to extend a logical volume group so I could complete an installation. I’d already installed the Grid Infrastructure, but there wasn’t enough room remaining to install the Oracle kernel on the same device. This is for a test environment which was being built on a VM that had just been created, and performance is not the issue we’re looking at here, so installing the Grid Infrastructure and RDBMS on the same device is not a concern for me. I’ve been around the Oracle database for way too many years, but my sysadmin skills leave a lot to be desired, so I did what anyone in this situation would do – I googled “resize volume linux” and followed someone else’s instructions.

pete.sharman's picture

Extending a Logical Volume Group

Introduction

Today I ran into the situation where I needed to extend a logical volume group so I could complete an installation. I’d already installed the Grid Infrastructure, but there wasn’t enough room remaining to install the Oracle kernel on the same device. This is for a test environment which was being built on a VM that had just been created, and performance is not the issue we’re looking at here, so installing the Grid Infrastructure and RDBMS on the same device is not a concern for me. I’ve been around the Oracle database for way too many years, but my sysadmin skills leave a lot to be desired, so I did what anyone in this situation would do – I googled “resize volume linux” and followed someone else’s instructions.

fritshoogland's picture

A look into Oracle redo, part 2: the discovery of the KCRFA structure

This is the second post in a series of blogposts on Oracle database redo internals. If you landed on this blogpost without having read the first blogpost, here is a link to the first blogpost: https://fritshoogland.wordpress.com/2018/01/29/a-look-into-oracle-redo-part-1-redo-allocation-latches/ The first blogpost contains all the versions used and a synopsis on what the purpose of this series of blogposts is.

In the first part, I showed how the principal access to the public redo strands is controlled by redo allocation latches, and showed a snippet of trace information of memory accesses of a foreground session when using the first public redo strand:

martin.bach's picture

OSWatcher, Tracefile Analyzer, and Oracle 12.2 single instance

I have previously written about TFA, OSWatcher et all for Oracle 12.1. Since then, a lot of things have happened and I had an update for 12.2 on my to-do list for far too long. Experience teaches me that references to support notes and official documentation get out of date rather quickly, so as always, if you find anything that changed please let me know via the comments section and I’ll update the post.

This is going to be a 3 part mini-series to save you having to go over 42 pages of text … In this first part I’m going to have a look at single instance Oracle. In part 2 I’ll have a look at Oracle Restart environments, and finally in part 3 I’ll finish the series by looking at a 12.2 RAC system.

fritshoogland's picture

A look into Oracle redo, part 1: redo allocation latches

This will be a series of posts about Oracle database redo handling. The database in use is Oracle version 12.2.0.1, with PSU 170814 applied. The operating system version is Oracle Linux Server release 7.4. In order to look into the internals of the Oracle database, I use multiple tools; very simple ones like the X$ views and oradebug, but also advanced ones, quite specifically the intel PIN tools (https://software.intel.com/en-us/articles/pin-a-dynamic-binary-instrumentation-tool). One of these tools is ‘debugtrace’, which contains pretty usable output on itself (a indented list of function calls and returns), for which I essentially filter out some data, another one is ‘pinatrace’, which does not produce directly usable output, because it provides instruction pointer and memory addresses.

dbakevlar's picture

Linux for the SQL Server DBA, Part III

Yes, there’s a Part III!

You’re going to have to start scripting and now that you know a few VI/VIM commands, lets talk beginning scripting with shell.

In our example below, we’re going to start a new project called “test”.  For this, the requirements are:

dbakevlar's picture

Why SQL Server Shouldn’t Run as Root on Linux

So more than one person contacted me about my last post and stated that they didn’t see a problem with SQL Server on Linux running as the root user.

Me:

dbakevlar's picture

Linux 101 for SQL Server DBAs, Part II

Linux has become a clear area of required learning for SQL Server DBAs in as of SQL Server 2016.  What?  You didn’t read that right, you say?  Yes, while a Linux edition was introduced in SQL Server 2016, it was pushed to the forefront with the release of 2017, along with Python in a push towards stronger DevOps initiatives, (one OS to rule them all!) and Python to assist with even stronger analytics trends.

fritshoogland's picture

Introduction to pinatrace annotate version 2: a look into latches again

This post is an introduction to pinatrace annotate version 2, which is a tool to annotate the output of the Intel Pin tools ‘pinatrace’ tool.

The pinatrace tool generates a file with every single memory access of a process. Please realise what this means: this is every single read from main memory or write to main memory from the CPU. This allows you to get an understanding what happens within a C function. This means you can determine what information or data is accessed in what function. Needless to say this is a tool for internals investigations and research, not something for normal daily database maintenance and support. Also, the performance of the process that you attached to is severely impacted, and it can only be turned off by stopping the process. Do not use this on a production database, use this at your own risk for research and investigational purposes only.

martin.bach's picture

Little things worth knowing: redo transport in Data Guard 12.2 part 2

In the first part of this article I looked at a number of views and some netstat output to show how redo is transported from the primary database to its standby systems. The long story short is that TT02 (“async ORL multi”) was found sending redo to CDB3 asynchronously whilest NSS2 (“sync”) transferred redo to the synchronised target – CDB2. Unlike v$dataguard_process wanted me to believe, it really wasn’t LGWR sending redo over the network.

In this little article I would like to show you how the standby databases CDB2 and CDB3 receive redo and how you can map this back to the primary database, closing the loop.

To prevent automated spam submissions leave this field empty.
Syndicate content