2.Local search – Visit Google Local enter the area you want to search and the keyword of the place you want to find. For example, typing: restaurant at the above link would display local restaurants.

3.Phone number lookup – Enter a full phone number with area code to display the name and address associated with that phone number.

4.Find weather – Type weather followed by a zip code or city and state to display current weather conditions and forecasts for upcoming days.

5.Track airline flight – Enter the airline and flight number to display the status of an airline flight and it’s arrival time. For example, type: delta 123 to display this flight information if available.

6.Track packages – Enter a UPS, FedEx or USPS tracking number to get a direct link to track your packages.

7.Pages linked to you – See what other web pages are linking to your website or blog by typing link: followed by your URL. For example, typing link:http://www.computerhope.com displays all pages linking to Computer Hope.

8.Find PDF results only – Add filetype: to your search to display results that only match a certain file type. For example, if you wanted to display PDF results only type: “dell xps” filetype:pdf — this is a great way to find online manuals.

9.Calculator – Use the Google Search engine as a calculator by typing a math problem in the search. For example, typing: 100 + 200 would display results as 300.

10.Stocks – Quickly get to a stock quote price, chart, and related links by typing the stock symbol in Google. For example, typing: msft will display the stock information for Microsoft.

DHCP is controlled by a DHCP server. Your router can be a DHCP server…and if you’re on a home network, it most likely is your DHCP server.

I know this might be confusing because the word dynamic is in the term, but just because you have DHCP enabled on your computer doesn’t mean you can’t be assigned a static IP. DHCP enabled on your computer simply means you’re letting a DHCP server assign its IP. Having it enabled DOES NOT mean it’s a DHCP server.

A true DHCP server (not your Linksys router) gives the LAN Admin a ton of control with IP assigning.

Ever print to a network printer? Ever wonder how that printer keeps its network assignment? Probably through DHCP. Each network device has a MAC address. You can assign a static IP at the DHCP server to a specific MAC address. This allows the network printer to always get the same IP even after it reboots and without assigning the IP at the printer. If you print the network configuration at the printer, it will probably tell you that DHCP is enabled and no static IP is assigned. That’s because the IP assignment is handled at the DHCP server.

Your ISP has a DHCP server. They can assign IPs by modem MAC addresses. When your modem comes online, it communicates to the network indicating it is looking for an IP address. The DHCP server listens to this communication and starts talking to the modem. The modem then transmits its MAC address to the DHCP server. At that point, either an IP has been reserved for the modem or one is assigned at that time. Hence cloning your MAC address to get a new IP from your ISP.

Routers and DHCP – Under the General Setup or LAN Setup tab in your router, you’ll see a settings option for DHCP. You can control how many IPs are assigned or to enable/disable the DHCP server portion of the router. If you disable it, you’ll have to statically assign IPs to each computer, or have a DHCP server or your network. This goes for wired and wireless. Any connection on your network has an IP address.

There’s a lot more to DHCP than this, but this is a basic explanation.

File transfer over the network using FTP protocol (defined by RFC 959 and later additions) has its roots in 1980, when the first RFC for FTP protocol was published. FTP provides functions to upload, download, and delete files; create and delete directories; and read directory contents. Although FTP is very popular, it has certain disadvantages that make it harder to use. The major drawbacks are lack of the uniform format for directory listing (this problem has been partially solved by introducing the MLST command, but it’s not supported by some servers) and the presence of the secondary connection (DATA connection). Security in FTP is provided by employing SSL/TLS protocol for channel encryption as defined in RFC 2228. The secured version of FTP is called FTPS.

In UNIX systems, another security standard has grown. It was the SSH family of protocols. The primary function of SSH was to secure remote shell access to UNIX systems. Later, SSH was extended with file transfer protocol—first SCP (in SSH 1.x), and then SFTP (in SSH2). Version 1 of the SSH protocol is outdated, unsecure, and generally not recommended for use. Consequently, SCP is not used anymore and SFTP gains popularity day by day.

The “SFTP” abbreviation is often mistakenly used to specify some kind of Secure FTP, by which people most often mean FTPS. Another (similar) mistake is that SFTP is thought to be some kind of FTP over SSL. In fact, SFTP is an abbreviation of “SSH File Transfer Protocol.” This is not FTP over SSL and not FTP over SSH (which is also technically possible, but very rare).

SFTP is a binary protocol, the latest version of which is standardized in RFC 4253. All commands (requests) are packed to binary messages and sent to the server, which replies with binary reply packets. In later versions, SFTP has been extended to provide not just file upload/download operations, but also some file-system operations, such as file lock, symbolic link, creation, and so forth.

Both FTPS and SFTP use a combination of an asymmetric algorithm (RSA, DSA), a symmetric algorithm (DES/3DES, AES, Twhofish and so on), and a key-exchange algorithm. For authentication, FTPS (or, to be more precise, SSL/TLS protocol under FTP) uses X.509 certificates, whereas SFTP (SSH protocol) uses SSH keys.

X.509 certificates include the public key and certain information about the certificate owner. This information lets the other side verify the integrity of the certificate itself and authenticity of the certificate owner. Verification can be done both by computer and to some extent by the human. An X.509 certificate has an associated private key that is usually stored separately from the certificate for security reasons.

A SSH key contains only a public key (the associated private key is stored separately). It doesn’t contain any information about the owner of the key. Neither does it contain information that lets one reliably validate the integrity and authenticity. Some SSH software implementations use X.509 certificates for authentication, but in fact they don’t validate the whole certificate chain—only the public key is used (which makes such authentication incomplete and similar to SSH key authentication).

