5 tips to improve physical access security

There is a wealth of information on how to secure your computer against remote intrusions and infections by malicious mobile code on the Internet, and such topics are central to a lot of formal IT security education. Physically securing a computer against theft is generally pretty easy, if you’re smart about it. A more problematic area of security for your IT resources is that of securing them against unauthorized use when someone has physical access to them.
Whole books — whole libraries, even — of discussion of this subject have been written, for purposes of controlling how computers are used on a corporate network, monitoring their use, and even dealing with the sticky problem of policy enforcement. An oft-neglected matter is that of just ensuring that other people do not have unauthorized access when you leave your computer unattended for a few minutes.

There may be any number of reasons this facet of computer security is important to you, in particular. For instance:
While you may think the workplace is a safe place to leave your computer unattended, even when there isn’t strict employee monitoring going on, it’s always worth ensuring you don’t fall prey to the malicious behavior of disgruntled employees or unexpected visitors.
In a workplace where employee behavior is audited based on activity under login name, it may be desirable to ensure that nobody else can do something under your user account while you’re on break.

If you spend a fair bit of time in coffee shops and other public places, working (or playing) with your laptop, you may find yourself certain it won’t be stolen but not so certain that someone won’t do something with it while you’re away. Even normally trustworthy friends with whom you leave your laptop might have a mischievous streak and decide to change your GUI configuration to use a painful color scheme, such as MS Windows’ Hot Dog Stand theme.
While one would hope you do not leave your computer so unprotected as to get it stolen, protecting your sensitive data against recovery by thieves can be very important.
Let’s assume you use the obvious, high-tech measures that are all the rage these days — e.g. full disk encryption, strong password security for OS login, and individual file encryption where warranted. More immediate concerns, of the sort that can help protect you when you leave your laptop to go to the bathroom or when you leave your desk for an IT department meeting, should still be addressed. Five simple measures that can be taken to improve the security of your system against those who have direct access follow:

1. Set a BIOS/CMOS password.
On one hand, setting a BIOS/CMOS password for a computer doesn’t really provide much in the way of “real” security. If someone doesn’t mind taking apart the computer and pulling the CMOS battery off the motherboard, it’s easy to bypass a BIOS/CMOS password. On the other hand, if someone is only going to have access to your computer for a few minutes while you’re away from it, that can prove a significant stumbling block — a problem that could slow down someone’s ability to get in and out before you get back. Since the BIOS/CMOS password would then be cleared, rather than simply cracked, you would also have a pretty good indicator that someone was trying to get unauthorized access to what’s on your computer.

2. Disable booting from external media.
With the ability to carry around an operating system on a floppy disk, a bootable CD or DVD, or even a USB flash media storage device, any number of security cracking tools can be brought to bear very quickly by simply inserting such bootable media into the appropriate drive, tray, et cetera, and rebooting the machine. If you have all boot options other than your hard drive disabled in the CMOS settings, though, those settings would have to be changed to allow someone to boot up another OS with a bunch of automated security cracking tools. If you have a BIOS/CMOS password set, the would be security cracker will not be able to change those boot device settings without clearing CMOS settings, as I described above.

3. Always lock your screen and/or log out when away from the computer.
Leaving your computer running with everything still active and receptive to user input while you’re away is the quickest and easiest way to give unauthorized people access to a lot of stuff on your computer. Full disk encryption doesn’t do much good if you leave it running with the disk decrypted for use so any old joker can come along and sit down in front of it, pretending to be you long enough to copy sensitive files to a USB flash media storage device or — perhaps even easier — email them to himself via GMail or Yahoo! Mail. Use your system’s screen locking functionality to protect against this kind of physical access, such as a screen saver that won’t deactivate without a password, or just log out of everything so anyone that wants access has to log in again.
Some GUI environments don’t include this kind of functionality by default, of course, including my own window managers of choice (AHWM and wmii). Users of lightweight GUI environments like these are not without options, however; I use a tiny little screen locking utility called slock to get the screen locking capabilities I need, and it works brilliantly. If you use a tool like that, however, make sure you remember to log out of your TTY consoles as well, because slock and its kin will only lock the X session — not the TTY consoles.

