sqlplus remote oracle database

C:\>sqlplus dacs2011/dacs2011@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(Host=oracle_database_fqdn)(Port=1521))(CONNECT_DATA=(SID=database_schema_id)))

SQL*Plus: Release 11.2.0.2.0 Production on 金 6月 26 10:19:01 2015
Copyright (c) 1982, 2010, Oracle.  All rights reserved.
Oracle Database 11g Release 11.2.0.4.0 – 64bit Production
に接続されました。

Alter table:
SQL> ALTER TABLE Table_Name

Alter view:
SQL> CREATE OR REPLACE FORCE VIEW

Azureクラウドで構築された仮想マシンに「ping」する方法

本文書はAzure上で仮想マシンを構築した後、RDP以外の方法でアクセスできるかどうかを確認するたびに使う「ping」する方法をご説明しています。内容は次の3つのセッションに含まれています。
・Azureの規則
pingの欠点
pspingについて

Azureの規則

Azureにおいて、ICMPプロトコールはAzure Load Balancerに許可されていないため、Azure VMの外から伝統のpingコマンドで「ping」することができません。かつ、Azure VMから外のインターネットロケーションにもpingできません。

Pingの欠点

windows pingコマンドはICMPプロトコールを使っています。当然ながら、Azure上のVMにpingすることができません。

PsPingについて

PsPingはping機能、TCP ping機能、latency and bandwidth評価機能を実現していたコマンドラインベースのツールです。
詳細の情報はここに載せています。
https://technet.microsoft.com/en-us/sysinternals/jj729731.aspx

サンプル

D:\>psping yokohama.cloudapp.net:80
(サンプルだから、アクセス情報は変更済み)

PsPing v2.01 – PsPing – ping, latency, bandwidth measurement utility
Copyright (C) 2012-2014 Mark Russinovich
Sysinternals – http://www.sysinternals.com

TCP connect to 23.102.76.115:80:
5 iterations (warmup 1) connecting test:
Connecting to 23.102.76.115:80 (warmup): 8.82ms
Connecting to 23.102.76.115:80: 10.13ms
Connecting to 23.102.76.115:80: 10.54ms
Connecting to 23.102.76.115:80: 10.85ms
Connecting to 23.102.76.115:80: 12.61ms

TCP connect statistics for 23.102.76.115:80:
  Sent = 4, Received = 4, Lost = 0 (0% loss),
  Minimum = 10.13ms, Maximum = 12.61ms, Average = 11.03ms

Azureクラウド上のVMで、netstat -anコマンドを実行すると、すべての「Local Address」、「Foreign Address」のポートが表示されます。そこの「Foreign Address」からの[IP]:[port]をPsPingすることができます。(環境によるアクセスできる場合もあります)

lookup your tenant domain

C:\Users\YAN>nslookup
既定のサーバー:  UnKnown
Address:  192.168.11.1

> set query=mx
> thisisme.onmicrosoft.com
サーバー:  UnKnown
Address:  192.168.11.1

権限のない回答:
thisisme.onmicrosoft.com        MX preference = 0, mail exchanger = thisisme.mai
l.protection.outlook.com

onmicrosoft.com nameserver = ns2.bdm.microsoftonline.com
onmicrosoft.com nameserver = ns3.bdm.microsoftonline.com
onmicrosoft.com nameserver = ns1.bdm.microsoftonline.com
onmicrosoft.com nameserver = ns4.bdm.microsoftonline.com
ns1.bdm.microsoftonline.com     internet address = 207.46.15.59
ns2.bdm.microsoftonline.com     internet address = 157.56.81.41
ns3.bdm.microsoftonline.com     internet address = 111.221.126.105
ns4.bdm.microsoftonline.com     internet address = 157.55.45.9
>

「動詞+なくて」と「動詞+ないで」の違いは?

「~なくて」「~ないで」は、いずれも動詞の否定形がテ形をとったもので、どちらを用いてもかまわないように思われる場合も少なくありません。

大事に至らないでよかった。
大事に至らなくてよかった。

これは、「~ないで」の表す意味の一部が「~なくて」の表す意味と重なることによるものです。「~ないで」には、次のように大きくわけて三つの用法があるといわれています。

(1)宿題をしないで学校にいった。
(2)宿題をしないでゲームばかりしている。
(3)宿題をしないで怒られた。

(1)~(3)の文では、「~ないで」までが同じ表現となっていますが、「~ないで」より後の内容に対する関係が異なっています。(1)では「宿題をしないで」は、別の行為(「学校に行く」)がどのような状況・事情のもとにおこなわれたかという、他の行為の付帯状況を表しています。

また(2)では、「宿題をする」という行為と「ゲームをする」という行為が対比的に述べられており、「宿題をすべきなのに、代わりにゲームばかりしている」のように言い換えることができます。

最後の(3)は、「~ないで」が原因を表しているもので、「宿題をしなかったために怒られた」のように言い換えることが可能です。

(1)~(3)のうち、(3)の場合には「~ないで」の代わりに「~なくて」が用いられますが、(1)(2)の場合には難しいようです。

×宿題をしなくて学校に行った。
×宿題をしなくてゲームばかりしている。

ご質問の文では、「雨が降らないために晴れた日が続いた」のように「雨が降らない」の部分を「晴れた日が続いた」ことに対する原因と解釈するよりは、「雨が降らない」と「晴れた日が続いた」が対比的に表現されていると考えるのが妥当であり、「~なくて」ではなく「~ないで」が選ばれることになります。

Imeplement C# Singleton Class

Context