Here’s the brief list of pros and cons of the two protocols:

FTPS

Pros:

Widely known and used
The communication can be read and understood by humans
Provides services for server-to-server file transfer
SSL/TLS has good authentication mechanisms (X.509 certificate features)
FTP and SSL/TLS support is built into many Internet communication frameworks
Cons:

Doesn’t have a uniform directory listing format
Requires a secondary DATA channel, which makes it hard to use behind the firewalls
Doesn’t define a standard for file name character sets (encodings)
Not all FTP servers support SSL/TLS
Doesn’t have a standard way to get and change file and directory attributes
SFTP

Pros:

Has good standards background that strictly defines most (if not all) aspects of operations
Has only one connection (no need for DATA connection)
The connection is always secured
The directory listing is uniform and machine-readable
The protocol includes operations for permission and attribute manipulation, file locking, and more functionality
Cons:

The communication is binary and can’t be logged “as is” for human reading
SSH keys are harder to manage and validate
The standards define certain things as optional or recommended, which leads to certain compatibility problems between different software titles from different vendors
No server-to-server copy and recursive directory removal operations
No built-in SSH/SFTP support in VCL and .NET frameworks
What to Choose

As usual, the answer depends on what your goals and requirements are. In general, SFTP is technologically superior to FTPS. Of course, it’s a good idea to implement support for both protocols, but they are different in concepts, in supported commands, and in many other things.

It’s a good idea to use FTPS when you have a server that needs to be accessed from personal devices (smartphones, PDAs, and the like) or from some specific operating systems that have FTP support but don’t have SSH/SFTP clients. If you are building a custom security solution, SFTP is probably the better option.

As for the client side, the requirements are defined by the server(s) that you plan to connect to. When connecting to Internet servers, SFTP is more popular because it’s supported by Linux and UNIX servers by default.

For private host-to-host transfer, you can use both SFTP and FTPS. For FTPS, you would need to search for a free FTPS client and server software or purchase a license for commercial one. For SFTP support, you can install an OpenSSH package that provides free client and server software.

Developer Tools

If you are a software developer and need to implement file transfer capability in your application, you will be searching for the components to do the job.

In .NET, you have built-in support for FTPS in the .NET Framework (see the FtpWebRequest class). However, functionality of this class is severely limited, especially in the SSL/TLS control aspect. The .NET Framework doesn’t include any support for SSH or SFTP.

In VCL, you have a selection of free components and libraries that provide FTP functionality. When you add OpenSSL to them, you can get FTPS for free. If you don’t want to deal with OpenSSL DLLs, you can use one of the commercially available libraries for SSL and FTPS support. Again, there are no freeware SFTP components available for .NET.

If you use a tool with which you have to use ActiveX controls, you need to search for commercial FTPS or SFTP controls. No free controls are available. SecureBlackbox library provides both FTPS and SFTP support for .NET, VCL and ActiveX technologies.

In this lesson we are going to focus on the Main Window. It is a convenient place to look at your database and jump to the details of the problem. There are things you should know about this window that will increase the efficiency of your work.

It takes some time to get familiar with the activity in your particular database. In general you should be concerned about how much system resources are in use: I/O load; CPU utilization; redo writing. You should assess the resource cost versus the useful work performed by database: number of users connected, rate of SQL execution, number of commits, SQLNet traffic etc. This is exactly what the Main Window should be used for. The charts in this window provide the last 15-20 minutes of history. This helps visualize the trends in the database load.

If you run a 10g database, make sure that the “CPU Sys+User” statistic is selected in one of the auxiliary charts. If you use older versions, please use third party tools to track CPU utilization.

Let’s look at every statistic in order of importance. Below are general recommendations; you may have your own sequence of checks depending on your database type and needs.

Let’s start with the CPU – it always makes sense to check CPU first. A load <25% indicates a relatively happy system. A load 50% and higher may indicate ongoing problems: you should think about finding and fixing the SQL statements responsible for CPU load, reducing the load, or investing in faster or more CPUs.

If it is not CPU, your system may be slow due to excessive waits. Keep an eye on top waits in the tabular view in the upper part of the window. Just a reminder: if the percentage of wait time exceeds 100% – that indicates more than one session is waiting on this event. If you see a high percentage of waits, click on this view to open the Activity Explorer window to see the history of waits. Wait events is a big subject covered in Lesson 2 where the Activity Explorer is explained. Whole database tuning can be based on exploring waits, but for now let’s return to the Main Window.

Based on the nature of waits there, the system assessment can go in a number of different directions; you can be prompted to focus on physical reads, redo logging, DB buffers, log archiver etc. Over time you will become familiar with all these paths. For now, let’s assume that your waits are moderately low. Next, we will take a look at physical reads. Decisions based on physical reads will depend on the type of database (OLTP, data warehouse, or hybrid) and the throughput of your system. Remember that Oracle has two types of physical reads: multi-block reads (db file scattered) used in full scans and single-block reads (db file sequential) used in index-based access. Therefore, a large number of blocks reads per second may be normal for multi-block reads but may be an indication of a problem for single-block reads due to saturation of the I/O subsystem by a large number of small I/O. If you have I/O problems, they will also show up in the database waits mentioned in the previous paragraph.

If you have parallel queries running in your system, you will see I/O activity in the “Direct Physical Reads” chart. You should also see busy PQ servers in the “PQ Servers” chart. These charts are helpful in monitoring data warehouse activity. Data warehouse environment will also typically see writes and reads into / from temporary tablespace(s) during large sorts and hash joins. The amount of temporary tablespace used for this activity can be seen in “Temporary Tablespaces info” on the right.