4. Only use secure memory for encryption tools.
As I explained in the “insecure memory” FAQ, encryption tools that take a password have to be able to store that password somewhere when you use it — and if your computer’s RAM is being taxed by heavy usage, some of what’s in memory might get swapped to disk (i.e., stored in the page file, in Microsoft terminology). If that happens, it becomes difficult to ensure that the data will not still be there when you shut down your computer, sitting inertly on the hard drive, waiting for someone to come along with a simple forensic tool to recover your encryption password.
The key is to make sure you’re using secure memory — basically, memory that is managed differently from the way RAM usage is normally managed by the OS, so that the contents of the memory locations set aside for a given application will never be swapped to disk. See the “insecure memory” FAQ for more details. While you’re at it, make sure you don’t leave a computer unattended where others can get at it for a few minutes after your first shut it down, because even data stored only in RAM can sometimes be recovered if a malicious security cracker with physical access to the machine is very quick about it.

5. Set speedbumps in the way of unauthorized password recovery.
Most modern, general purpose OSes these days offer options for recovering from varying degrees of system corruption and user error. Some of these can even provide a means of recovering or resetting a lost administrator password — which then, in theory, gives one almost unfettered access to everything on the system (barring need for additional passwords in the case of encrypted files and the like). One of the easiest ways to accomplish this is with alternate operating modes, such as MS Windows Safe Mode and Unix (and Linux) Single-User Mode.
Safe Mode can ensure that a lot of security software is disabled on MS Windows, including some logging tools and encryption utilities that you may use. A stumbling block in the way of the would-be security cracker, however, is to simply make sure you give the Administrator account a password; by default, MS Windows XP (for instance) creates the Administrator account without a password, which is a terrible lapse in good security practice. Rectify that problem, and Safe Mode will be inaccessible to the casual, “drive-by” unauthorized person who wants access to your system. If such a person has one of the dozens of simple MS Windows password recovery tools available for free download from the Internet, though, this won’t be much of a barrier to entry.
Unix and Unix-like systems, on the other hand, tend to be more difficult to crack when it comes to circumventing security on the root password. Such OSes do have a Single-User Mode that can provide root-level access to much of the system if you don’t have it set up properly. It is possible to change configuration for TTY consoles to deny root access, to solve this problem, though. How this is accomplished will vary from system to system. For instance, on FreeBSD and Apple MacOS X the configuration options you need are in the /etc/ttys file, and on many Linux systems they’re in the /etc/securetty file.

Wrapping Up
Obviously, this article isn’t intended to provide you with better perimeter security in your enterprise network, or to teach you how to perform a site survey or penetration test. It is, however, meant to remind you about the sort of security measures that we should all employ on an individual basis, no matter what the context — work, home, school, et cetera — in one of the most overlooked, but most common, cases of vulnerability created by user carelessness. It isn’t comprehensive (it’s only a five item list, after all), but it gives you a place to start.
Often, the weakest link in a chain of security is the user. Don’t let that be true of you.

The 10 most useful Linux commands

I understand that many of you don’t want to use the command line in Linux (or in any operating system, for that matter). But the truth is, to be a good administrator, you have to know the command line. Why? Well, with Windows there are times when the command line is the only thing that can save your skin. With Linux, the command line is vast, reliable, flexible, fast… I could go on and on.
And of the 2,119 possible commands from the /usr/bin directory (in Mandriva Spring 2008) and the 388 possible commands from /usr/sbin/, a few are indispensable. Here are 10 of them that might make your Linux admin life — or your introduction to Linux — a whole lot simpler.
I could make this easy and go with the most used commands (cd, ls, rm, etc — okay, etc isn’t a command, but you get the point). But instead, I am going to go with the most useful commands, and I’ll keep it as distribution-neutral as I can.

