Reduce Log file

Reduce Log file

Introduction

So there is a recurring question in the newsgroups and forums about the size of the file of transactions from a database of SQL Server. The problem is that the log file grows indefinitely until it is so big that eats the entire hard drive, arriving in the worst cases to fill with the resulting error:

Error: 1105, Severity: 17, State: 2 Could not allocate space for the transaction log for database 'MiBase' because the device is full. Dump the log or enlarge the device to create more space.

This error is not really a problem of SQL Server. Is normal on the server when we take into account in any database is to perform a series of maintenance tasks so that everything works properly. What we are signaling is that the log file can not grow, either because we have limited size, or because we have filled the entire disk, and if the server can not write to the log file can not continue working. But let us see a little how the data storage in SQL Server and that is the file of transactions (or log) to understand how we can resolve this error, and most importantly, how to avoid it.

File type

In any database SQL Server there are at least two files. One file is the database where the data will be stored in our tables (and other objects) and the other is the file of transactions. The transaction file is a series of records of all changes to the database and the transaction that has made each change. In the transaction log contains the start of each transaction. It also records changes to data and provides enough information to undo the modifications (if necessary later) made during each transaction. The file has extension mdf database while the transaction has ldf extension. In this case we will concentrate on the latter which is what can give us problems in terms of space.

Recovery mode

The recovery mode of the database is very important to understand where our problem arises. Depending on how we created the database several ways to recover the database in SQL Server. We have the full mode, the mass registration and simple. If you created the database did not specify any recovery mode chosen is full. To learn how you have configured one can look at the "Corporate Administrator" in the properties of the database in the "Options". Here we can see what the recovery mode of the database. We can also determine the recovery model by running sp_helpdb 'NombreBaseDatos' in Query Analyzer. If we do so in the results pane status where there is a column detailing, among other things, the model of recovery (Recovery = FULL).

Have full recovery mode means you can recover the database until the time when an error occurs or until a certain moment of time. Is the usual way in a production database.

In this recovery mode every transaction that occurs in the database (insert, modify, delete ...) was recorded in the transaction file (the. Log) so that it can reconstruct what happened to the database against time. But using this way means that the transaction file will grow indefinitely, even to be bigger than the database itself.

The solution to this growth is simple: to make backups. When we do a backup of transaction log data to pass to the backup disk is erased, leaving free space. So with every copy of the disc will remove the log file that is no longer necessary, leaving free space for recording new transactions that occur in our database.

The bad thing is that when this happens is released into space from log file, but it does not mean reducing the size of this file to disk. In this case we will have to shrink the log file in a second phase.

Operation of the log file

As they say what each BOL SQL Server transaction log file is divided logically into smaller segments called virtual log files (VLF). The virtual log files are the units of transaction log truncation. When a virtual log file no longer contains records for active transactions may truncated to ensure that there is space available for recording new transactions.

The minimum size of a virtual log file is 256 KB. The minimum size of a transaction log is 512 KB, which provides two virtual log files of 256 KB. The number and size of virtual log files in a file of transactions increases as does the log file. A log file can have a small number of small virtual log files while a log file can be larger virtual log files larger.

As we said when the transaction becomes very large the solution is to make a backup and that part of the file which makes a copy is released. That is, the VLF is emptied and once empty can be truncated to reduce the space occupied by the file on disk. To truncate the log file you can use Enterprise Manager using the "Shrink Database" or do it from Query Analyzer. I prefer Query Analyzer because it gives more of what we are doing and any errors that may appear. Let's see what we have to execute commands to do this from the Query Analyzer with TSQL.

Reduce the log file

Assuming we have a database name MiBase the steps would be:

1 - Open Query Analyzer. Execute the statement USE MiBase For the execution context is the database we want.

2 - Implement the decision CHECKPOINT To write to disk all the pages out of date (they are cached And are not yet on disk)