Let’s imagine you are concerned about high I/O load and want more details. Click on the Physical Reads graph to open a larger graph window with more details. You can make the graphical chart bigger by resizing the window and you can change time resolution to see larger period of time or scroll to the past. A quick tip: in order to scroll the graph horizontally, hold the right mouse button on the graphical area and move left or right. If you move up or down, the vertical scale will change.

While having the statistic detailed graph open, let’s assume that load has been uneven: there were periods of abnormally higher load. You may need even more details about that period of time. First, select the period of time around the spike by highlighting with the mouse. Then, right click to open a pop-up menu. The first two items “Show in Activity Explorer” and “Show in SQL Explorer” call two very powerful tools to explore database activity in high detail. Select the first choice to open the Activity Explorer. Please note that the same time interval is already selected. All data in the Activity Explorer is summarized for the time period of interest. The SQL Explorer can be called in a similar manner and will also retain the selected time interval.

The previous paragraph demonstrated a very powerful way of troubleshooting a database by using Lab128. Troubleshooting can be narrowed from the general “big” picture of the database activity in the Main Window, down to the detailed statistics view, focusing on specific time intervals and calling the Activity or SQL explorers.

This, of course, applies to any statistics graph in the Main Window, not only physical reads. The same principle also applies to the graphs in other windows, not just the Main Window. For now, let’s continue our tour of the Main Window. If you are in some other window, press the “Home” button in the toolbar, or press the “Back” arrow until you get back to the Main Window.

Let’s take a look at the left part of the Main Window. It shows the network activity and the number of user sessions connected to the database. These statistics are self-explanatory. Typically, you should be concerned about the number of active sessions. A high number of active sessions usually indicate a problem. Note that “Users” and “Active” are underlined, which means they are links to other windows. Click on either link to open the Sessions window. This window can also be opened by using the button in the tool bar, or by using the main menu. This demonstrates the behavior of links in Lab128. The links have same appearance and behave the same way throughout the application.

Now return to the Main Window. There are more links in this window. Many of them are in the central section: “Buffer Explorer”, “All Ratios”, “Library Cache Ratios”, “Redo log wait charts”. If you followed this lesson, you already know that the Activity Explorer can be called by clicking on the Wait Event tabular view. Other tabular views, located in the right part of the window, also serve as links to the corresponding windows: “Tablespaces & Datafiles”, “Transaction and RBS”, “Temp segment”.

The transactional activity is represented in the Main Window by the “Redo Entries”, “Redo Write”, “Rollback Writes”, “Log Sync Wait” graphs. The redo log writer and archiver activity is monitored by the “Redo Log Written”, number of “ARC” processes, “Switch Rate”, and “Not Archived” graphs in the bottom part of the window. To see the description of the monitored statistics, right-click on the graph and select “About Statistics”. This is an excellent way to refresh your memory about the most important Oracle performance statistics.

In conclusion, the Main Window provides the opportunity to explore activity history by scrolling back in time using the scroll bar at the bottom of the window. When scrolling, a time window appears showing the time. Casual scrolling back in time can be a bit more difficult than opening a detailed graphical chart window for individual statistics and scrolling back in time there. The detailed chart window is very easy to scroll. But if you already know a particular time to investigate, it is highly recommended to scroll the Main Window to that point to get a comprehensive view of the database state.

Lesson Summary. The Main window is a convenient place to start exploring the database. It has many links to call other windows in the application. Statistic graphs can be “magnified” by clicking and opening a detailed graphical chart. This very powerful technique has been described as drilling down the general “big” picture to detailed statistics views, then selecting a time interval and calling Activity or SQL Explorers.

Lesson 2. Active Session History (ASH). Wait Event-Based Tuning with Activity Explorer.

The purpose of an Oracle server is to serve queries. While serving a query, the server process can be either running on the CPU or waiting. The goal of database tuning is to reduce query execution time, translating into reduced time spent both on CPU and in waits.

Historically, Oracle wait event-tuning was based on the v$system_event view. This approach has been limited to instance-level tuning and lacked CPU data. In recent years, another technique proved to be more effective, based on active session data snapshots (v$session, status=’ACTIVE’). The active session data is then aggregated to expose components of the database time at various levels, most commonly at the individual SQL statement level.

Active session history (ASH) collection has been built into Oracle 10g. This data can be accessed through v$active_session_history but using that data requires purchasing the license. Lab128 has an independent ASH collection engine that collects more statistics and stores more history. The ASH collection is integrated into Lab128 and doesn’t require other licenses. Optionally, Lab128 can use the v$active_session_history view (if the user owns the corresponding license) to populate ASH data that can be later analyzed using sophisticated analytical facilities built into the application.

Let’s take a tour of the Activity Explorer, which supports database tuning using both approaches mentioned above. Although somewhat redundant, we decided to include the older technique using v$system_event. This provides an opportunity to reconcile and validate ASH data and to catch even the smallest waits which may not be detected by the ASH method. You should be familiar with these two sources of wait data when using the Activity Explorer.

There are many ways to open the Activity Explorer. For now, let’s open it by using main menu: View | Activity Explorer, or pressing the appropriate button in the tool bar, or simply pressing F5. There are three parts in this window: upper – the graphical charts, middle – the tabular view of system wait values, and lower – Active Session History (ASH).