#1: top
I figured it was fitting to put the top command at the top. Although top is actually responsible for listing currently running tasks, it is also the first command Linux users turn to when they need to know what is using their memory (or even how much memory a system has). I often leave the top tool running on my desktop so I can keep track of what is going on at all times. Sometimes, I will even open up a terminal (usually aterm), place the window where I want it, and then hide the border of the window. Without a border, the terminal can’t be moved, so I always have quick access to the information I need.
Top is a real-time reporting system, so as a process changes, it will immediately be reflected in the terminal window. Top does have some helpful arguments (such as the -p argument, which will have top monitor only user-specified PIDs), but running default, top will give you all the information you need on running tasks.
#2: ln
To many administrators, links are an invaluable tool that not only make users lives simpler but also drastically reduce disk space usage. If you are unaware of how links can help you, let me pose this simple scenario: You have a number of users who have to access a large directory (filled with large files) on a drive throughout the day. The users are all on the same system, and you don’t want to have to copy the entire directory to each user’s ~/ directory. Instead, just create a link in each user’s ~/ directory to the target. You won’t consume space, and the users will have quick access. Of course when spanning drives, you will have to use symlinks. Another outstanding use for links is linking various directories to the Apache doc root directory. Not only can this save space, it’s often advantageous from a security standpoint.
#3: tar/zip/gzip
Tar, zip, and gzip are archival/compression tools that make your administrator life far easier. I bundle these together because the tools can handle similar tasks yet do so with distinct differences (just not different enough to warrant their own entry in this article). Without these tools, installing from source would be less than easy. Without tar/zip/gzip, creating backups would require more space than you might often have.
One of the least used (but often most handy) features of these tools is the ability to extract single files from an archive. Now zip and gzip handle this more easily than tar. With tar, to extract a single file, you have to know the exact size of the file to be extracted. One area where tar/zip/gzip make administration simple is in creating shells scripts that automate a backup process. All three tools can be used with shell scripts and are, hands down, the best, most reliable backup tools you will find.
#4: nano, vi, emacs
I wasn’t about to place just one text editor here, for fear of stoking the fires of the “vi vs. emacs” war. To top that off, I figured it was best to throw my favorite editor — nano — into the mix. Many people would argue that these aren’t so much commands as they are full-blown applications. But all these tools are used within the command line, so I call them “commands.” Without a good text editor, administering a Linux machine can become problematic.
Imagine having to attempt to edit /etc/fstab or /etc/samba/smb.conf with OpenOffice. Some might say this shouldn’t be a problem, but OpenOffice tends to add hidden end-of-line characters to text files, which can really fubar a configuration file. For the editing of configuration or bash files, the only way to go is with an editor such as nano, vi, or emacs.
#5: grep
Many people overlook this amazingly useful tool. Grep prints lines that match a user-specified pattern. Say, for instance, that you are looking at an httpd.conf file that’s more than 1,000 lines long, and you are searching for the “AccessFileName .htaccess” entry. You could comb through that file only to come across the entry at line 429, or you can issue the command grep -n “AccessFileName .htaccess” /etc/httpd/conf/http.conf. Upon issuing this command you will be returned “439:AccessFileName .htaccess” which tells you the entry you are looking for is on, surprise of all surprises, line 439.
The grep command is also useful for piping other commands to. An example of this is using grep with the ps command (which takes a snapshot of current running processes.) Suppose you want to know the PID of the currently crashed Firefox browser. You could issue ps aux and search through the entire output for the Firefox entry. Or you could issue the command ps auxgrep firefox, at which point you might see something like this:jlwallen 17475 0.0 0.1 3604 1180 ?