3 - Run the sentence EXEC sp_addumpdevice 'disk', 'CopiaMiBase', 'd: \ LogMiBase.bak' To create a hardware device to store the backup. This device is a file in d: LogMiBase.bak name. Make sure there is enough room for the backup. We can also create this device from the Corporate Administrator.

4 - Create a backup of the database MiBase BACKUP DATABASE TO CopiaMiBase This created a complete copy of the database

5 - Create a backup log file BACKUP LOG MiBase TO CopiaMiBase We have now created a copy of the log file information with the have released some of the VLF (virtual log file) Now if we look at the log file has been reduced, and if you have not Turn to the next point.

6 - Free space of the log file DBCC SHRINKFILE (MiBase_Log, 3000) This command frees space if there are any VLF gap. The first argument is the logical name of the file you want to reduce the size is 100 Goal Mb Although in this example we use size as 100Mb goal in each case will look what is the desired value and up depending on where you can get of VLF-free after you have the backup of the file Log. Once this is done and we should have a log file size reasonable.

Plan b

If we are interested not have backup of all data from the log file (or there is no space for the backup) we can follow a quicker method but does not back up this file, but that of the base Data: 1 - USE MiBase

2 - CHECKPOINT

3 - EXEC sp_addumpdevice 'disk', 'CopiaMiBase', 'd: \ LogMiBase.bak'

4 - BACKUP DATABASE MiBase TO CopiaMiBase

5 - BACKUP LOG MiBase WITH TRUNCATE_ONLY

6 - DBCC SHRINKFILE (MiBase_Log, 100)

This option simply truncates the log file the missing part of this file is not active.

A final solution

So that does not happen again is to have a maintenance plan for the base damage you make full backups and log file each time. How long is hard to say without knowing how to use the database and what is its size, but could be from several times a day to once a week. Of course it is much easier if we schedule the execution of work as the backup schedule and if you tell us some warning if you exceed the limit that we consider reasonable for the size of our files. Prevention is always better to correct the errors. Endnote I know it is not necessary to say, but if we do any task that can be dangerous is mandatory to backup the database and the database system if there are any unforeseen problems.

Temporary Tables in SQL

Temporary Tables in SQL

Introduction

In the world of databases is very common the use of temporary tables. While everyone knows that these kind of structures are slowing the operation of our consultations, programmers can not avoid using them because they often facilitate the resolution of problems. Store data for later use, save partial results, to analyze large amounts of rows. There are many cases where we may need these temporary tables, but you have to use them properly!.

First advice:Don't use temporary tables

The first advice that we must continue to work with temporary tables is quite simple: do not use them. And why not? Well there are plenty of reasons that we see throughout this text, but begin to see that translated using a temporary table in SQL Server:

• The temporary tables are created in tempdb, and when you create there are several blocks on the database such as tables and sysobjects sysindex. The locks on tempdb affect the entire server.
• When you create need to be made in writing to the disk access (not always if the tables are small)
• When entering data into the temporary tables are again on disk activity, and we know that the disk access is usually the "bottleneck" of our system • When reading data from the temporary table have to resort back to disk. Moreover, these data read from the table often combined with others.
• Clearing the table is to buy new locks on the tempdb database and perform operations on disk.
• Using temporary tables inside a stored procedure we lose the advantage of having compiled the implementation plan for the stored procedure and recompiled to occur more often. The same happens when the SQL Server attempts to reuse the execution plan of a parameterized query. If the query is a temporary table is difficult to reuse implementation plan. Viewed these problems I think that there is no need to repeat our first Council.

¿What can we do?

Instead of temporary tables can improve our code is not necessary, we can use subqueries (subquery usually use a drastically improved performance to use temporary tables), using permanent tables, use tables derived. We must always remember that any alternative is good if you avoid using temporary tables (¡cursors excluded of course!) Anyway if you ever have to use it is better to know well, so let's do this.

Types of temporary tables

Temporary tables are of two types in the scope table. We have local temporary tables and global temporary tables.