In the upper part, select the time interval around interesting activity by highlighting with the mouse. The other two sections will show data for the selected time interval. Note that the first chart shows data obtained from v$system_event and the second chart shows data obtained from ASH. These two charts should be similar with the exception that the ASH chart will also have a CPU component (shown in green). The CPU component can be turned off with the check box at the top of this window, but because the CPU time is very valuable information, you should keep it on in most cases.

The tabular view in the middle section presents “delta” values from v$system_event for the selected time. As a reminder, this data for wait events is at an instance level. This data is complementary because it can be indirectly inferred from the ASH data. Therefore, the v$system_event section has lower priority and you can resize it to a smaller size and give more space to the lower ASH section.

The ASH section has several tabs. The Summary view is displayed by default when the Activity Explorer window opens. In this view, the stacked colored bars show wait components for each SQL statement. This helps quickly assess which SQL statements are causing which problems. Select an individual SQL statement to see its details. Now, switch to the History view. Each row in this view has active session data for a particular moment in time. By default, data in this view is sorted by Statement ID and time of the snapshot. Therefore, the rows are grouped by SQL statement to show multiple snapshots of a single SQL statement. Please note that selection is placed on the first row of the SQL statement group highlighted in the Summary view. The history view shows every single detail about active sessions and the number of rows depends on the length of the selected time period so the amount of data can be huge. Typically, you shouldn’t need to go to this view unless you are examining the finest details of session activity, e.g. you need to see which table or index the session was reading (there is a better way to do that in the Tree view, discussed later) or find a blocking session for the blocked session etc. If you must work in this view, please note that the timestamp column is a link to the Active Session History window, where you can see the entire snapshot with all sessions that have been active at that moment. If you wish to track an individual session, select the row, then right click and select “Selected Session History”.

The Tree view in the ASH section deserves special attention. This tree-style view shows the sum of elapsed time (sum of all response times) broken down by groups defined by you, the user. For example, if you select a SQL statement in the first box, you will get data similar to the Summary view you have seen earlier. This is because the Summary view represents just one (although very important) way of grouping by SQL statement. Let’s select “Event” in the second box, and “Object” in the third. The tree view will update. Now traverse the tree by expanding nodes. If there were read events, you should see which objects have been accessed and see the percentage of time spent for each of them. This is much easier than digging through the details history as we tried minutes earlier.

The Tree view shows the response time aggregated by dimensions, and Lab128 helps you analyze the components of response time. This is called dimensional analysis. There are many dimensions which can be selected at each level. However, which dimensions should be selected? This depends on the type of problem. Generally, you should first select dimensions which you can influence directly or indirectly. For example, SQL statement can be tuned or changed, so it is common to break down the response time by SQL statement. If, for example, you have a hot segment (table, or index, or partition etc) which you can repartition or move to another tablespace, you should select “Object”, then “Event” (or “Event” then “Object”). You need to select “Event” because you want to make sure you are looking at the object which was causing a “db file sequential read” event, for example, and not by “enq: TX row lock contention”. As another example, if you distribute I/O load to other tablespaces / datafiles, you may choose the “Event” and “File” dimensions. Another guideline is to use the leading dimension as a filter. For example, if you are concerned about locking issues in your database, you may select first “Event” as a filter, and then select “SQL” in the second box. Expanding the Event dimension, you can find “enq: TX row lock contention” and then see which SQL statements were causing this wait.

As a reminder, all data shown in the Activity Explorer pertains to the selected period of time. You may want to explore the same period of time in other windows. Lab128 can switch to another window and automatically make the same time selection. For example, if you decide to examine the same period of time in the SQL Explorer, an option in the right-click menu of any graphical chart will call the appropriate tool. This is a powerful feature, which can make monitoring and tuning much easier. Another useful feature is the ability to add more statistics from other windows into any graphical section. Similarly, multiple graphs can be merged into a separate window. See Lesson 4, which provides more information on graphical charts.

Lesson Summary. The Activity Explorer provides extensive information on wait events by using its own implementation of ASH collection and by using the system-wide view v$system_event; you should be familiar with these two sources of data. All data presented in this window pertains to the selected time period, so it is critical to make the selection around interesting activity in the graphical chart section. Alternatively, the Activity Explorer can be called from other windows while preserving the time selection. The middle section presents instance-wide waits; it is included for completeness but you should focus on the ASH section first because it generally contains more pertinent information. The goal of tuning activity is to reduce database response time (elapsed time), which has two components: time spent on CPU and wait time. The Summary view presents top SQL statements with the highest elapsed time and shows the components of elapsed time: waits and CPU time. The History view provides finer details, but the amount of information is usually too large to handle. If you ever need to explore details, you should select a SQL statement in Summary and then switch to History. From the History view, the Session History window and individual Session History window can be opened for a particular snapshot or session ID. The Tree view can be used for advanced analysis of response time, allowing for user-defined dimensions. The selection of dimensions should be driven by user-influenced attributes. Alternatively, selected dimensions can act as filters for the analysis of response time.

Lesson 3. SQL Explorer and SQL Statistics-Based Tuning.

You should already be familiar with the v$sql view. This view provides cumulative statistics for SQL statements. Traditionally, this view has been used for finding top SQL statements in different categories: reads, gets (logical reads), elapsed time (response time), CPU time etc. This tuning method is widely used and has been very valuable (the SQL Area window in Lab128 covers this type of tuning). The obvious drawback of this method is that it doesn’t show when the load happened. This shortcoming can be partially worked around by taking snapshots of v$sql before and after suspected activity or even flushing the shared pool to reset counters in v$sql view. These tricks are not eloquent; they are tedious and lack time precision.