Ss 10:54 0:00 /bin/sh /home/jwallen/firefox/firefoxjlwallen 17478 0.0 0.1 3660 1276 ? S 10:54 0:00 /bin/sh /home/jlwallen/firefox/run-mozilla.sh /home/jlwallen/firefox/firefox-bin
jlwallen 17484 11.0 10.7 227504 97104 ? Sl 10:54 11:50 /home/jlwallenfirefox/firefox-bin
jlwallen 17987 0.0 0.0 3112 736 pts/0 R+ 12:42 0:00 grep --color firefox
Now you know the PIDs of every Firefox command running.
#6: chmod
Permissions anyone? Linux administration and security would be a tough job without the help of chmod. Imagine not being able to make a shell script executable with chmod u+x filename. Of course it’s not just about making a file executable. Many Web tools require certain permissions before they will even install. To this end, the command chmod -R 666 DIRECTORY/ is one very misused command. Many new users, when faced with permissions issues trying to install an application, will jump immediately to 666 instead of figuring out exactly what permissions a directory or folder should have.
Even though this tool is critical for administration, it should be studied before jumping in blindly. Make sure you understand the ins and outs of chmod before using it at will. Remember w=write, r=read, and x=execute. Also remember UGO or User, Group, and Other. UGO is a simple way to remember which permissions belong to whom. So permission rw- rw- rw- means User, Group, and Other all have read and write permissions. It is always best to keep Other highly restricted in their permissions.
#7: dmesg
Call me old-school if you want, but any time I plug a device into a Linux machine, the first thing I do is run the dmesg command. This command displays the messages from the kernel buffer. So, yeah, this is an important one. There is a lot of information to be garnered from the dmesg command. You can find out system architecture, gpu, network device, kernel boot options used, RAM totals, etc.
A nice trick is to pipe dmesg to tail to watch any message that comes to dmesg. To do this, issue the command dmesg tail -f and the last few lines of dmesg will remain in your terminal. Every time a new entry arrives it will be at the bottom of the “tail.” Keep this window open when doing heavy duty system administration or debugging a system.
#8: kill/killall
One of the greatest benefits of Linux is its stability. But that stability doesn’t always apply to applications outside the kernel. Some applications can actually lock up. And when they do, you want to be able to get rid of them. The quickest way to get rid of locked up applications is with the kill/killall command. The difference between the two commands is that kill requires the PID (process ID number) and killall requires only the executable name.
Let’s say Firefox has locked up. To kill it with the kill command you would first need to locate the PID using the command ps auxgrep firefox command. Once you got the PID, you would issue kill PID (Where PID is the actual PID number). If you didn’t want to go through finding out the PID, you could issue the command killall firefox (although in some instances it will require killall firefox-bin). Of course, kill/killall do not apply (nor should apply) to daemons like Apache, Samba, etc.
#9: man
How many times have you seen “RTFM”? Many would say that acronym stands for “Read the Fine* Manual” (*This word is open for variation not suitable for publication.) In my opinion, it stands for “Read the Fine Manpage.” Manpages are there for a reason — to help you understand how to use a command. Manpages are generally written with the same format, so once you gain an understanding of the format, you will be able to read (and understand) them all. And don’t underestimate the value of the manpage. Even if you can’t completely grasp the information given, you can always scroll down to find out what each command argument does. And the best part of using manpages is that when someone says “RTFM” you can say I have “RTFMd.”
#10: mount/umount
Without these two commands, using removable media or adding external drives wouldn’t happen. The mount/umount command is used to mount a drive (often labeled like /dev/sda) to a directory in the Linux file structure. Both mount and umount take advantage of the /etc/fstab file, which makes using mount/umount much easier. For instance, if there is an entry in the /etc/fstab file for /dev/sda1 that maps it to /data, that drive can be mounted with the command mount /data. Typically mount/umount must have root privileges (unless fstab has an entry allowing standard users to mount and unmount the device). You can also issue the mount command without arguments and you will see all drives that are currently mounted and where they’re mapped to (as well as the type of file system and the permissions).
Can’t live without ‘em
These 10 Linux commands make Linux administration possible. There are other helpful commands, as well as commands that are used a lot more often than these. But the commands outlined here fall into the necessity category. I don’t know about you, but I don’t go a day without using at least half of them.

IPv6: What is Internet Protocol?