• # local: local temporary tables have a # as first character in its name and can only be used in the connection in which the user creates. When the connection drops the temporary table disappears.
• # # The overall global temporary tables begin with # # and are visible by any user connected to SQL Server. And one more thing, these tables disappear when no user is referring to, not the user is disconnected box that I think.
• Temp There really is a kind of temporary tables. If we create a table within the database is a temp table in real terms we can use it like any other table in any database, and is temporary in that it disappears as soon turn off the server.

Operation of temporary tables

Create a temporary table is like creating a normal table.

Let's see an example:

CREATE TABLE # TablaTemporal (Field1 int, Field2 varchar (50))

And are used on a regular basis.

INSERT INTO # TalbaTemporal VALUES (1, 'first field')

INSERT INTO # TalbaTemporal VALUES (2, 'Second field')

SELECT * FROM # TablaTemporal

As we see almost no limitations when working with temporary tables (one limitation is that they can not have restrictions Foreign KEY).

Optimizing the use of temporary tables

The use that we can give this type of tables is infinite, but always bearing in mind a few guidelines that we must continue to slow our work as little as possible. For example it's a good habit to create temporary tables with DDL commands as in the previous example (CREATE TABLE) and then fill them with INSERT statements or INSERT INTO. It is true that we can achieve it in one step with SELECT INTO, but this is worse because the locks that are acquired on system objects that last longer.

As is always better to ask the fields we want and do not put the typical SELECT * FROM ... In the same way is highly recommended that we want to qualify the rows and rows do not have that we will not use temporary tables.

Another good habit is to remove us our tables. Yes it is true that at the end of the connection local temporary tables disappear, but if we have a set of sentences over and create a temporary table at the beginning and we are not going to use the remaining time does not make sense to have that table there taking up space and memory.

If the temporary tables are a great option to increase performance is to create an index that will help us to recover data from that table (for smaller tables is an unnecessary waste because they never used the index).

Place the tempdb database on a single disk dedicated to this function will increase overall system performance if it is an intensive use of temporary tables.

And last but not least, do not think temporary tables within transactions within nor triggers. Believe that the existence of your database if you do suffer a lot.

Variables Table With

SQL Server 2000 we can declare variables of type table. Such variables have a number of advantages over temporary tables so that we can always choose to use table variables versus temporary tables. Use temporary variables are easy:

DECLARE @ VariableTabla TABLE (Field1 int, Field2 char (50))

INSERT INTO @ VariableTabla VALUES (1, 'first field')

INSERT INTO @ VariableTabla VALUES (2, 'Second field')

SELECT * FROM @ VariableTabla

Find advantages in using table variables:

• Have a clearly defined scope. The stored procedure, function or batch in which they are declared.
• The variables of type table has less recompile the stored procedures in those that use temporary tables.
• Table variables do not need locks or as many resources as temporary tables.

But they also have disadvantages:

• We can not change the table definition once declared
• We can not use non-clustered indexes
• You can not use INSERT INTO or SELECT INTO
• We can not use functions in the restrictions

If we balance the pros and cons we see that in general it is better to use variables of type table that the temporary tables. Just in case you have large amounts of data into a temporary table and if we will use repeatedly is the preferred choice of temporary tables because they can define indexes.

An example

This is all very well, but as always it is best to see an example in which we can see that it is worth the effort to reprogram our code to not use temporary tables.

Let's see a simple example from the truth but to illustrate what we explain in this text. We will use the Northwind database.

This database requests are sent through three transportation companies: Speedy Express (1), United Package (2) and Federal Shipping (3). Federal Shipping Company, we offer complete all shipments that do this through the United Package price $ 10.

We decided that this is worth saving and we are going to change in our database, all open orders that have to be sent by United Package to be sent via Federal Shipping.

To make this update of the data we have several options. Let's compare three ways.

Method 1: temporary tables

declare @ st datetime

SET @ st = getdate ()

CREATE TABLE # Actualizar(int OrderId, ShipVia int, Freight money)

INSERT INTO # Actualizar SELECT OrderID, ShipVia, Freight FROM Orders WHERE ShipVia = 2 ShippedDate IS NULL