You are building an application in C#. You need a class that has only one instance, and you need to provide a global point of access to the instance. You want to be sure that your solution is efficient and that it takes advantage of the Microsoft .NET common language runtime features. You may also want to make sure that your solution is thread safe.

Implementation Strategy

Even though Singleton is a comparatively simple pattern, there are various tradeoffs and options, depending upon the implementation. The following is a series of implementation strategies with a discussion of their strengths and weaknesses.

Singleton

The following implementation of the Singleton design pattern follows the solution presented in Design Patterns: Elements of Reusable Object-Oriented Software [Gamma95] but modifies it to take advantage of language features available in C#, such as properties:

 

using System;

public class Singleton
{
   private static Singleton instance;

   private Singleton() {}

   public static Singleton Instance
   {
      get 
      {
         if (instance == null)
         {
            instance = new Singleton();
         }
         return instance;
      }
   }
}
 

This implementation has two main advantages:

  • Because the instance is created inside the Instance property method, the class can exercise additional functionality (for example, instantiating a subclass), even though it may introduce unwelcome dependencies.

  • The instantiation is not performed until an object asks for an instance; this approach is referred to as lazy instantiation. Lazy instantiation avoids instantiating unnecessary singletons when the application starts.

    The main disadvantage of this implementation, however, is that it is not safe for multithreaded environments. If separate threads of execution enter the Instance property method at the same time, more that one instance of the Singleton object may be created. Each thread could execute the following statement and decide that a new instance has to be created:

    if (instance == null)

    Various approaches solve this problem. One approach is to use an idiom referred to as Double-Check Locking [Lea99]. However, C# in combination with the common language runtime provides a static initialization approach, which circumvents these issues without requiring the developer to explicitly code for thread safety.

    Static Initialization

    One of the reasons Design Patterns [Gamma95] avoided static initialization is because the C++ specification left some ambiguity around the initialization order of static variables. Fortunately, the .NET Framework resolves this ambiguity through its handling of variable initialization:

     
    
    public sealed class Singleton
    {
       private static readonly Singleton instance = new Singleton();
       
       private Singleton(){}
    
       public static Singleton Instance
       {
          get 
          {
             return instance; 
          }
       }
    }
     

    In this strategy, the instance is created the first time any member of the class is referenced. The common language runtime takes care of the variable initialization. The class is marked sealed to prevent derivation, which could add instances. For a discussion of the pros and cons of marking a class sealed, see [Sells03]. In addition, the variable is marked readonly, which means that it can be assigned only during static initialization (which is shown here) or in a class constructor.

    This implementation is similar to the preceding example, except that it relies on the common language runtime to initialize the variable. It still addresses the two basic problems that the Singleton pattern is trying to solve: global access and instantiation control. The public static property provides a global access point to the instance. Also, because the constructor is private, the Singleton class cannot be instantiated outside of the class itself; therefore, the variable refers to the only instance that can exist in the system.

    Because the Singleton instance is referenced by a private static member variable, the instantiation does not occur until the class is first referenced by a call to the Instance property. This solution therefore implements a form of the lazy instantiation property, as in the Design Patterns form of Singleton.

    The only potential downside of this approach is that you have less control over the mechanics of the instantiation. In the Design Patterns form, you were able to use a nondefault constructor or perform other tasks before the instantiation. Because the .NET Framework performs the initialization in this solution, you do not have these options. In most cases, static initialization is the preferred approach for implementing a Singleton in .NET.

    Multithreaded Singleton

    Static initialization is suitable for most situations. When your application must delay the instantiation, use a non-default constructor or perform other tasks before the instantiation, and work in a multithreaded environment, you need a different solution. Cases do exist, however, in which you cannot rely on the common language runtime to ensure thread safety, as in the Static Initialization example. In such cases, you must use specific language capabilities to ensure that only one instance of the object is created in the presence of multiple threads. One of the more common solutions is to use the Double-Check Locking [Lea99] idiom to keep separate threads from creating new instances of the singleton at the same time.

    Note: The common language runtime resolves issues related to using Double-Check Locking that are common in other environments. For more information about these issues, see "The ‘Double-Checked Locking Is Broken’ Declaration," on the University of Maryland, Department of Computer Science Web site, at http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html.

    The following implementation allows only a single thread to enter the critical area, which the lock block identifies, when no instance of Singleton has yet been created:

     
    
    using System;
    
    public sealed class Singleton
    {
       private static volatile Singleton instance;
       private static object syncRoot = new Object();
    
       private Singleton() {}
    
       public static Singleton Instance
       {
          get 
          {
             if (instance == null) 
             {
                lock (syncRoot) 
                {
                   if (instance == null) 
                      instance = new Singleton();
                }
             }
    
             return instance;
          }
       }
    }
     

    This approach ensures that only one instance is created and only when the instance is needed. Also, the variable is declared to be volatile to ensure that assignment to the instance variable completes before the instance variable can be accessed. Lastly, this approach uses a syncRoot instance to lock on, rather than locking on the type itself, to avoid deadlocks.

    This double-check locking approach solves the thread concurrency problems while avoiding an exclusive lock in every call to the Instance property method. It also allows you to delay instantiation until the object is first accessed. In practice, an application rarely requires this type of implementation. In most cases, the static initialization approach is sufficient.

    Resulting Context

    Implementing Singleton in C# results in the following benefits and liabilities:

    Benefits
  • The static initialization approach is possible because the .NET Framework explicitly defines how and when static variable initialization occurs.

  • The Double-Check Locking idiom described earlier in "Multithreaded Singleton" is implemented correctly in the common language runtime.

    Liabilities

    If your multithreaded application requires explicit initialization, you have to take precautions to avoid threading issues.