Internet Protocol (IP) is one of many communications protocols that compose the Internet Protocol Suite(IPS) and is arguably the most important protocol. Experts usually describe IPS as a stack of protocols that convert application information (like e-mail or Web traffic) into digital packets capable of traversing networks, including the Internet.
Specifically, IP is responsible for transmitting the digital packets from a source host to a destination host over a network connection. The Request for Comment (RFC) 791 is the last word about IP and provides the following definition:
“The internet protocol is specifically limited in scope to provide the functions necessary to deliver a package of bits (an internet datagram) from a source to a destination over an interconnected system of networks. There are no mechanisms to augment end-to-end data reliability, flow control, sequencing, or other services commonly found in host-to-host protocols. The internet protocol can capitalize on the services of its supporting networks to provide various types and qualities of service.”
Packets and datagrams: Is there a difference?
When discussing IP, many people (including me) interchange the terms packet and datagram as both terms have similar (identical, some argue) definitions. RFC 1594 defines a datagram/packet as:
“A self-contained, independent entity of data carrying sufficient information to be routed from the source to the destination computer without reliance on earlier exchanges between the source and destination computer and the transporting network.”
Since they’re the same, why worry about definitions? Well, sometimes experts define packets differently from datagrams, and that’s when it gets confusing. They use the term packet when discussing reliable data transmission protocols such as TCP/IP, and then use the term datagram when talking about best-effort data transmission protocols like UDP. For our discussion of IP, it doesn’t matter which term is used, but I’d like to stick with datagram (you’ll see why in a moment).
IP attributes
IP has several attributes that define how data is transmitted, and they’re important regardless of whether we’re discussing IPv4 or IPv6. So, let’s take a look at them:
Host addressing: IP defines the addressing scheme for each host on the network and uses the addresses to facilitate datagram delivery.
Protocol independence: IP by design is able to work with any type of underlying network protocol using protocol stack technology.
Connectionless delivery: IP does not set up a relationship between the sending host and the receiving host. The sending host just creates datagrams and sends them on their way.
Best-effort delivery: IP tries its best to ensure that the receiving host actually gets the datagrams addressed to it, but there are no guarantees.
No provision for delivery acknowledgments: The receiving host does not acknowledge the fact that it indeed did receive the data addressed to it.
One wonders how IP datagrams get where they’re supposed to, when the last three attributes create less than a perfect environment. Why leave those features out of the protocol? The simple reason is better performance. Using established connections, error-checking, and guaranteed delivery require additional processing power and network bandwidth. So if the datagram being transmitted does not require certain attributes, it’s better they aren’t used. Besides, the people who developed IP are a smart bunch, designing a more efficient approach that uses protocol stacking.
Protocol or TCP/IP stack
If you recall, I mentioned something called a protocol stack (officially TCP/IP) earlier. If the type of transmitted data (such as e-mail) requires guaranteed delivery, receipt acknowledgment, or an official connection handshake, the information is appended earlier in the datagram-building process, or what is called “further up the stack.” It turns out to be good solution, especially since it conserves network resources.
On a side note, I debated whether to include information about the TCP/IP stack in this discussion, as we’re supposed to be focused on IP. The only problem is that it’s very hard to divorce TCP from IP. Especially since a large percentage of datagrams include TCP information.
TCP/IP Guide has an excellent explanation of what a TCP/IP stack is and how it works. The process of encapsulation (ultimately why I included this information) also takes place in the TCP/IP stack. Encapsulation is where the next protocol in the stack encapsulates the datagram, giving it additional information that’s required, so the packet can successfully reach its destination.

10 mistakes new Linux administrators make

If you’re new to Linux, a few common mistakes are likely to get you into trouble. Learn about them up front so you can avoid major problems as you become increasingly Linux-savvy.
For many, migrating to Linux is a rite of passage that equates to a thing of joy. For others, it’s a nightmare waiting to happen. It’s wonderful when it’s the former; it’s a real show stopper when it’s the latter. But that nightmare doesn’t have to happen, especially when you know, first hand, the most common mistakes new Linux administrators make. This article will help you avoid those mistakes by laying out the most typical Linux missteps.

