Unix for Oracle DBAs Pocket Reference By Donald K. Burleson Publisher: O'Reilly Pub Date: January 2001 ISBN: 0-596-00066-9 Table of • Pages: 110 Contents • Index • Reviews • Examples Reader • Reviews • Errata Copyright Chapter 1. Unix for Oracle DBAs Pocket Reference Section 1.1. Introduction Section 1.2. Understanding Unix Section 1.3. Building Unix Commands Section 1.4. Unix Server Environment Section 1.5. Process Management Section 1.6. Server Values Section 1.7. Memory and CPU Management Section 1.8. Semaphore Management Section 1.9. System Log Messages Section 1.10. Server Monitoring Section 1.11. File Management Section 1.12. Disk Management Section 1.13. Miscellaneous Shell Scripts Chapter 1. Unix for Oracle DBAs Pocket Reference Section 1.1. Introduction Section 1.2. Understanding Unix Section 1.3. Building Unix Commands Section 1.4. Unix Server Environment Section 1.5. Process Management Section 1.6. Server Values Section 1.7. Memory and CPU Management Section 1.8. Semaphore Management Section 1.9. System Log Messages Section 1.10. Server Monitoring Section 1.11. File Management Section 1.12. Disk Management Section 1.13. Miscellaneous Shell Scripts 1.1 Introduction The Unix for Oracle DBAs Pocket Reference is a quick reference describing the Unix commands most often used by Oracle database administrators. It's the result of my 20 years of accumulating Unix tips and techniques. For each of the commands included in this book, I've provided the basic syntax and a short, illustrative example. This guide also contains many short Unix scripts that should save you dozens of hours of manual effort. I've organized the commands and examples in this book into the following major topic areas: Understanding Unix Gives you a little bit of the history of Unix and tells you some things that you need to know regarding case sensitivity, safety, and shells. Building Unix Commands Describes the process of creating complex Unix commands for Oracle. Unix Server Environment Describes the commands that make Unix easier for DBAs. Process Management Describes the basic Unix commands you use to display and manage server processes. Server Values Shows you how to display relevant server values in Unix. Memory and CPU Management Shows the main commands used to display information about memory segments, swap space, and semaphores used by an Oracle database. Also covers commands used to monitor CPU utilization. Semaphore Management Shows you how to monitor semaphore usage by your Oracle server and how to remove semaphore sets for an instance that has crashed. System Log Messages Shows you how to view operating-system log files. Server Monitoring Describes the details of using the server utilities vmstat, sar, and glance. File Management Describes commands that assist in file management tasks. Disk Management Shows you how to get information about the disks on your system. This section includes commands to list physical volumes, logical volumes, and mount points. Miscellaneous Shell Scripts Presents a number of shell scripts that I've found to be useful over the years, but that don't fit into any of the other sections. Writing this pocket reference was especially challenging because of the dialect differences between the major implementations of Unix. For example, commands in HP-UX are often different from those in Sun Solaris. I've emphasized commands that are common to all Unix dialects. Where differences occur, I've attempted to cover the following platforms: HP-UX, IBM AIX, and Sun Solaris. You'll also find some specific dialect commands for IRIX and DEC Unix. In addition to experimenting with the commands shown in this book, I encourage you to read more about them in books such as Unix in a Nutshell by Arnold Robbins (O'Reilly). Also, remember that the online Unix manpages are a great source of information about Unix commands. For example, to learn about the cat command, enter man cat at the command prompt. 1.1.1 Acknowledgments This type of book requires the dedicated efforts of many people, and I have worked closely as a team with many others who have supported this effort. Foremost, I need to acknowledge the efforts of my wife, Janet Burleson, whose impatience with Unix syntax led to the development of this book. This book certainly would not have been possible without a tremendous amount of hard work and support from the staff of O'Reilly & Associates. In particular, I would like to express my thanks to Jonathan Gennick, one of the Oracle Series editors, whose dedication to quality added a great deal of value to this text. Jonathan provided countless hours of work editing and improving each section in this book. Three technical reviewers also contributed generously of their time and efforts in order to make this a better book. My thanks to Dan Hardin, John-Paul Navarro, and Joseph Testa for their many comments and suggestions. Ellie Volckhausen designed the cover, and I want to thank her (I think) for giving me the fly book. It's certainly a memorable distinction. Flies are annoying, as is Unix at times. It's my sincere hope that after reading this book you will find Unix to be much less annoying than any pesky fly. 1.1.2 Conventions Used in This Book It is important to remember that all Unix commands are case-sensitive and should be entered exactly as displayed in this text. The following conventions are used in this book: Italics Used for script, file, and directory names, variables, utilities, commands in text, and new terms where defined. Constant Width Used for code examples. Constant Width Italics In some code examples, indicates an element (e.g., a filename) that you supply. Constant Width Bold Used to indicate user input in code examples. [] In syntax examples, square brackets enclose optional items. Indicates a tip, suggestion, or general note. Indicates a warning or caution. 1.1.3 Long Code Lines One aspect of Unix that caused my editor and me much consternation as we worked on this book was the problem of dealing with long Unix code lines in a narrow book format. When you start combining several Unix commands together as one large compound command, you quickly exceed the 50 characters or so that fit on one printed line in this book. Tabular output from the various monitoring utilities also typically exceeds 50 characters in width. After much discussion and debate, we came up with some solutions. Our approach to handling long code lines recognizes the following four categories: • Long commands introduced by preceding text • Long commands in input/output examples • Wide columnar output • Unix script examples Long commands that appear by themselves, and that are introduced by preceding text, are simply allowed to wrap to the width of the printed line. For example: ps -ef|grep "ora_"|grep -v grep|grep $ORACLE_SID|awk '{print $2}'|xargs kill -9 In these cases, it's usually obvious from the context that the multiple printed lines really represent one long Unix command. Similarly, I allow commands to wrap in input/output examples, as shown here: >ps -ef|grep "ora_"|grep -v grep|grep $ORACLE_SID|awk '{ print $2 }' 17748 18134 In these input/output examples, user input is shown in bold, and the prompt appears non-bold at the front of each input line. These visual cues make it reasonably obvious when a line has wrapped because of page width limitations. Wide, columnar output presented the greatest challenge. An 80-column report simply looks ugly if each line is allowed to wrap separately. I take one of two approaches to columnar output, depending on whether I need to keep all or only some of the columns. When it's not important for you to see every column of output, I snip a few columns out of the middle in order to make things fit. Notice the horizontal ellipses in the following example, which mark the location of one or more missing columns: -rwxr-xr-x 1 oracle dba ... 09:11 a.ksh* -rwxr-xr-x 1 oracle dba ... 09:11 lert.ksh* Where it's important that you see all of the columns, I split the output into two blocks, and I stack those blocks on top of each other. For example: Filesystem 1024-blks Free %Used... /dev/hd4 32768 11636 65%... /dev/hd2 802816 15920 99%... ... Iu %Iu Mounted on ... 2017 13% / ... 26308 14% /usr Here, the trailing ellipses at the end of the first three lines indicate where you would normally see more columns. Those columns are then shown separately, with leading ellipses to indicate the continuation. Using these two methods, I hope I've made the columnar output as readable as possible given the small size of this book. Scripts represent the last area of concern. I've included many small scripts in this book, and some of the commands in those scripts are quite long. Fortunately, I have some control of line width and format when writing a script. To provide reliable visual cues of when a long line wraps, I've chosen to make use of the Unix continuation character, which is a backslash (\). When you see it at the end of a long line, you know that the subsequent line is a continuation of the first. Here's an example: if [ -z "$2" ] then echo "Usage: mon_purge.ksh <ORACLE_SID>\ <#_days> (where value is > 100)" exit 99 fi In this if statement, the echo command is one long command. When you type in scripts from this book, you can enter them exactly as shown, including the backslash characters. Unix will recognize the backslashes and reassemble the continued commands before executing them. The following two commands, for example, are identical as far as Unix is concerned: echo "Hello world" echo "Hello\ world" When I continue commands, any leading spaces you see in a continuation line are significant. In this example, there is one space between the words "Hello" and "world". 1.2 Understanding Unix Unix is an operating system. It's been developed over the past 30 years by several different vendors. This book can't hope to be a tutorial on the use of Unix. I assume that you know enough to log into your Unix system, get a command prompt, and issue commands. Even so, there are some important things to review before you get started with this book. 1.2.1 History The history of Unix goes back to 1969, when the first versions of Unix were developed by AT&T's Bell Labs. The operating system had a certain elegance, was freely available, and quickly caught on with vendors of mini-computer systems who needed an operating system for the hardware that they were selling. As different vendors adopted Unix, they each began to create their own, slightly unique versions of the operating system. Today, you have HP-UX, Sun Solaris, IBM AIX, and a number of other variants to deal with. Linux is a Unix-like operating system first put together by Linus Torvalds in 1991 because he needed an operating system for his PC and could not afford any of the commercial Unix variants of that day. Linux has gone on to achieve phenomenal growth and is widely used today as a server operating system on x86 machines. Linux is also available for the PowerPC, Sparc, IBM S/390, and Amiga. Most commonly used Unix commands work more or less identically on all Unix and Linux platforms. The ls command, which lists files in a directory, is an example of such a command. I've never seen a Unix or Linux version that did not support ls. There are a number of command options available with ls, however, and not all options are available on all platforms. System management commands probably represent the area where you will run into the greatest number of differences between the Unix variants on the market. These are the commands used to display information about disks, memory, and performance. Most Unix users are not bothered by this problem, but unfortunately, these commands are the ones that you as the database administrator (DBA) will most likely need to use. Unless specified otherwise, I've used only commonly available commands and options in this book. Where platform differences exist, I've attempted to cover all the platforms listed in the introduction. Sometimes a command available on one platform does not have an analog on another. I've noted this in the text where appropriate. 1.2.2 Case Sensitivity Unix commands often consist of cryptic abbreviations and acronyms, and they are always case- sensitive. Command options are case-sensitive as well. People who have "grown up" using Unix simply accept this as the way things are, but it can be a major stumbling block for people making the transition to Unix from other operating systems. The vast majority of Unix commands are lowercase. The command to list files, for example, is ls. As you can see, you can enter ls in lowercase and get results, but if you try using uppercase, you'll get an error: >ls listener.ora sqlnet.log tnsnames.ora >LS bash: LS: command not found Unix commands support a wide variety of command options that allow you to fine-tune their behavior. Command options are introduced by a hyphen following the command, and they usually consist of one letter. Like commands, options are case-sensitive. For example, use ls -c, and you'll get a list of files in your current directory that is sorted by creation date. Use ls -C, and you'll get a columnar listing of files. 1.2.3 Safety Some operating systems attempt to protect you from making a serious mistake. Often this protection takes the form of an "are you sure?" prompt. Unix does no such thing. A key design philosophy behind Unix is to assume that you, the user, know exactly what you are doing at all times. Thus, if you log in as the root user, Unix will allow you to use a simple command such as rm -rf * to wipe out all files on every disk and filesystem connected to your server. You won't be prompted for confirmation. Unix will simply delete everything. Usually, you are protected from such disastrous consequences as deleting your entire disk by Unix privileges and file protections. No sane Unix administrator logs in as root unless root privileges are specifically required. This is the reason that all Oracle installs are done as the Unix Oracle user. Most users have access to only their own files. Still, when working in Unix, it pays to be careful. Be certain that you understand what a command is going to do before you issue it. When first using a new and potentially dangerous command, consider trying it out on a test system before you try it on your production servers. 1.2.4 Linkability Another guiding design philosophy of Unix is that commands should be simple, should do one thing well, and should be capable of linking with other commands. Because of this design, commands are frequently not issued by themselves, but rather in conjunction with one or more others. Each command performs one task, and then feeds its output to the next command. The following example shows cat and grep being used to extract information about the Oracle SID named prod from the /etc/oratab file: >cat /etc/oratab | grep prod prod:/s01/app/oracle/product/8.1.6:Y There are many examples in this book that reference the oratab file. In AIX and HP-UX, oratab is located in the /etc directory. In Solaris, the oratab file is located in the /var/opt/oracle directory. In this instance, cat types out the entire file. That output feeds into the grep command, which filters out everything but the line containing the word "prod". Commands such as this that are linked together can sometimes be quite long and intimidating. You'll learn more in Section 1.3. 1.2.5 Shells You'll often hear the term "shell" in connection with Unix. A Unix shell is a program that allows you to enter commands and see results. The bash shell is one of the most commonly used Unix shells. Other shells include csh and Korn. For consistency, all of the shell scripts are written for the Korn shell, one of the most popular Unix shells. Unix commands function identically under different shells, but shells also sometimes have commands of their own. All the commands in this book should work regardless of which shell you are using. The one area where you may be affected is described in the later section Section 1.4, where I talk about placing commands in a startup script that is executed when you first log on to your server. Not all shells use the same filename for the startup script. 1.3 Building Unix Commands One of the most confounding things for the Unix neophyte is being confronted with a complex Unix command. The cryptic nature of Unix is such that even the most seasoned Unix professional may have trouble deciphering such a command. Hidden in that complexity, however, is a great deal of power. In order to leverage that power for your day-to-day work, it's essential for you to learn how to deal with complex commands. In this section, we will begin by examining a cryptic Unix command in order to see how it is really composed of many simpler commands. We'll then walk through the process of creating such a command in order to perform a specific task.