Lab128 uses the same method to take snapshots of v$sql; although this method has been taken to an extreme: the snapshots are collected every 15-30 seconds. This generates enormous amounts of data, so Lab128 stores it in compressed form. The result of this technique is astonishing! Now, any time period in the past can be analyzed, the top SQL statements can be identified, and statistical charts of individual statements can be drawn and compared to other key performance data.

How does this technique compare to ASH (Active Session History) analysis? Both v$sql snapshots and ASH methods primarily target expensive SQL statements. In this area, these two methods are similar in ability. You can use either method and the results should be close. In our experience, v$sql snapshots provide more complete and accurate data when it comes to pure SQL statistics (version 10g Release 2 and later). On the other hand, ASH methods have wider scope, since they provide additional data, such as nature of waits, database objects involved etc. Therefore, these two techniques complement each other. In fact, the SQL Explorer window blends data from both techniques in one place, making it a very powerful tool.

Let’s take a tour of the SQL Explorer. There are many ways to open SQL Explorer window. For now, let’s open it using main menu: View | SQL Explorer, or by selecting the SQL Explorer icon in the tool bar. There are three sections in this window: upper – the graphical charts; middle – the tabular view of system wait values, and lower – Active Session History (ASH).

The upper section shows graphical charts of selected SQL statistics summarized for all SQL statements. These charts provide the “big” picture of activity in the database. Use the check boxes on the right to select the statistics you wish to use. Typically, “Elapsed Time”, “CPU Time”, “Disk Reads”, and “Buffer Gets” are used most often. For frequent and short queries, “Executions” may also be useful. If you suspect a locking issue, check “Application Wait Time”; for index contention and other concurrency issues, check “Concurrency Wait Time”. Don’t select too many charts at the same time; select enough to provide the information you need while keeping the display uncluttered. In most cases, the single chart “Elapsed Time” (relating to response time) is sufficient.

In the upper section, highlight the time interval around interesting activity by highlighting with the mouse. Time selection is important because the other two sections show data for the selected time interval.

The tabular view in the middle section presents delta values for the selected time interval. This data is shown for individual SQL statements. Click on the column headers to sort rows in descending order. As with charts, you will be most interested in the “Elapsed Time”, “CPU Time”, “Disk Reads”, and “Buffer Gets” statistics. Click on those to see the top SQL statements in each category. If you are interested in a particular statement, select it. If you want to plot this individual statement in the Charts section, right-click and select “Show Graph for selected SQL”. Select OK in the “Select SQL Statistics” window and the chart will be added to the Charts section. This chart shows the dynamics of statement execution and identifies exact moments when the statement used peak system resources.

Select another row in the tabular view and add this SQL statement to the charts section. What if you want to locate the row corresponding to the first statement’s graph? It has cryptic IDs, so it is difficult to find the row again. Try this: right click on the graph in question and select “Locate SQL for this Graph”. The corresponding row will be selected again. The tabular view is searchable too. Ctrl-F will call a “Find” dialog box. All columns and rows in the view are searchable and you can search forwards or backwards.

Sometimes, the Charts section will get crowded and you will want to remove charts. It can be done through the right-click menu, or by using the “Remove Extra Charts” link at the end of the statistics list on the right of the Charts section (you may need to scroll down a bit).

Let’s assume you are interested in only one SQL statement and want to closely examine it by changing the time selection and viewing the statement’s statistics. Use the “Selected Row only” check box. Only one row will be shown in the tabular view. You can then change time selection and see how the numbers change for the selected row. “Selected Row only” makes it much simpler to follow a particular SQL statement. You can always uncheck this option to have all rows back.

The lower section of the SQL Explorer window contains the already familiar ASH section. As you select a particular statement, the ASH section updates to show data for that statement. As mentioned above, ASH complements SQL statistics by providing additional data. The ASH section behaves exactly the same as in the Activity Explorer, described in Lesson 2.

In the lower right corner, you can find SQL text. The SQL_ID and Plan Hash Value fields on top of the SQL text box are links to the SQL Statement Details window. Click on a link to open this window. The SQL Statement Details window gets data from the same source as the SQL Explorer. It has all the available information about a particular SQL Statement. This window behaves similarly to the SQL Explorer. Once you get familiar with the SQL Explorer, the SQL Statement Details window should become familiar too. You can close this window to return to the SQL Explorer. The link can be used to quickly check the individual SQL charts. The SQL Statement Details window has its own merits, but this is a topic for another lesson.

Just to remind you, all data shown in SQL Explorer pertains to the selected period of time. If you want to explore the same time period in other windows, Lab128 can switch to other windows and keep the same time selection.

For example, you may decide to examine the same period of time in the Activity Explorer. As soon a time period is selected in any graphical chart, there is an option in the right-click menu to call the Activity Explorer. Another useful feature is the ability to add more statistics from outside windows into a graphical section. The reverse action is also available; any or all graphs can be merged into other windows. See Lesson 4, which provides more information on graphical charts.

Lesson summary. Lab128 uses frequent snapshots of v$sql (or v$sqlstats in 10gR2 and later) to power the SQL Explorer. All important SQL statistics for individual statements can be explored and plotted in the charts. All data presented in this window pertains to the selected time period, so it is critical to make the selection around interesting activity in the graphical chart section. Alternatively, the SQL Explorer can be called from other windows while preserving the time selection from the calling window. The middle section presents data for individual statements. Click on column headers to sort rows and find top SQL statements in each statistic category. The most important statistics have been suggested in this lesson. Individual statement charts can be viewed by selecting the statement and using the right-click menu. Alternatively, a link is available to open the SQL Statement detail window, which provides charts and other information on the selected statement. Finally, the SQL Explorer blends SQL data with ASH data, presented in the lower section