#1: Installing applications from various types
This might not seem like such a bad idea at first. You are running Ubuntu so you know the package management system uses .deb packages. But there are a number of applications that you find only in source form. No big deal right? They install, they work. Why shouldn’t you? Simple, your package management system can’t keep track of what you have installed if it’s installed from source. So what happens when package A (that you installed from source) depends upon package B (that was installed from a .deb binary) and package B is upgraded from the update manager? Package A might still work or it might not. But if both package A and B are installed from .debs, the chances of them both working are far higher. Also, updating packages is much easier when all packages are from the same binary type.
#2: Neglecting updates
Okay, this one doesn’t point out Linux as much as it does poor administration skills. But many admins get Linux up and running and think they have to do nothing more. It’s solid, it’s secure, it works. Well, new updates can patch new exploits. Keeping up with your updates can make the difference between a compromised system and a secure one. And just because you can rest on the security of Linux doesn’t mean you should. For security, for new features, for stability — the same reasons we have all grown accustomed to updating with Windows — you should always keep up with your Linux updates.
#3: Poor root password choice
Okay, repeat after me: “The root password is the key to the kingdom.” So why would you make the key to the kingdom simple to crack? Sure, make your standard user password something you can easily remember and/or type. But that root password — you know, the one that’s protecting your enterprise database server — give that a much higher difficulty level. Make that password one you might have to store, encrypted, on a USB key, requiring you to slide that USB key into the machine, mount it, decrypt the password, and use it.
#4: Avoiding the command line
No one wants to have to memorize a bunch of commands. And for the most part, the GUI takes care of a vast majority of them. But there are times when the command line is easier, faster, more secure, and more reliable. Avoiding the command line should be considered a cardinal sin of Linux administration. You should at least have a solid understanding of how the command line works and a small arsenal of commands you can use without having to RTFM. With a small selection of command-line tools on top of the GUI tools, you should be ready for just about anything.
#5: Not keeping a working kernel installed
Let’s face it, you don’t need 12 kernels installed on one machine. But you do need to update your kernel, and the update process doesn’t delete previous kernels. What do you do? You keep at least the most recently working kernel at all times. Let’s say you have 2.6.22 as your current working kernel and 2.6.20 as your backup. If you update to 2.6.26 and all is working well, you can remove 2.6.20. If you use an rpm-based system, you can use this method to remove the old kernels: rpm -qa grep -i kernel followed by rpm-e kernel-{VERSION}.
#6: Not backing up critical configuration files
How many times have you upgraded X11 only to find the new version fubar’d your xorg.conf file to the point where you can no longer use X? It used to happen to me a lot when I was new to Linux. But now, anytime X is going to be updated I always back up /etc/X11/xorg.conf in case the upgrade goes bad. Sure, an X update tries to back up xorg.conf, but it does so within the /etc/X11 directory. And even though this often works seamlessly, you are better off keeping that backup under your own control. I always back up xorg.conf to the /root directory so I know only the root user can even access it. Better safe than sorry. This applies to other critical backups, such as Samba, Apache, and MySQL, too.
#7: Booting a server to X
When a machine is a dedicated server, you might want to have X installed so some administration tasks are easier. But this doesn’t mean you should have that server boot to X. This will waste precious memory and CPU cycles. Instead, stop the boot process at runlevel 3 so you are left at the command line. Not only will this leave all of your resources to the servers, it will also keep prying eyes out of your machine (unless they know the command line and passwords to log in). To log into X, you will simply have to log in and run the command startx to bring up your desktop.
#8: Not understanding permissions
Permissions can make your life really easy, but if done poorly, can make life really easy for hackers. The simplest way to handle permissions is using the rwx method. Here’s what they mean: r=read, w=write, x=execute. Say you want a user to be able to read a file but not write to a file. To do this, you would issue chmod u+r,u-wx filename. What often happens is that a new user sees an error saying they do not have permission to use a file, so they hit the file with something akin to chmod 777 filename to avoid the problem. But this can actually cause more problems because it gives the file executable privileges. Remember this: 777 gives a file rwx permissions to all users (root, group, and other), 666 gives the file rw privileges to all users, 555 gives the file rx permissions to all users, 444 gives r privileges to all users, 333 gives wx privileges to all users, 222 gives w privileges to all users, 111 gives x privileges to all users, and 000 gives no privileges to all users.
#9: Logging in as root user
I can’t stress this enough. Do NOT log in as root. If you need root privileges to execute or configure an application, su to root in a standard user account. Why is logging in as root bad? Well, when you log on as a standard user, all running X applications still have access only to the system limited to that user. If you log in as root, X has all root permissions. This can cause two problems: 1) if you make a big mistake via a GUI, that mistake can be catastrophic to the system and 2) with X running as root that makes your system more vulnerable.
#10: Ignoring log files
There is a reason /var/log exists. It is a single location for all log files. This makes it simple to remember where you first need to look when there is a problem. Possible security issue? Check /var/log/secure. One of the very first places I look is /var/log/messages. This log file is the common log file where all generic errors and such are logged to. In this file you will get messages about networking, media changes, etc. When administering a machine you can always use a third-party application such as logwatch that can create various reports for you based on your /var/log files.
Sidestep the problems
These 10 mistakes are pretty common among new Linux administrators. Avoiding the pitfalls will take you through the Linux migration rite of passage faster, and you will come out on the other side a much better administrator.

