Posts Tagged ‘table’

Switching Logic

June 8, 2012

If you are a junior admin in a small to medium organization then building campus network is simple. Buy several switches, connect desktops and switches together and that’s it. You don’t need any additional configuration, all switches work right out of the box. However, it’s important to understand how packet switching work to troubleshoot problems that can show up later in your work.

Switching works on TCP/IP Layer 2. It means that networking hardware logic operates with MAC addresses. Each time switch receives a packet from any workstation or server it remembers its MAC address and port it was received from. It’s called MAC address or switching table. When somebody wants to send a packet to an other host with particular IP address he sends an ARP request packet. Like tell me who has IP address. Host replies with its MAC address and sender can form a package to it.

Initially switch has empty switching table and does not know where to send packets. When switch doesn’t have particular MAC address in its table it forwards (floods) the packet to all ports. If the next switch doesn’t know this MAC, it further forwards the packet. When packet finally reaches its destination, host answers and switch adds its MAC address into the table.

If you don’t use VLANs, all switches in your network form a broadcast domain. It means that when host sends a broadcast message, ARP request for example, and host with this IP address is powered off then this ARP request will traverse the whole network. It’s important to bear in mind that if you have many hosts in your network, broadcast messages can eventually slow it down. VLANs are usually a solution here.

Structure of DB2 database

December 16, 2011

Now lets talk about databases which is a more interesting topic for developers. If you show up here then you apparently know that databases consist of tables. But there is another slice between them called schema. Schema is just a convenient aggregator of database objects. If your database is bigger than 10 tables then logically separating them into different schemas would probably be beneficial for you.

Next term is view. Using views you can look at your tables from different angle, so to speak. So if you have your table in place and don’t want to change it but it’s more convenient sometimes to use it with different structure from SQL-query then use views.

And a last but not least and probably a most interesting feature is index. Indexes help database to increase performance when searching for data programmer requests. Instead of comparing all fields you indicate in query to find necessary data, database generates indexes for each row in advance, then generate index from query when you run it and compare indexes to find requested data. Basic idea here is to to compare two numbers instead of strings and/or several numbers. It’s just faster.