Lesson 4. All about graphical charts.

Please make sure you are using Lab128 version 1.5.9.2 (April 2008) or later before taking this lesson.

This lesson will help you customize and create your own charts. The charts in Lab128 behave the same way in all windows. Once you have learned how to use them, this knowledge becomes applicable throughout the entire application.

Let’s open a chart window from the Main window. For example, click on the “Logical Reads” mini-graph in the upper part of the window. A Chart window will open. There will only be one chart in this window. Now let’s go back to the Main window and click on “Phys Reads”. Another window will open. What if you want to combine two charts together? Right click on a chart and select “Merge Graph to Other Page”. You will see a list of available chart pages. For now, you should see ‘Charts – UnNamed01′ in the list. Select it and press OK. You will be switched to the first Chart window and the new statistic will be added. You can also add a statistic from the Main window directly to an already open Chart window. For example, switch back to the Main window, right click on “Phys Writes” or any other mini-graph, and select “Merge to Another Chart”. Then select the Chart window and press OK.

The point of this exercise is to show how graphical charts can be exchanged between windows. The Chart windows have been specifically designed for charts added by the user; it can contain a large number of charts. Many other windows in Lab128, such as the Activity Explorer, SQL Explorer, Session History and others have a chart area which can accept additional charts. For example, open the Activity Explorer window. You can merge charts from the Activity Explorer to the already opened UnNamed01. Right click on the “Active Sessions” chart and select “Merge to Another Chart”, then merge to UnNamed01. This example demonstrates the consistency of chart exchange. As mentioned earlier, this principle applies to other windows.

What if you want to change the order of statistics in a Chart window? Click on any non-graphical area of the desired chart (e.g. the title area) and drag it to its new location. Drag and drop only works inside one window. These windows can contain up to 60 charts per window. In order to save a user-defined chart, select “Select Page” in the right-click menu and give it a name. All saved chart pages can be opened by using the toolbar: View | User Charts | .

A few words about scrolling charts. Most likely, you will need to scroll charts in time. This can be done by using a scroll bar, but it can often be done much easier with the mouse. Right-click at some point on the graph and move the mouse left or right while holding the mouse button. The graphs will scroll following your movements. If you move the mouse vertically instead of horizontally, the vertical scale of the graph will change.

Other useful hints. To find the value at some point, click on the point. A vertical dashed line will indicate the selected point. Its value will be shown in the upper right corner. To find the average value over a period of time, you need to select the time interval. The boxes in the bottom left and right indicate the selected time interval. The average value is shown in the upper right corner of the graph. You can export statistics data for a selected time interval into an .csv file or onto the clipboard. Click “Clear Selection” to clear the time selection.

The time scale can be “zoomed in” and “zoomed out”. Sometimes, zooming out works better than time-scrolling, providing a picture over a bigger period of time. You can then make a selection around interesting activity and “zoom into selection” by selecting the corresponding item in the right-click menu.

Lesson summary. Clicking on a statistic mini-graph in the Main menu opens a larger and more detailed Chart window. The Chart window can have multiple statistics added by the user. Chart windows can be named and saved to be used later. The statistics can be exchanged between all Lab128 windows containing charts. The order of statistics in the Chart window can be changed by dragging and dropping. All the different manipulations on charts can be performed by using the right-click menu. Time interval selection can be used to find average values and to export data. “Zooming out” can be used as an alternative to scrolling charts.

Lesson 5. Saving performance data and working with saved data.

Don’t overlook this feature. You can configure Lab128 to collect and store data automatically. You can save months of the most detailed performance data with continuous coverage and without the need of large disk storage. Thanks to compression, even very busy Oracle instances need no more than 4GB of disk space per month with all Lab128 features enabled. No other tools, including Oracle AWR, can provide this level of variety and time resolution. Does anyone need that level of performance data detail? Truthfully, you never know what kind of performance troubleshooting will be required. It can be a week until that someone will need to compare the load and resource usage, or will need to troubleshoot a query and will be tracking down changes over past days, weeks, or months. And often, you will need to troubleshoot events that happened hours or days ago. Lab128 addresses all these needs by saving performance data onto disk.

We are going to explain the best practices and strategies for saving performance data. It is assumed that you are using Lab128 on an NT-compatible computer running 24/7.

First, we should explain what data is stored in the .lab files. Lab128 keeps collected data in a ring buffer in memory. When the ring buffer becomes full, it continues collecting data while overwriting the oldest previously stored data. When you set the desired history length, the size of the ring buffer changes dynamically. The goal of automatic sizing is to allocate a buffer large enough to accommodate the specified history length. When performance data is saved onto disk, the contents of the ring buffer are dumped. The performance file also contains certain lookup tables, such as the names of statistics, names and IDs of database objects, names and IDs of database users, text of SQL statements, etc. Lab128 keeps all the ring buffer information compressed. When dumped onto disk, this data remains compressed. When opening the performance file, the reverse process takes place: the buffer in memory is populated from the file. The lookup tables are also restored. The data can be then viewed and explored as though it was in real-time. Obviously, the length of history stored in the performance file correlates to the size of the ring buffer. Therefore, setting the desired history length also affects the amount of history stored in the single performance file.