ORACLE8 AND THE WINDOWS NT OPERATING SYSTEM

ORACLE8 AND THE WINDOWS NT OPERATING SYSTEM
The Oracle8 RDBMS for NT is written using Microsoft’s 32-bit API. By using the Microsoft 32-bit API the Oracle8 RDBMS has been tightly integrated with the underlying hardware. Oracle8’s architecture for Microsoft Windows NT has been implemented as a single multithreaded process to conform with the Windows NT memory model.Under the Windows NT operating system a process represents a logical unit of work or job that the operating system is to perform. A thread is one of many subtasks that are required to accomplish the job. The components of a thread include:
A unique identifier called a client ID.
The content of a set of registers that represent the state of the processor.
A stack for when the thread is running in user mode and a stack for when the thread is running in kernel mode.
The thread resides within the process’s virtual address space. When more then one thread exists in the same process, the threads share the address space of all the process’s resources. The NT kernel schedules processes thread(s) for execution. All processes running under Windows NT must have at least one thread before the process can be executed.Unlike Oracle8 for UNIX, Oracle8 for NT uses a single process with multiple threads, thereby sharing memory in a single address space. The database uses the operating system facility for preemptive scheduling and load balancing across multiple CPUs.The Oracle instance on Windows NT consists of a memory segment and a number of background threads. By default, the Oracle8 server and its associated background threads run in the Normal Priority class. In this class, the scheduler can dynamically vary the priority between 1 and 15, but it cannot raise the dynamic priority to the real-time priority class. The real-time priority class ranges from 16 to 31 and cannot vary in priority based on behavior.The Windows NT GUI and its associated utilities can be used to observe various portions of the Oracle8 RDBMS. The Windows menu is used to access the Windows NT control panel.By accessing the Windows NT CONTROL PANEL the administrator can perform various tasks One such task may be to observe, start, or stop any of the various services that are running on the machine. The various services associated with the Oracle RDBMS. The remainder of this chapter is used to investigate the various components of the Oracle8 RDBMS architecture. Where possible the GUI utilities provided by the Windows NT operating system are used to observe the various components of the RDBMS. The same utilities will also help develop our understanding of how the Oracle8 RDBMS is integrated with the Windows NT operating system.ORACLE8 RDBMS ARCHITECTUREThe architecture of the Oracle RDBMS is divided into two distinct parts. One part is called the Oracle database the other part is called the Oracle The Oracle database is defined as:
A logical collection of data to be treated as a unit (tables).
Operating system files called data files, redo log files, initialization files and control files.
The Oracle instance is defined as:
The software mechanism used for accessing and controlling the database.
Having at least four background threads called PMON, SMON, DBWR and LGWR.
Including memory structures called the SGA and the PGA.
Each Oracle instance is identified by a System Identifier (SID).
Instances and databases are independent of each other, but neither is of any use without the other. For the end user to access the database the Oracle instance must be started (the four background threads must be running) and the database must be mounted (by the instance) and opened. In the simple model a database can be mounted by only one instance. The exception to this is the Oracle parallel server, where a database can be mounted by more then one Oracle instance.ORACLE DATABASE STRUCTUREOur discussion of the Oracle RDBMS architecture will first focus on that part that makes up the Oracle database. The Oracle database has both a physical and a logical structure. The physical structure consists of the operating system files that make up the database. The logical structure is determined by the number of tablespaces and the database’s schema objects.TablespacesAll Oracle databases must consist of at least one logical entity called a tablespace. The characteristics of a tablespace are:
One or more per database. The database must have at least one tablespace called “SYSTEM.” The SYSTEM tablespace holds the Oracle Data Dictionary. The Data Dictionary holds the various system tables and views such as the Oracle performance tables, information about the users of the database, and how much space is left in the various tablespaces that make up the database. There are usually more tablespaces other than the SYSTEM tablespace. Most Oracle databases also include additional tablespaces. These tablespaces are used to hold user data for sorting, and indexes that are used to speed up data access. Additional tablespaces should be created to hold data that is being sorted and another tablespace to hold data that is required for read consistency.
The physical representation of the tablespace is called a data file (a tablespace may consist of more then one data file).
Can be taken off line (due to media failure or maintenance purposes) leaving the database running. The exception to this rule is that the SYSTEM tablespace cannot be taken off line if the database is to remain running.
Unit of space for object storage. Objects are tables, indexes synonyms, and clusters.
Contains default storage parameters for database objects.
When an end-user’s Oracle user ID is created the user is given access to a default tablespace and a temporary tablespace (where the sorting of data is performed).
Can be dropped (removed from the database).
As stated previously tablespaces are logical entities. Tablespaces are physically represented by files that are called data files. Data files have the following attributes:
Are operating system files.
There is one or more per tablespace.
The finest granularity of the data file is called the data block.
A collection of data blocks is called an extent.
A segment (by definition) consists of one or more extents (therefore to make a segment larger, extents are added to the segment).
A data file consists of segments.
Contain transaction System Change Numbers (SCNs).
Data File Contents and Types of SegmentsA data file can consist of several types of segments and a segment can consist of one of more extents. The four different types of segments are rollback segments, temporary segments, index segments and data segments.Rollback segments have the following attributes:
Records old data.
Provides for rollback of uncommitted transactions.
Provides information for read consistency.
Used during database recovery from media or processor failure.
Wrap-around/reuseable.
Can be dynamically created or dropped.
Rollback segments contain the following information:
Transaction ID.
File ID.
Block number
Row number
Column number
Row/column data.
Temporary segments have the following attributes:
Used by the Oracle RDBMS as a work area for sorting data.
The DBA defines which tablespace will contain temporary segments and therefore the tablespace where sorting will occur.
Index segments have the following attributes:
Allows for faster data retrieval by providing an index for the data in a table, thus eliminating a full table scan during the execution of a query (similar to how a reader would use the index in a book rather then scanning through the entire book to find a particular topic).
Data segments have the following attributes:
One per table/snapshot.
Contains all table data.
Data segments contain the following information:
Transaction ID.
File ID.
Block number
Row number
Column number
Row/column data.
Besides data files there are also files called redo log files. Redo log files record changes made to the database by various transactions. All changes made to the database will first be written to the redo log file. These files can also be written to an off-line log file (archived). Redo logs are used during database recovery to recover the database to the last physical backup or to the point in time of failure (for this type of recovery the database must be running in ARCHIVELOG mode). Redo log files have the following attributes:
Records new data.
Ensures permanence of data transactions.
Provides for roll forward recovery during database startup and after a media failure.
Redo log files contain:
Transaction IDs
Contents of redo log buffers.
Transaction SCN.
The Control FileEach database has one or more control files. The control file is used to store information about the database. The information in the control file includes:
Transaction System Change Number (SCN)
Location of all datafiles.
Names and locations of the redo log files.
Time stamp when database was created.
Database name.
Database size.
For database recovery purposes it is best to have multiple copies of the control file. Without the control file the Oracle RDBMS cannot find the pointers to the rest of the files that make up the database (data files and redo log files).The INIT.ORA FileThe init.ora file is the database initialization parameter file. It is only read at database start-up time. Every Oracle instance that is running will have its own init.ora file (the user should substitute with the Oracle System IDentifier for their instance). This file contains various initialization and tuning parameters that are needed by the RDBMS. Some of the parameters in the init.ora file are:
The maximum number of processes that the Oracle instance will use (PROCESSES=).
The name of the database (DB_NAME=).
Various parameters for tuning memory management (DB_BLOCK_BUFFERS, SORT_AREA_SIZE...)
The location of the control file(s).
How these parameters affect the starting and running of the database are covered in the chapters on Oracle RDBMS installation and performance analysis and tuning.