UPDATE Orders SET ShipVia = 3 Freight = 10 WHERE OrderID IN (SELECT OrderID FROM # Actualizar )

DROP TABLE # Actualizar

PRINT 'Operation completed in:' +

RTRIM (cast (datediff (ms, @ st, getdate ()) as char (10))) + 'Milliseconds'

And as a result we obtain:

(11 rows affected)

(11 rows affected)

Operation completed in 140 milliseconds

Method 1: Variables Table type

DECLARE @ st datetime

SET @ st = getdate ()

DECLARE @Actualizar Table (OrderId int , ShipVia int, Freight money)

INSERT INTO @Actualizar Select OrderID, ShipVia, Freight FROM Orders WHERE ShipVia = 2 ShippedDate IS NULL

UPDATE Orders SET ShipVia = 3 Freight = 10 WHERE OrderID IN (SELECT OrderID FROM @ Actualizar)

PRINT 'Operation completed in' +

rtrim (cast (datediff (ms, @ st, getdate ()) AS char (10))) + 'Milliseconds'

And in this case the result is:

(11 rows affected)

(11 rows affected)

Operation completed in 73 milliseconds

Method 1: No temporary tables

DECLARE @ st datetime

SET @ st = getdate ()

UPDATE Orders SET ShipVia = 3 Freight = 10 WHERE OrderID IN (SELECT OrderID FROM Orders WHERE ShipVia ShippedDate = 2 AND IS NULL)

PRINT 'Operation completed in' + rtrim (cast (datediff (ms, @ st, getdate ()) AS char (10))) + 'Milliseconds'

And finally we get:

(11 rows affected)

Operation completed in 50 milliseconds

Of course this example is not significant, and in each case we must study the situation and compare the results obtained in a working environment to know what is the best option, but anyway I hope this will serve at least for a little better to the "temporary tables".

Modify tables and columns in design mode

Modify tables and columns in design mode

By default, in SQL Server 2008, prevent from saving changes in Design mode.
If you modify some table in design mode, probably appears the message "Saving changes is not permitted"

Desing Mode

Warning Message

For changing this option, go to Tools menu, Options, Designers tree option, and Table and Database Designers option. (You can see in next picture).

I hope that this article is usefull for you.

Returning Ranked Results with Microsoft SQL Server 2005

Returning Ranked Results with Microsoft SQL Server 2005

Numbering Rows with ROW_NUMBER

The ROW_NUMBER function assigns an ordinal value with each record returned, with the ordinal values depending on a particular ORDER BY clause used in tandem with the function. The syntax for ROW_NUMBER is: ROW_NUMBER() OVER([partition] order-by-clause)

For example:

Notice that certain customers are on this list multiple times (Nil, Dani, and Jordi). Perhaps rather than seeing all orders, ordered by sales amount, we are interested in seeing the top orders per customer. We can accomplish this with the PARTITION BY clause in the ROW_NUMBER function like so:

SELECT c.Name, o.DateOrdered, tab.TotalOrderAmount,
ROW_NUMBER() OVER (PARTITION BY c.CustomerID ORDER BY TotalOrderAmount DESC) AS BestCustomer
FROM vwTotalAmountBilledPerOrder AS tab
INNER JOIN Orders AS o ON
o.OrderID = tab.OrderID
INNER JOIN Customers AS c ON
c.CustomerID = o.CustomerID

This will return the following results:

Name DateOrdered TotalOrderAmount BestCustomer
Nil 12/1/2005 12649.9900 1
Nil 12/19/2005 265.8500 2
Jordi 12/22/2005 14.9500 1
Jordi 12/18/2005 12.4400 2
Peter 1/2/2006 620.0000 1
Dani 1/5/2006 14.9500 1
Dani 1/4/2006 9.9900 2
MC 1/3/2006 8.5000 1

¿Quienes son los Black Belt?

¿Quienes son los Black Belt?

Los Black Belt son los ejecutores de los proyectos 6 Sigma, líderes técnicos y promotores del cambio en la organización. Son los encargados de implementar los principios, prácticas y técnicas de 6 Sigma, buscando en todo caso la máxima reducción de los costes.
Utilizan software para el tratamiento estadístico de datos como por ejemplo Minitab y/o Crystal Ball para la simulación de modelos predictivos.

Los cursos de formación para adquirir dichos conocimientos cuestan alrededor de 9.000€ + IVA, y tienen una duración aproximada de 4 semanas.

JCI, Junior Chamber International

JCI, Junior Chamber International

La JCI es una organización sin ánimo de lucro pensada para los jóvenes líderes y empresarios.
Se podría decir que es como un "Campo de entrenamiento", práctico, realizando proyectos de cualquier tipo, para aprender, y mejorar las habilidades directivas, creación de negocios...etc.

Actualmente estoy como beneficiado en la JCI, y me parece muy interesante, por ésta asociación han pasado personajes como Kofi Annan, Taro Aso, Gerald Ford, Alberto de Mónaco, Jordi Pujol, etc.

Para más información os podéis dirigir a http://www.jci.cc/, http://www.jci.cat/, http://www.jciempresarisbarcelona.com/,

Blog de la asociación en la que soy beneficiario, http://jciempresarisbarcelona.blogspot.com/

PMI-MS Project

PMI-MS Project

La inversión en I+D+i es “insuficiente”

La inversión en I+D+i es “insuficiente”

Los empresarios catalanes tecnológicos suspenden al sector: la situación de las TIC en Cataluña es “más bien positiva” para el 44,3%, “fuertemente negativa” para el 37,7.

El I+D+i no está recibiendo las inversiones necesarias. Los empresarios catalanes del ámbito de las nueva tecnologías consideran que las cifras destinadas a este campo son “insuficientes” de forma global, suspendiendo a todos los agentes inversores.

La peor nota se la lleva la Administración: el gasto en I+D+i del sector público consigue un mediocre 3,5 sobre 10, tal y como concluye el informe Barómetro de las TIC 2009 que mañana presentará en Barcelona el Cercle Tecnològic de Catalunya y que contó con la participación de los empresarios TIC catalanes.

“Débil y muy frenado, esa es una de las características [del sector] aquí”, explica uno de los directivos encuestados. “Está muy fragmentado; todos creemos que sabemos hacer las cosas y todos queremos hacer las mismas cosas, y en lugar de unirnos, de juntar fuerzas, tenemos una tendencia a la fragmentación”, añade.

Los empresarios catalanes no sólo ven con malos ojos la inversión en I+D+i: tampoco aprueban con nota la situación general del sector TIC en la comunidad, que suspende por poco en la valoración general. La nota media sobre 10 no supera el 4,7: un suspenso alto, pero suspenso al fin y al cabo.

De hecho, para el 44,3% de los encuestados, el segmento catalán consigue una valoración “más bien positiva”, seguido de cerca por aquellos que lo ven bajo un prisma negativo. Para el 37,7% la situación es “fuertemente negativa” y para un 6,6 “muy negativa”, lo que arroja un balance final de un 44,3% de directivos que ven al sector de forma poco optimista.

El sector podría suspender por la mala situación de algunos de los elementos clave en su desarrollo. Los empresarios suspenden con un 4,5 las actuaciones políticas a favor del sector (a pesar de que un 36,1%, la cifra más alta considere que la legislación “más bien promueve” el mercado), con un 4,7 el uso del marketing y la promoción y tampoco aprueban la situación financiera (un 4,5, con predominio de los porcentajes que consideran “débil” o “muy débil” las cuentas de las TIC).

Como apunta uno de los directivos que participaron en el estudio, “el tema presupuestario, éste sí que es el gran reto. El grifo lo tienen las empresas madre”.

Fuente: Raquel C. Pico (siliconnews)

Retos Consultoría TIC 2009

Retos Consultoría TIC 2009

Dentro de un contexto de mercado cada vez más competitivo y globalizado, donde se pierden las fronteras territoriales de las naciones a través de Internet, el mercado de la consultoría se enfrenta de manera especial a una constante necesidad de adaptación eficiente.

En época de crisis o recesión, esta necesaria evolución exige además retos mayores como fruto de la depreciación de los servicios y la drástica reducción en inversión en la que, en la mayoría de las ocasiones, recaen las organizaciones. En este paradigma, el mayor compromiso en la obtención de resultados, así como la voluntad de que éste -el resultado- influya positivamente en la mejora del negocio, se configuran como los grandes retos para la consultoría TIC en este 2009.

De Perogrullo sería obviar que en los incipientes y siempre constantes retos de la consultoría se halla la necesidad de incorporar equipos multidisciplinares formados por profesionales altamente cualificados con un nivel de competencias propio de las necesidades del siglo XXI. Este capital, además, debe ser equilibrado en sus funciones y costes, pues de lo contrario el paquete retributivo impediría la posibilidad de ser competitivo frente a nuestros voraces competidores.

Pero el reto de seguir existiendo en el 2009 no se satisface con un buen equipo de profesionales. El compromiso, la adecuación a la situación del mercado y, sobre todo, el valor tangible, son los auténticos retos a los que se enfrenta la consultoría TIC.

La obtención de soluciones que influyan directamente en la cuenta de resultados acaricia el paladar de las organizaciones, cada vez más necesitadas de fórmulas que refloten su posicionamiento y nivel de ventas. La consultoría debe elevar su valor revalorizándose por el ROI (retorno de la inversión), garantizando proyectos de un coste variable en función del beneficio repercutido, donde el fijo es el mínimo e indispensable para acometer el desarrollo y medirnos en coste a nuestra competencia.

Los plazos deben ser hoy más que nunca cortos y sólo en los proyectos inevitablemente grandes debe medirse por etapas, permitiendo y garantizando la confianza del cliente y de los resultados a obtener a lo largo de la consecución del proyecto.

En definitiva la consultoría debe ser hoy estandarte de modernidad y de necesidad del resultado. El equipo, el compromiso, el conocimiento, la metodología, la marca e incluso el precio son variables indiscutibles, pero, hoy por hoy, no ciñen la decisión de un cliente a la hora de contratar una consultoría en época de crisis.

El valor tangible y las métricas de ROI para obtener beneficio del trabajo encomendado son los auténticos retos que acompañarán a las consultoras en un mercado marcado por la recesión y la pérdida de posicionamiento en la mayoría de marcas y organizaciones. Sólo el trabajo bien hecho tiene unos claros resultados asociados y tangibles.

La Crisis de la Web 2.0

La Crisis de la Web 2.0

"Los ciclos económicos o fluctuaciones cíclicas de la actividad económica, pueden definirse como las oscilaciones de la expansión a la contracción de la economía, que ocurren entre crisis sucesivas". Esta es la definición de ciclo económico que aparece publicado en la Wikipedia. Así mismo los ciclos económicos se caracterizan por constar de 4 fases: Ascenso, Descenso, Recesión y Reactivación.

De nuevo las bases de la economía vuelven a estar de radiosa actualidad, y una vez más Internet no es ajeno a este fenómeno. Tal como ocurrió en la primera etapa comercial de Internet, antes del pinchazo de la burbuja.com, y por tanto con anterioridad al fuerte ajuste producido en este sector se vuelven a dar algunos características similares, aunque esta similitud por supuesto ni siquiera se acerca a lo vivido en aquel momento, Internet es ya un sector mucho más maduro, y aquellos errores han evitado que se volviese a crear algo similar.

Sin embargo algunos factores como la sobrevaluación de ciertas acciones de empresas tecnológicas si se ha dado en algún sector de Internet, como es el caso de las redes sociales, sin salir de nuestro país recientemente Qualitas Equity Partners, la firma de capital riesgo participada por la familia Polanco, cierra la compra del 20% de Tuenti, la red social para jóvenes que más éxito tiene en la actualidad. Esta operación supone una valoración cada usuario registrado en Tuenti en 28 €. Si nos centramos en países como EE.UU. el boom de las redes sociales ha sido extraordinario y hace meses que este sector está atravesando dificultades. ¿Cuántas redes sociales horizontales sobrevivirán? después de alcanzar algunas valoraciones estratósféricas como ocurrió con la red social líder Facebook, así el valor de Facebook alcanzó los 10.000 millones de dólares, lo que significa valorar esa compañía en la mitad que Yahoo, y 66 veces los ingresos de 2007.

Serán las redes sociales lo que fueron los marketplaces respecto de la primera burbuja de Internet, y es que una vez más las tremendas expectativas que se han generado alrededor de las redes sociales, han provocado el crecimiento de los precios de estos proyectos, entonces se producen ventas de empresas o parte estas empresas con un valor irracional, esto coincide con la aparición de nuevos millonarios que se convierten en modelo a seguir en un mercado distorsionado, olvidándose de las máximas económicas y de perseguir un equilibrio financiero en la creación de cualquier compañía, lo que provoca el nacimiento de un gran número de proyectos, esta fase del ciclo se mantiene hasta que se provoca una crisis en el sistema que tarde o temprano acaba reventando por los excesos, en este caso provocado por la crisis de las hipotecas subprime y la burbuja inmobiliaria en España, en ese momento se empieza a cerrar el flujo de crédito barato, los bancos cierran el grifo, los inversores privados se retiran, el capital riesgo deja de invertir, y si a esto le añadimos que en contextos de crisis las empresas lo primero que hacen es recortar los presupuestos publicitarios, -- aunque el peso de Internet cada vez es mayor en el reparto del paste publicitario, esto ocurre dentro de un contexto de cada vez menor inversión publicitaria en general --, lo que acabará afectando a otra importante fuente de financiación de los portales de Internet, en muchos casos la única.

En este momento muchos proyectos e inversiones en Webs de Internet, por otra parte centradas en adquirir a toda costa millones de usuarios, dejan de ser rentables. En el caso de las redes sociales esto se ve agravado por el mal funcionamiento como soporte publicitario de las redes sociales horizontales o agregadores de noticias como Digg, meneame o Fresqui o aplicaciones como Twittter donde la intencionalidad del usuario no es buscar publicidad o comprar algo, a esto se añade la difícil segmentación en contenidos para anunciantes tan necesaria para los anunciantes.

Como dice Máximo Kinast, destacado columnista de WinRed en su artículo ¿Por qué Facebook no funciona?: "porque parte de la misma estúpida idea con que nació Terra. Mientras más variada sea la oferta, más gente nos visitará y los anunciantes ganarán más dinero porque venderán más." Máximo defiende que es una cuestión de marketing, lo que funciona en la red es 'one selling proposition' algo que si se da en portales verticales o redes especializadas.

Por otra parte empiezan a escucharse voces que auguran que muchos blogs y redes de blogs desaparecerán próximamente, un sector superado por el exceso de publicidad y la huída de las estrellas, castigado por Google y falto de originalidad.

Teniendo en cuenta lo comentado, parece que poco a poco entramos en la fase de descenso de esta etapa de Internet, calificada como Web 2.0, estos días leíamos como Mobuzz TV, la televisión online pionera en España, está a punto de cerrar, sin tener claro un modelo de negocio que le asegure unos ingresos operativos, y tal como asegura su fundador Anil de Mello "Mantener la programación de Mobuzz cuesta 50.000 euros al mes y ahora mismo no podemos aguantar hasta la próxima ronda de financiación", solo las donaciones de los usuarios de Mobuzz puede evitar que sea tal vez la primera víctima.

En este contexto es necesario reflexionar sobre nuestro modelo de negocio, tal vez sea necesario cambiar de estrategia, como en su día hizo Amazon, una de las iniciativas que ha sobrevivido y se ha consolidado tras la primera burbuja de Internet, o simplemente centrarse en sobrevivir, priorizar y optimizar costes e inversiones.

Fuente:Winred.com