You can always save current data manually. In the Settings, you can specify a default directory where performance files should be saved. We suggest a dedicated directory per instance. When saving manually, you have the option to choose a folder other than the default one. When continuous coverage is required, you will need to make the next save before data is overwritten in the ring buffer. Therefore, the next file should slightly overlap with the previous one. It makes sense to run these saves automatically. This option can be toggled in Settings -> Saving Performance Data tab -> Autosave. The “Use suggested interval” check box sets the saving interval to one hour less than the History Length. We recommend you check this box and set Data History Length (Main Settings tab) to 9 hours (data will be saved every 8 hours) or 13 hours (data will be saved every 12 hours). This will simplify locating files when you need to view them later.

Opening and browsing stored files is straightforward. Most of the advice given for real time mode in previous lessons applies to exploring stored data. By default, the name of the file should include the name of the instance and date / time of the last data point it contains. This helps to locate the required file. As in real time mode, a typical sequence of troubleshooting actions includes Main window -> Individual Statistic charts -> Activity Explorer or SQL Explorer. Please see “Lesson 1. General Assessment of the State of Oracle Instance” for details.

Viewing and exploring performance data loaded from the file doesn’t require an Oracle connection. The file can be moved and opened off-site; all it needs is another instance of Lab128. This creates an opportunity for practicing Oracle performance specialists and consultants to conduct performance analysis remotely without having access to the database.

Lesson summary. Lab128 can save current performance data onto disk. The file stores data in a proprietary compressed format. The “Data History Length” setting defines the history length stored in a single file. Use the Autosave option to automatically save data. For best results, set Data History Length to 9 or 13 hours.

In IIS 6.0 worker process isolation mode, application pools enhance Web site or application reliability by isolating applications and the worker processes that service those applications. For even greater reliability, you can configure an application pool to be supported by multiple worker processes. An application pool that uses more than one worker process is called a Web garden. The worker processes in a Web garden share the requests that arrive for that particular application pool. If a worker process fails, another worker process can continue to process requests.

Note

Web gardens are different from Web farms. A Web garden is configured on a single server by specifying multiple worker processes for an application pool. Web farms use multiple servers for a Web site.

Creating a Web garden for an application pool can also enhance performance in the following situations:
•

Robust processing of requests: When a worker process in an application pool is tied up (for example, when a script engine stops responding), other worker processes can accept and process requests for the application pool.
•

Reduced contention for resources: When a Web garden reaches a steady state, each new TCP/IP connection is assigned, according to a round-robin scheme, to a worker process in the Web garden. This helps smooth out workloads and reduce contention for resources that are bound to a worker process.
Procedures

Important You must be a member of the Administrators group on the local computer to perform the following procedure or procedures. As a security best practice, log on to your computer by using an account that is not in the Administrators group, and then use the runas command to run IIS Manager as an administrator. At a command prompt, type runas /user:Administrative_AccountName “mmc %systemroot%\system32\inetsrv\iis.msc”.
To configure a Web garden by using IIS Manager

1.

In IIS Manager, expand the local computer, expand Application Pools, right-click the application pool, and then click Properties.

2.

Click the Performance tab, and under Web garden, in the Maximum number of worker processes box, type the number of worker processes that you want to assign to the application pool. (You must type a number greater than 1 for the application pool to become a Web garden.

3.

Click OK.

Optionally, you can configure a Web garden by setting the metabase property MaxProcesses. The MaxProcesses property determines the maximum number of worker processes that an application pool allows to service its requests. A value of zero indicates an unmanaged application pool that is not served by a worker process.

The default value for the MaxProcesses property is 1, which is the default number of worker processes that service an application pool. To configure an application pool so that it is a Web garden, set the MaxProcesses property to a value greater than 1.

Important You must be a member of the Administrators group on the local computer to run scripts and executables. As a security best practice, log on to your computer by using an account that is not in the Administrators group, and then use the runas command to run your script or executable as an administrator. At a command prompt, type runas /profile /user:MyComputer\Administrator cmd to open a command window with administrator rights and then type cscript.exeScriptName (include the script’s full path and any known parameters).
To configure a Web garden by using Adsutil.vbs

1.

In the Run dialog box, type cmd, and then click OK.

2.

At the command prompt, type:

cscript %SystemDrive%\Inetpub\AdminScripts\adsutil.vbs set W3SVC/AppPools/ApplicationPoolName/MaxProcesses n

Replace n with the number of worker processes that you want to service the application pool.

For more information about configuring Web gardens, see MaxProcesses Metabase Property.

Oracle Backup and Recovery can be complicated (especially the recovery) and the consequences of getting it wrong can be very expensive in time and money and sleepless nights. Avoiding this requires knowledge – what are the possible strategies? typical scenarios? the pros and cons of each method of backup and recovery?

We’ll take a look at these so you have the information you need to make Oracle Backup and Recovery stress free in your organisation. However there will still be one thing missing – the proof.

Whichever method(s) you chose, you need to test the whole process – the backup and the recovery – and the various scenarios – from the best to the worst – then you can sleep easy at night!

What To Consider

One of the most important tasks is to find out how much data the business can afford to lose. For a production database, the users will probably say none, in which case you have to dig deeper and find out the source of the data, the amount of changes per day, how much it would cost the business if they lost any data and how much the business is prepared to pay to ensure zero data loss (deep pockets will be required).

But let’s not get ahead of ourselves, before we can discuss Oracle backup and recovery options with business users we need to know what options are available and the pros and cons of each option.

Oracle Backup and Recovery Options

• Oracle utilities export (for backup) and import (for recovery) orOracle Datapump in 10g and above. 
  Advantages: fairly easy to use for basic situations. Can be used to backup only those objects (tables/triggers/views etc.) which have changed. Can be used to backup and recover individual objects, schemas, tablespaces or the whole database whilst the database is being used (although this may mean the backup contains inconsistent data if updates are taking place).
  Disadvantages: both backup and recovery could be slow – especially for large databases, as objects are copied one at a time. No good for recovering from physical corruption or physical data loss.
• Offline (cold) backup: This is performed when the database is shutdown (cold) and therefore unavailable for use. Operating system commands are used to copy the database files to an archive location on disk or possibly straight to tape. Recovery is the reverse – copy all the database files from the backup area to their original location (with the database shutdown), open the database and reset the logs.
  Advantages: simple to understand, simple to perform.
  Disadvantages: In the event of a failure you would lose all changes since the last backup. This is also potentially a slow process – you have to copy all the data files and other files comprising the database (except for the redo logs) every time and recovery would take at least as long as the backup.
• Online (hot) backup: To use this option the database must be running in archive log mode. Tablespaces are backed up one at a time. Recovery involves restoring the required files from backup and then rolling forward (redoing changes since the backup) using the redo logs. For more details about this option see here .
  Advantages: No data is lost. Database can be open for read/write during both backup and recovery. Good for recovering from physical data file loss/corruption.
  Disadvantages: More complex than cold backup and database performance may be affected during backup and recovery. It may take some time to recover the data as all changes since the last backup have to be replayed. Not useful for recovering an individual or small number of objects (table/view/etc.) or from a logical data loss/corruption. Extra disk space is required to hold all the redo logs.
• Standby database/Oracle Dataguard. This is strictly speaking more a high-availability option than an Oracle backup and recovery option, but is an option worth considering. This option uses one or more extra databases to act as a standby in case of a failure of the main database.
  Advantages: Can protect against a wide range of failure scenarios. Standby databases can also be used for reporting whilst remaining in sync with the primary database.
  Diadvantages: Much more complex and more expensive than other methods.
• Oracle flashback database (available in 10g onwards). This builds on the flashback query option available in Oracle 9i and enables you to revert the whole database or just an individual table to its state at a given scn or point in time (assuming the flashback logs are still available).
  Advantages: Easy to configure. Good for recovery of small number of tables from logical data loss or corruption.
  Disadvantages: Extra i/o load may impact performance. Extra disk space is required for flashback logs. No good for recovering from physical data loss.
• RMAN (Oracle Recovery Manager). This is a tool designed for the management of Oracle backup and recovery and can be used with the options already discussed except for export/import/datapump and Flashback database.
  Advantages: Manages backup/recovery options for you and keeps track of required backups and created backup files and backup sets. Can be used for incremental backups. Backup and recovery may be faster due to its ability to read/write files in parallel.
  Disadvantages: Another utility to master. Adds a layer of complexity to Oracle backup and recovery operations.

How To Translate This Into Business Terms

We’ve looked at the options for Oracle backup and recovery and seen that they all have disadvantages so it’s really up to you as the dba to pick the best option depending on business requirements and constraints (money/resources) and the consequences (costs) of not meeting the requirements.

Another thing to consider is that the best option may not be to bother backing up the database at all! You might consider this the best option for a development database and devolve responsibility to the developers to keep copies of their source code and test data.

This might also be the best option for a datawarehouse if it would take longer to recover the data from backup then it would to reload the data from the source system and re-process it.

On the other hand for an ecommerce database with 24×7 operation, you will need to use hot backups as a minimum and you would probably use Oracle RAC and Oracle Dataguard as well.

One very important point to remember is that whichever option you pick, as mentioned earlier, make sure you test everything – test the whole process from end to end, the backup and the recovery. Ensure your backups have actually been created and are readable and that you have everything you need should a failure occur.

This may sound obvious but many companies have lost valuable data and spent thousands of dollars and many hundreds of man-hours extra because either the backup failed and nobody noticed or not all of the data was available when recovery was required. So make sure you test frequently and thoroughly, then when the inevitable problems occur you’ll have an excellent chance of averting a disaster.

SQL> set autotrace traceonly explain
SQL> select ename from emp where empno = 12;

Execution Plan
———————————————————-
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 TABLE ACCESS (BY INDEX ROWID) OF ‘EMP’
2 1 INDEX (UNIQUE SCAN) OF ‘PK_EMP’ (UNIQUE)

Statistics
———————————————————-
83 recursive calls
0 db block gets
21 consistent gets
3 physical reads
0 redo size
221 bytes sent via SQL*Net to client
368 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
0 rows processed

For even more detailed SQL execution statistics, see the TKPROF (SQL Trace) utility.

Reading an execution plan
For a full tutorial, get my book “Oracle Tuning: The Definitive Reference” where I’ve devoted over 100 pages to reading execution plans. My goals for SQL tuning with execution plans are simple, “Fetch the rows while minimizing data block touches”:

Eliminate sub-optimal large-table full-table scans: Ensure that the fastest access path to the data is chosen. The execution plan “FULL” is the key.

Use fastest table join method: The optimizer must choose intelligently between nested loop joins, hash joins and star transformation join methods and these are displayed in the execution plan.

Ensure optimal table-joining order: SQL will run fastest when the first table joins deliver the smallest result set.
In sum, I review execution plans looking for tuning opportunities as follows:

Add indexes (especially function-based indexes)
Change the optimizer parms 
Employ Materialized Views
Improve CBO statistics (especially histograms)
Cache high-use small tables & indexes
Tune the library cache (cursor_sharing, etc)
Adjust segment structure (large blocksizes for index range scans, small blocksizes for random OLTP)